通用 HTML 性能考量因素

构建快速加载的网站的第一步是及时收到服务器对页面 HTML 的响应。当您在浏览器的地址栏中输入网址时，浏览器会向服务器发送 GET 请求以检索该网址。对网页的第一个请求是针对 HTML 资源，确保 HTML 快速到达且延迟最小是关键的性能目标。

HTML 的初始请求会经历几个步骤，每个步骤都需要一些时间。减少每个步骤花费的时间可以加快您的首字节时间 (TTFB)。虽然 TTFB 不是您在页面加载速度方面应关注的唯一指标，但较高的 TTFB 确实使达到最大内容渲染时间 (LCP)和首次内容渲染时间 (FCP)等指标的指定“良好”阈值变得具有挑战性。

最大限度地减少重定向

当请求资源时，服务器可能会以重定向进行响应，可以是永久重定向（301 Moved Permanently 响应）或临时重定向（302 Found 响应）。

重定向会降低页面加载速度，因为它需要浏览器在新位置发出额外的 HTTP 请求才能检索资源。有两种类型的重定向

  1. 同源重定向，完全发生在您的来源内。这些类型的重定向完全在您的控制范围内，因为管理它们的逻辑完全位于您的 Web 服务器上。
  2. 跨源重定向，由另一个来源发起。这些类型的重定向通常超出您的控制范围。

跨源重定向通常由广告、网址缩短服务和其他第三方服务使用。虽然跨源重定向超出您的控制范围，但您可能仍然希望检查是否避免多次重定向，例如，广告链接到 HTTP 页面，而 HTTP 页面又重定向到其 HTTPS 等效页面，或者跨源重定向到达您的来源，但随后触发同源重定向。

缓存 HTML 响应

缓存 HTML 响应很困难，因为响应可能包含指向其他关键资源（例如 CSS、JavaScript、图片和其他资源类型）的链接。这些资源可能在其各自的文件名中包含唯一指纹，该指纹会根据文件的内容而变化。这意味着您的缓存 HTML 文档在部署后可能会变得陈旧，因为它将包含对过时的子资源的引用。

尽管如此，较短的缓存生存期（而不是不缓存）可能具有优势，例如允许在 CDN 中缓存资源（从而减少从源服务器提供的请求数量），以及在浏览器中，允许重新验证资源而不是再次下载资源。此方法最适合在任何上下文中都不会更改的静态内容，并且可以将缓存资源的适当时间设置为您认为合适的分钟数。静态 HTML 资源的五分钟是一个安全的选择，并确保不会忽略定期更新。

如果页面的 HTML 内容以某种方式进行了个性化设置（例如针对经过身份验证的用户），您很可能根本不希望缓存内容，原因有很多，包括安全性和新鲜度。如果 HTML 响应被用户的浏览器缓存，您将无法使缓存失效。因此，在这些情况下，最好完全避免缓存 HTML。

缓存 HTML 的谨慎方法可能是使用 ETag 或 Last-Modified 响应标头。ETag（也称为实体标记）标头是一个唯一表示所请求资源的标识符，通常通过使用资源内容的哈希

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

每当资源更改时，都必须生成新的 ETag 值。在后续请求中，浏览器通过 If-None-Match 请求标头发送 ETag 值。如果服务器上的 ETag 与浏览器发送的 ETag 匹配，则服务器会以 304 Not Modified 响应进行响应，并且浏览器使用缓存中的资源。虽然这仍然会产生网络延迟，但 304 Not Modified 响应远小于整个 HTML 资源。

但是，重新验证资源新鲜度所涉及的网络延迟仍然是其自身的缺点。与 Web 开发的许多其他方面一样，权衡和妥协是不可避免的。这取决于您来确定以这种方式缓存 HTML 的额外工作是否值得，或者最好保持安全并完全不费心缓存 HTML 内容。

衡量服务器响应时间

如果未缓存响应，则服务器的响应时间在很大程度上取决于您的托管服务提供商和后端应用程序堆栈。提供动态生成的响应（例如从数据库中获取数据）的网页的 TTFB 可能高于可以立即提供的静态网页，而无需后端进行大量计算。显示加载微调器，然后在客户端获取所有数据，会将工作从更可预测的服务器端环境转移到可能不可预测的客户端环境。最大限度地减少客户端工作通常会改善以用户为中心的指标。

