前端性能优化（六）：测试和监控

Front-End Performance Checklist 2021[1]
https://www.smashingmagazine....
前端性能优化（一）：准备工作[2]
前端性能优化（二）：资源优化[3]
前端性能优化（三）：构建优化[4]
前端性能优化（四）：传输优化[5]
前端性能优化（五）：网络与HTTP/2[6]

一、优化审计工作流程

这听起来可能没什么大不了的，但是你轻而易举的正确设置可能会为你节省相当多的测试时间。考虑使用Tim Kadlec的Alfred工作流来提交一个测试到 WebPageTest 的公共实例。事实上，WebPageTest 有很多晦涩的功能，所以花点时间学习如何阅读 WebPageTest瀑布视图图表[7]以及如何阅读 WebPageTest连接视图图表[8]以更快地诊断和解决性能问题。

你还可以从 Google电子表格驱动WebPageTest，并将可访问性、性能和 SEO 分数与 Lighthouse CI 导入到你的Travis设置中，或直接导入到 Webpack 中。

看看最近发布的 AutoWebPerf，这是一个模块化工具，可以从多个来源自动收集性能数据。例如，我们可以在你的关键页面上设置每日测试，以捕获来自 CrUX API 的现场数据和来自 PageSpeed Insights 的 Lighthouse 报告的实验室数据。

如果你需要快速调试某些东西，但你的构建过程似乎非常缓慢，请记住"对于大多数 JavaScript，无需详细的代码转换，空格去除和符号修改占缩小代码大小减少的 95%。你可以只需禁用压缩即可将 Uglify 构建速度提高 3 到 4 倍。"

（一）WebPageTest

访问www.webpagetest.org，输入你的网站即可得到结果。

1、瀑布视图图表[7]

翻译自Matt Hobbs的How to read a WebPageTest Waterfall View chart[7]

（1） 基本布局

■ Key

显示三种类型的信息：

● 有关连接状态的信息（DNS查找、连接建立、SSL协商）
● 请求的资源类型（如HTML、图像等）
● 杂项事件（wait、JavaScript执行）

每个资源有 2 种颜色，浅色和深色。浅色表示浏览器发出资源请求的时间点，深色是资源实际下载的点。

“wait”可视化是WPT的新增功能。它显示从浏览器首次发现页面上的资源到浏览器向服务器发出资源请求之间的时间。

■ Request list

浏览器在页面上发现的资产列表以及请求它们的顺序，请注意最左侧的请求编号，如果请求是通过安全连接 (HTTPS) 发出的，请注意黄色锁。

■ Request timeline

时间线显示沿水平 (x) 轴的时间与垂直 (y) 轴上的每个请求。从中你可以看到浏览器发出的请求的生命周期：从发现（wait），到发出请求，最后到下载资产。

确保此时间线涵盖尽可能少的时间，因为这表明整体性能更好。时间线越细，用户加载页面的速度就越快。

■ CPU Utilisation

显示设备上运行的浏览器进程的 CPU 利用率的简单图表。它显示当前网页在任何时间点使用的 CPU 数量。它的范围为 0 - 100% 利用率。

■ Bandwidth In

这是数据何时进入浏览器的指示器。可视化有助于查看浏览器是在做有用的工作还是在浪费时间。绝对比例可以忽略，因为它不是很准确。如果你想要更准确的结果，请使用 WebPageTest 主页上高级选项卡中的“捕获网络数据包跟踪 (tcpdump)”选项。

■ Browser main thread

该图可视化了浏览器主线程在任何特定时间点（x 轴）正在执行的操作。y 轴显示 0 - 100% 的百分比。颜色是从 Chrome DevTools CPU 图表（在性能选项卡下）复制的。以下是每种颜色的含义：

● 橘色 - 脚本解析、评估和执行 
● 紫色 - 布局 
● 绿色 - 绘画 
● 蓝色 - HTML 解析 
● 灰色 - 用于任务处理的主线程时间未计入其他类别 

使用此图可以查看 CPU 是否正在成为上述区域之一的瓶颈。

