2022年之WEB开发新基准
总结:
2022年网页开发的基准将会是:性能方面的低规格Android设备，网络标准方面的Safari(从两年前迄今为止的版本)，以及网络方面的4G。一般来说，网络并没有很好地满足这些需求，特别是在性能方面，过度依赖JavaScript等因素阻碍了我们网站的性能。
你好!我是Alan Dávalos, LINE的前端工程师。你可能认为这篇文章的只是标题党，但请耐心听我讲一段时间，我保证这是值得的。主要原因是，在2021年至2022年之间，网络发生了一些重大变化，这些变化影响了我们应对网络发展的整体方式。
所以，今天我想通过分析许多不同的数据点来剖析这些变化，以及我们作为web开发者如何适应它们。
# 2021年最大的变化是ie浏览器的"淘汰"
虽然2021年发生了很多变化，但没有一个比IE正式"退役" (opens new window)更大的变化。微软在2021年5月宣布了这一消息，到8月，包括微软365在内的许多微软产品都正式放弃了对IE的支持。IE的正式退役日期定于2022年6月，但还有其他几个原因可以让我们认为IE现在已经完全"淘汰"了。
# 一些大型网站放弃了对IE的支持
在微软宣布这一消息后，许多其他项目开始放弃对IE的支持。这其中包括很多包含海量用户的大型网站:
例如，谷歌搜索在2021年10月放弃了对IE的支持。
此外，约33%的网络用户使用的WordPress还宣布，他们会在2021年7月发布的WordPress 5.8版本中放弃对IE的支持。
# IE目前的市场份额
IE的市场份额在2021年大幅下降
2021年全球浏览器市场份额分布:
在全球范围内，IE目前的市场份额不到0.5%。即使是在IE市场份额高于其他国家的日本，IE的市场份额也接近2%，并且有下降的趋势。
# web开发的新基准
到目前为止，由于IE的市场份额，我们一直支持它。但是现在，基本上没有什么好的理由继续支持IE。然而，这带来了一个新问题，IE是许多工具的支持基线。IE的开发已经停止了很长一段时间，所以它所支持的web标准与现代浏览器所支持的web标准非常不同。
现在IE消失了，基线变得模糊了。因此，我将通过分析我们用户设备的当前状态来定义一个新的基线。
# 用户的设备和浏览器
浏览器和操作系统的市场份额
让我们以不同的格式来看看浏览器市场份额图表:
这里我想强调几种趋势,换言之，我们至少需要支持以下3个浏览器引擎:
Chrome, Edge -- 三星网络浏览器和Opera的基础。
Gecko -- Firefox的基础。
WebKit -- Safari的基础。
# 浏览器与网络标准的一致性
在不同的浏览器中，最影响web开发的部分是它们实现了不同的web标准。如上所述，我们应该关注3种浏览器引擎。那么，让我们来看看这些不同的浏览器是如何实现网络标准的。检查这些差异的最简单的方法是使用下面的Web平台测试数据。
Web平台仅一个浏览器不通过测试(其余浏览器测试通过):
注:上图来源为:"Browser Specific Failures" (opens new window)-摘自2021年12月4日
此图表显示了仅在一个浏览器中失败的Web平台测试的数量。换句话说，其他两个浏览器已经实现了多少特性。
很明显我们可以看到，只有Safari还没有实现的网络标准的数量比Firefox和Chrome多很多倍。准确地说，是火狐的2.4倍，Chrome的4.7倍。
此外，我们还应该考虑到Safari和iOS之间的密切关系。具体来说，有两点:
- 其他移动浏览器的更新独立于操作系统，而Safari只有在iOS更新时才会更新。新版本的iOS不再支持的iOS设备不能更新到最新版本的Safari。
- iOS中的所有浏览器都是基于Webkit的:iOS中有Chrome和Firefox版本，但它们使用的引擎与iOS中的Safari相同。这是因为苹果有一条规定，即所有iOS浏览器都必须使用Webkit。 iOS和Safari之间的这种关系也意味着我们必须检查iOS版本的市场份额随着每一个新的主要iOS版本的发布而发生的变化。
iOS主要版本的季度市场份额如下:
为了更深入地了解每个iOS版本的市场份额是如何变化的，让我们来看看iOS 12在过去2年的市场份额变化:
从2019年第一季度到第三季度，iOS 12的份额逐渐增长，但随着iPhone 11和iOS 13在第三季度的发布，这一数字直线下降。
从那以后，iOS 12的市场份额在接下来的一年里下降到了20%以下。
然后，在2020年第三季度iPhone 12和iOS 14发布后，iOS 12的份额急剧下降，到2021年第二季度，它的份额微不足道。
在iOS 12上发生的同样的情况也出现在后来的版本13和14上。
综上所述，我们可以肯定的是，在过去2年里，iOS市场份额将持续占据90%以上。换句话说，我们只需要支持过去两年发布的Safari版本。
# 移动端网络状况分析
到目前为止，我们主要谈论的是设备和浏览器，但现在让我们看看一个对用户体验有很大影响的因素，而web开发者却没有影响:网络连接。
当连接到Wi-Fi网络时，连接基本上是稳定的，但移动网络就不是这样了。让我们来看看移动网络的现状。
# 3G 和 4G
当使用诸如Lighthouse之类的测试工具时，网络可以被用来模拟3G，但是最近全球的移动网络都发生了变化。根据Opensignal 2020年5月的一份报告 (opens new window)，全球4G的平均可用性为86.8%。因此，我们可以放心地假设，全球大多数用户都可以接入4G网络。
# 5G
然而，5G网络仍远未成为现实。根据Opensignal 2021年11月的一份报告 (opens new window)，全球5G可用性最高的国家只有韩国的29.1%。
新的基准线是什么?
考虑到上述所有数据，web开发的新基线将是:
Safari是网络标准的基准:我们开发的站点必须在至少2年前的Safari版本中运行。
低端Android设备是性能的基准:低端Android设备在过去几年中几乎没有进步，所以我们必须确保我们的站点具有不错的性能。
4G是网络的基准:近年来，全球范围内的移动网络已经变得更快、更稳定。
# 我们在多大程度上满足了用户需求?
我们已经成功地定义了构成基线的3个部分，但这还不够。我们需要看看我们在多大程度上满足了用户的需求。然而，深入的分析会为不同的项目带来不同的结果。
考虑到这一点，我将进一步分析整个网络。幸运的是，我们有一个很好的数据来源，2021年网络年鉴 (opens new window)。这是由HTTP Archive创建的年度报告。在这份报告中，他们分析了超过820万个网站，创建了24个章节。在本文中，我们将从这些章节中选取一些数据，看看当前的网络与上述定义的基线匹配得如何。
# 2021年网站的中位数
2021年的网站体积的中位数为1923 KB。如果我们按文件类型划分大小，我们可以看到图像和JavaScript占据了大部分的比例。
按文件类型划分的网站size中位数:
通过上面这些数据，我们很清晰地看到在图像处理(image资源)占据了最大的比例，但我们更应该特别注意JS的大小。因为处理图像不像处理JS那么复杂。图像基本上可以被渲染，只要他们被下载，但JS需要被解析和执行。所以，一般来说，JS的处理会占用更多的资源。
此外，根据Alex Russell上面提到的文章 (opens new window)，当在4G网络上测试一个低级Android设备时，一个网站要保持良好的性能，需要100kb的HTML和CSS以及350kb的JS。换句话说，当前的中位数站点在HTML和CSS方面满足了性能预算，但在JS方面却远远超过了预算。
# HTML和CSS的使用情况分析
网页年鉴中有一章同时介绍了HTML (opens new window)和CSS (opens new window)，其中包含了大量的信息。我想强调几个关键的数据点，我认为它们可以用来举例说明我们目前是如何使用HTML和CSS的。
# HTML
让我们先来谈谈HTML，目前有112个未弃用的HTML元素 (opens new window)。但是页面中使用的HTML元素的中位数是31。显然，没有必要在所有页面中使用每个元素，但是这31个元素包括诸如html标签、body标签和script标签。这意味着我们用来显示内容的元素数量实际上更少了。
在最常用的HTML元素列表中,div标签第一名，span 标签第三名,p标签第七名。此外，页面有98.9%的概率是div标签,div肯定是最常用来显示内容的元素。
相比之下，main元素被使用的概率只有27.9%。这之所以重要，是因为，相比于aside以及header等其他元素，main元素是没有应用特殊样式但具有语义化的元素之一。换句话说，main标签的使用可以作为一个指示器，指示有多少页面主动使用语义化元素。这就是27.9%这个数字如此重要的原因。
# CSS
对于CSS的使用，我认为有一个数据点可以很好地总结CSS的使用，这就是现代布局特性的使用:Flex和Grid的使用率。
Flex和Grid的使用率:
正如你所看到的，虽然71%的页面使用了Flex，但只有8%的页面使用了Grid。造成这种差异的最大原因在于对IE的支持。IE只支持旧的Grid规范 (opens new window)，所以想要支持IE的页面必须考虑到这一点。CSS特性不能像JS特性那样容易填充。这可能是许多开发人员放弃使用Grid的主要原因。然而，现在我们可以减少对IE的支持，许多例如Grid之类的现代CSS特性就可以考虑使用。
# 性能
目前最常用的性能测量方法是通过测量核心指标Web Vitals (CWV) (opens new window)。采用这个测量方法的原因是CWV被用作谷歌搜索的排名因素可能是最大的一个 (opens new window)。让我们看看网络在CWV方面的表现如何。
CMV分数良好的页面百分比:
总的来说，性能不是很好，超过一半的页面CWV分数很差。考虑到不同设备之间的CPU性能差异，移动端页面在12%的时间里比桌面页面得分低似乎是合理的。这个结果也与大多数站点的JS体积大小高于性能预算的事实相一致。
我们还可以在下一张图表中看到，性能直接影响用户的数量:
我们可以看到，良好的CWV分数与浏览量之间存在相关性。也许部分是受CWV是谷歌搜索排名因素的影响。在浏览量排名前1000位的网站中，有37%的CWV得分良好，而总体得分为32%。当查看排名前1万或10万的网站时，我们可以看到，在浏览量方面排名更高的网站往往有更好的性能。
可以毫不夸张地说，提升网站性能是我们可以直接增加项目收入的方法之一。
# JS库和框架
到目前为止，我们已经看到我们服务的JS数量对我们网站的性能产生了不良影响。大多数使用大量JS的项目都会以某种方式使用库或框架。那么，让我们来看看这种过度依赖框架库的选择可能带来的后果。
# JS库和框架的使用情况
根据网络年鉴的JS章节 (opens new window)，使用最多的库是jQuery，使用率为84%。我们上面提到的大约33%的网站都使用WordPress，这是其中一个重要原因。
在众多框架中，React最受欢迎，占8%。但是如果你认为其他框架甚至没有达到4%的标志，那么你可以说其他框架的使用仍然是占据极少数。
# 比较框架性能
虽然框架仍然是少数，但我们有足够的数据来比较最流行的框架的性能。本节的数据来自Tim Kadlec的这篇2020年的文章 (opens new window)。
首先，我们将使用React、Angular、Vue和jQuery的站点的JS大小与常规数据进行比较：
总体数据和jQuery的中位数分别为414KB和430KB。这个数字接近中位数为2021。
然而，Vue和React的中位数都在690 KB左右。超过总中位数250 KB。
角度更高，达到1066KB，第一个数字超过1MB。
即使看第10个百分位，情况也是相似的：第10个百分位的总大小是93KB，jQuery是110KB，Vue是245KB，React是348KB，Angular是445KB。
换句话说，即使是使用JS最少的框架的站点，也几乎无法达到上面设定的性能预算。
当然，虽然JS大小是性能的一个重要指标，但它肯定不是全部。现在，让我们深入了解一下这些站点在实际设备中的表现。
为了公平起见，不包括使用多个库或框架的站点。
看看jQuery和Vue的中值时间，它们分别是2.3秒和3.2秒。通过简单的数学计算，尺寸差的比率与时间差的比率非常接近。
然而，React和Angular并没有遵循同样的趋势。Angular的中值时间是3.7秒，而React的中值时间要慢一些，为10.1秒。
很明显，在比较JS库时，大小并不是唯一重要的指标。
# 比较静态站点(SSG)中的框架性能
框架经常用于创建单页应用程序（SPA），但也用于创建静态站点。让我们比较一下使用框架的静态站点生成器（SSG）和不使用JS框架的SSG的性能。我们将比较实际可检测到使用情况的排名前五的SSG框架 (opens new window)。
按SSG划分的js资源体积中位数:
基于React的Gatsby和Next.JS体积中位数和基于Vue的Nuxt.js的大小都在700 KB左右，这个数字与React和Vue的中位数大致相似。
相比之下，基于Go的Hugo和基于Ruby的Jekyll分别为177KB和129KB。
基于JS框架的SSG比不基于JS的SSG提供的JS平均超过500KB。
既然我们提到了JS大小并不是性能的全部，那么让我们看看移动端网站CWV分数之间的差异:
Next.js和Nuxt。js的CWV得分低于15%。
Gatsby占比高，为21.9%。
非基于框架的Hugo和Jekyll在CWV方面的得分分别为31.8%和34.3%。
不使用JS框架的SSG的CWV分数百分比高于总体平均水平。
# 通过实验测试比较框架性能
到目前为止，我们已经查看了三种最流行的框架的使用数据，并比较了它们的性能。然而，除了这三个框架之外，还有许多其他框架。考虑到这一点，让我们将这三个框架与其他一些框架进行比较，这些框架可能没有被充分使用，无法出现在网络年鉴中，但它们是最受欢迎的框架之一。
注：
这些比较的数据来自实验室测试，在实际项目中使用时，性能可能会有所不同。
添加到比较中的框架是作者认为最具动力的框架之一。通过查看每次比较的数据源，可以看到与其他框架的比较。
上表将框架与手动优化的Vanilla JS实现进行了三个主要方面的比较:DOM操作、启动和内存分配。从中我们可以观察到以下几点:
React和Angular的平均性能是Vanilla JS的两倍。
相比之下，Vue实际上更接近Preact和Stencil，平均为1.5倍。这个结果和我们在Web年鉴中看到的报告之间的差异的主要原因可能是由于Vue在3.0版本发布时的性能改进。
最后，Solid、Lit以及Svelte都是1.2倍左右。它们的性能都非常接近Vanilla JS版本。
IE显然影响了这些结果。你可能会问:“为什么要提IE?”为此，我们必须回顾一下框架和JS标准的历史。
可以说，Edge在2015年发布后，IE的新开发基本上停止了。那一年也是ES 2015(或ES6)标准出台的一年;这可以说是JS历史上最大的革命。ES 2015包含了Promise和箭头函数等功能。后来的版本开始向JS添加更多的特性，可以用更少的代码实现更多的事情。换句话说，因为ES 2015之前的世界开发的东西与为ES 2015以后的世界开发的东西有很大的不同。
在上表中，性能最差的是Angular和React。这两个框架和Vue是唯一在2015年之前发布第一个版本的框架。换句话说，他们的表现差异可以归因于他们发展的时代。这条规则似乎不适用于Vue的原因是，如上所述，Vue 3.0为了提高性能改变了很多内部代码。
还有一种方法可以完全理解上面提到的区别:比较Solid、Preact和React。Solid和Preact深受React的影响。在Preact的例子中，他们甚至有一个兼容模块来使用React代码作为Preact代码。但从上面的表中可以看出，Solid和Preact在每一个参数上都优于React。这意味着React的性能问题并不在于它的理念或你为React编写代码的方式。它们存在于React的内部。确切地说，在React的虚拟DOM和合成事件系统实现中，这两者都需要对IE进行很多考虑。Preact和Solid更喜欢使用默认api，而不是使用现代浏览器中可用的api。这可能是性能差的最大原因。
最后，让我们再看一张图表。
使用相同库的30个组件的包大小:
这个图表比较了前面提到的大多数框架的不同指标:用同一个框架创建30个组件时的包大小。通过这种比较，我们可以模拟这些框架在创建完整应用程序时是如何工作的。
React最终以45.45 KB的大小再次成为最大的，但就实际开发代码而言，它是最小的，只有9.26 KB。只是因为React框架自身的体积比其他框架体积大而已。
Vue在3.0版本中做了很多改进，但它的大小仍然是其他库的两倍，为32.65 KB。
其他框架最终的大小都差不多，都在14-18 KB范围内。
# 可访问性(Accessibility,简称a11y)
我们已经讨论了很多关于用户设备的内容，现在让我们来谈谈用户本身。据世界卫生组织统计，有超过全世界约有10亿人患有不同程度的残疾 (opens new window)。有许多不同类型的残疾，但其中许多都会影响用户与设备的交互方式。我们通常使用术语无障碍(a11y)来指确保残疾用户能够完全与我们的网站交互所需要的操作。
然而，a11y并不仅仅适用于残疾人。促进a11y的行动对每个用户的用户体验都有积极的影响。造成这种情况的主要原因是情境障碍。一些情景障碍的例子包括试图用一只手在吃东西或喝东西时使用手机，或者设备设置在一小时后在屏幕上设置一个黑白滤镜来改善睡眠质量。面对这些情境障碍的用户将能够像往常一样使用在设计时考虑到a11y的页面。
此外，网站若是存在糟糕可访问性也可能招致法律问题。根据法律的规定，用户甚至可以起诉那些"糟糕可访问性"的网站。一些著名的案例包括碧昂丝和达美乐披萨(Domino’s Pizza)因视觉障碍用户无法访问而被起诉 (opens new window)。因此，没有合适的a11y也可能会让你付出惨痛代价。
# 网络的可访问性如何?
现在让我们来看看网络的可访问性。为此，我们将从《网络年鉴》的a11y章节 (opens new window)中取出一些具有代表性的数据。如果你想要更深入地了解，这里还有更多的数据点。
77.8%的网站背景和字体颜色对比度不佳。这意味着，一些视力受损的用户和使用上面提到的过滤器的用户可能不能完全使用80%的网络。
29.4%的网站阻止缩放。现在有些浏览器忽略了这个设置，但这仍然是一个很大的数字。
42%的网站标题排列不当。例如使用h2元素而不使用h1元素。这种无序可能会导致问题，特别是对于使用辅助技术的用户。
29%的网站使用role="button"。有些人可能认为拥有这个role="button"和一个事件监听器就足够了，但是按钮还必须响应键盘事件并具有适当的焦点处理。虽然您可以使用JS实现这一点，但如果您只使用button标签的话，则根本不需要JS。
32.7%的站点有没有可访问标签的输入元素。换句话说，它们没有关联的标签元素、aria-label属性或其他任何东西。这是令人担忧的，因为你可能会因此而承担损失。例如，如果信用卡输入没有标记，可能会有想买东西但不知道在哪里编写所需信息的用户。
# 结论
最后让我们看一下结论:
WEB开发并没有百分百满足用户的需求:特别是在性能和其他方面。
WEB开发过度使用JS:无论是在依赖关系中还是在我们自己的代码中。
WEB开发没有充分使用HTML和CSS:这部分是由于IE的支持，但现在我们不需要支持IE，有许多特性变得可用。
这里有一些建议，可以帮助那些想要改善WEB体验和性能的前端工程师们:
如果你可以用CSS做一些事情，那就用CSS:有很多以前只能用JS完成的事情，现在只能用CSS完成。这样做可以在一定程度上减少JS代码。
解放思想，不要为旧的思维定式所禁锢:在做技术选型，需要拓宽视角。与旧的工具相比，许多新的工具具有更好的性能，并且不是每个项目都需要SPA。一些非基于框架的SSG技术，如Hugo、Jekyll或11ty，也许会更适合这些场景。
为现代浏览器构建:放弃IE支持，将构建目标设置为ES 2017甚至2018。这样做可能会让你的Bundle大小减少20%以上。
全面的思考问题:在规划和设计阶段就将所有因素考虑在内是最理想的方案。从提高对比度、字体大小、语义化HTML的使用和键盘导航等方面入手，可以带来很明显的改善效果。