HTML 性能的一般注意事项

要构建能快速加载的网站，第一步就是要及时获得 服务器对网页 HTML 的响应。当您在 浏览器地址栏，那么浏览器会向服务器发送 GET 请求， 检索它。网页的第一个请求是针对 HTML 资源，并且 确保 HTML 以尽可能短的延迟快速呈现是关键 目标。

最初的 HTML 请求会经历几个步骤，每个步骤 一段时间。通过减少每个步骤所花的时间，您可以更快完成 第一个字节 (TTFB)。虽然 TTFB 并不是衡量转化、 至于网页加载速度，较高的 TTFB 确实会导致网页难以覆盖用户 指定的“良好”Largest Contentful Paint 等指标的阈值， (LCP) 和 First Contentful Paint (FCP)。

<ph type="x-smartling-placeholder">

尽量减少重定向

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

重定向会降低网页加载速度，因为它要求浏览器 在新位置发送额外的 HTTP 请求以检索资源。还有 有两种重定向：

  1. 完全发生在源站内的同源重定向。这些类型 的重定向次数完全由您控制 它们完全位于您的网络服务器中。
  2. 由其他来源启动的跨域重定向。这些类型的 重定向通常不受您的控制。

跨源重定向通常用于广告、网址缩短服务 第三方服务。虽然跨域重定向不在您的控制范围之内， 您可能仍需要检查是否避免了多次重定向，例如， 广告链接到 HTTP 网页，而 HTTP 网页又重定向至其 HTTPS 或到达您的源站的跨源重定向，但 会触发同源重定向。

<ph type="x-smartling-placeholder">

缓存 HTML 响应

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

不过，缓存生命周期较短（而不是没有缓存）可能具有诸多优势， 例如允许在 CDN 上缓存资源，从而减少 从源服务器和浏览器中发出的请求，允许 重新验证资源，而不是重新下载资源。这种方法适用于 最适合在任何上下文中都不会变化的静态内容， 可以将资源缓存时间设置为您认为 应该的分钟数 适当的选择。将静态 HTML 资源设置为 5 分钟是稳妥的选择，而且可以确保 因此，定期更新不会被忽略

如果网页的 HTML 内容以某种方式个性化（例如 那么您可能完全不希望为某个经过身份验证的用户 包括安全问题 和时效性如果 HTML 响应为 您无法使缓存失效。时间是 因此，在这种情况下最好避免完全缓存 HTML。

一种谨慎的 HTML 缓存方法是使用 ETag 或 Last-Modified 响应标头。ETag - 也称为实体 tag — 标头是唯一表示所请求资源的标识符， 通常使用资源内容的哈希进行：

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

每当资源发生变化时，都必须生成新的 ETag 值。已开启 后续请求，浏览器会通过ETag If-None-Match 请求标头。如果服务器上的 ETag 与 服务器会返回 304 Not Modified 响应， 浏览器会使用缓存中的资源虽然这仍然会导致 网络延迟，304 Not Modified 响应会比整个响应小得多 HTML 资源。

但是，重新验证资源新鲜度所涉及的网络延迟为 但也有自己的缺点与 Web 开发的许多其他方面一样， 权衡和妥协是不可避免的。您可以自行决定 以这种方式缓存 HTML 的额外工作是值得的，或者，如果 确保安全，根本无需缓存 HTML 内容。

<ph type="x-smartling-placeholder">

测量服务器响应时间

如果响应没有缓存，则服务器的响应时间与 托管服务提供商和后端应用堆栈提供 动态生成的响应（例如从数据库中提取数据） 其 TTFB 可能会比 在后端没有大量计算时间。显示 加载旋转图标，然后在客户端获取所有数据， 从可预测性的服务器端环境转变为可能 客户端一个。尽可能减少客户端的工作量通常可以改善 以用户为中心的指标

如果用户在字段中遇到 TTFB 缓慢的问题，您可以透露相关信息， 使用 Server-Timing 了解在服务器上花费的时间 响应标头：

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