■ Page is interactive(Long Tasks)

此图指示主线程何时被阻塞。红色块表示主线程已经被阻塞了 50 毫秒（这也会阻塞像按钮按下这样的输入）。绿色表示线程没有被阻塞。注意：在红色阻塞阶段仍然可以滚动，因为对于大多数浏览器，滚动通常是在主线程之外处理的。

注意：截至 2021 年 2 月，"Page is interactive"已重命名为"Long Tasks"。一切都保持不变，只是名称更改。

（2）Vertical lines

■ Start Render - Green line

这是用户将看到绘制到页面上的像素的第一个点。像素可以来自任何东西（背景颜色、边框等），不一定是内容。在此之前，屏幕是空白的。该指标是通过分析在页面加载期间捕获的单个视频帧来衡量的。

■ First Contentful Paint - Light green line

这是浏览器在屏幕上呈现与导航前视觉上不同的任何内容（即 WPT 的空白屏幕）的点。如果测试浏览器支持 PerformanceObserver API，则使用浏览器的性能时间线报告此指标。因此，该值是它认为将第一个内容绘制到视口的时间。

■ Largest Contentful Paint - Dark green dashed line

Largest Contentful Paint 是一个重要的指标，它是 Core Web Vitals 的一部分。这是一个以用户为中心的指标，可帮助开发人员了解网页的感知性能。实际上，它报告相对于页面开始加载时在视口内可见的最大图像或文本块的渲染时间。

■ Layout Shift - Orange dashed line

页面累积布局偏移 (CLS) 分数是 Core Web Vitals 的另一个指标。以用户为中心的指标，用于衡量页面的整体稳定性。WebPageTest 将突出显示测试浏览器 API 检测到的每个意外布局偏移。意外的布局转换不是由用户输入（例如按下按钮）引发的。

注意：你可以在瀑布图上有多个布局转换线，因为在测试期间你可以有多个布局转换。布局移位线是键中发生这种情况的唯一一行。

■ DOM Interactive - Yellow line

浏览器完成所有 HTML 的解析，DOM 构建完成的时刻。不幸的是，这不是一个可靠的指标。

■ DOM Content Loaded - Pink line

加载和解析 HTML 并且浏览器到达文档末尾的点。所有阻塞脚本都已加载并运行，此时的 DOM 已完全定义。注意key中这条线的粗细。这是为了表明这条线涵盖了一段持续时间，而不是瀑布中的单个时间点。

■ On Load - Lavender line

窗口加载事件触发的点。所有对象都在 DOM 中，所有图像和脚本都已完成加载。注意这条线的粗细。这是为了表明这条线涵盖了一段持续时间，而不是瀑布中的单个时间点。

■ Document Complete - Blue line

触发 onload 事件且所有静态图像内容已加载的点。由 JavaScript 执行触发的内容更改可能不包括在内。

（3）Horizontal timings

即请求时间线。如果你单击单个请求，你将看到一个包含更多信息的弹窗，如下例所示：

（4）The HTML

请求详细时间如下：

● Discovered（发现）：0.011 秒
● Request Start（请求开始）：0.116 秒
● DNS Lookup（DNS 查找）：27 毫秒
● Initial Connection（初始连接）：25 毫秒
● SSL Negotiation（SSL 协商）：43 毫秒
● Time to First Byte（第一个字节到达的时间）：315 毫秒
● Content Download（内容下载）：40 毫秒

（5）A third-party JavaScript file

此请求与检查的其他请求不同，因为该文件来自不同的域。请求详细时间如下：

● Discovered（发现时间）：0.473 秒
● Request Start（请求开始）：0.702 秒
● DNS Lookup（DNS 查找）：28 毫秒
● Initial Connection（初始连接）：39 毫秒
● SSL Negotiation（SSL 协商）：153 毫秒
● Time to First Byte（第一个字节到达的时间）：48 毫秒
● Content Download（内容下载）：9 毫秒

