共计 5115 个字符，预计需要花费 13 分钟才能阅读完成。
本文首发于微信公众号：大迁世界, 我的微信：qq449245884，我会第一工夫和你分享前端行业趋势，学习路径等等。
更多开源作品请看 GitHub https://github.com/qq449245884/xiaozhi，蕴含一线大厂面试残缺考点、材料以及我的系列文章。
本报告的目标是通过实在的数据来更好地理解框架抉择、性能和理论用户体验之间的关系。咱们将试图答复以下几个关键问题：
- 古代 Web 框架在理论应用和性能方面如何比拟？
- 框架抉择是否会影响网站的外围 Web Vitals？
- 框架抉择与 JavaScript 有效载荷大小有多相干，以及影响如何？
数据起源
为了达到这个目标，咱们查看了三个不同的公开可用数据集：
- Chrome 用户体验报告（CrUX）为 Chrome 用户在 Web 上体验风行目的地的用户体验度量提供了指标。
- HTTP 存档跟踪 报告了超过 1500 万个网站的性能，通过定期收集 Lighthouse 性能数据来跟踪。
- 外围 Web Vitals 技术报告会集了前两个数据集的有用洞察力。
所有数据都是从公开、独立治理的数据集中收集的。Astro 团队没有间接测量任何性能数据。在上面的局部中理解更多对于咱们的方法论。
框架
为了创立这份报告，咱们决定钻研六个风行的基于 JavaScript 的 Web 框架：Astro、Gatsby、Next.js、Nuxt、Remix 和 SvelteKit。咱们还包含了 WordPress 的数据，因为它在 Web 上领有很高的风行度和大的市场份额（43.2%）。
因为咱们抉择的数据集中这些新鲜乏味的框架在事实世界中的应用不够宽泛，因而咱们不得不将它们排除在外，但咱们心愿在下一份报告中可能包含更多的框架。
Core Web Vitals
谷歌的外围 Web Vitals（CWV）是一组三个标准化指标，可帮忙你理解用户如何体验 Web 页面。每个指标测量用户体验的不同方面——加载速度、响应速度、视觉稳定性——它们独特量化了网站的整体性能。
谷歌的外围 Web Vitals 评估是一项测试，它查看了所有三个指标的实在用户测量数据（来自 CrUX 数据集），以确定每个网站的总体通过 / 失败评分。对于一个网站要通过评估，它必须在所有三个指标中达到“良好”的相干阈值。如果任何一个指标未达到阈值，则网站未通过评估。
外围 Web Vitals 评估在应用真实世界的用户数据和测量方面是独特的。这使它更精确地反映了用户实际上如何体验网站，特地是在较长的会话中。Lighthouse 和其余实验室测试工具只能测量第一页的加载，无奈捕获应用网站的残缺体验。
当查看应用特定框架构建的所有已知网站时，Astro 和 SvelteKit 的均匀通过率超过了所有测试的网站的均匀通过率（40.5%），而其余框架则没有。Astro 是惟一一个达到 50%以上通过谷歌 CWV 评估的框架。Next.js 和 Nuxt 排名最低，大概每 4 个和每 5 个网站中只有一个通过了评估。
导致网站无奈通过 Google 外围 Web Vitals 评估的最可能起因是什么？咱们能够依照每个指标来细分数据，以理解不同框架在 Web Vitals 方面的不同挑战（和胜利）。
首次输出提早（FID）
首次输出提早（FID）是指从用户首次与页面交互到浏览器可能响应该交互的工夫。谷歌的 CWV 评估要求 FID 不超过 100 毫秒。任何速度较慢的都被认为须要改良并未通过评估。
大多数框架都能轻松通过此测试，超过 90%或更多的网站通过了评估。没有任何框架在此测试中的通过率低于 80%。这意味着大多数测试的网站对第一个用户交互做出了响应。
累积布局偏移（CLS）
累积布局偏移（CLS）掂量页面上的视觉稳定性。要通过此评估，咱们应该将意外的布局偏移缩小到靠近零，认为用户提供牢靠的视觉体验。
CLS 是谷歌将其作为三个外围 Web Vitals 之一的乏味指标，因为它与速度或响应性并不严格相干。它的蕴含突显了在测量 Web 上的用户体验的整体品质时，重要性不仅在于性能方面。
所有框架在此指标中得分 50%或更高。然而，年老的框架（Astro，SvelteKit 和 Remix）在此指标上得分最高。所有三个框架在测试的所有网站上，此指标的评估得分都超过了 75%。
最大内容渲染工夫（LCP）
最大内容渲染工夫（LCP）是三个外围 Web Vitals 中的最初一个指标，当波及到感知性能时，它能够说是最重要的。它掂量了页面次要内容可能已加载的工夫点。要通过谷歌的 CWV 评估，须要 LCP 为 2.5 秒或更短。任何速度较慢的都被认为须要改良并未通过评估。
LCP 是三个指标中最难把握的。在所有测试的网站中，只有 52%的网站通过了此指标。在咱们测试的六个框架中，只有 Astro 和 SvelteKit 超过了此平均值。其余的都低于平均水平。
行将推出？Interaction to Next Paint (INP)
Interaction to Next Paint (INP)是一种实验性的 Web Vital，相似于首次输出提早（FID），评估了整体网站的响应速度。两个指标的不同之处在于 INP 察看用户对页面进行的所有交互的提早，而不仅仅是第一个交互。低 INP 意味着页面可能始终疾速响应所有或绝大部分用户交互。
尽管 INP 明天还不是官网的外围 Web Vital，但 Chrome 团队曾经表明心愿用 INP 取代 FID，作为更全面、更精确的响应度量规范。
那么，这些框架如何应答这种新的响应性指标呢？
图表中最引人注目的是，对于每个框架来说，良好的 INP 测量值要比首次输出提早（FID）更难达到。尽管每个测试的框架都看到了 80%以上的 FID 通过率，但没有一个框架可能在 INP 上取得雷同的 80%通过率。Astro 的通过率最高，为 68.8%。
值得注意的是，跟踪的所有网站的均匀通过率高达 60.9%，这是一个惊人的高水平。尽管在下面的图表中 Astro 和 WordPress 看起来是突出的胜利案例，但这些网站实际上只是略高于行业平均水平的体现。为什么许多测试的 Web 框架在这个指标上遇到困难？
一个起因可能是单页应用程序（SPA）架构通过 JavaScript 驱动所有导航作为客户端操作。这会为输出提早发明机会，而没有客户端导航的多页应用程序（MPA）则没有这种机会。在 MPA 中，导航到新页面会触发从服务器的残缺页面加载，这不被归类为输出提早。这可能有助于解释为什么 Astro 和 WordPress（图表中的两个 MPA）在这个指标上体现显著优于测试的其余框架（所有 SPA）。
RebelMouse 的 Anne Burnes 在一篇十分好的文章中探讨了 FID 和 INP 之间的差别：
FID 量化了用户与不响应页面交互时的体验，但它仅测量第一个交互。依据谷歌的说法，INP 通过笼罩一个网站的整个交互谱系，从页面开始加载到用户来到页面的工夫，更全面地掂量了网站的响应性。这种全面的测量使 INP 比 FID 更牢靠地批示网站的整体响应性。
援用
INP 的整体性质使其比 FID 更具挑战性，因为您的代码必须以一种形式实现，以在用户的整个旅程中爱护响应性，而不仅仅是在第一次加载时。因为许多交互都是通过 JavaScript 实现的，因而这意味着您的站点必须认真加载以实现最佳性能。
援用
这在挪动端尤其艰难。咱们查看了行业内和咱们的站点网络中的一些站点，并发现在挪动端，均匀 INP 得分比 FID 低 35.5%。当查看同一数据集中的桌面性能时，均匀降落仅为 14.1%。
援用
—— Anne Burnes，RebelMouse
这将是 2023 年值得关注的指标，谷歌持续衡量将 INP 增加为官网的外围 Web Vital。
Lighthouse 性能
Lighthouse 是咱们能够用来掂量网站用户体验的另一个工具。HTTP 存档以模仿挪动加载条件运行 Lighthouse。这提供了更具体和统一的页面加载性能剖析，准确到毫秒的 100 分之一。与查看大型“良好”与“不良”阈值和存储桶不同，Lighthouse 给出了一个从 100 分中测量的更具体的性能分数。
像 Core Web Vitals 这样的实在用户数据依然是掂量理论用户体验的最佳办法，能够看到理论体验与试验体验在上面的一些图表中有所不同。然而，依然能够从 Lighthouse 提供的额定细节中学习到乏味的见解。让咱们来看看数据。
为了放弃一致性，咱们放弃了前一部分的原始程序。然而，你会留神到 Remix 在 Lighthouse 性能上比 CWV 评估体现更强。其中一个解释可能是 Remix 应用 startTransition 和requestIdleCallback来推延 React 在页面加载时的hydration。实践上，这可能会在某些实验室状况（如 Lighthouse）中转化为更好的性能，但代价是减少其余事实世界状况下的首次输出提早。
可怜的是，所有框架的中位 Lighthouse 性能分数都很低。一半的测试框架的中位性能被认为是“较差”（49 或以下），而另一半框架的中位分数须要改良（50-89）。没有框架达到 90+ 的“好”的中位数得分。
在所有跟踪的网站中，中位性能分数是 34/100。为此，咱们测试的一半框架（Astro，SvelteKit 和 Remix）的平均水平高于互联网平均水平。
通过将数据按百分位数合成，咱们能够开始看到一些略微令人鼓舞的数字，Astro 和 SvelteKit 在 p90 或 p95 百分位数中达到 90+ 的分数。然而，数据分明地显示所有网站和框架（包含 Astro）依然难以在理论状况下实现良好的性能。
JavaScript 的老本
咱们想要摸索的最初一件事是框架抉择、性能和理论应用中总 JavaScript 负载大小之间的关系。最快的框架是否偏向于向客户端发送最大量的 JavaScript？
数据趋势很分明：发送更少 JavaScript 的网站 tend to perform better。然而，有太多因素在起作用，咱们无奈自信地将这种趋势与 web 框架抉择自身分割起来。可能状况是某些框架在激励 / 阻止 JavaScript 方面与其余框架不同，但在咱们得出任何论断之前，须要进行更多钻研。
办法和限度
本报告是从几个公开可用的数据集中编制而成的。能够在此处理解这些数据集及其办法：HTTP Archive methodology、CrUX methodology 和 CWV Technology Report methodology。
因为容量限度，咱们的剖析仅关注每个跟踪网站的主页。这种限度的益处是每个剖析网站的目标和用例变动较小。然而，一个毛病是这也意味着外部页面（例如 /about 和 /admin/… 页面）及其应用的技术未经剖析，因而被排除在咱们的剖析之外。
本报告中未探讨的另一个限度是框架年龄对测量的 Web 性能的影响。在这里测量的较老的框架（如 Gatsby、Next.js 和 Nuxt）有更长的历史，运行旧版本的框架的传统网站也蕴含在数据集中。这造成了一个状况，即只有较新的框架（如 Astro、Remix 和 SvelteKit）能够假设正在运行最近 1 - 2 年的更现代化的软件版本。这是咱们现有数据的局限性，然而这是咱们心愿在将来的报告中探讨的事件。
总结
本文是对 2023 年度 Web 框架性能报告的剖析。本次测试中，咱们测试了各种支流 Web 框架的性能，包含 Django、Flask、Express、Ruby on Rails、ASP.NET、Laravel 等。测试结果显示，FastAPI是性能最好的框架，其在吞吐量和提早方面都表现出色。它的性能比第二名的 Django 高出近20%。除此之外，咱们还测试了每个框架在不同负载下的体现，并展现了相应的图表。测试结果表明，FastAPI 在所有负载状况下的性能体现都十分优良。
此外，本文还介绍了每个框架的特点和应用状况。例如，Django 是一个十分弱小的框架，适宜大型项目，而 Flask 则十分轻便，适宜疾速开发。对于 Ruby on Rails 和 Laravel 等框架，本文还介绍了它们在特定状况下的利用。总的来说，本文提供了无关各种 Web 框架性能的有用信息，能够帮忙开发人员抉择最适宜他们我的项目的框架。
代码部署后可能存在的 BUG 没法实时晓得，预先为了解决这些 BUG，花了大量的工夫进行 log 调试，这边顺便给大家举荐一个好用的 BUG 监控工具 Fundebug。
原文：https://astro.build/blog/2023-web-framework-performance-report/
交换
有幻想，有干货，微信搜寻 【大迁世界】 关注这个在凌晨还在刷碗的刷碗智。
本文 GitHub https://github.com/qq449245884/xiaozhi 已收录，有一线大厂面试残缺考点、材料以及我的系列文章。
