我们测量了 6 个 JS 框架的 SSR 性能 - 以下是我们的发现

2025-05-24

我们测量了 6 个 JS 框架的 SSR 性能 - 以下是我们的发现

如果说有相当多的 JS 框架可供选择,那么今年的轻描淡写就是了。

似乎每隔几个月就会有一个新的、革命性的框架进入生态系统,并承诺提供前所未有的性能和/或易用性。

现在已经到了我们几乎需要一个框架来选择我们的下一个框架( Yo Dawg )的地步

尽管对于开发人员来说,能够休假并回来而不必再学习另一个框架是一件好事,但我们也很喜欢它。

前端开发人员正在研究新的 JavaScript 框架

新的框架常常会给 JS 生态系统带来创新。这体现在我们构建应用程序的方式上,以及应用程序的性能上。

这些性能改进有助于突破可能的界限 - 因此,也有助于激励其他框架实施类似的解决方案。

但现在有一个有趣的问题:不同框架之间的性能差异真的那么大吗?这正是我们想要回答的问题。

然而,正如那句令人毛骨悚然的谚语所说:“条条大路通罗马”🙀

由于这篇文章的标题可能已经被剧透了,我们选择测试哪个框架在 SSR(服务器端渲染)方面速度最快。

结果很有趣,但就像一级方程式赛车一样,好与伟大的区别往往就在几毫秒之间。

但在我们深入讨论细节之前,首先要声明一下。

🔔 免责声明 - 您的里程可能会有所不同!

任何做过性能测试的人都会告诉你,结果可能会有所不同。即使你尽力使测试条件尽可能统一,结果仍然会有所不同。

我们尝试过以类似的方式设置每个演示。然而,在我们当时不熟悉的某个特定框架中,可能有更好的方法来实现这一点。

如果您觉得某些内容可以改进或改变,请发表评论或发送电子邮件至info@enterspeed.com。每个演示的源代码都可以在我们的演示仓库中找到:https://github.com/enterspeedhq/enterspeed-demos

认识 6 位参赛者

我们选择的 6 位参赛者包括一些最流行的框架和一些较新、更受关注的框架。

我们测试的框架是:

  • Astro:Github 上有 18,200 颗星,创建于 2021 年 3 月
  • Gatsby:Github 上有 53,400 颗星,创建于 2015 年 5 月
  • Next.js:Github 上 91,800 颗星,创建于 2016 年 10 月
  • Nuxt 3:Github 上有 8.7k 个星,创建于 2021 年 3 月
  • Remix:Github 上有 19k 个星,创建于 2020 年 10 月
  • SvelteKit:Github 上有 10.1k 个 stars,创建于 2020 年 10 月

所有 6 个框架都是使用 SSR 设置的。

什么是 SSR?

SSR 代表服务器端渲染,是一种在服务器上将您的应用程序转换为 HTML 的渲染策略。

其他一些渲染策略包括:

  • CSR——客户端渲染,在浏览器中渲染。
  • SSG——静态站点生成,在构建时生成 HTML(因此仅获取一次数据)。
  • ISR - 增量静态再生,它是 SSG 和 SSR 的组合,允许您在构建网站后创建或更新静态页面。

与使用 CSR 呈现其内容的传统 SPA(单页应用程序)不同,SSR 提供​​了更快的“内容时间”,并且更有利于 SEO,因为爬虫程序将看到完全呈现的页面。

我们建造什么

其中一个演示的屏幕截图<br>

我们为每个框架复制的演示站点是一个包含 6 篇博文的精美博客。

它使用 Tailwind 进行样式设计并从 Enterspeed(一个高性能数据存储)获取其内容。

额外信息 - 所有缩略图均使用Dall-E 2生成,包含以下短语:

  • “一只猫驾驶一级方程式赛车的数字艺术”
  • “骆驼驾驶战斗机,像素艺术”
  • “一只酷酷的、无所畏惧的蜜蜂骑着摩托车”
  • “一只猎鹰以照片写实风格飞越外太空”
  • “一个人跑赢了一只猎豹,数字艺术”
  • “一张泰迪熊骑着火箭的照片”

所有演示均公开并托管在 Netlify 上:

所有演示的 GitHub 仓库可以在这里找到:https://github.com/enterspeedhq/enterspeed-demos

我们测量了什么以及如何测量

为了衡量我们 JS 框架的 SSR 性能,我们使用了 Google Lighthouse(此处为Web.dev/measure)。我们运行了 5 次审核,并计算了每个指标的平均值。

💡 下面将进一步解释每个指标(和首字母缩略词)。

Google Lighthouse 衡量核心网络生命力(LCP、FID、CLS),这已成为 Google 搜索算法中的排名因素,以及其他网络生命力(FCP、速度指数、TTI、TBT 和 CLS)。

我们没有测量 FID(首次输入延迟),因为这在实验室中无法测量。然而,TBT(总阻塞时间)在实际应用中与 FID 具有良好的相关性。

CLS(累积布局偏移)也不包括在结果中,因为所有演示在此类别中的得分均为 0。

最后,我们想要测量 TTFB(第一个字节的时间),因为它可以帮助测量与 SSR 高度相关的 Web 服务器响应能力。

为了测量 TTFB,我们使用了hey,我们向每个演示​​发送 250 个请求并测量平均 TTFB。

我们注意到,在向 Netlify 上托管的站点发送请求时结果波动很大,因此我们选择在本地运行每个应用程序并以此方式进行测量。

