【转载】2022 年 Web 开发的基线性能方面的低规格 Android 设备，Web 标准方面两年前的 Safari，

转载自engineering.linecorp.com/en/blog/the…

TL;DR： 2022 年 Web 开发的基线是：性能方面的低规格 Android 设备，Web 标准方面两年前的 Safari，以及网络方面的 4G。总体而言，网络无法正确满足这些需求，尤其是在性能方面，过度依赖 JavaScript 等因素阻碍了我们网站的性能。

2021 年发生的最大变化～Internet Explorer 的退役

2021 年发生了许多变化，但没有一个比 Internet Explorer (IE) 的正式退役那么大。微软于 2021 年 5 月宣布了这一消息，到 8 月，包括 Microsoft 365 在内的许多微软产品已正式放弃对 IE 的支持。IE 的正式退役日期定于 2022 年 6 月，但还有其他几个原因可以让我们认为 IE 现在已完全退役。

一些最大的网站不再支持 IE

在微软宣布之后，许多其他项目开始放弃对 IE 的支持。其中包括大多数互联网用户与之互动的网站。

例如，谷歌搜索在 2021 年 10 月放弃了对 IE 的支持。

首席软件工程师兼工程总监 Malte Ubl 在 2021 年 10 月 2 日的推文中提到 Google 搜索放弃了对 IE 的支持。

推特@cramforce

在日本，雅虎！JAPAN 于 2021 年 9 月宣布将 IE 设置为非推荐浏览器（日文网站）。

摘自雅虎！ JAPAN 关于他们推荐的浏览器的页面。下一个报价有完整的翻译。

雅虎！JAPAN 将 Internet Explorer 11 作为推荐的浏览器。但随着微软雅虎宣布终止对 Internet Explorer 的支持！JAPAN 决定从 2021 年 9 月 7 日起将 Internet Explorer 11 设置为不推荐的浏览器。

此外，您仍然可以使用 Internet Explorer 11 来使用我们的某些服务，但您可能会遇到页面无法正常运行或呈现的问题。我们还建议任何使用 Internet Explorer 11 的用户使用我们推荐的其他浏览器，因为 Internet Explorer 11 的正式终止支持日期即将到来。

此外，约有 33% 的 Web 使用的WordPress也宣布将在 2021 年 7 月发布的WordPress 5.8 版中放弃对 IE 的支持。

今年 7 月发布 WordPress 5.8 时，将不再支持 Internet Explorer 11。

IE目前的市场份额

上面的公告没有等到 IE 正式退休是有充分理由的。IE 的市场份额在整个 2021 年急剧下降。

2021 年 11 月全球浏览器市场份额饼状图。更详细的解释如下。

Statcounter 在 CC BY-SA 3.0下使用的 “全球浏览器市场份额”的图表衍生品。此图由 Alan Dávalos在CC BY-SA 3.0下获得许可。

2021 年 11 月日本浏览器市场份额的饼图。更详细的解释如下。

Statcounter 在 CC BY-SA 3.0下使用的 “日本浏览器市场份额”的图表衍生品。此图由 Alan Dávalos在CC BY-SA 3.0下获得许可。

在全球范围内，IE 目前的市场份额不到 0.5%。而即使是在IE市场占有率高于其他国家的日本，IE的市场占有率也接近2%，并有下降趋势。

Web 开发的新基线

到目前为止，由于 IE 的市场份额，我们一直在支持它。但是现在，基本上没有充分的理由继续支持 IE。但是，这带来了一个新问题，IE 是许多工具的支持基线。IE 的开发大多在很久以前就停止了，因此它支持的 Web 标准与现代浏览器支持的 Web 标准非常不同。

现在 IE 消失了，那个基线变得模糊了。因此，我将通过分析用户设备的当前状态来承担定义新基线的任务。

用户的设备和浏览器

浏览器和操作系统的市场份额

让我们看一下不同格式的浏览器市场份额图表。

2021年11月全球浏览器市场份额的条形图。更详细的解释如下。

Statcounter 在 CC BY-SA 3.0下使用的 “全球浏览器市场份额”的图表衍生品。此图由 Alan Dávalos在CC BY-SA 3.0下获得许可。

2021 年 11 月日本浏览器市场份额的条形图。更详细的解释如下。

Statcounter 在 CC BY-SA 3.0下使用的 “日本浏览器市场份额”的图表衍生品。此图由 Alan Dávalos在CC BY-SA 3.0下获得许可。

