专栏名称: 前端大全
分享 Web 前端相关的技术文章、工具资源、精选课程、热点资讯
目录
相关文章推荐
前端早读课  ·  【第3431期】Ant Design X ... ·  昨天  
歸藏的AI工具箱  ·  藏师傅的 Sora 模型初体验报告 ·  3 天前  
前端早读课  ·  【早阅】浏览器扩展程序攻击 ·  4 天前  
格斗迷  ·  张伟丽最新对手!干掉过3个UFC冠军 ·  4 天前  
格斗迷  ·  张伟丽最新对手!干掉过3个UFC冠军 ·  4 天前  
前端早读课  ·  【早阅】Signals分析:从历史到影响 ·  6 天前  
51好读  ›  专栏  ›  前端大全

2024 年前端性能报告

前端大全  · 公众号  · 前端  · 2024-12-09 12:00

正文


转自:code秘密花园

今天我们一起来看 2024 年的 Web Almanac - 性能篇

数据说明

本报告的大部分内容均基于 Chrome 用户体验报告 (CrUX) 中的真实用户数据。

Chrome 用户体验报告(CrUX)反映了真实世界中 Chrome 用户在热门网站上的体验,是 Web Vitals 项目的官方数据集,展示了所有用户中心的核心 Web Vitals 指标。CrUX 数据基于全球真实浏览器用户收集,并通过多种 Google 和第三方工具公开提供,用于 Google 搜索的页面体验排名因素。并非所有原点或页面都在数据集中,需公开可发现且访客数量足够多以达统计显著性。

核心网页指标(Core Web Vitals)

核心网页指标(Core Web Vitals, 简称 CWV)是以用户为中心的一组指标,用于衡量网页性能的不同方面。这些指标包括

  • 用于跟踪加载性能的 最大内容绘制时间(Largest Contentful Paint, LCP)
  • 衡量交互性的 下一次绘制后的交互时间(Interaction to Next Paint, INP)
  • 评估视觉稳定性的 累积布局偏移量(Cumulative Layout Shift, CLS)。

从今年开始,INP 已正式取代了 首次输入延迟(First Input Delay, FID),成为CWV的一部分。INP 测量用户所经历的所有交互的全部延迟,而 FID 只关注第一次交互的输入延迟。由于 INP 的范围更广,因此更能反映完整的用户体验。

替换 FID 为 INP 指标显著影响了移动端具有良好 CWV 的网站百分比。值得注意的是,这并不意味着用户体验变差了,而是由于指标更新,现在反映得更加准确。如果我们仍使用 FID 作为交互性指标,48% 的网站在移动设备上会拥有良好的 CWV。然而,采用 INP 指标后,这一数据降至 43%。有趣的是,无论我们使用何种响应指标,桌面设备的性能都保持在 54%。

从 2020 年到 2022 年,使用 FID 测量的移动网页性能改进速度快于桌面端,两者之间的差距不断缩小,到 2022 年仅差 5%。然而,根据 INP 指标,2024年桌面端网页性能比移动端高出 11%,这表明两者之间的差距更大了。

使用 INP 指标分析网站排名时,展现了新的趋势。以往最受欢迎的网站往往有最好的 CWV 体验,但今年的统计数据表明情况相反:在移动设备上最受欢迎的 1000 个网站中,仅有 40% 的网站拥有良好的 CWV,低于总体网站的 43%。

正如前文提到的,由于引入 INP 指标,CWV 得分有所下降。我们调查了不同技术受这一变化的影响。上图显示了 INP 引入后各技术的 CWV 良好占比下降的百分比。

几种技术受到显著影响,包括

  • 1C-Bitrix (中亚地区流行的 CMS) 的 19% 下降
  • 基于 React 的框架 Next.js 下降了 10%
  • Emotion (一种 CSS-in-JS 工具) 的 8% 下降

我们无法完全确定 CWV 得分下降仅是由于使用的技术。尽管 Next.js 具有服务器端渲染 (SSR) 和静态站点生成 (SSG) 功能,这些理论上应能提升 INP,但其得分依然显著下降。由于 Next.js 基于 React,许多网站依赖客户端渲染,这会对 INP 产生负面影响。这可能提醒开发者要充分利用其框架的 SSR 和 SSG 功能。

加载速度

人们通常将网站加载速度视为一个单一的指标,但实际上,加载体验是一个多阶段过程。没有任何单一指标能完全概括所有影响加载速度的因素。每个阶段都会对网站的加载速度产生影响。