请注意浏览器需要再次进行整个连接协商（DNS、连接、SSL 协商），因为该文件存在于不同的域中。这为请求增加了相当多的时间（28 + 39 + 153 = 220 毫秒）。

（6）A sponsor PNG

通过这个请求，浏览器发现了一个 PNG 图像并从服务器请求它。请求详细时间如下：

● Discovered（发现）：0.652 秒
● Request Start（请求开始）：0.824 秒
● Time to First Byte（第一个字节到达的时间）：214 毫秒
● Content Download（内容下载）：28 毫秒

等待时间是通过从请求开始时间中减去发现时间来计算的。等待时间是从浏览器第一次找到资产到它有能力向服务器发送请求的时间。

此请求后的持续时间是从发出请求到完成请求所用的时间（第一个字节时间 + 内容下载）。由于与域的连接已经建立，因此不需要 DNS、连接、SSL 协商。

（7）GIF file moved

该请求的背景是黄色的，这是表示服务器响应状态代码不是通常的 200。在本例中，它是 302 状态代码，表示 GIF 文件已被临时移动。事实上，所有带有 3xx 状态代码的响应都将具有黄色背景。请求详细信息如下：

该请求不需要建立 TCP 连接，这是因为它已经在请求 20 中针对该域发生了。

错误状态代码 4xx 和 5xx 以类似的方式显示，只有背景是红色的，如下例所示（此图像来自不同的测试）：

请注意此实例中返回的资源响应的颜色，它不是图像的预期紫色，而是表示它是 HTML 页面的蓝色。或者，换句话说，因为找不到资产，所以服务器响应 404 页面。

（8）Download chunks

较浅的颜色表示已发出请求并且浏览器正在等待响应，较深的颜色表示特定资源的字节正在传送到浏览器。有时这不会同时发生。这会导致看起来像斑马条纹，随着时间的推移，浏览器正在滴灌字节。这些称为下载块（红色箭头）。

这是因为并行下载大量资产产生资源竞争。

（9）Inline script execution

如果你的页面中有许多内联脚本（Google Analytics、Dreamweaver MM_preloadImages 等）。它们将如何被可视化？

在这里，我们看到浏览器正在下载 HTML 块，然后在非常接近这些下载的地方，我们看到 JavaScript 执行行（粉红色）。这是来自正在执行的页面中内联的 JavaScript。如果你在浏览器主线程中仔细观察，你将看到 HTML 解析（蓝色）和非常小的黄色滑行以指示 JavaScript 执行。

（10）Updated JavaScript execution visualisation

最近WebPageTest更新了瀑布图上的JavaScript执行视图，可区分JavaScript运行非常密集还是只是短暂但快速的重复执行：

现在，当 JavaScript 执行被渲染时，你并不总是只看到一个粉红色的实心块。粉红色执行条的高度表示 JavaScript 运行的速度。快速但频繁的 JavaScript 执行将具有非常短的高度条，它们不再占据视图的主导地位。

（11）Different First Byte values

在表格的最左侧，有一列"First Byte"，当你单击页面 HTML 请求时，你还会看到"Time to First Byte"。这两个值是不同的，顶部表格中的"First Byte"是所有这些值的总和（Discovered + DNS + Connect + SSL + TTFB），它基本上是从 navigationStart 到浏览器从服务器接收第一个字节数据所花费的时间。而"Time to First Byte"只是从请求开始到收到第一个数据字节的时间。

常见场景：

■ DNS-prefetch

DNS Prefetch 告诉浏览器在不久的将来需要对另一个域进行 DNS 查找。因此，与其等待，不如立即开始查找。到真正需要域时，浏览器只需要完成 TCP 握手和可选的 SSL 协商。

■ Preconnect

Preconnect 允许开发人员给浏览器一个“提示”，在不久的将来也需要连接域。通过尽早连接到域，连接将不需要在瀑布中稍后建立，从而允许在需要时更快地请求和下载来自所述域的资产。

■ Prefetch

