性能优化 - HTML 性能的一般注意事项
想要构建快速高效稳定的Web应用程序，需要我们在细节上做文章，毕竟进步都是点滴积累，今天来看下HTML性能的一般注意事项。
前序
当您在浏览器的地址栏中输入网址时，浏览器会向服务器发送 GET 请求进行检索。网页的第一个请求针对的是 HTML 资源，因此，确保 HTML 以最短延迟快速到达是关键性能目标。
尽量减少重定向
在请求资源时，服务器可能会做出一个重定向响应，该重定向可以是永久重定向（301 Moved Permanently 响应）或临时重定向（302 Found 响应）。
重定向会降低网页加载速度，因为它需要浏览器在新位置发出额外的 HTTP 请求来检索资源。重定向有两种类型：
- 完全发生在源站内的同源重定向。这些类型的重定向完全由您控制，因为管理它们的逻辑完全位于您的 Web 服务器上。
- 由其他源启动的跨域重定向。这些类型的重定向通常无法控制。
广告、网址缩短服务和其他第三方服务通常会使用跨源重定向。虽然跨源重定向超出了您的控制范围，但您可能仍需要检查是否避免了多次重定向。例如，将广告链接到 HTTP 网页，而该网页又重定向到其 HTTPS 等效网页，或者跨源重定向到达您的来源，但随后触发同源重定向。
缓存 HTML 响应
缓存 HTML 响应很困难，因为响应可能包含指向其他关键资源（例如 CSS、JavaScript、图片和其他资源类型）的链接。这些资源的文件名中可能包含唯一指纹，该指纹会根据文件的内容而变化。这意味着，缓存的 HTML 文档可能会在部署后变得过时，因为它包含对过时子资源的引用。（现代前端工程化打包后的资源hash值随时在变，会产生较多这样的问题）
不过，较短的缓存生命周期（而不是不缓存）具有诸多优势，例如允许在 CDN 中缓存资源，减少从源服务器传送的请求数量，以及在浏览器中传送资源，从而重新验证资源而不是再次下载。此方法最适合在任何上下文中不会更改的静态内容，并且可以将缓存资源的适当时间设置为您认为合适的分钟数。将静态 HTML 资源花五分钟的时间是一个可靠的选择，可以确保定期更新不会引起注意。
如果网页的 HTML 内容以某种方式进行了个性化（例如针对经过身份验证的用户），那么您很有可能因各种问题（包括安全性和新鲜度）而根本不想缓存内容。如果用户浏览器缓存了 HTML 响应，您就无法使缓存失效。因此，在此类情况下，最好避免完全缓存 HTML。
缓存 HTML 的一种审慎方法是使用 ETag 或 Last-Modified 响应标头。ETag（也称为实体标记）标头是一个标识符，用于唯一标识所请求资源，通常使用资源内容的哈希值：
1 | |
Last-Modified 响应标头包含资源的最后修改日期和时间：
1 | |
测量服务器响应时间
如果响应未缓存，则服务器的响应时间在很大程度上取决于您的托管服务提供商和后端应用堆栈。与动态网页相比，提供动态生成的响应（例如从数据库获取数据）的网页的 TTFB 可能更高，无需在后端投入大量计算时间即可立即提供。如果显示加载旋转图标，然后在客户端提取所有数据，则会将工作从更加可预测的服务器端环境移至可能不可预测的客户端环境。最大限度地减少客户端工作量通常可以改进以用户为中心的指标。
如果用户在字段遇到 TTFB(TTFB 是 Time to First Byte 的缩写，指的是浏览器开始收到服务器响应数据的时间) 缓慢的问题，您可以使用 Server-Timing 响应标头公开有关时间在服务器上的什么位置的信息：
1 | |
Server-Timing 标头的值可以包含多个指标，以及每个指标的时长。然后，可以在现场使用 Navigation Timing API 从用户那里收集这些数据，并进行分析，以了解用户是否遇到延迟。在前面的代码段中，响应标头包含两个显示时间：
对用户进行身份验证的时间 (auth)，用时 55.5 毫秒。
数据库访问时间 (db)，用时 220 毫秒。
压缩
基于文本的响应（例如 HTML、JavaScript、CSS 和 SVG 图片）应进行压缩，以减小通过网络传输时的大小，从而加快其下载速度。最常用的压缩算法是 gzip 和 Brotli。Brotli 比 gzip 提高了约 15% 到 20%。