我想在这里强调两个趋势：

我们需要支持 3 个浏览器引擎
1. Chromium，Chrome、Edge、三星互联网浏览器和 Opera 的基础。
2. Gecko，Firefox 的基础。
3. WebKit，Safari 的基础。
日本的 Safari 用户比例高于全球平均水平。

在查看以下图表时，很容易理解后者的原因。

2021 年 11 月全球移动操作系统市场份额饼状图。更详细的解释如下。

Statcounter 在 CC BY-SA 3.0下使用的 “全球移动操作系统市场份额”的图表衍生品。此图由 Alan Dávalos在CC BY-SA 3.0下获得许可。

2021 年 11 月日本移动操作系统市场份额的饼图。更详细的解释如下。

Statcounter 在 CC BY-SA 3.0下使用的 “日本移动操作系统市场份额”的图表衍生品。此图由 Alan Dávalos在CC BY-SA 3.0下获得许可。

如您所见，Android 约占全球移动操作系统市场份额的 70%，而 iOS 则为 28%。另一方面，在日本则相反，Android 仅占 33% 的市场份额，而 iOS 为 66%。

CPU性能差异

操作系统的差异不仅在于软件方面，还意味着硬件方面的差异。最大的一个可以认为是CPU性能。

比较 2011 年至 2020 年发布的代表性 iOS 和 Android 设备的多核 CPU 性能的条形图。更详细的解释如下。

比较 2011 年至 2020 年发布的代表性 iOS 和 Android 设备的单核 CPU 性能的条形图。下面有更详细的说明。

资料来源： “2021 年移动性能不平等差距”——Alex Russell

如上图所示，iOS 设备在过去 10 年中每年的 CPU 性能得分都最高。相比之下，高端安卓设备的结果有些相似，但中端和低端设备的表现要差得多。引用文章作者 Alex Russel 的话，上面两张图表来自：

2020 年的高端 Android 具有 iPhone 8 的单核性能，这是 17 年第三季度发布的手机
中等价位的 Android 比 2014 年的 iPhone 6 稍快
低端 Android 终于从 2012 年赶上了 iPhone 5

浏览器与 Web 标准的一致性

不同浏览器对 Web 开发影响最大的部分是它们对不同 Web 标准的实现。如上所述，我们应该关注 3 个浏览器引擎。那么，让我们来看看这些不同的浏览器是如何实现网络标准的。检查这些差异的最简单方法是使用以下 Web 平台测试数据。

比较仅在一个浏览器中失败的测试数量的条形图。更详细的解释如下。

来源： “浏览器特定故障” ——摘自 2021 年 12 月 4 日

此图表显示了仅在一个浏览器中失败的 Web 平台测试数量。换句话说，其他两个浏览器已经实现了多少功能。

一个事实在这里变得很明显，只有 Safari 没有实现的网络标准的数量是 Firefox 和 Chrome 的许多倍。准确地说，是 Firefox 的 2.4 倍，是 Chrome 的 4.7 倍。

此外，我们还应该考虑到 Safari 和 iOS 之间的密切关系。具体来说就是这两点：

其他移动浏览器独立于操作系统更新，而 Safari 仅在 iOS 更新时更新。较新版本的 iOS 不再支持的 iOS 设备无法更新到最新版本的 Safari。
iOS 中的所有浏览器都基于 Webkit：iOS 有 Chrome 和 Firefox 版本，但它们使用与 iOS 中的 Safari 相同的引擎。这是因为 Apple 指南中提到所有 iOS 浏览器都必须使用 Webkit。

iOS 和 Safari 之间的这种关系也意味着我们还必须检查 iOS 版本的市场份额如何随着每个新的主要 iOS 版本发布而变化。

折线图显示了从 2019 年到 2021 年 iOS 主要版本的市场份额的季度变化。更详细的解释如下。

Statcounter 在 CC BY-SA 3.0下使用的 “Mobile & Tablet iOS Version Market Share Worldwide”的图表衍生品。此图由 Alan Dávalos在CC BY-SA 3.0下获得许可。

为了更深入地了解每个 iOS 版本的市场份额如何变化，让我们来看看过去 2 年 iOS 12 的市场份额是如何变化的：