Prefetch 允许开发人员告诉浏览器在当前导航中预取资源（例如 CSS、JS、HTML文档），因为它可能在以后需要。例如，如果你知道大多数用户从你的主页导航到特定页面（例如，可能是你的登录页面），你可以决定预取它，以便在需要时它已经存在于用户浏览器缓存中。

WebPageTest 在弹出窗口中为我们提供了一些信息，让我们知道这是一个预取提示：

● Priority: IDLE（在详细信息选项卡下）
● purpose: prefetch（在请求选项卡下）

在 WebPageTest 中，在 Chrome 中进行测试时，它被列为priority: IDLE。这映射到 DevTools 中的最低优先级（根据 Chromium 文档中的资源优先级和调度）。所以 prefetch 是一个可选的并且通常是低优先级的提取，浏览器会尽可能晚地加载。这与 preload 不同，preload 是强制获取并在浏览器中获得高优先级。使用 preload 加载的资源会阻塞布局，因此请谨慎使用它，否则它实际上可能会降低感知性能。

■ Preloading

Preload 用于提高所选资源的加载优先级。开发人员可以告诉浏览器：“这个资源很快就会被需要，所以马上加载它”。加载网络字体时经常使用这种技术。

在没有使用preload的情况下，当加载 Web 字体时，浏览器首先需要下载 HTML 和 CSS，然后解析它们以创建渲染树。只有此时浏览器才能请求字体。这可能导致所谓的不可见文本闪烁 (FOIT) 和无样式文本闪烁 (FOUT)。解决此问题的一种方法是使用 preload 指令立即请求 Web 字体文件。

使用preload：

不使用preload：

■ HTTP/1.1 vs HTTP/2

HTTP/1.1

■ OSCP

在线证书状态协议 (OCSP) 是一种用于获取 SSL 证书吊销状态的 Internet 协议。浏览器验证证书的一种方法是连接到 OCSP 服务器进行验证。当这种情况发生时，WebPageTest 将显示在瀑布中，如下所示：

此 OCSP 检查对性能不利。验证需要 DNS 查找和到 OCSP 服务器的初始连接。只有在验证了证书后，才能与原始域进行 SSL 协商。正如你在图像中看到的，整个瀑布都被推回。在请求 HTML 页面之前几乎需要 2 秒钟！

如果你在 WebPageTest 时间线上注意到这一点，你应该考虑在你的服务器上启用 OCSP stapling。注意：如果你使用的是扩展验证证书 (EV)，OCSP stapling无法完全解决问题。

■ Service worker precaching

使用 Service Worker 预缓存资产时要记住的一个重要细节是浏览器可能需要下载相同的文件两次。一次用于 HTTP 缓存（标准浏览器缓存），再次用于 Service Worker 缓存（Cache API）。这些是两个完全独立的缓存，不共享资产。

在请求 17 和 18 中，你可以看到service worker JavaScript 被请求、下载和初始化。紧接着，Service Worker 会查看它的预缓存 JSON 文件并请求列出的任何资产。注意：在上面的示例中，Workbox 库用于简化 Service Worker 工作流程。

另外，WebPageTest添加了一项新功能，其中非来自主页文档的请求（例如

■ Large Time to First Byte (TTFB)

Time to First Byte 是从浏览器请求第一个资源到服务器将第一个字节数据发送回浏览器的时间，它包括：

● 浏览器从服务器请求资产（在 DNS + Connect + SSL 之后）
● 数据包从浏览器传输到服务器所需的时间
● 服务器收到请求，处理和构建响应并将其传输回
● 响应数据包从服务器传输到浏览器所需的时间

从浏览器到服务器所需的时间称为网络延迟。来回传输的数据称为往返 (RTT)。那么当你有一个大的TTFB时，你如何使用WebPageTest来识别？

上述测试是在 WebPageTest 定义的标准“Cable”连接上运行的，因此该连接的 RTT 为 28 毫秒。现在，如果将此值与 TTFB 进行比较，即 3.1 秒，我们可以看到这里存在问题。通过查看连接协商时间（请求 3 中的橙色），你可以了解数据包在网络中的传输速度（在本例中为 32 毫秒）。因此很明显，TTFB 延迟不是由网络拥塞引起的。根据带宽图，网络上的活动为零，CPU 上发生的活动相当少。在它可以做任何其他事情之前，设备正在等待服务器响应。

