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

HTTP/2

■ 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 增加了一项新性能，其中非来自主页文档的申请（例如 <iframe> 和 Service Worker 申请）当初以蓝色突出显示（仅限 Chrome）。

■ 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 上进行可视化的具体步骤。

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

在 Chrome 和 Firefox 中进行测试是不够的。查看你的网站在代理浏览器和旧版浏览器中的工作形式。例如，UC 浏览器和 Opera Mini 在亚洲领有 可观的市场份额 [11]（在亚洲高达 35%）。 测量你感兴趣的国家 / 地区的均匀互联网速度[12]，以防止将来呈现重大意外。应用网络节流进行测试，并模仿高 DPI 设施。BrowserStack 非常适合在近程实在设施上进行测试，并且至多在你的办公室中应用一些实在设施对其进行补充——这是值得的。

中国的均匀互联网速度如下：

三、测试 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，并将它们内联到每个模板的 <head> 中。对于 CSS/JS，要害文件大小管制在估算范畴内[170KB gzipped（0.7MB 解压）]。

04 修剪、优化、提早和提早加载脚本。设置打包配置以打消冗余并查看轻量级代替计划。

05 始终自托管你的动态资产，并且始终自托管第三方资产。限度第三方脚本的影响。应用 facade，在交互时加载小部件并留神防闪动片段。

06 抉择框架时要有选择性。对于单页面应用程序，辨认要害页面并动态提供它们，或至多预渲染它们，并在组件级应用渐进式水化并在交互时加载模块。

07 独自的客户端渲染不是性能的好抉择。如果你的页面变动不大，可应用预渲染，如果能够，推延框架的启动。如果能够，思考应用流式服务器端渲染。

08 仅应用 <script type=”module”> 和 module/nomodule 模式将旧代码提供给旧浏览器。

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…