作者丨Rick Viscomi
翻译者 |知山。
策展 |丁晓云.
网络越来越快。 来自 HTTP Archive 的数据显示，越来越多的 Web 指标正在传递核心指标：加载速度、交互式响应能力和布局稳定性。
最近，Chrome 团队发布了一份关于 Web Vitals 项目的回顾性报告，详细介绍了浏览器和生态系统的一些进展。 根据 Chrome 团队的说法，对 Core Web Vitals 的改进相当于大约 10,000 年的等待。
因此，随着我们越来越接近 2024 年，我想仔细研究如何保持这种势头并继续让网络更快。
但有一个问题，我们用来衡量交互响应能力的指标将在 2024 年发生变化，这个新指标已经确定了许多迄今为止未被注意到的响应能力问题。
我们能迎接这个新的挑战吗？ 我们能否在 2023 年应对这一挑战的同时保持性能改进？ 我想是的，但我们需要学习一些新的技巧习。
在我看来，这是理所当然的。 在过去的 11 年里，我一直在为网络性能优化而努力和倡导，有时认为每个人——至少在我的圈子里——都这么认为是天真的。
如果我们要继续提高 Web 性能，我们需要更多的开发人员和业务领导者同意性能优化值得采取行动。
那么，让我们谈谈为什么要优化 Web 性能。
塔米·埃弗茨2024年11月演出now（） 中。
***schmitzoide@twitter
上周，我有机会参加了在阿姆斯特丹的演出now（） 大会。 对于我们许多从事 Web 性能工作的人来说，这已成为我们如何齐心协力突破 Web 性能界限的年度朝圣之旅。 塔米·埃弗斯（Tammy Evers）是会议的联合主席和演讲者之一，他在上面的幻灯片中完美地总结了这个问题的答案。
2016 年，Tammy 出版了一本名为《时间就是金钱》的书，其中她列出了所有者对优化 Web 性能感兴趣的一些可能原因：
跳出率购物车大小转化率收入停留时间页面浏览量用户满意度用户留存自然搜索流量品牌认知度品牌认知度生产力节省带宽 CDN 竞争优势 基于数十年的经验和众多案例研究和神经科学研究，Tammy 认为通过改进网络
性能，所有这些都可以产生积极影响。
Tammy 还与 Tim Kadlec 合作创建了 WPO Statistics，这是一个 Web 性能案例研究，记录了 Web 性能改进与更好的业务成果之间多年来的直接关联。
例如，在一个案例研究中，Shopify ** 的加载性能和布局稳定性分别提高了 25% 和 61%，跳出率降低了 4%，转化率提高了 6%。 在另一个案例研究中，"obama for america"**性能提高 60%，转化率相应提高 14%。 像这样的例子还有很多。
快乐的用户赚更多的钱。 如果你看一个典型的转化漏斗，就会发现越来越少的用户会深入到漏斗的深处。 优化性能可以有效地“润滑漏斗”，并通过为用户提供更流畅的体验来推动转化。
这是对业务的影响，但更根本，因为性能与用户体验有关。
如果用 Google 的 Core Web Vitals 来衡量 Web 性能，那么现代 Web 是有史以来最快的。 为了形成全面的理解，让我们看看我们是如何走到这一步的。
**由 Core Web Vitals 评估的时间序列（2023 年 1 月至 9 月）
*：http archive
2024年初，401%** 通过了针对移动用户体验的 Core Web Vitals 评估。 从那时起，我们见证了稳步增长。 截至 2023 年 9 月，42% 的人已通过 Core Web Vitals5%，同比增长24个百分点，同比增加6个百分点0%。这是一个新的工作水平，代表了整个网络生态系统中正在完成的大量工作。
看起来它一半是满的，一半是空的。 你可以说他们中有近一半的人有可衡量的良好表现并庆祝它，当然，你可以认为他们中有一半以上没有达到绩效标准。
我们也可以两者兼而有之！ 网络已经发展到如此之远，我们可以继续努力将这种势头延续到 2024 年。
那么，我们能否保持目前的利率并通过评估获得更多的 6%**？ 我认为我们可以，但随着我们用于评估页面响应能力的指标发生变化，一切都会发生变化。
今年早些时候，我写了一篇博文，其中我表示，“与下一个 Paint 的交互”（INP） 将成为 Google Core Web Vitals 中的一个新响应能力指标，并将在 2024 年 3 月取代“首次输入延迟”（FID）。
这是一个非常好的变化，因为 INP 在捕捉响应速度较慢的情况方面更有效。 尽管如此，与 FID 相比，具有良好 INP 分数的**要少得多，尤其是在移动体验方面。
在 2022 年网络年鉴的性能章节中，我写了如果使用 INP 而不是 FID，核心 Web Vitals 的通过率会是什么样子。
对于移动体验，只有 31 个2% 的站点通过了评估，即 8 个4个百分点（21个百分点）2%）。这是基于 2022 年 6 月的数据。 那么现在是什么情况呢？
按设备比较 INP 和 FID 分数良好的人群百分比（2023 年 9 月）。
*：chrome ux report
事实上，情况要好得多！ 桌面端的差距几乎已经消除，移动体验仅落后6个百分点（14个百分点）。2%）。
但事实仍然是：一旦INP生效，通过率将大幅下降。
虽然乍一看这似乎是倒退了一步，但请记住，INP 让我们更准确地了解真实用户如何体验交互响应。 网络的实际体验没有改变，只是我们衡量它的方式发生了变化。 因此通过率的下降实际上并不意味着网络正在放缓
因此，我仍然乐观地认为，我们将在 2024 年继续改善业绩。 只是当INP出现时，我们需要根据新的基准重新调整我们的期望。
FID 是 Core Web Metrics 中最古老的指标。 它于 2018 年 6 月首次出现在 Chrome 用户体验报告数据集中。 截至今天，只有 5 个8%** 在桌面或移动设备上存在 FID 问题。 所以我认为可以公平地说，在大多数情况下，我们不需要担心交互响应能力。
INP挑战了我们在过去五年中发展起来的惰性满意度。 为此，我们将不得不使用一些我们可能很少甚至从不使用的 Web 性能技术。 我们将不得不采用一些新工具。
Chrome DevTools 性能面板中显示的长任务。
*：optimize long tasks on web.dev
我们将不得不适应这一点。
这是 Chrome DevTools 性能面板中的一项长期任务。红色条纹表示超过 50 毫秒的任务量为“长”。 如果用户此时尝试与页面交互，则长任务将阻止页面响应，从而导致用户（和 INP 指标）感知交互速度较慢。
长任务拆分，如 Chrome DevTools 性能面板中所示。
*：optimize long tasks on web.dev
解决此问题可能需要一种您以前从未尝试过的 Web 性能技术：拆分长任务。 最终完成的任务数量是相同的，但通过在主要工作块之间添加输出点，页面将能够更快地响应任务期间发生的用户交互。
Chrome 正试图通过一些实验性 API 来解决有问题的长任务。 首先是调度程序yield（） API，旨在让开发人员更好地控制拆分长任务。 它确保任务继续进行，并且不会被其他任务中断。
了解哪些长任务需要细分本身就是一门科学。 为了解决这个问题，Chrome 还尝试使用长动画帧 API。 与长任务 API 类似，它报告长时间的渲染更新，其中可能包含多个任务。 至关重要的是，它还公开了有关任务的可操作属性的更多信息，包括脚本中字符的位置。
与在分析工具中跟踪 INP 性能类似，开发人员可以使用长动画帧 API 来跟踪 INP 速度缓慢的原因。 总体而言，这些数据缩小了常见性能问题的根本原因，使开发人员不必进行试验和优化，而无需反复试验。
这些 API 目前不稳定，但它们提供了强大的新功能，可以补充现有工具包以优化响应能力。 虽然这可能会让我们觉得我们只是将通过率恢复到以前以 FID 为中心的评估，但它确实使网络速度更快！
随着 INP 取代 FID，响应能力似乎将成为新的瓶颈，但事实并非如此。 根据 LCP 衡量的负载性能，现在是并将继续是 Core Web Vitals 评估中最薄弱的环节。
要通过 Core Web Vitals 评估，需要满足以下条件：所有三个指标表现良好。 因此，为了继续前进，我们需要关注最需要改进的指标。
截至 2023 年 9 月的 HTTP Archive 数据显示，54% 的移动用户拥有良好的 LCP2%，而 INP 和 CLS 分别为 641% 和 760%。
自从 Web 性能成为不可或缺的东西以来，开发人员一直在谈论加载性能。 从简单的 HTML 程序时代开始，我们已经积累了很多关于后端性能和图像优化等传统技术的知识。 但从那时起，网络发生了很大变化。 它们变得越来越复杂，越来越多的第三方依赖项，用于在客户端呈现内容的技术越来越丰富和更复杂。 解决现代问题需要现代解决方案。
2022 年，Philip Walton 分享了一种分解 LCP 时间消耗的方法：在客户端上开始接收内容所需的时间 （TTFB）、开始加载 LCP 图像所需的时间（资源加载延迟）、完成加载 LCP 图像所需的时间（资产加载时间）以及渲染 LCP 元素所需的时间（元素渲染延迟）。 通过测量这些指标中最慢的指标，我们可以将注意力集中在最有效的优化措施上。
传统观点认为，如果希望 LCP 图像更早出现，则应优化图像本身，包括使用更高效的图像格式、将其缓存更长时间、将其大小调整为更小的尺寸等。 从 LCP 指标来看，这些只会缩短资源加载时间，但其他指标呢？
正如我之前提到的，我参加了表演now（） 大会。 会议的另一位演讲者是 Estella Franco，我与她一起分享了来自真实 Chrome 用户的新数据，包括 LCP 时间通常花在哪里。
Estel Franco 用于展示 Chrome 数据的 LCP 时间分配（2023 年 11 月）。
***rick viscomi
上图显示了 Estella 的幻灯片，其中 LCP 指标是平均 LCP 时间。 以下是相同的数据，以毫秒为单位：
按 LCP 评分分组的平均 LCP 诊断性能分析（2023 年 10 月）。
*：Chrome 119 测试版内部数据。
最令人惊讶的是，资源加载时间（load duration）实际上已经是最快的 LCP 指标了。 最慢的部分实际上是资源加载延迟。 因此加速慢速 LCP 图像的最可能时间是尽早加载它们。同样，问题不在于加载图像需要多长时间，而在于我们没有加载它们的时间。
浏览器通常非常擅长在标记中发现图像并快速加载它们。 那么为什么会有问题呢？ 开发人员在使 LCP 图像可被发现方面做得不好。
我在 2022 年网络年鉴中写过关于 LCP 可发现性问题的文章。 在那篇文章中，我说 387% 的移动网页包含图片 LCP，但并未使其静态可被发现。 即使在 http 存档的最新数据中，这个数字仍然是 360%。
这个问题的很大一部分仍然是延迟加载问题。 我写了一篇关于 2021 年 LCP 延迟加载对性能的负面影响的文章。 延迟加载不仅仅是原生的 loading=lazy 属性，开发者还可以使用 j**ascript 来动态设置图片源。 去年，我说 178% 的带有 LCP 图像的页面以某种方式延迟加载，而来自 HTTP Archive 的最新数据显示略有改善，有 16 个8% 的页面使用延迟加载。 如果您延迟加载，获得快速 LCP 并非不可能，但这肯定不会是有益的。 LCP 映像不应延迟加载。
需要明确的是：延迟加载对性能有好处，但仅适用于非关键内容。 其他内容（包括 LCP 图像）必须尽早加载。
客户端渲染是一个完全不同的问题。 如果向客户端发送的唯一标签是由 j**ascript 呈现的标签
容器中，浏览器无法加载 LCP 镜像，直到最终在 DOM 中发现它。 一个更好的（尽管值得商榷）的解决方案是切换到服务器端渲染。
我们还需要处理以 CSS 样式声明的 LCP 图像，例如 background-image： url（"cat.gif")。这些图像不是由浏览器预加载的扫描程序捕获的，因此它们不能提前加载，而是使用普通图像
元素。
对于这些场景，还可以使用声明性预加载来使图像可显式发现。 最简单的形式可以是这样的：
浏览器会尽早开始加载图像，但只要它的渲染依赖于 j**ascript 或 css，那么问题就从加载延迟到渲染延迟。 通过直接放在 HTML 中
元素来消除这些依赖关系是避免这种延迟的最直接方法。
到目前为止，所有这些 LCP 建议基本上都是为了解决我们在应用程序中引入的一些复杂性而设计的：LCP 延迟加载、客户端渲染和 LCP 背景图像。 还有一些相对较新的技术可用于提高性能，甚至完全避免这些延迟。
在去年的网络年鉴中，我报告了 003% 的页面在 LCP 图像上使用 FetchPriority=High。 此属性向浏览器暗示图像的加载优先级应高于默认优先级。 在 Chrome 中，默认情况下，图像通常优先级较低，因此这可以显着提高它们的性能。
自去年以来发生了很多变化！ 最新的 HTTP Archive 数据显示，有 9 个25% 的页面使用 FetchPriority=high 来加载 LCP 图像。 这是一个巨大的飞跃，主要是因为WordPress在6Fetchpriority 在版本 3 中使用。
还有一些技术可以有效地实现动态导航：利用前向后缓存和预加载。
当用户单击“后退”或“前进”按钮时，将恢复以前访问过的页面。 如果页面保存在浏览器的后向正向内存缓存（也称为 bfcache）中，则它将立即加载。 LCP 图像已加载，并且已运行渲染它所需的 j**ascript，但并非所有页面都适合缓存。 unload 或 cache-control： no-store 指令目前会导致网页不符合 Chrome 的缓存条件，即使这些事件***是由第三方设置的。
自从我上次在 Web 年鉴中报告了 bfcache 的适用性以来，卸载使用率从 17% 下降到 12%，无存储使用率从 22% 下降到 21%。 因此，越来越多的页面适合这种即时加载缓存，这有利于所有核心 Web Vitals。
另一种动态导航技术称为推测加载。 使用实验性的推理规则 API，开发人员可以提示浏览器，如果用户可能导航到下一页，则应提前呈现整个页面。 此 API 还支持预取，这是一种提高加载性能的不太激进的方法。 但缺点是它只加载文档本身，而不是子资源，因此它比预渲染模式更不可能兑现“即时导航”的承诺。
下面是 mdn 文档中的推测加载示例：
随着越来越多的开发人员意识到提高性能的挑战和机遇，我希望我们能看到 Core Web Vitals 评估的 2023 年之后的持续增长。
首先要克服的障碍之一是了解您的设备是否存在性能问题。 最简单的方法是使用 PageSpeed Insights，它使用来自 Chrome 用户体验报告的公共核心网络体验数据。 即使您的设备目前通过了评估，也请密切关注 Interaction to Next Paint （INP） 性能，因为这将在 2024 年 3 月成为新的响应能力标准指标。 您还可以使用 Google Search Console 中的 Core Web Vitals 报告来监控效果。 了解性能的更好方法是进行自我测量，从中可以更精细地诊断性能为什么很慢。
下一个障碍是投入时间和精力甚至金钱来提高性能，但首先您需要专注于性能。
如果 INP 的性能较差，则可能会有一条 习 曲线，借助文档、技术和工具来优化长期任务。 在交互式响应能力方面，FID 给了我们一种虚假的安全感，但现在我们有机会发现并修复可能让用户感到沮丧的问题。
我们也不要忘记，LCP 是 Core Web Vitals 评估中最薄弱的环节。 与其他指标相比，LCP 存在问题的情况更多。 多年来，我们构建 Web 应用程序的方式发生了很大变化，因此我们需要相应地调整我们的优化技术，以专注于更快地加载图像。
我希望这篇文章有助于展示我们今年看到的一些进展和改进的空间。 网络速度提高 6% 当然值得庆祝，但大多数**仍然不够快——至少目前还不够快。
如果我们保持每年 6% 的变化率，到 2026 年，超过一半的 ** 将在移动设备上拥有良好的核心 Web 体验。 让我们继续更快地突破 CMS、JASCRIPT 框架和第三方依赖项的界限，并继续成为 Web 社区中的性能最佳实践倡导者。 2024 年的下一个 6% 指日可待！
原文链接：你可以错过web3，但不要错过web5
其他人不会告诉你的 web3 的未来。
Web3 如今，最好的投资就是投资自己。
反思 web3，不要抱怨。