在这种情况下，导致延迟的是服务器上的处理时间。无论服务器为构建响应做什么，都需要大约 3 秒。这是构建 HTML 的大量时间。关于为什么会在服务器上发生这种情况，要列出的原因太多了，但一个好的起点是查看数据库查询、托管设置、可用的服务器资源以及正在运行的服务器软件。需要确定和修复导致问题的任何原因，因为这将对网站用户产生巨大影响。因此，如果您看到类似这样的 WebPageTest 瀑布，请检查您的服务器设置并尝试减少此时间。正如 Harry Roberts 在他的文章"Time to First Byte: What It Is and Why It Matters"中提到的：

虽然一个好的 TTFB 并不一定意味着你会有一个快速的网站，但一个糟糕的 TTFB 几乎肯定会保证一个缓慢的网站。

2、连接视图图表[8]

连接视图有多少行，就意味着加载网站时创建了多少个TCP连接，这些连接中的每一个都涉及某种形式的 DNS、TCP、SSL 协商，这在时间上很昂贵并且会影响 Web 性能。连接视图是快速查看有多少连接以及每个连接如何使用的好方法。将它与瀑布视图结合使用将使你能够快速识别潜在的性能问题，而单独使用瀑布视图是很难发现的。

想了解更多关于连接视图，可阅读连接视图原文[8]。

（二）AutoWebPerf（AWP）[9]

AWP 是一个基于模块的库，包含三种不同类型的模块：

● 引擎
● 连接器模块
● 采集模块

例如，你可以使用以下命令对存储在 Google 表格中的测试列表运行审计，并将结果写入 CSV 文件：

PSI_APIKEY=<YOUR_KEY> SHEETS_APIKEY=<YOUR_KEY> ./awp run sheets:<SheetID> csv:output.csv

在电子表格中收集每日指标后，你可以创建一个 Data Studio 仪表板，直接从电子表格加载数据，并将趋势绘制成时间序列图表。查看Google 电子表格 API 连接器[10]，了解有关如何使用电子表格作为数据源设置 AWP 以在 Data Studio 上进行可视化的详细步骤。

二、在代理浏览器和传统浏览器中测试

三、测试404页面的性能

通常我们在谈到 404 页面时不会三思而后行。毕竟，当客户端请求服务器上不存在的页面时，服务器将使用 404 状态代码和关联的 404 页面进行响应。没有那么多可考虑的，不是吗？

404 响应的一个重要方面是发送到浏览器的实际响应正文大小。根据 Matt Hobbs 对 404 页的研究[13]，绝大多数 404 响应来自丢失的图标、WordPress 上传请求、损坏的 JavaScript 请求、manifest文件以及 CSS 和字体文件。每次用户请求不存在的资产时，他们都会收到 404 响应——这种响应通常是巨大的。

确保检查和优化 404 页面的缓存策略。我们的目标是仅在浏览器需要 HTML 响应时才向浏览器提供 HTML，并为所有其他响应返回一个小的错误负载。根据 Matt 的说法，"如果我们在服务器前面放置一个 CDN，我们就有机会在 CDN 上缓存 404 页面响应。这很有用，因为没有它，点击 404 页面，通过强制源服务器响应每个 404 请求，而不是让 CDN 响应缓存版本，可能被用作 DoS 攻击向量"。

404 错误不仅会影响你的性能，而且还会造成流量损失，因此在你的 Lighthouse 测试套件中包含一个 404 错误页面并随着时间的推移跟踪其分数是一个好主意。

四、测试GDPR同意提示的性能

在 GDPR 和 CCPA 时代，依靠第三方为欧盟用户提供选择加入或退出跟踪的选项已变得很普遍。但是，与任何其他第三方脚本一样，它们的性能会对整个性能工作产生相当大的破坏性影响。