如果用户在实际环境中遇到缓慢的 TTFB，您可以使用 Server-Timing 响应标头公开有关服务器花费时间的信息

Server-Timing: auth;dur=55.5, db;dur=220

Server-Timing 标头的值可以包含多个指标，以及每个指标的持续时间。然后可以使用 Navigation Timing API 从实际环境中使用 Navigation Timing API 收集此数据并进行分析，以查看用户是否遇到延迟。在前面的代码段中，响应标头包含两个计时

  • 验证用户身份的时间 (auth)，耗时 55.5 毫秒。
  • 数据库访问时间 (db)，耗时 220 毫秒。

您可能还需要查看您的托管基础设施，并确认您有足够的资源来处理您的网站接收的流量。共享托管服务提供商通常容易出现高 TTFB，而提供更快响应时间的专用解决方案可能更昂贵。

压缩

应压缩基于文本的响应（例如 HTML、JavaScript、CSS 和 SVG 图片），以减小其在网络上的传输大小，以便它们可以更快地下载。最广泛使用的压缩算法是 gzip 和 Brotli。Brotli 比 gzip 提高了约 15% 到 20%。

压缩通常由大多数 Web 托管服务提供商自动设置，但如果您可以配置或调整压缩设置，则需要考虑一些重要事项

  1. 尽可能使用 Brotli。 如前所述，Brotli 比 gzip 提供了相当明显的改进，并且所有主流浏览器都支持 Brotli。尽可能使用 Brotli，但如果您的网站被大量使用旧版浏览器的用户使用，请确保使用 gzip 作为后备方案，因为任何压缩都胜过不压缩。
  2. 文件大小很重要。 非常小的资源（小于 1 KiB）的压缩效果不佳，有时甚至根本不压缩。任何类型的数据压缩的有效性都取决于拥有大量数据，压缩算法可以使用这些数据来查找更多可压缩的数据位。文件越大，压缩效果越好，但是，不要仅仅因为大型资源可以更有效地压缩而交付非常大的资源。大型资源（例如 JavaScript 和 CSS）在浏览器解压缩它们后需要花费更多时间来解析和评估，并且即使它们仅发生细微更改也可能更频繁地更改，因为任何更改都会导致不同的文件哈希。
  3. 了解动态与静态压缩。 动态压缩和静态压缩是何时应压缩资源的不同方法。动态压缩在请求资源时压缩资源，有时每次请求资源时都压缩资源。另一方面，静态压缩提前压缩文件，在请求时无需执行压缩。静态压缩消除了压缩本身所涉及的延迟，这在动态压缩的情况下会增加服务器响应时间。静态资源（例如 JavaScript、CSS 和 SVG 图片）应进行静态压缩，而 HTML 资源（尤其是为经过身份验证的用户动态生成的 HTML 资源）应进行动态压缩。

自己正确进行压缩具有挑战性，通常最好让内容分发网络 (CDN)（将在下一节中讨论）为您处理此问题。但是，了解这些概念可以帮助您辨别您的托管服务提供商是否正确使用了压缩。这些知识可以帮助您找到改进压缩设置的机会，以便它们为您的网站带来最大收益。

内容分发网络 (CDN)

内容分发网络 (CDN)是一个分布式服务器网络，它缓存来自您的源服务器的资源，然后从物理上更靠近用户的边缘服务器提供这些资源。与用户的物理接近度缩短了往返时间 (RTT)，而 HTTP/2 或 HTTP/3、缓存和压缩等优化使 CDN 能够比从您的源服务器获取内容更快地提供内容。在某些情况下，使用 CDN 可以显着改善您网站的 TTFB。

测试您的知识

哪种类型的重定向完全在您的控制范围内？

跨源重定向。
请重试。
同源重定向。
正确！

Server-Timing 标头可以包含多个指标。

正确。
正确！
错误。
请重试。

哪种类型的服务器最有可能在物理上最靠近您的最终用户？

您网站的源服务器。
请重试。
内容分发网络 (CDN) 的边缘服务器。
正确！

接下来：了解关键路径

现在您已经熟悉了网站 HTML 涉及的一些性能考量因素，您可以更好地确保它可以尽可能快地加载，但这只是学习 Web 性能的开始。接下来，将介绍关键渲染路径背后的理论。本模块介绍了关键概念，例如渲染阻塞和解析阻塞资源，以及它们在尽快在浏览器中获得页面初始渲染方面所起的作用。