从 2019 年第 1 季度到第 3 季度，iOS 12 的份额逐渐增长，但随着 iPhone 11 和 iOS 13 在第三季度问世，这一数字直线下降。
从那时起，iOS 12 的份额在接下来的一年中下降了 20% 以下。
然后，iPhone 12 和 iOS 14 在 2020 年第三季度一出，iOS 12 的份额就出现了如此急剧的下降，到 2021 年第二季度它的份额可以忽略不计。
发生在 iOS 12 上的相同模式在后来的版本 13 和 14 中也观察到了。

总之，我们可以有把握地假设，超过 90% 的 iOS 市场份额将不断由过去 2 年发布的主要版本组成。也就是说，我们只需要支持最近 2 年发布的 Safari 版本即可。

手机网络

到目前为止，我们主要讨论的是设备和浏览器，但现在让我们来看看对 Web 开发人员没有影响的 UX 有很大影响的因素之一：网络连接。当连接到 Wi-Fi 网络时，连接大部分是稳定的，但对于移动网络则不能这样说。让我们来看看移动网络的现状。

3G 和 4G

使用 Lighthouse 等实验室工具时，网络被束缚以模拟 3G，但全球移动网络最近发生了变化。根据 Opensignal 2020 年 5 月的一份报告，全球 4G 平均可用性为 86.8%。因此，我们可以放心地假设大多数用户都可以访问全球 4G 网络。在测试的国家中，日本的 4G 可用性最高，为 98.5%。

5G

然而，5G 网络仍远未成为现实。根据 Opensignal 2021 年 11 月的一份报告，全球最高的 5G 可用性仅为韩国的 29.1%。

新的基线是什么？

考虑到上述所有数据，Web 开发的新基线将是：

Safari 是网络标准的基准：我们开发的网站必须在 Safari 版本中运行至少 2 年。
低端 Android 设备 是性能的基准：低端 Android 设备在过去几年中几乎没有进步，因此我们必须确保我们的网站具有超级性能。
4G 是网络的基准：近年来，全球移动网络变得更快、更稳定。

我们在满足用户需求方面做得如何？

我们已经成功定义了构成基线的 3 个部分，但这还不够。我们需要看看我们在满足用户需求方面做得如何。然而，深入的分析会为不同的项目带来不同的结果。因此，在 LINE 中谈论特定项目对大多数人来说并没有那么大的帮助。

考虑到这一点，我将深入分析整个网络。幸运的是，我们有一个很好的数据源， Web Almanac 2021。这是由 HTTP 存档创建的年度报告。在其中，他们分析了超过 820 万个站点以创建 24 个章节。在本文中，我们将从其中一些章节中获取一些数据，以了解当前 Web 与上面定义的基线的匹配程度。

2021年网站中位数

2021 年网站的中位数为 1,923 KB。如果我们按文件类型分隔大小，我们可以看到图像和 JavaScript (JS) 构成了大部分大小。

按文件类型显示 2021 年中位网站权重的条形图。更详细的解释如下。

资料来源： “页面权重” – Web Almanac 2021

查看这些数据，很容易关注图像，因为它们是最重的，但我们应该特别注意 JS 大小。最大的原因是处理图片不像处理JS那么复杂。图片基本上一下载就可以渲染，但是JS也需要解析和执行。所以，一般来说，JS处理占用资源比较多。

此外，根据上面提到的 Alex Russell 的文章，在 4G 网络上测试低端 Android 设备时，网站保持良好性能的预算是 100 KB 的 HTML 和 CSS 以及 350 KB 的JS。换句话说，当前的中位站点在 HTML 和 CSS 方面满足了性能预算，但在 JS 方面却远远超过了它。

HTML 和 CSS 使用

Web Almanac 有一章关于标记和 CSS ，其中包含大量信息。我想强调一些我认为可以用来举例说明我们当前如何使用 HTML 和 CSS 的关键数据点。

HTML

我们先来说说 HTML，目前有 112 个未弃用的 HTML 元素。但是页面中使用的 HTML 元素的中位数是 31。显然没有必要使用所有页面中的每个元素，但这 31 个元素包括诸如 <html>、 <body>和等元素<script>。这意味着我们用于实际显示内容的元素数量实际上更少。

在最常用的 HTML 元素列表中， <div> 第 1 位、 <span> 第 3 位和 <p> 第 7 位。而且，页面有 <div> 元素的概率是98.9%；它绝对是显示内容最常用的元素。

