通过分析和优化关键渲染路径来掌握 Web 性能。一篇为开发者准备的综合指南，深入探讨 JavaScript 如何影响渲染以及如何解决性能问题。
JavaScript 性能优化：深入探索关键渲染路径
在 Web 开发的世界里，速度不仅仅是一个功能，它更是良好用户体验的基石。一个加载缓慢的网站会导致更高的跳出率、更低的转化率和沮丧的用户。虽然影响 Web 性能的因素有很多，但其中一个最基本也最常被误解的概念就是关键渲染路径 (Critical Rendering Path, CRP)。对于任何重视性能的开发者来说，理解浏览器如何渲染内容，以及更重要的，JavaScript 如何与这一过程互动，是至关重要的。
本综合指南将带您深入探索关键渲染路径，并特别关注 JavaScript 在其中的角色。我们将探讨如何分析它、识别瓶颈，并应用强大的优化技术，使您的 Web 应用程序为全球用户提供更快、更灵敏的体验。
什么是关键渲染路径？
关键渲染路径是浏览器将 HTML、CSS 和 JavaScript 转换为屏幕上可见像素所必须经过的一系列步骤。CRP 优化的主要目标是尽快向用户渲染首屏（“above-the-fold”）内容。这个过程越快，用户感知到的页面加载速度就越快。
该路径包含几个关键阶段：
- DOM 构建： 当浏览器从服务器接收到 HTML 文档的第一个字节时，这个过程就开始了。它开始逐个字符地解析 HTML 标记，并构建文档对象模型 (Document Object Model, DOM)。DOM 是一个树状结构，表示 HTML 文档中的所有节点（元素、属性、文本）。
- CSSOM 构建： 在浏览器构建 DOM 的同时，如果遇到 CSS 样式表（无论是在
<link>标签中还是内联的<style>块中），它就会开始构建CSS 对象模型 (CSS Object Model, CSSOM)。与 DOM 类似，CSSOM 也是一个树状结构，包含了页面的所有样式及其关系。与 HTML 不同，CSS 默认是渲染阻塞的。浏览器在下载并解析完所有 CSS 之前，无法渲染页面的任何部分，因为后面的样式可能会覆盖前面的样式。 - 渲染树构建： 一旦 DOM 和 CSSOM 都准备就绪，浏览器会将它们结合起来创建渲染树 (Render Tree)。这棵树只包含渲染页面所需的节点。例如，带有
display: none;的元素和<head>标签不会包含在渲染树中，因为它们在视觉上不会被渲染。渲染树知道要显示什么，但不知道显示在哪里或多大。 - 布局 (Layout 或 Reflow)： 渲染树构建完成后，浏览器进入布局阶段。在这一步中，它会计算渲染树中每个节点相对于视口的确切大小和位置。此阶段的输出是一个“盒模型”，它捕获了页面上每个元素的精确几何形状。
- 绘制 (Paint)： 最后，浏览器获取布局信息，并将每个节点的像素“绘制”到屏幕上。这包括绘制文本、颜色、图像、边框和阴影——本质上是光栅化页面的每个可视部分。这个过程可以在多个层上进行以提高效率。
- 合成 (Composite)： 如果页面内容被绘制到多个层上，浏览器必须按正确的顺序将这些层合成为一体，才能在屏幕上显示最终的图像。这一步对于动画和滚动尤为重要，因为合成的计算开销通常比重新运行布局和绘制阶段要小。
JavaScript 在关键渲染路径中的干扰作用
那么 JavaScript 在这个过程中处于什么位置呢？JavaScript 是一种功能强大的语言，可以修改 DOM 和 CSSOM。然而，这种能力是有代价的。JavaScript 可能会，而且经常会，阻塞关键渲染路径，导致渲染出现严重延迟。
解析器阻塞的 JavaScript
默认情况下，JavaScript 是解析器阻塞 (parser-blocking)的。当浏览器的 HTML 解析器遇到一个 <script> 标签时，它必须暂停构建 DOM 的过程。然后，它会继续下载（如果是外部文件）、解析和执行 JavaScript 文件。这个过程是阻塞的，因为脚本可能会执行类似 document.write() 的操作，这可能会改变整个 DOM 结构。浏览器别无选择，只能等待脚本执行完毕，然后才能安全地恢复解析 HTML。
如果这个脚本位于文档的 <head> 部分，它会在一开始就阻塞 DOM 的构建。这意味着浏览器没有内容可以渲染，用户只能盯着一个空白的白屏，直到脚本完全处理完毕。这是导致感知性能差的主要原因。
DOM 和 CSSOM 操作
JavaScript 也可以查询和修改 CSSOM。例如，如果你的脚本请求一个计算样式，如 element.style.width，浏览器必须首先确保所有 CSS 都已下载并解析，以提供正确的答案。这在你的 JavaScript 和 CSS 之间创建了依赖关系，脚本的执行可能会因为等待 CSSOM 就绪而被阻塞。
此外，如果 JavaScript 修改了 DOM（例如，添加或删除元素）或 CSSOM（例如，更改一个类），它可能会触发一系列浏览器工作。一个更改可能会迫使浏览器重新计算布局（回流/reflow），然后重新绘制屏幕上受影响的部分，甚至整个页面。频繁或时机不当的操作会导致用户界面迟钝、无响应。
如何分析关键渲染路径
在优化之前，你必须先进行测量。浏览器开发者工具是你分析 CRP 的最佳伙伴。让我们重点关注 Chrome DevTools，它为此提供了一套强大的工具。
使用 Performance 标签页
Performance 标签页提供了浏览器渲染页面所做一切的详细时间线。
- 打开 Chrome DevTools (Ctrl+Shift+I 或 Cmd+Option+I)。
- 转到 Performance 标签页。
- 确保勾选 “Web Vitals” 复选框，以便在时间线上看到关键指标。
- 点击重新加载按钮（或按 Ctrl+Shift+E / Cmd+Shift+E）开始分析页面加载。
页面加载后，你会看到一个火焰图。在 Main 线程部分，你需要关注以下内容：
- 长任务 (Long Tasks)： 任何耗时超过 50 毫秒的任务都会被标记一个红色三角形。这些是优化的主要目标，因为它们会阻塞主线程，并可能导致 UI 无响应。
- Parse HTML (蓝色)： 这显示了浏览器在何处解析你的 HTML。如果你看到大的间隙或中断，很可能是由阻塞脚本引起的。
- Evaluate Script (黄色)： 这是 JavaScript 正在执行的地方。寻找长的黄色块，尤其是在页面加载早期。这些就是你的阻塞脚本。
- Recalculate Style (紫色)： 这表示 CSSOM 构建和样式计算。
- Layout (紫色)： 这些块代表布局或回流阶段。如果你看到很多这样的块，你的 JavaScript 可能通过反复读写几何属性导致了“布局抖动 (layout thrashing)”。
- Paint (绿色)： 这是绘制过程。
使用 Network 标签页
Network 标签页的瀑布图对于理解资源下载的顺序和持续时间非常有价值。
- 打开 DevTools 并转到 Network 标签页。
- 重新加载页面。
- 瀑布图会向你展示每种资源（HTML、CSS、JS、图片）何时被请求和下载。
请密切关注瀑布图顶部的请求。你可以轻松发现那些在页面开始渲染之前就被下载的 CSS 和 JavaScript 文件。这些就是你的渲染阻塞资源。
使用 Lighthouse
Lighthouse 是一个内置于 Chrome DevTools（在 Lighthouse 标签页下）的自动化审计工具。它提供了一个高级别的性能得分和可操作的建议。
针对 CRP 的一个关键审计项是“消除渲染阻塞资源 (Eliminate render-blocking resources)”。这份报告会明确列出那些延迟了首次内容绘制 (First Contentful Paint, FCP) 的 CSS 和 JavaScript 文件，为你提供一个清晰的优化目标列表。
JavaScript 核心优化策略
既然我们知道了如何识别问题，让我们来探讨解决方案。目标是最大限度地减少阻塞初始渲染的 JavaScript 数量。
1. `async` 和 `defer` 的威力
防止 JavaScript 阻塞 HTML 解析器最简单、最有效的方法是在你的 <script> 标签上使用 `async` 和 `defer` 属性。
- 标准
<script>：<script src="script.js"></script>
正如我们所讨论的，这是解析器阻塞的。HTML 解析停止，脚本被下载和执行，然后解析继续。 <script async>：<script src="script.js" async></script>
脚本与 HTML 解析并行地异步下载。一旦脚本下载完成，HTML 解析就会暂停，然后执行脚本。执行顺序不保证；脚本在下载完成后立即执行。这最适合于那些不依赖 DOM 或其他脚本的独立第三方脚本，例如分析或广告脚本。<script defer>：<script src="script.js" defer></script>
脚本与 HTML 解析并行地异步下载。但是，脚本只有在 HTML 文档完全解析完毕后（在 `DOMContentLoaded` 事件之前）才执行。带有 `defer` 的脚本也保证按它们在文档中出现的顺序执行。对于大多数需要与 DOM 交互且对初始绘制不关键的脚本来说，这是首选方法。
通用规则： 对你的主应用程序脚本使用 `defer`。对独立的第三方脚本使用 `async`。除非脚本对于初始渲染绝对必要，否则避免在 <head> 中使用阻塞脚本。
2. 代码分割
现代 Web 应用程序通常被打包成一个单一、庞大的 JavaScript 文件。虽然这减少了 HTTP 请求的数量，但它迫使用户下载大量对于初始页面视图可能并非必需的代码。
代码分割 (Code Splitting) 是将那个大的包分解成可以按需加载的更小代码块的过程。例如：
- 初始代码块： 只包含渲染当前页面可见部分所需的基本 JavaScript。
- 按需加载的代码块： 包含用于其他路由、模态框或首屏以下功能的代码。这些只有当用户导航到该路由或与该功能交互时才会被加载。
现代打包工具如 Webpack、Rollup 和 Parcel 都内置了对使用动态 `import()` 语法的代码分割的支持。像 React（使用 `React.lazy`）和 Vue 这样的框架也提供了在组件级别轻松分割代码的方法。
3. Tree Shaking 和死代码消除
即使进行了代码分割，你的初始包中也可能包含实际上未被使用的代码。这在你导入了库但只使用了其中一小部分时很常见。
Tree Shaking 是现代打包工具用来从最终包中消除未使用代码的过程。它会静态分析你的 `import` 和 `export` 语句，并确定哪些代码是不可达的。通过确保只发布用户需要的代码，你可以显著减小包的大小，从而加快下载和解析时间。
4. 压缩和压缩
对于任何生产网站来说，这些都是基本步骤。
- 代码压缩 (Minification)： 这是一个自动化过程，它会从你的代码中删除不必要的字符——如空格、注释和换行符——并缩短变量名，而不改变其功能。这会减小文件大小。像 Terser（用于 JavaScript）和 cssnano（用于 CSS）这样的工具被普遍使用。
- 文件压缩 (Compression)： 在代码压缩之后，你的服务器应该在将文件发送给浏览器之前对其进行压缩。像 Gzip 以及更高效的 Brotli 这样的算法可以将文件大小减少高达 70-80%。浏览器在接收到文件后会对其进行解压。这是一个服务器配置，但对于减少网络传输时间至关重要。
5. 内联关键 JavaScript（谨慎使用）
对于那些对首次绘制绝对必要的小段 JavaScript（例如，设置主题或关键的 polyfill），你可以将它们直接内联到 HTML 的 <head> 中的 <script> 标签内。这可以节省一次网络请求，对于高延迟的移动连接可能很有利。然而，这种方法应该谨慎使用。内联代码会增加 HTML 文档的大小，并且无法被浏览器单独缓存。这是一个需要仔细权衡的取舍。
高级技术和现代方法
服务器端渲染 (SSR) 和静态站点生成 (SSG)
像 Next.js (用于 React)、Nuxt.js (用于 Vue) 和 SvelteKit 这样的框架普及了 SSR 和 SSG。这些技术将初始渲染工作从客户端浏览器转移到服务器。
- SSR： 服务器为请求的页面渲染完整的 HTML 并将其发送给浏览器。浏览器可以立即显示这个 HTML，从而实现非常快的首次内容绘制。然后 JavaScript 会加载并“激活 (hydrate)”页面，使其具有交互性。
- SSG： 每个页面的 HTML 都在构建时生成。当用户请求一个页面时，一个静态 HTML 文件会立即从 CDN 提供。这对于内容密集的网站是最快的方法。
SSR 和 SSG 都通过在大部分客户端 JavaScript 开始执行之前提供有意义的首次绘制，从而极大地改善了 CRP 性能。
Web Workers
如果你的应用程序需要执行繁重的、长时间运行的计算（如复杂的数据分析、图像处理或加密），在主线程上执行这些操作会阻塞渲染，使你的页面感觉被冻结。Web Workers 提供了一个解决方案，允许你在一个与主 UI 线程完全分离的后台线程中运行这些脚本。这可以在进行繁重工作的同时保持你的应用程序响应迅速。
CRP 优化的实用工作流程
让我们将所有内容整合成一个你可以应用到你项目中的可操作工作流程。
- 审计： 从一个基线开始。在你的生产版本上运行 Lighthouse 报告和 Performance 分析，以了解你当前的状态。记下你的 FCP、LCP、TTI，并识别任何长任务或渲染阻塞资源。
- 识别： 深入研究 DevTools 的 Network 和 Performance 标签页。精确定位哪些脚本和样式表正在阻塞初始渲染。对每个资源问自己：“这对于用户看到初始内容是绝对必要的吗？”
- 优先处理： 将你的精力集中在影响首屏内容的代码上。目标是尽快将这部分内容呈现给用户。其他任何东西都可以稍后加载。
- 优化：
- 对所有非必要的脚本应用
defer。 - 对独立的第三方脚本使用
async。 - 为你的路由和大型组件实施代码分割。
- 确保你的构建过程包含代码压缩和 tree shaking。
- 与你的基础设施团队合作，在你的服务器上启用 Brotli 或 Gzip 压缩。
- 对于 CSS，考虑内联初始视图所需的关键 CSS，并延迟加载其余部分。
- 对所有非必要的脚本应用
- 测量： 在实施更改后，再次运行审计。将你的新分数和时间与基线进行比较。你的 FCP 是否有所改善？渲染阻塞资源是否减少了？
- 迭代： Web 性能不是一次性的修复；它是一个持续的过程。随着你的应用程序的增长，新的性能瓶颈可能会出现。将性能审计作为你开发和部署周期的常规部分。
结论：掌握通往性能之路
关键渲染路径是浏览器将你的应用程序变为现实所遵循的蓝图。作为开发者，我们对这一路径的理解和控制，尤其是在 JavaScript 方面，是我们改善用户体验最强大的杠杆之一。通过从仅仅编写能工作的代码转变为编写高性能的代码，我们可以构建不仅功能齐全，而且对全球用户来说快速、易于访问且令人愉悦的应用程序。
这段旅程始于分析。打开你的开发者工具，分析你的应用程序，并开始质疑每一个阻碍在你的用户和完全渲染的页面之间的资源。通过应用延迟脚本、分割代码和最小化负载的策略，你可以为浏览器扫清道路，让它发挥其最佳作用：以闪电般的速度渲染内容。