当然，实际同意可能会改变脚本对整体性能的影响，因此，正如 Boris Schapira 所指出的，我们可能想要研究一些不同的 Web 性能配置文件：

● 同意被完全拒绝
● 同意被部分拒绝
● 完全同意
● 用户未对同意提示采取行动（或提示被内容拦截器拦截）

通常 cookie 同意提示不应该对 CLS 产生影响，但有时会影响，因此请考虑使用免费和开源选项 Osano 或 cookie-consent-box。

通常，值得研究弹出窗口的性能，因为你需要确定鼠标事件的水平或垂直偏移，并相对于锚点正确定位弹出窗口。Noam Rosenthal 在文章 Web 性能案例研究：维基百科页面预览[14]（也提供视频[14-a]和会议记录[14-b]）中分享了 Wikimedia 团队的经验。

五、性能诊断 CSS

虽然我们可以包括各种检查以确保部署了表现不佳的代码，但通常快速了解一些可以轻松解决的唾手可得的方法还是很有用的。为此，我们可以使用 Tim Kadlec 出色的 Performance Diagnostics CSS（灵感来自 Harry Roberts 的片段，它突出显示了延迟加载的图像、未调整大小的图像、旧格式的图像和同步脚本。

例如：你可能希望确保折叠上方的任何图像都不是延迟加载的。你可以根据需要自定义代码段，如突出显示未使用的网络字体，或检测图标字体。一个很棒的小工具，可以确保在调试过程中可以看到错误，或者只是快速审核当前项目。

/* Performance Diagnostics CSS */
/* via Harry Roberts. https://twitter.com/csswizardry/status/1346477682544951296 */
img[loading=lazy] {
  outline: 10px solid red;
}

六、测试对可访问性的影响

当浏览器开始加载页面时，它会构建一个 DOM，如果有屏幕阅读器等辅助技术在运行，它还会创建一个可访问性树。然后屏幕阅读器必须查询可访问性树以检索信息并将其提供给用户 - 有时是默认情况，有时是按需 而且有时需要时间。

在谈论快速交互时间时，通常我们指的是用户可以通过单击或点击链接和按钮与页面交互的时间指标。屏幕阅读器的上下文略有不同。在这种情况下，快速交互时间意味着屏幕阅读器可以在给定页面上显示导航并且屏幕阅读器用户可以实际点击键盘进行交互之前经过了多长时间。

Léonie Watson 就可访问性性能发表了令人大开眼界的演讲[15]，特别是加载缓慢对屏幕阅读器公告延迟的影响。屏幕阅读器习惯于快节奏的公告和快速导航，因此可能比视力正常的用户更没有耐心。

使用 JavaScript 的大页面和 DOM 操作将导致屏幕阅读器通知延迟。这是一个尚未开发的领域，需要一些关注和测试，因为屏幕阅读器在每个平台上都是可用的（Jaws, NVDA, Voiceover, Narrator, Orca）。

七、设置持续监控

拥有 WebPagetest 的私有实例对于快速和无限制的测试总是有益的。但是，具有自动警报功能的持续监控工具（如 Sitespeed、Calibre 和 SpeedCurve）可以让你更详细地了解自己的表现。设置你自己的用户计时标记来衡量和监控特定于业务的指标。此外，可以考虑添加自动性能回归警报监视其随时间的变化。

考虑使用 RUM 解决方案来监控性能随时间的变化。对于自动化单元测试类负载测试工具，你可以使用 k6 及其脚本 API。此外，请查看 SpeedTracker、Lighthouse 和 Calibre。

速成方案

此列表非常全面，完成所有优化可能需要很长时间。那么，如果你只有 1 小时的时间来获得显着的改进，你会怎么做？ 让我们把它全部归结为 17 个容易实现的目标。显然，在开始之前和完成之后，测量结果，包括最大内容绘制和 3G 和电缆连接上的交互时间。

01 衡量现实世界的体验并设定适当的目标。目标是至少比最快的竞争对手快 20%。保持最大内容绘制 < 2.5 秒，首次输入延迟 < 100 毫秒，交互时间 < 5 秒（慢速 3G），重复访问，TTI < 2 秒。至少针对首次内容绘制和交互时间进行优化。

