你的 SSR 很慢，而且你的开发者工具在欺骗你

作为开发人员，我们希望我们的网站能够快速运行，而要打造一个性能卓越的网站则需要很多小的改进。

我想特别谈谈两个性能因素，以及你的开发者工具可能会如何误导你，让你觉得它们不值得追求，从而导致用户体验变慢。这两个因素是渲染和流式传输。

渲染

让我们从渲染开始。事实上，我们很多人使用的工具主要专注于客户端更新，来构建网站。对于这些工具来说，最简单的方法通常是在服务器上复制浏览器环境来生成初始 HTML，所以很多工具都是这么做的——无论是功能齐全的无头浏览器、jsdom 还是虚拟 dom。

在这个范围的较轻端（vdom），性能通常被认为“足够好”，通常是几十毫秒，而专门构建的基于字符串的 HTML 渲染器可能更像是 1 毫秒。

这些框架还会执行一个称为“hydration”的过程，该过程通常涉及将大量数据序列化到浏览器，以使页面具有交互性。此序列化过程会消耗宝贵的 CPU 时间，并进一步延迟响应。

好吧，但是页面加载多花 50 毫秒真的重要吗？也许没关系。但如果是并发请求呢？要知道，渲染是一项 CPU 密集型（阻塞）任务：如果渲染需要 50 毫秒，而 10 个请求几乎同时（发往同一个渲染进程）到达，那么第 10 个请求需要等待 450 毫秒才能开始工作并做出响应。查看单个请求的响应时间并不能反映全部情况。

流媒体

接下来是流式传输。具体来说，就是在获得渲染整个页面所需的所有数据之前，提前刷新 HTML。如果不使用流式传输，页面速度将与最慢的上游依赖项一样慢。流式传输将“首字节时间 (TTFB)”与数据源解耦，使浏览器能够更早地开始渲染和获取已知资源。根据上游数据源的速度，这可能会产生重大影响。

它不仅会影响您的 TTFB，还能加速首次内容绘制 (FCP)，从而更早地显示可用内容和加载指示器。并且，根据页面的细分程度，它还能让加载更早、分段地进行。最终，流式加载还能对可交互时间 (TTI) 产生积极的影响。

即使你的数据源速度很快，最坏的情况也是你的内容最终会同时到达最终用户。但是，当你的 API、数据库或网络出现延迟异常时，流式传输可以为你提供帮助。

在 Devtools 中模拟减速

如果你正在测试性能，你通常需要了解最坏的情况。对于使用配备 10 Gigabit 以太网的 Mac Studio M1 Ultra 的用户来说，一切都看起来很快。不，你想了解你的网站对于使用老款 Android 设备的用户在信号不稳定的蜂窝网络上的体验如何。而最后一种情况，慢速网络，正是我们遇到麻烦的地方。

devtools 模拟慢速网络的方式隐藏了服务器延迟的影响。如果我们深入研究“慢速 3G”和“快速 3G”等预设值的作用，就能明白其中的原因：

您会看到这里有一个“延迟”设置，它可以确保请求至少需要那么长时间，但是......

如果已达到指定的延迟，DevTools 不会添加额外的延迟。——
Matt Zeunert，DebugBear

什么？那么，在“慢速 3G”模式下，延迟为 2 秒，这意味着无论服务器是立即响应，还是需要整整 2 秒才能响应，devtools 显示的请求时间都是一样的吗？没错。

你可以自己尝试一下。对比一下这两个页面在没有 devtools 网络限制和开启“慢速 3G”的情况下的耗时：

• https://restless-cake-d61e.mlrawlings.workers.dev/?ttfb=0
• https://restless-cake-d61e.mlrawlings.workers.dev/?ttfb=2000

总结

你会注意到我这里没有包含任何确切的数字。服务器架构之类的因素会影响这些因素的相关性。请在真实设备和网络上进行测试。更重要的是，关注实际用户的体验——尤其是在长尾部分。

在真正测试这些方面之前，我们常常会被锁定在某一类 SSR 性能上，这很无助。如果你已经使用前面提到的某个以客户端为中心的工具构建了你的应用，你可能需要重新考虑这个决定，或者寄希望于在其他地方找到足够的优势。

虽然可能还有其他因素会影响网站的性能，但提高服务器响应速度只会事半功倍。千万别被开发者工具蒙蔽了：如果某个程序在快速网络上运行速度较慢，那么在慢速网络上运行速度也会更慢。