要构建能快速加载的网站，第一步就是要及时获得
服务器对网页 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 请求以检索资源。还有 有两种重定向：
- 完全发生在源站内的同源重定向。这些类型 的重定向次数完全由您控制 它们完全位于您的网络服务器中。
- 由其他来源启动的跨域重定向。这些类型的 重定向通常不受您的控制。
跨源重定向通常用于广告、网址缩短服务 第三方服务。虽然跨域重定向不在您的控制范围之内， 您可能仍需要检查是否避免了多次重定向，例如， 广告链接到 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 毫秒。
您可能还需要检查您的托管基础架构，并确认 拥有足够的资源来处理您的网站所获得的流量。已分享 托管服务提供商通常容易受到较高的 TTFB 的影响，而 但响应时间更短，费用可能更高。
<ph type="x-smartling-placeholder">压缩
HTML、JavaScript、CSS 和 SVG 图片等文本响应应 通过压缩来减少其通过网络的传输大小 下载速度会更快最常用的压缩算法是 gzip 和 Brotli。与 gzip 相比，Brotli 可将性能提升约 15% 至 20%。
压缩功能通常由大多数网站托管服务提供商自动设置，但 如果您打算配置 或自行调整压缩设置：
- 尽可能使用 Brotli。如前所述，Brotli 提供了相当 与 gzip 相比，效果得到显著提升，并且 Brotli 在所有主流 浏览器。请尽可能使用 Brotli，但如果您的网站的使用率很高， 确保使用 gzip 作为后备 因为任何压缩都比完全不压缩好。
- 文件大小很重要。非常小的资源（小于 1 KiB）不会压缩 有时甚至根本不压缩。任意类型的有效性 但前提是拥有大量数据 为了找到更可压缩的位 数据。文件越大，压缩效果就越好，但请勿 但实际上 。JavaScript 和 CSS 等大型资源 浏览器完成分析和评估后， 解压缩了，并且可能会更频繁地更改，即使只有 因为任何更改都会产生不同的文件哈希值。
- 了解动态压缩与静态压缩。动态和静态 压缩是确定资源应何时使用的不同方法 压缩。动态压缩会在资源 请求，有时则每次请求。另一方面 静态压缩提前压缩文件，无需压缩 您请求 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 标头可以包含多个指标。
哪种类型的服务器最有可能离您的终端 用户？
下一篇：了解关键路径
现在，您已经熟悉了涉及到的一些性能注意事项 与网站的 HTML 结合使用，则更有利地确保它能够加载 但这仅仅是学习 Web 的开始 性能接下来，关键渲染路径背后的理论是 。本单元将介绍一些关键概念，例如阻塞渲染和 解析阻塞资源，以及它们在获取网页初始 以便尽快呈现在浏览器中