相比之下，该 <main> 元素被使用的概率仅为 27.9%。这很重要的原因是 <main>，与和等其他元素一起 <aside> ， <header>是没有应用特殊样式但具有语义含义的元素之一。换句话说， <main> 可以将的使用作为有多少页面主动使用语义元素的指标。这就是为什么 27.9% 的数字如此重要的原因。

CSS

对于 CSS 的使用，我认为有一个数据点很好地总结了 CSS 的使用。这就是现代布局功能的使用：Flex 和 Grid。

条形图显示了 2021 年 flex 和 grid 的使用情况。更详细的解释如下。

资料来源： “CSS”——2021 年网络年鉴

如您所见，虽然 71% 的页面使用了 Flex，但只有 8% 的页面使用了 Grid。造成这种差异的最大原因在于对 IE 的支持。 IE 只支持 Grid 的旧规范，因此想要支持 IE 的页面必须考虑到这一事实。CSS 特性不能像 JS 特性那样容易地填充。这可能是许多开发人员放弃使用 Grid 的主要原因。但是，现在我们可以减少对 IE 的支持，许多现代 CSS 功能（例如 Grid）变得可用。

表现

目前最常用的衡量性能的方法是衡量核心网络生命值 (CWV)。发生这种情况的原因有很多，但 CWV 被用作 Google 搜索中的排名因素可能是最大的原因之一。让我们看看网络在 CWV 方面的表现。

比较 2021 年 CWV 得分较高的页面百分比的条形图。桌面页面为 41%，移动页面为 29%。

资料来源： “绩效”——2021 年网络年鉴

整体性能不是很好，超过一半的页面的 CWV 分数很差。考虑到设备之间 CPU 功率的差异，移动页面在 12% 的时间内得分低于桌面页面似乎是合理的。这一结果也与大多数网站的 JS 大小高于性能预算这一事实相吻合。

通过查看下一张图表，我们还可以看到性能直接影响用户数量。

一个条形图，比较了 2021 年在按浏览次数排名分离页面时具有良好 CWV 分数的页面百分比。更详细的解释如下。

资料来源： “绩效”——2021 年网络年鉴

我们可以看到，好的 CWV 分数和观看次数之间存在相关性。可能部分受到 CWV 是 Google 搜索中的排名因素这一事实的影响。观看次数排名前 1,000 的网站在 37% 的时间内拥有良好的 CWV 得分，而总体数量为 32%。在查看前 10,000 或 100,000 时，我们可以看到在浏览量方面排名较高的网站往往具有更好的性能。毫不夸张地说，提高性能是我们可以直接增加项目收入的方法之一。

JS 库和框架

到目前为止，我们已经看到我们服务的 JS 数量如何对我们网站的性能产生不良影响。大多数使用大量 JS 的项目都会以一种或另一种方式使用库或框架。那么，让我们来看看选择可能产生的后果。

JS 库和框架的使用

根据 Web Almanac 的 JS 章节，最常用的库是 jQuery，使用率高达 84%。我们上面提到的 33% 的网站都使用了 WordPress，这是造成这种情况的重要原因之一。

在框架中，React 最受欢迎，占 8%。但是如果你考虑到其他框架甚至没有达到 4% 的标记，那么可以肯定地说框架的使用仍然是少数。

比较框架性能

虽然框架仍然是少数，但我们有足够的关于最受欢迎的数据来进行一些性能比较。本节的数据来自 Tim Kadlec 2020 年的这篇文章。

将使用 React、Angular、Vue 和 jQuery 的网站的 JS 大小与整体数据进行比较的图表。更详细的解释如下。

资料来源： “Javascript 框架的成本”——Tim Kadlec

让我们首先将使用 React、Angular、Vue 和 jQuery 的网站的 JS 大小与一般数据进行比较：

整体数据和 jQuery 的中位数分别为 414 KB 和 430 KB。这个数字接近 2021 年的中位数。
然而，Vue 和 React 的中值都在 690 KB 左右。比整体中位数高出 250 KB 以上。
Angular 甚至更高，达到 1,066 KB，这是第一个超过 1 MB 的数字。
即使看第 10 个百分位，情况也相似：整体第 10 个百分位是 93 KB，jQuery 是 110 KB，Vue 是 245 KB，React 是 348 KB，Angular 是 445 KB。
换句话说，即使是使用 JS 最少的框架的网站也几乎无法满足上面设定的性能预算。

