原文链接：astro.build/blog/2023-w…

这份报告的目的是查看实际数据，以更好地理解框架选择、性能和实际用户体验之间的关系。我们将尝试阐明以下几个关键问题：

• 现代 Web 框架在实际使用和性能方面如何比较？
• 框架选择是否会影响网站的核心 Web 基准？
• 框架选择与 JavaScript 负载大小的相关性如何，并有什么影响？

数据

为了阐明上述的问题，我们查看了三个不同的公开数据集：

• Chrome用户体验报告（CrUX）为实际使用 Chrome 的用户体验流行网站提供用户体验指标。
• HTTP存档跟踪和报告超过1500万个网站的性能，定期收集 Lighthouse 性能数据。
• Core Web Vitals技术报告从前两个数据集中收集有用的信息。 所有数据都来自公开、独立管理的数据集。 Astro团队没有直接测量任何性能数据。通过下面的部分了解更多我们的方法论。

框架

为了更好的写这份报告，我们决定研究基于JavaScript的六个流行web框架：Astro, Gatsby, Next.js, Nuxt, Remix, 和 SvelteKit。我们的数据也包含了来自WordPress的,毕竟它在Web上拥有巨大的市场份额（43.2%）。

核心 Web 基准

Google的核心Web体验指标（CWV）是一组三个标准化指标，可帮助您了解用户如何体验网页。每个指标都衡量不同方面的用户体验，包括加载速度、响应能力和视觉稳定性，它们共同量化了网站的整体性能。

谷歌的核心Web体验指标评估是一项测试，它查看所有三个指标的真实用户测量数据（来自CrUX数据集），以确定每个网站的总体通过/失败等级。为了通过测试，网站必须在所有三个指标中都达到“良好”阈值。如果任何指标未达到阈值，网站则无法通过评估。

CWV 评估在使用真实世界的用户数据和测量方面是独一无二的。这使得它可以更准确地反映用户实际体验网站的方式，尤其是在较长的会话期间。Lighthouse和其他实验室测试工具只能测量首页的加载速度，无法捕捉使用网站的完整体验。 当查看使用特定框架构建的所有已知网站时，Astro和SvelteKit超过了所有已测试网站的平均通过率（40.5％），而其余框架则没有。Astro是唯一一个覆盖超过 50% 的网站并通过 Google 的 CWV 评估的框架。Next.js和Nuxt在整个框架中的表现最差，Next.js 和 Nuxt 垫底，分别有大约四分之一和五分之一的网站通过了评估。

网站未通过 Google 的核心网络活力评估的最可能原因是什么？我们可以按单个指标分解数据，以深入了解不同框架在 Web Vitals 方面的挣扎（和成功）之处。

首次输入延迟 (FID)

首次输入延迟(FID)测量从用户首次与页面交互，到浏览器能够响应该交互的时间。Google 的 CWV 评估寻找 100 毫秒或更短的 FID。任何较慢的东西都被认为需要改进并且未通过评估。

大多数框架都轻松通过了这个测试，超过 90% 或更多的网站通过了评估。没有框架在此测试中的通过率低于 80%。这意味着大多数被测试的网站都会对第一次用户交互做出响应。

累积布局偏移 (CLS)

累积布局偏移 (CLS)测量页面上的视觉稳定性。为了通过这个评估，你应该将不必要的布局偏移减少到接近零，从而为你的用户提供可靠的视觉体验。

CLS 是 Google 将其作为三个核心网络生命力之一的有趣指标，因为它并非严格与速度或响应能力有关。它的包含强调了在衡量Web用户体验的整体质量时，重要性不仅仅在于性能方面的考虑，还需要考虑更多因素。

所有框架在此指标中的得分都在 50% 或更高。然而，在这个指标上得分最高的是最年轻的框架（Astro、SvelteKit 和 Remix）。在所有测试的网站上，这三者在对该指标的评估中得分超过 75%。

最大内容绘画 (LCP)

最大内容绘画 (LCP)是三个 Core Web Vitals 中的最后一个，在感知性能方面可以说是最重要的。它测量页面的主要内容可能加载的时间点。通过 Google 的 CWV 评估需要 2.5 秒或更短的 LCP。任何较慢的东西都被认为需要改进并且未通过评估。

LCP 是三个指标中最难掌握的。在所有测试的网站中，仅有 52% 通过了这个指标。在我们测试的六个框架中，只有 Astro 和 SvelteKit 超过了这个平均水平。其余的框架得分均低于平均水平。

即将推出？与 Next Paint 的交互 (INP)

交互到下一个绘制 (INP) 是一个实验性的 web 核心指标，用于评估整体网站的响应能力，类似于首次输入延迟 (FID)。这两个指标的不同之处在于， INP 观察用户与页面进行的所有交互的延迟，而不仅仅是第一次交互。低的INP意味着页面能够持续快速响应所有或绝大多数用户交互。

虽然INP今天还不是官方的核心Web指标，但Chrome团队已经表达了他们的希望用INP替代FID作为更全面、准确的响应能力测量指标。

那么，这些框架在这个新的响应能力指标上表现如何呢？

图表中最值得注意的是，对于每个框架而言，良好的 INP 测量比首次输入延迟 (FID)更难实现。每个测试的框架在FID上都有80%以上的通过率，但没有一个框架能够在INP上获得相同的80%通过率。Astro最接近，通过率为68.8%。