首字节时间(Time to First Byte, TTFB

TTFB 测量的是从用户开始加载页面到浏览器接收到响应的第一个字节所用的时间。这个过程包括重定向时间、DNS 查找、连接和 TLS 协商以及请求处理。减少连接和服务器响应时间的延迟可以改善 TTFB。800 毫秒被认为是良好 TTFB 的阈值,当然也有一些例外情况。

在过去的五年中,具有良好 TTFB 的移动网页比例保持稳定,从 2021 年的 41% 到 2024 年的 42%。需要改善 TTFB 的页面比例减少了 1%,而不幸的是,具有糟糕 TTFB 的页面比例保持不变。由于这个指标没有显著变化,我们可以得出结论,连接速度或后端延迟方面没有重大改进。

首次内容绘制(First Contentful Paint, FCP

FCP 是一个性能指标,用于指示用户开始看到内容的速度。它衡量的是用户第一次请求页面到第一个内容呈现在屏幕上的时间。良好的 FCP 应该小于 1.8 秒。

FCP 在过去几年里有所改善。尽管在 2023 年有些许下降,但该指标在 2024 年恢复,桌面网站达到 68%,移动网站达到 51%。总体上,这反映了首屏内容加载速度的积极趋势。考虑到 TTFB 指标基本未变,FCP 的改进可能更多是由客户端渲染驱动,而不是服务器端优化。

最大内容绘制(Largest Contentful Paint, LCP

LCP 是一个重要指标,因为它表示视口最大的元素加载的速度。一个最佳实践是确保 LCP 资源尽早开始加载。良好的 LCP 应该小于 2.5 秒。

LCP 近年来也有所改善(从 2022 年具有良好 LCP 的 44% 页面到 2024 年的 54%),这符合 CWV 的总体积极趋势。2024 年,59% 的移动页面达到了良好的 LCP 得分。然而,与桌面站点相比,移动站点仍有显著差距,桌面站点中 74% 具有良好的 LCP。这种趋势主要是由于设备处理能力和网络质量的差异,但也表明许多网页仍未针对移动使用优化。

大多数 LCP 元素(73% 的移动页面)是图片。有趣的是,这一比例在桌面页面上高出 10%。对于文本内容,情况则相反。与桌面相比,10% 更多的移动网页使用文本作为 LCP 元素。这种差异可能是因为桌面网站可以容纳更多的视觉内容,因为它们的视口更大且性能普遍更高。

LCP 元素完全渲染之前,必须经过几个处理阶段:

  • 首次字节时间 (TTFB),这是服务器开始响应初始请求所需的时间。
  • 资源加载延迟,这是浏览器在 TTFB 后开始加载 LCP 资源的时间。来源于内联资源的 LCP 元素(如基于文本的元素或内联图片(数据 URI))的加载延迟为 0 毫秒。而需要下载其他资源的则可能会有加载延迟。
  • 资源加载时长,测量加载 LCP 资源所需的时间;如果不需要资源,时长为 0 毫秒。
  • 元素渲染延迟,这是资源加载完毕到 LCP 元素完成渲染所需的时间。

研究表明,图像加载时长对 LCP 时间影响最小,在 LCP 表现较差的网站中,其在第 75 百分位数仅占 350 毫秒。尽管经常推荐用图像大小减小等资源加载时长优化技术,但它们相比 LCP 其他部件并不能带来太多时间节省,即便是对 LCP 表现差的站点。

TTFB 是所有 LCP 部件中占比最大的部分,这是由于网络请求的外部资源引起的。具有较差 LCP 的网站在 TTFB 上的花费为 2.27 秒,几乎与一个良好 LCP 的阈值(2.5 秒)一样长。正如我们在 TTFB 部分所看到的,具有良好 TTFB 的网站比例并没有显著提升,这表明该指标在 LCP 优化上具有重大潜力。

今年,我们分析了来自另一个真实用户监控来源的数据:RUMvision。尽管 RUMvision 的网站群体不同,比较它与更大 CrUX 网站群体的数据也很有趣。我们假设使用性能监控工具如 RUMvision 的网站对性能优化机会有更深入的了解,自然地,来自两个不同数据集的 LCP 部件结果有一些差异。

根据 RUMvision 数据,在所有 LCP 部件中,TTFB 也是 LCP 时间的最大贡献者。然而,其他部件的结果有所不同。渲染延迟是 LCP 的第二大贡献者,占 184 毫秒。在第 75 百分位,渲染延迟增长到 443 毫秒。这与 CrUX 数据集有所不同,在其中,LCP 加载延迟是第二大子部分。

通常情况下,如果 LCP 元素尚未被添加到 DOM 中,LCP 元素的渲染会花费较长时间——这是客户端生成内容的常见问题,我们将在下节探讨。此外,被长任务阻塞的主线程也会导致延迟。此外,类似样式表或 中的同步脚本等渲染阻塞资源也可能延迟渲染。

CrUXRUMvision 数据中的 LCP 部件显示,资源加载时长很少是 LCP 缓慢的主要瓶颈。然而,分析关键优化因素(如 LCP 资源的大小和格式)仍然有价值。

2024 年,48% 的移动网站使用的 LCP 图像大小为 100KB 或以下。然而,8% 的移动页面 LCP 元素大小超过 1000KB。

JPG 和 PNG 仍然是采用率最高的,合计为 87%;然而,WebP 和 AVIF 格式的使用都在增加。与 2022 年相比,WebP 图像格式的使用从 4% 增加到 7%。另外,AVIF 的使用率也略有增加,从 0.1% 增加到 0.3%。根据 Baseline 数据,AVIF 格式已在主流浏览器中可用,因此我们预计未来会有更高的采用率。

可交互性

网站的可交互性指的是用户与页面上的内容、功能或元素进行互动和响应的程度。评估可交互性需要衡量各种用户交互的性能,例如点击、触摸和滚动,以及更复杂的操作如表单提交、视频播放或拖放功能。

Interaction to Next PaintINP

INP 的计算通过观察用户在会话期间与页面进行的所有交互,并报告最差的延迟(针对大多数网站)。一次交互的延迟由一组事件处理程序的最长持续时间决定,从用户开始交互到浏览器下次能够绘制帧的时刻。

要获得“良好”的 INP 分数,至少 75% 的会话必须达到 200 毫秒或以下的 INP 分数。INP 分数反映了页面上所有交互中最慢或接近最慢的时间。

2024 年,74% 的移动端和 97% 的桌面端网站有良好的 INP。有趣的是,移动端和桌面端之间的差距超过 20%。

移动端性能较差的主要原因是其较低的处理能力和频繁的网络连接不佳。低端设备与高端设备之间的性能差距正在扩大。随着高端设备价格的上涨,能够负担得起这些设备的用户越来越少,这加剧了不平等差距。

虽然 INP 结果比 FID 更差,但过去三年中有一个积极的趋势。具有良好 INP 的移动页面比例从 2022 年的 55% 增加到 2024 年的 74%。这是一个显著的增长,尽管我们不能完全确定这一变化的原因,但可以推测一些潜在的驱动因素。

第一个可能的因素是认知意识。随着 INP 的引入和替代 FID 的宣布,很多团队意识到这对总体的 CWV 得分和搜索排名的影响,促使他们积极修复会导致低 INP 分数的部分网站。第二个驱动因素可能是技术的常规进步。考虑到 INP 数据来自真实用户,我们可以假设用户的设备和网络连接在过去几年中有所改善,提供了更好的网站互动性。第三个(也是可能最大的)驱动因素是浏览器本身的改进。Chrome 团队在过去两年中进行了许多影响 INP 的改进。

按排名分析移动端 INP 指标显示了一个有趣的趋势。

排名前 1000 的网站中,具有良好 INP 的网站比例较总网站数据少。例如,排名前 1000 的网站中,53% 具有良好的 INP 分数,而所有网站中这一比例为 74%。

长任务

INP 的一个部分是输入延迟,由于各种因素,包括长任务,可能比预期更长。任务是浏览器执行的离散工作单位,JavaScript 通常是任务的最大来源。当任务超过 50 毫秒时,它被视为长任务。这些长任务会造成用户交互响应的延迟,直接影响互动性能。

任务持续时间分布显示,桌面端的中位任务持续时间为 90 毫秒,移动端为 108 毫秒,是最佳实践推荐(50 毫秒以下)的两倍。少于 25% 的网站任务持续时间低于 50 毫秒。我们还看到,在每个百分位数,移动网站的任务持续时间都长于桌面网站的,随着百分位数增加,差距亦增加。在第 90 百分位数,设备类型的平均任务持续时间差距为 46 毫秒。这与显示桌面结果比移动更好的 INP 分数相一致。

总阻塞时间(Total Blocking Time, TBT

TBT 测量的是首次内容绘制(FCP)之后主线程阻塞时间足够长以至于无法响应输入的总时长。

TBT 是一个实验室指标,常用作现场响应性指标(如 INP)的代理,后者只能通过真实用户监控(如 CrUXRUMvision)收集。基于实验室的 TBT 和基于现场的 INP 是相关的,这意味着 TBT 结果通常反映 INP 趋势。小于 200 毫秒的 TBT 被认为是好的,但大多数移动网站远远超过这一目标。

移动端的中位 TBT 为 1209 毫秒,是最佳实践(200 毫秒)的 6 倍。相比之下,桌面网站表现更好,中位 TBT 仅为 67 毫秒。需要强调的是,实验室结果使用了模拟的低功耗设备和慢网速,可能不反映真实用户数据,因为实际设备和网络条件可能有所不同。但即便如此,这些结果仍显示,在第 90 百分位数,移动设备用户需要等待近 6 秒才可交互。

由于 TBT 是由长任务引起的,注意到百分位数的相似趋势及移动与桌面之间的差距也不足为奇。同样需要注意的是,高 TBT 可能导致输入延迟,从而负面影响总体 INP 分数。

视觉稳定性

网站的视觉稳定性指的是页面加载和用户交互过程中视觉元素的一致性和可预测性。一个视觉稳定的网站确保内容不会意外地移动或更改布局,从而避免破坏用户体验。这些不稳定通常由于未指定尺寸的资源(例如图片和视频)、第三方广告、重型字体等引起。衡量视觉稳定性的主要指标是 累积布局偏移(Cumulative Layout Shift, CLS)。

累积布局偏移CLS

CLS 测量的是页面打开期间发生的意外布局偏移的最大突发布局偏移得分。当一个可见元素的位置从一个地方变化到另一个地方时,便会发生布局偏移。

CLS 得分在 0.1 或以下被认为是良好的,意味着页面提供了视觉稳定的体验;得分在 0.1 到 0.25 之间表示需要改进,而得分在 0.25 以上则被认为是较差的,意味着用户可能会体验到破坏性的意外布局偏移。

在 2024 年,72% 的网站达到了良好的 CLS 得分,而 11% 的网站表现较差。我们还可以看到,在视觉稳定性方面,移动设备上的用户体验优于桌面设备。

随着时间的推移,我们看到这些指标有上升趋势。具有良好视觉稳定性的网站比例从 2020 年的 60% 增加到 2024 年的接近 80%。2022 年引入的 bfcache 带来了显著的提升。

前进/后退缓存(Back/forward cache, bfcache

前进/后退缓存(bfcache)是一个浏览器优化功能,能够通过在内存中缓存页面的完全交互快照来提高在页面之间导航的速度和效率。然而,并非所有网站都有资格使用 bfcache。要检查网站是否符合条件,最简单的方法是在 Chrome DevTools 中进行测试。

我们来深入检查一些常见的、使用实验室数据容易测量的符合条件的标准。

其中一个常见问题是用户导航离开页面时触发的 unload 事件。由于 bfcache 保存页面状态的方式,unload 事件使页面不符合 bfcache 的条件。需要注意的是,此功能特定于桌面浏览器。移动浏览器在决定 bfcache 资格时忽略 unload 事件,因为在这些设备上,后台页面被丢弃的频率更高。这种行为可以解释近几年在移动设备与桌面设备之间的 CLS 改进差异:

从上图显示页面 unload 事件来看,可以看到一些有趣的现象。总体事件使用率很低,仅为 15-16%。但在排名前 1000 的网站中急剧增加,在桌面端为 35%,在移动端为 27%,表明更受欢迎的网站可能使用了更多的第三方服务,这些服务通常使用此特定事件。移动和桌面之间的差距显著,尽管使用 unload 事件的移动站点仍然符合 bfcache 的资格,但其可靠性较低。

自从 2020 年起,主要浏览器(如 Google ChromeFirefox)逐步停止使用 unload 事件并鼓励使用替代事件如 pagehidevisibilitychange,预计 unload 事件的使用率会下降。这些事件更可靠,不会阻塞浏览器的导航,并且与 bfcache 兼容,允许页面保存在内存中并在用户前进或后退时立即恢复。

另一个导致网站无法使用 bfcache 的常见原因是使用 Cache-Control: no-store 指令。该缓存控制头指示浏览器(以及任何中间缓存)不要存储资源副本,确保每次请求都从服务器获取内容。

21% 的网站使用 Cache-Control: no-store,较 2022 年的 22% 略有下降。

bfcache 首次引入时,对核心网页指标带来了显著的改进。基于这一点,Chrome 逐步将 bfcache 引入到以前因使用 Cache-Control: no-store 头而不符合条件的更多网站。这一变化旨在进一步提升网站性能。

unload 事件以及 Cache-Control: no-store 不会直接影响页面的视觉稳定性。正如前文所述,bfcache 加载作为副作用通过消除某些可能直接影响指标(如未指定尺寸的图像或动态内容)的潜在问题,产生了此积极影响。

CLS 最佳实践

以下最佳实践可以减少甚至完全避免 CLS

  • 明确的尺寸

意外布局偏移的一个最常见原因是未为资源或即将到来的动态内容保留空间。例如,在图像上添加 widthheight 属性是保留空间和避免偏移的最容易的方法之一。

每个网页中段数量的未指定尺寸图像为2张。当移动到第 90 百分位数时,桌面网站上未指定尺寸的图像数量上升至26张,移动为23张。在页面上有未指定尺寸的图像可能会导致布局偏移;然而,一个重要的方面是这些图像是否影响视口,若是,影响程度如何。

中位移动网站的未指定尺寸图像高度约为 100 像素。我们的测试设备具有 512 像素的移动视口高度,代表了几乎 20% 的屏幕宽度。当加载未指定尺寸的(全宽)图像时,这可能会导致显著的偏移。

  • 字体

字体可以直接影响 CLS。当网页字体异步加载时,从页面初步渲染到自定义字体应用之间会有延迟。在此期间,浏览器通常会使用后备字体显示文本,这些字体与网页字体可能在尺寸(宽度、高度、字母间距)上有所不同。当网页字体最终加载时,文本可能会移动以适应新尺寸,导致可见的布局偏移,从而贡献了更高的 CLS 得分。

使用系统字体是一种解决此问题的方法。然而,85% 的移动页面使用网页字体,所以它们在短期内不太可能停止使用。一种控制使用网页字体的网站视觉稳定性的方法是使用 font-display 属性在 CSS 中控制字体的加载和显示。不同的 font-display 策略可以根据团队对性能和美观之间权衡决定使用。

从上图数据可以看到,约 44% 的移动和桌面网站使用 font-display:swap,23% 的网站使用 font-display:block。9% 的网站将 font-display 属性设置为 auto,3% 设置为 fallback。仅约 1% 的网站使用 optional 策略。

与 2022 年数据相比,所有 font-display 策略的使用都有明显增加,尤其是 swap,其在移动和桌面页面上的使用从 2022 年的约 30% 增加到超过 44%。

既然大多数 font-display 策略可能会导致 CLS,我们需要寻找其他策略来最小化潜在问题。其中一种是使用资源提示确保第三方字体尽早被发现并加载。

大约 11% 的被测试移动和桌面页面在预加载其网页字体,告诉浏览器应下载这些文件,希望足够早地避免字体迟到导致的偏移。需要注意的是,错误使用预加载可能会损害性能而不是帮助它。为了避免这一点,我们需要确保预加载的字体将被使用,并且我们不会预加载过多的资源。预加载过多的资源可能会延迟其他更重要的资源。

18% 的网站使用 preconnect 与第三方来源建立早期连接。与 preload 类似,重要的是谨慎使用该资源提示而不过度使用。

  • 动画

非合成的 CSS 动画也是意外偏移的原因之一。这些动画涉及更改影响多个元素布局或外观的属性,迫使浏览器执行更多的高强度步骤,如重新计算样式、重新排列文档和在屏幕上重新绘制像素。最佳实践是使用如 transformopacity 之类的 CSS 属性。

39% 的移动页面和 42% 的桌面页面仍使用非合成动画,从 2022 年的分析中移动端略增 1%,桌面端略增 1%。

最后

  • 2024年网页性能继续改善,多个关键指标呈现积极趋势。新的INP指标使网站交互性评估更全面准确,希望能进一步推动性能优化。
  • 依然存在挑战,例如桌面和移动设备INP性能差距显著。展示延迟主要由第三方脚本引起,如用户行为追踪和CDN脚本。
  • 视觉稳定性通过采用良好实践,如适当的图像大小和保留动态内容的空间不断提高,近期Chrome浏览器bfcache兼容性变化让更多网站受益于更快的前进后退导航。


本文章是对报告内容关键部分的解读,报告原文请查看:https://almanac.httparchive.org/en/2024/performance


推荐阅读  点击标题可跳转

1、Vue.js 高调宣布:我们将成为最快的响应式框架!

2、重磅!Chrome 被强制出售?谷歌或将抛弃 ChromeOS 全面转向 Android 系统

3、“应该禁止所有新项目使用 React!”微软资深工程师犀利 diss:“React 是行业标准”简直胡说!