Server-Timing 标头的值可以包含多个指标，以及 每个时段的播放时长然后，系统可从现场的用户收集这些数据 Navigation Timing API，并进行了分析，以了解用户 延误。在上述代码段中，响应标头包含两个时间：

  • 对用户进行身份验证所用的时间 (auth)，耗时 55.5 毫秒。
  • 数据库访问时间 (db)，耗时 220 毫秒。
。 <ph type="x-smartling-placeholder">

您可能还需要检查您的托管基础架构，并确认 拥有足够的资源来处理您的网站所获得的流量。已分享 托管服务提供商通常容易受到较高的 TTFB 的影响，而 但响应时间更短，费用可能更高。

<ph type="x-smartling-placeholder">

压缩

HTML、JavaScript、CSS 和 SVG 图片等文本响应应 通过压缩来减少其通过网络的传输大小 下载速度会更快最常用的压缩算法是 gzip 和 Brotli。与 gzip 相比，Brotli 可将性能提升约 15% 至 20%。

压缩功能通常由大多数网站托管服务提供商自动设置，但 如果您打算配置 或自行调整压缩设置：

  1. 尽可能使用 Brotli。如前所述，Brotli 提供了相当 与 gzip 相比，效果得到显著提升，并且 Brotli 在所有主流 浏览器。请尽可能使用 Brotli，但如果您的网站的使用率很高， 确保使用 gzip 作为后备 因为任何压缩都比完全不压缩好。
  2. 文件大小很重要。非常小的资源（小于 1 KiB）不会压缩 有时甚至根本不压缩。任意类型的有效性 但前提是拥有大量数据 为了找到更可压缩的位 数据。文件越大，压缩效果就越好，但请勿 但实际上 。JavaScript 和 CSS 等大型资源 浏览器完成分析和评估后， 解压缩了，并且可能会更频繁地更改，即使只有 因为任何更改都会产生不同的文件哈希值。
  3. 了解动态压缩与静态压缩。动态和静态 压缩是确定资源应何时使用的不同方法 压缩。动态压缩会在资源 请求，有时则每次请求。另一方面 静态压缩提前压缩文件，无需压缩 您请求 Google Analytics API 时静态压缩消除了 压缩本身涉及的延迟时间，这可能会增加服务器响应时间 。静态资源 JavaScript、CSS 和 SVG 图片）应进行静态压缩，而 HTML 尤其是为进行身份验证动态生成的资源 用户）都应进行动态压缩。

自行进行压缩颇具挑战，通常最好 内容分发网络 (CDN) - 具体内容将在下一部分讨论， 为您处理此问题。不过，了解这些概念可以帮助您 您的托管服务提供商是否正确使用了压缩功能。这些知识可以 可以帮助您找出优化压缩设置的机会， 让您的网站获得最大收益。

内容分发网络 (CDN)

内容分发网络 (CDN) 是分布式服务器网络， 从您的源服务器缓存资源，继而从边缘提供这些资源 物理位置更靠近用户的服务器商家的实际距离 这样用户就可以缩短往返时间 (RTT)，而 HTTP/2 或 HTTP/3、缓存和压缩可让 CDN 更快地传送内容 与从您的源服务器提取相比。利用 CDN 在某些情况下，可以显著提高网站的 TTFB。

<ph type="x-smartling-placeholder">

知识测验

哪种类型的重定向完全由您控制？

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

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

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

哪种类型的服务器最有可能离您的终端 用户？

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

下一篇：了解关键路径

现在，您已经熟悉了涉及到的一些性能注意事项 与网站的 HTML 结合使用，则更有利地确保它能够加载 但这仅仅是学习 Web 的开始 性能接下来，关键渲染路径背后的理论是 。本单元将介绍一些关键概念，例如阻塞渲染和 解析阻塞资源，以及它们在获取网页初始 以便尽快呈现在浏览器中