HTML 性能的一般注意事项

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

对 HTML 的初始请求会经历多个步骤，每个步骤都需要花费一些时间。缩短每个步骤所花费的时间可缩短第一字节时间 (TTFB)。虽然 TTFB 并不是衡量网页加载速度时唯一需要关注的指标，但较高的 TTFB 确实会使 Largest Contentful Paint (LCP) 和 First Contentful Paint (FCP) 等指标难以达到指定的“良好”阈值。

尽量减少重定向

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

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

  1. 完全在您的来源内发生的同源重定向。这些类型的重定向完全由您控制，因为用于管理它们的逻辑完全位于您的 Web 服务器上。
  2. 由其他来源发起的跨源重定向。此类重定向通常不受您的控制。

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

缓存 HTML 响应

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

不过，较短的缓存生命周期（而不是不缓存）也有一些好处，例如允许在 CDN 中缓存资源（从而减少从源服务器提供服务的请求数量），以及在浏览器中允许重新验证资源，而不是再次下载资源。此方法最适合在任何情况下都不会更改的静态内容，并且可以将缓存资源的时间设置为您认为合适的分钟数。对于静态 HTML 资源，5 分钟是一个保险的选择，可确保定期更新不会被忽略。

如果网页的 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 从实际用户那里收集这些数据，并进行分析以了解用户是否遇到延迟。在上述代码段中，响应标头包含两个时间：

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

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

压缩

HTML、JavaScript、CSS 和 SVG 图片等基于文本的响应应进行压缩，以减小其通过网络传输的大小，从而更快地下载。最常用的压缩算法是 gzip 和 Brotli。Brotli 比 gzip 提高了大约 15% 到 20%。

大多数网站托管服务提供商通常会自动设置压缩，但如果您可以自行配置或调整压缩设置，则需要考虑以下几个重要事项：

  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 性能的开始。接下来，我们将介绍关键渲染路径背后的理论。本模块介绍了关键概念，例如渲染阻塞资源和解析阻塞资源，以及它们在尽快获取浏览器中的网页初始渲染方面的作用。