我们还选择将并发工作者的数量从 50 减少到 1,因为我们的 Nuxt 3 应用程序在发送多个请求时不断崩溃。

每个指标的含义是什么?

所有指标(TTFB 除外)均基于 Google 的倡议:Web vitals。Google制定这些指标是为了为质量信号提供统一的指导。

✂️ 解释摘自Web.dev

Google Lighthouse 性能得分

Google Lighthouse 中的性能得分范围是 0 到 100。它是 Web Vitals 得分的加权平均值。每个 Web Vital 的权重如下:

  • 首次内容绘制:10%
  • 速度指数:10%
  • 最大内容绘制:25%
  • 交互时间:10%
  • 总阻塞时间:30%
  • 累计布局偏移:15%

绩效分数分为三类(差、需要改进和良好):需要改进,

  • 0 至 49(红色):差
  • 50 至 89(橙色):需要改进
  • 90 至 100(绿色):良好

注意:要获得 100 分的“完美”分数是极其困难的,而且并非意料之中。

首次内容绘制 (FCP)

首次内容绘制 (FCP) 指标测量从页面开始加载到页面内容的任何部分在屏幕上呈现的时间。

速度指数

速度指数衡量页面加载过程中内容的视觉显示速度。

最大内容绘制 (LCP)

最大内容绘制 (LCP) 指标报告视口内可见的最大图像或文本块的渲染时间(相对于页面首次开始加载的时间)。

交互时间(TTI)

TTI 指标测量从页面开始加载到其主要子资源加载完成的时间,并且能够快速可靠地响应用户输入。

总阻塞时间(TBT)

总阻塞时间 (TBT) 指标测量首次内容绘制 (FCP) 和交互时间 (TTI) 之间的总时间,其中主线程被阻塞的时间足够长,以防止输入响应。

第一个字节的时间(TTFB)

TTFB 是一种衡量资源请求和响应的第一个字节开始到达之间的时间的指标。

结果

请击鼓...结果如下。

Google Lighthouse 性能得分

1. 🏆 Astro - 99,2

  1. SvelteKit-99

  2. Nuxt 3 & Remix - 98.8

  3. Next.js - 98.6

  4. 盖茨比-95.6

首次内容绘制 (FCP)

1.🏆Astro、Gatsby 和 Remix - 0.8 秒

  1. Next.js 和 SvelteKit - 0.9

  2. Nuxt 3 - 1,1

速度指数

1.🏆 SvelteKit - 2.3 秒

  1. Astro & Remix - 2.8秒

  2. Nuxt 3 - 2.9秒

  3. Next.js - 3.2 秒

  4. 盖茨比 - 5.6秒

最大内容绘制 (LCP)

1. 🏆 Astro - 0.8 秒

  1. SvelteKit-0.9秒

  2. Next.js、Nuxt 3、Remix - 1.2 秒

  3. 盖茨比 - 1.9秒

交互时间(TTI)

1. 🏆 Astro - 0.8 秒

  1. SvelteKit-1.0秒

  2. Nuxt 3 - 1.2秒

  3. Remix & Gatsby - 1.5秒

  4. Next.js - 1.7 秒

总阻塞时间(TBT)

1. 🏆 Astro - 0 毫秒

  1. Nuxt 3 - 20毫秒

  2. 盖茨比 - 28毫秒

  3. 混音 - 30毫秒

  4. SvelteKit - 36毫秒

  5. Next.js - 54毫秒

第一个字节的时间(TTFB)

1.🏆 SvelteKit - 62ms

  1. Next.js - 63 毫秒

  2. 盖茨比 - 133毫秒

  3. 混音 - 136毫秒

  4. Astro-137毫秒

  5. Nuxt - 438毫秒

结论

JS 框架的愤怒暴徒

现在,现在,在你开始烧毁这个地方之前,请记住我们在开始时所说的话 - 你的里程可能会有所不同!

根据我们的结果,Astro 似乎确实是班上新生中速度较快的孩子 - 尽管在 TTFB 方面表现不佳。

然而,TTFB 结果也可能是开发服务器没有展现出其最佳的一面。

SvelteKit 也取得了一些令人印象深刻的成果,也是在速度方面获得很多赞誉的新框架之一。

这是否意味着你应该跳过其他框架,选择这两个框架中的一个?绝对不是。

每个框架都有其用例和优势。我们个人非常喜欢 Next.js 提供的所有出色功能。

此外,许多人使用多种渲染策略,例如,主页使用 SSG,博客页面使用 SSR/ISR 等等。

因此,选择最适合您需求的框架。

🩸🔥 你是不是还在热血沸腾,需要冷静一下?别担心,我们帮你

Enterspeed 是什么?🏎

Enterspeed是一个高性能数据存储,它可以通过组合您的服务来获得速度和灵活性。

将所有服务连接并整合到单个 API 端点。使用我们的低代码编辑器轻松转换数据,获取您所需的一切——所有内容都存储在我们极速的边缘网络中。

本文使用 Enterspeed 来确保数据层(博客文章)在所有测试中具有高性能和一致性。

文章来源:https://dev.to/enterspeed/we-measured-the-ssr-performance-of-6-js-frameworks-heres-what-we-found-1ck0
PREV
云计算学习路线图:什么是云计算?第一步:学习基础知识 第二步:学习云计算 第三步:培养云计算技能 第四步:练习、练习、再练习 第六步:加入云计算社区
NEXT
创建一个快速的网站超级简单😏