值得注意的是，所有跟踪网站的平均通过率高达惊人的 60.9%。虽然在上面的图表中，Astro和WordPress看起来是显著的成功者，但事实上，这些网站的表现只是略高于行业平均水平。为什么许多经过测试的Web框架在这个指标上表现不佳呢？

其中一个原因可能是，单页应用（SPA）架构通过 JavaScript 作为客户端操作驱动所有导航。这就为输入延迟创造了机会，而无客户端导航的多页面应用（MPA）则没有这个问题。在MPA中，导航到新页面会从服务器触发完整的页面加载，这不被归类为输入延迟。这可能有助于解释为什么Astro和WordPress（图表中的两个MPA）在这个指标上的表现明显优于其他经过测试的框架（所有的SPA）。

RebelMouse的Anne Burnes对FID和INP之间的区别有一个很好的解释：

FID 量化了用户在尝试与不响应的页面进行交互时的体验，但它仅测量第一个交互。根据 Google 的说法，INP通过覆盖页面从开始加载到用户离开的整个交互过程，更全面地衡量了站点的响应能力。这种全面的测量使INP成为一个比FID更可靠的站点响应能力指标。

INP的整体特性使其比FID更难解决，因为您的代码必须以一种保护用户整个交互过程的方式进行实现，而不仅仅是在第一次加载时。由于许多交互是通过JavaScript完成的，这意味着您的站点必须谨慎加载，以获得优化的性能。

这在移动设备上尤其困难。我们查看了整个行业和我们网站网络内的一些网站，发现移动 INP 分数平均比 FID 低 35.5%。在查看同一数据集的桌面性能时，平均仅下降了 14.1%。

——安妮伯恩斯叛逆鼠

这将是 2023 年值得关注的一个有趣指标，谷歌继续考虑将 INP 添加为官方 Core Web Vital。

灯塔表演

灯塔是我们可以用来衡量网站用户体验的另一种工具。HTTP Archive 在模拟的移动加载条件下运行 Lighthouse。这提供了更详细和一致的页面加载性能分析，可以精确到100毫秒的时间间隔。与查看大型“好”与“坏”阈值和桶不同，Lighthouse为您提供了一个以100分为单位的更详细的性能得分。

像 Core Web Vitals 这样的真实用户数据仍然是真实用户体验的最佳衡量标准，您可以在下面的一些图表中看到真实体验与实验室体验的不同之处。然而，从Lighthouse提供的额外细节中仍然可以获得有趣的见解。让我们看一下数据。

为了保持一致性，我们保留了上一节中的原始顺序。但是，您会注意到 Remix 在 Lighthouse 上的表现似乎比在 CWV 评估中的表现要强得多。对此的一种解释可能是 Remix 对andstartTransition的使用requestIdleCallback在页面加载时延迟 React hydration。在某些实验室情况下（例如Lighthouse），这理论上可以转化为更好的性能，但代价是在其他真实情况下增加了首次输入延迟。

不幸的是，所有框架的中位数Lighthouse性能分数都很低。一半的框架的中位数性能被认为是“差”（49或更低），而另一半则是中等的（50-89）。没有任何框架达到了90以上的“好”的中位数分数。

在所有跟踪的网站中，中位数性能得分是34/100。因此，我们测试的一半框架（Astro，SvelteKit和Remix）的中位数得分高于互联网平均水平。

通过按百分位数分解数据，我们可以开始看到一些稍微更令人鼓舞的数字，其中 Astro 和 SvelteKit 在 p90 或 p95 百分位数中达到 90+ 的分数。然而，数据清楚地表明，所有网站和框架（包括 Astro）仍然在实际情况下难以实现良好的性能。

JavaScript 的成本

我们想要探索的最后一个问题是框架选择、性能和实际使用中 JavaScript 有效载荷大小之间的关系。最快的框架是否往往也是向客户端发送最少量 JavaScript 的框架？

数据的趋势很明显：发布较少 JavaScript 的网站往往表现更好。然而，有太多因素在起作用，我们无法自信地将这种趋势与 Web 框架本身的选择联系起来。某些框架可能会以不同于其他框架的方式鼓励/阻止 JavaScript，但在我们得出任何结论之前还需要进行更多的研究。

方法论和局限性

本报告是从几个公开可用的数据集中编制而成。您可以在此处了解有关这些数据集及其方法的更多信息：HTTP 存档方法, CrUX 方法论， 和CWV 技术报告方法.

由于容量限制，我们的分析只查看每个跟踪网站的主页。这种限制的好处之一是每个分析网站的目的和用途变化较小。但是，缺点是这也意味着内部页面（如/about和/admin/...页面）和及其使用的技术未得到分析，因此被排除在我们的分析之外。

本报告中未探讨的另一个限制是框架的年龄对测量 Web 性能的影响。此处测量的旧框架（Gatsby、Next.js、Nuxt）具有更长的遗留网站尾部，运行旧版本的框架，这些版本包含在数据集中。这会导致只能假定运行更现代软件的较新框架（Astro，Remix，SvelteKit）来自过去1-2年的版本。这是我们现有数据的限制，但我们希望在未来的报告中探讨这一点。