当然，虽然 JS 大小是性能的一个重要指标，但它绝对不是全部。因此，现在让我们深入研究有关这些相同站点在实际设备中的表现的一些数据。

将使用 React、Angular、Vue 和 jQuery 的网站的 JS CPU 处理时间与整体数据进行比较的图表。更详细的解释如下。

资料来源： “Javascript 框架的成本”——Tim Kadlec

为了尽可能公平，不包括使用多个库或框架的站点。
查看 jQuery 和 Vue 的中位时间，它们分别为 2.3 秒和 3.2 秒。做简单的数学运算，大小差异的比率接近时间差异的比率。
然而，React 和 Angular 并不遵循同样的趋势。Angular 的中位时间为 3.7 秒，而 React 的中位时间慢了几秒，为 10.1 秒。
很明显，在比较 JS 库时，大小并不是唯一重要的指标。

比较静态站点中的框架性能

框架经常用于创建单页应用程序 (SPA)，但它们也用于创建静态站点。让我们比较一下使用框架的静态站点生成器 (SSG) 与不使用 JS 框架的 SSG 的性能。我们将比较实际可检测到使用的前 5 个 SSG 。

比较 2021 年最受欢迎的 5 个 SSG 的中值 JS 大小的条形图。更详细的解释如下。

资料来源： “Jamstack”——2021 年网络年鉴

基于 React 的 Gatsby 和 Next.js 以及基于 Vue 的 Nuxt.js 的中值 JS 大小都在 700 KB 左右。这个数字通常与 React 和 Vue 的中位数相似。
相比之下，基于 Go 的 Hugo 和基于 Ruby 的 Jekyll 分别为 177 KB 和 129 KB。
基于 JS 框架的 SSG 服务的 JS 中位数比不基于 JS 的多 500 KB。

由于我们提到 JS 大小并不是性能的全部，让我们来看看移动网站的 CWV 分数之间的差异。

条形图比较了 2021 年最受欢迎的 5 个 SSG 中具有良好 CWV 分数的页面百分比。更详细的解释如下。

资料来源： “Jamstack”——2021 年网络年鉴

Next.js 和 Nuxt.js 的 CWV 得分不到 15%。
Gatsby 比基于 React 的 Next.js 高出 21.9%。
基于非框架的 Hugo 和 Jekyll 的 CWV 得分分别为 31.8% 和 34.3%。
不使用 JS 框架的 SSG 的 CWV 分数百分比高于整体平均水平。

比较实验室测试中的框架性能

到目前为止，我们已经查看了三个最流行框架的使用数据并比较了它们的性能。但是，除了这三个之外，还有许多其他框架。考虑到这一点，让我们将这三个框架与其他一些框架进行比较，这些框架可能不足以出现在 Web Almanac 中，但属于最受欢迎的框架之一。

笔记：

这些比较的数据来自实验室测试，在实际项目中使用时性能可能会有所不同。
添加到比较中的框架是作者认为最有动力的框架之一。您可以通过转到每个比较的数据源来查看与其他框架的比较。

比较各种框架的性能的表格。更详细的解释如下。

来源： “js web 框架基准测试结果——正式运行”

上表在三个主要类别中将框架与手动优化的 vanilla JS 实现进行了比较：DOM 操作、启动和内存分配。在其中，我们可以观察到以下内容：

React 和 Angular 的平均性能是 Vanilla JS 的两倍。
相比之下，Vue 实际上更接近 Preact 和 Stencil，平均为 1.5 倍。这个结果与我们在 Web Almanac 中看到的结果之间存在差异的主要原因可能是 Vue 在 3.0 版本发布时的性能改进。
最后，Solid、Lit 和 Svelte 都在 1.2 倍左右。它们的性能都非常接近 Vanilla JS 版本。

明显影响这些结果的东西是 IE。你可能会问，“为什么要提到 IE？” 为此，我们必须总体上看一下框架和 JS 标准的历史。

可以说，2015 年 Edge 的发布是 IE 新开发大部分停止的时间点。那一年也是 ES 2015（或 ES6）标准问世的一年；这可以说是 JS 历史上最大的革命。ES 2015 包含诸如承诺和箭头函数等特性。后来的版本开始向 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 的 Virtual DOM 和合成事件系统的实现中，两者都有很多 IE 需要考虑的因素。Preact 和 Solid 更喜欢默认使用现代浏览器中可用的 API。这可能是造成业绩不佳的最大原因。

最后，让我们再看一张图表。