02 使用 Squoosh、mozjpeg、guetzli、pingo 和 SVGOMG 优化图像，并使用图像 CDN 提供 AVIF/WebP。

03 为主模板准备关键 CSS，并将它们内联到每个模板的 中。对于 CSS/JS，关键文件大小控制在预算范围内[170KB gzipped（0.7MB 解压）]。

04 修剪、优化、延迟和延迟加载脚本。设置打包配置以消除冗余并检查轻量级替代方案。

05 始终自托管你的静态资产，并且始终自托管第三方资产。限制第三方脚本的影响。使用facade，在交互时加载小部件并注意防闪烁片段。

06 选择框架时要有选择性。对于单页面应用程序，识别关键页面并静态提供它们，或至少预渲染它们，并在组件级使用渐进式水化并在交互时加载模块。

07 单独的客户端渲染不是性能的好选择。如果你的页面变化不大，可使用预渲染，如果可以，推迟框架的启动。如果可以，考虑使用流式服务器端渲染。

08 仅使用

09 尝试重新组合 CSS 规则并测试 body 内的 CSS。

10 添加资源提示(resource hints)以提升页面加载速度，例如"dns-lookup"、"preconnect"、"prefetch"、"preload"、和"prerender"等。

11 设置 Web 字体子集并异步加载，并利用 CSS 中的 font-display 实现快速的首次呈现。

12 检查 HTTP 缓存标头和安全标头是否设置正确。

13 在服务器上启用 Brotli 压缩。 （如果这不可能，至少确保启用 Gzip 压缩。）

14 只要你的服务器在 Linux 内核版本 4.9+ 上运行，启用 TCP BBR 拥塞。

15 考虑启用 OCSP stapling和 IPv6。并始终提供 OCSP stapling的 DV 证书。

16 为 HTTP/2 启用 HPACK 压缩并移至 HTTP/3（如果可用）。

17 在 Service Worker 缓存中缓存字体、样式、JavaScript 和图像等资产。

下载核对清单（PDF，Apple Pages）

● Download the checklist PDF[16] (PDF, 166 KB)
● Download the checklist in Apple Pages[17] (.pages, 275 KB)
● Download the checklist in MS Word[18] (.docx, 151 KB)

欢迎关注我的个人公众号：

参考文献：

Front-End Performance Checklist 2021[1]：https://www.smashingmagazine....前端性能优化（一）：准备工作[2]：https://mp.weixin.qq.com/s/QD...前端性能优化（二）：资源优化[3]：https://mp.weixin.qq.com/s/Yb...前端性能优化（三）：构建优化[4]：https://mp.weixin.qq.com/s/sp...前端性能优化（四）：传输优化[5]：https://mp.weixin.qq.com/s/Iq...前端性能优化（五）：网络与HTTP/2[6]：https://mp.weixin.qq.com/s/lL...How to read a WebPageTest Waterfall View chart[7]：https://nooshu.github.io/blog...How to read a WebPageTest Connection View chart[8]：https://nooshu.github.io/blog...AutoWebPerf[9]：https://web.dev/autowebperf/Google Spreadsheets API Connector[10]：https://github.com/GoogleChro...浏览器市场份额[11]：https://gs.statcounter.com/br...测量平均网速[12]：https://www.webworldwide.io/Why you should be testing your 404 pages web performance[13]：https://nooshu.github.io/blog...Web performance case study: Wikipedia page previews[14]：https://techblog.wikimedia.or...视频[14-a]：https://www.youtube.com/watch...会议记录[14-b]：https://docs.google.com/docum...There's more to Performance than meets the Eye[15]：https://www.youtube.com/watch...Download the checklist PDF[16]：https://www.dropbox.com/s/34n...Download the checklist in Apple Pages[17]：https://www.dropbox.com/s/iku...Download the checklist in MS Word[18]：https://www.dropbox.com/scl/f...