比较使用相同框架创建 30 个组件的捆绑大小的条形图。更详细的解释如下。

资料来源： “制作 Web 组件的所有方法 – 2021 年 11 月更新” – WebComponents.dev 博客

该图表以不同的指标比较了上述大多数框架：使用相同框架创建 30 个组件时的包大小。这种比较使我们能够模拟这些框架在使用它们创建完整应用程序时的工作方式。

React 最终再次成为最大的 45.45 KB，但就实际的开发人员代码而言，它是最小的 9.26 KB。只是图书馆本身比其他图书馆大几倍。
Vue 确实在 3.0 版中做了很多改进，但它最终仍然是其他库的两倍，大小为 32.65 KB。
其余框架在捆绑多少开发人员代码和库代码方面可能有所不同，但它们最终都具有相似的大小，在 14-18 KB 范围内。

可访问性

我们已经谈了很多关于用户设备的内容，但现在让我们谈谈用户本身。根据世界卫生组织的数据，超过 10 亿人患有某种残疾。有许多不同类型的残疾，但其中许多会影响用户与他们的设备交互的方式。我们通常使用术语可访问性 (a11y) 来指代确保残疾用户可以与我们的网站完全交互所需的操作。

但是，a11y 不仅适用于残疾人。改善 a11y 的行动对每个用户的 UX 都有积极影响。造成这种情况的主要原因是情境障碍。情境障碍的一些示例包括尝试用一只手吃东西或喝东西时使用手机，或者在特定小时后在屏幕上放置黑白滤镜以改善睡眠质量的设备设置。面临这些情境障碍的用户将能够像往常一样使用设计时考虑到 a11y 的页面。

此外，无法访问也可能导致法律问题。根据立法，用户甚至可以起诉不考虑 a11y 的网站。一些著名的案例包括 Beyonce 和 Domino's Pizza 因视障用户无法访问而被起诉。因此，没有适当的 a11y 也可能代价高昂。

网络的可访问性如何？

现在让我们看看网络的可访问性。为此，我们将从 Web Almanac 的 a11y 章节中提取一些具有代表性的数据。如果您想更深入地了解，那里还有更多数据点。

77.8% 的网站在背景和字体颜色之间没有很好的对比。这意味着，一些视障用户和使用上述过滤器的用户可能无法充分使用几乎 80% 的网络。
29.4% 的网站阻止缩放。现在有些浏览器会忽略此设置，但这仍然是一个很大的数字。
42% 的网站标题排序不正确。之前使用 h2 元素而不使用元素的情况h1 。这种缺乏秩序可能会导致问题，尤其是对于使用辅助技术的用户。
29% 的网站使用 role="button". 有些人可能认为拥有该角色和点击监听器可能就足够了，但按钮还必须响应键盘事件并具有适当的焦点处理。button 虽然您可以使用 JS 来实现这一点，但如果您只使用元素，则根本不需要 JS 。
32.7% 的网站有 input 没有可访问标签的元素。换句话说，它们没有关联的 label 元素、 aria-label 属性或其他任何东西。这令人担忧，因为您可能会因此而损失收入。例如，如果没有标记信用卡输入，您可能会有想要购买东西但不知道在哪里写所需信息的用户。

结论

让我们看看结论。

我们没有满足用户的需求：尤其是在性能和 a11y 方面。
我们过度使用 JS：在我们的依赖项和我们自己的代码中。
我们没有充分利用 HTML 和 CSS：这部分是由于 IE 支持，但现在我们不需要支持 IE，有许多功能变得可用。

以下是一些总体提示，适用于想要了解如何改进的人：

如果您可以使用CSS做某事，请使用 CSS：以前只有使用 JS 才能完成的许多事情现在只能使用 CSS 完成。通过这样做，您可以部分减少 JS 代码。
评估您的 工具集：与旧工具相比，许多新工具具有更好的性能基线，并且并非每个项目都需要成为 SPA。一些非基于框架的 SSG，如 Hugo、Jekyll 或 11ty 非常适合这些用例。
为现代 浏览器构建：放弃 IE 支持并将构建目标设置为 ES 2017 甚至 2018。这样做可能会使您的捆绑包大小提高多达 20%。
从一开始就考虑 a11y ：从规划和设计阶段就考虑 a11y 是理想的方案。从改进对比度、字体大小、语义 HTML 使用和键盘导航等开始可以产生很大的不同。