此页面由 Cloud Translation API 翻译。

Lighthouse：优化网站速度

Kayce Basques

Sofia Emelianova

概览

使用 Lighthouse 面板对您的网站进行全面审核。Lighthouse 面板会生成一份报告，让您深入了解网站的以下方面：

性能
无障碍
最佳做法
搜索引擎优化 (SEO)

...以及许多其他指标。

以下教程可帮助您在 Chrome 开发者工具中开始使用 Lighthouse。

如需详细了解 Lighthouse 提高网站质量的其他方式，请参阅我们的 Lighthouse 文档。

本教程的目标

本教程将教您如何使用 Chrome DevTools 寻找加快网站加载速度的方法。

请继续阅读或观看本教程的视频版本：

前提条件

您应该具备基本的 Web 开发经验，这与“Web 开发简介”课程中所学的内容类似。

您无需了解任何有关加载性能的信息。

简介

我是 Tony。托尼在猫咪界非常有名。他创建了一个网站，以便粉丝了解他的最爱食物。他的粉丝非常喜欢该网站，但 Tony 一直听到粉丝抱怨网站加载速度缓慢。Tony 请您帮他提高网站速度。

第 1 步：审核网站

每当您打算提高网站的加载性能时，都应先进行审核。此审核具有两项重要功能：

它会创建一个基准，以便您据此衡量后续的变化。
它会提供实用提示，帮助您了解哪些更改最有助于提升效果。

设置

首先，您需要为 Tony 的网站设置新的工作环境，以便稍后可以对其进行更改：

在 Glitch 上重新合成网站的项目。您的新项目会在新标签页中打开。此标签页称为“编辑器”标签页。

项目名称会从 tony 更改为一些随机生成的名称。现在，您就有自己的可修改代码副本了。稍后，您将更改此代码。
在编辑器标签页的底部，依次点击预览 > 在新窗口中预览。演示页面随即在新标签页中打开。该标签页称为演示标签页。网站可能需要一段时间才能加载完毕。
将演示与打开的 DevTools 一起运行。

建立基准

基准是记录您在进行任何性能改进之前网站的表现。

打开 Lighthouse 面板。它可能隐藏在 “更多面板”后面。

注意：此面板由同名工具 Lighthouse 提供支持，Lighthouse 是一款用于提升 Web 应用质量的自动化工具。
将您的 Lighthouse 报告配置设置与屏幕截图上的设置保持一致。以下是对不同选项的说明：
- 清除存储空间。启用此复选框后，系统会在每次执行审核之前清除与网页关联的所有存储空间。如果您想审核初访者在您网站上的体验，请将此设置保持开启状态。如需提供回访体验，请停用此设置。
- 启用 JS 采样。此选项在默认情况下处于停用状态。启用此功能后，系统会向性能轨迹添加详细的 JavaScript 调用堆栈，但可能会减慢报告生成速度。生成 Lighthouse 报告后，您可以在 Tools menu（工具菜单）> View Unthrottled Trace（查看未节流的轨迹）下找到该轨迹。
- 模拟节流（默认） 。此选项可模拟在移动设备上浏览的典型条件。之所以称之为“模拟”，是因为 Lighthouse 在审核过程中实际上不会限制。而是仅推断出页面在移动设备条件下需要多长时间才能加载完毕。另一方面，开发者工具节流（高级）设置实际上会节流 CPU 和网络，但审核流程会因此而延长。
- 模式 > 导航（默认）。此模式会分析单次网页加载，而这正是本教程中所需的。如需了解详情，请参阅三种模式。
- 设备 > 移动设备。“移动设备”选项会更改用户代理字符串并模拟移动设备视口。“桌面设备”选项几乎会停用移动设备更改。
- 类别 > 效果。启用单个类别后，Lighthouse 会仅生成包含相应一组审核的报告。如果您想查看其他类别提供的建议类型，可以将其保持启用状态。停用不相关的类别可以略微加快审核流程。
点击分析网页加载情况。10 到 30 秒后，Lighthouse 面板会显示网站性能报告。

处理报告错误

如果您的 Lighthouse 报告中出现错误，请尝试在无痕式窗口中运行演示版标签页，并确保未打开其他标签页。这样可以确保您在干净状态下运行 Chrome。特别是 Chrome 扩展程序可能会干扰审核流程。

包含错误的报告。

了解报告

报告顶部的数字是网站的整体效果得分。稍后，当您更改代码时，您应该会看到此数字增加。得分越高，效果越好。

总体效果得分。

指标

向下滚动到指标部分，然后点击展开视图。如需阅读某个指标的相关文档，请点击了解详情...。

“指标”部分。

本部分提供了网站性能的量化衡量数据。每个指标都可以让您深入了解效果的一个不同方面。例如，首次内容渲染会告知您内容首次绘制到屏幕上的时间，这是用户感知网页加载过程中的一个重要里程碑，而互动所需时间则标记了网页看起来已准备好处理用户互动的时间点。

屏幕截图

下面是一组屏幕截图，展示了页面在加载时的显示效果。

屏幕截图：网页在加载时的外观。

商机

接下来是优化部分，其中提供了有关如何提高此特定网页的加载性能的具体提示。

“优化建议”部分。

点击相应优化建议即可了解详情。

$详细了解文本压缩机会。$

点击了解详情...可查看有关优化建议为何重要的文档以及有关如何修正此问题的具体建议。

诊断

诊断部分会详细介绍造成网页加载时间的因素。

“诊断”部分。

已通过审核

通过的审核部分会显示网站做对了哪些方面。点击以展开该部分。

“已通过的审核”部分。

第 2 步：开展实验

Lighthouse 报告的优化建议部分会提供有关如何提升网页性能的提示。在本部分中，您将对代码库实施建议的更改，并在每次更改后审核网站，以衡量更改对网站速度的影响。

启用文本压缩

您的报告显示，启用文本压缩是提升网页性能的首要机会之一。

文本压缩是指在通过网络发送文本文件之前缩减或压缩文本文件的大小。就像在通过电子邮件发送文件夹之前压缩文件夹的大小一样。

在启用压缩功能之前，您可以通过以下几种方式手动检查文本资源是否已压缩。

打开 Network 面板，然后勾选 Settings > Use large request rows。

“Network”面板中的“Size”列，显示了大型请求行。

每个大小单元格都会显示两个值。顶部值是下载资源的大小。底部值是未压缩资源的大小。如果这两个值相同，则在通过网络发送资源时，系统不会对资源进行压缩。在此示例中，bundle.js 的顶部和底部值均为 1.4 MB。

您还可以通过检查资源的 HTTP 标头来检查是否进行了压缩：

点击 bundle.js，然后打开 Headers 标签页。
在响应标头部分中搜索 content-encoding 标头。您应该不会看到任何输出，这意味着 bundle.js 未压缩。当资源被压缩时，此标头通常设置为 gzip、deflate 或 br。如需了解这些值的说明，请参阅指令。

说明已经够多了。现在可以进行一些更改了！添加几行代码即可启用文本压缩：

在编辑器标签页中，打开 server.js 并添加以下两行（突出显示的内容）：

...
const fs = require('fs');
const compression = require('compression');

app.use(compression());
app.use(express.static('build'));
...

请务必将 app.use(compression()) 放在 app.use(express.static('build')) 之前。

注意：通常，您必须通过 npm i -S compression 等工具安装 compression 软件包，但系统已为您完成此操作。
等待 Glitch 部署网站的新 build。左下角显示开心表情符号表示部署成功。

使用您之前学过的工作流手动检查压缩是否正常运行：

返回演示标签页并重新加载页面。

现在，Size 列应针对 bundle.js 等文本资源显示两个不同的值。bundle.js 的 269 KB 上限值是通过网络发送的文件的大小，1.4 MB 的下限值是未压缩的文件大小。
bundle.js 的响应标头部分现在应包含 content-encoding: gzip 标头。

再次针对该网页运行 Lighthouse 报告，以衡量文本压缩对网页加载性能的影响：

打开 Lighthouse 面板，然后点击顶部操作栏上的 Perform an audit...。
将设置保持不变，然后点击分析网页加载情况。

棒极了！这看起来像是进展。您的总体效果得分应该会有所提高，这表示网站速度变快了。

文本压缩实际应用

实际上，大多数服务器都拥有像这样的简单修复方法，用于启用压缩！只需搜索如何配置用于压缩文本的服务器即可。

调整图片大小

您的新报告指出，适当调整图片大小是另一个重大机会。

调整图片大小可通过缩减图片文件大小来帮助缩短加载时间。如果您的用户在宽度为 500 像素的移动设备屏幕上查看您的图片，那么发送宽度为 1500 像素的图片实际上毫无意义。理想情况下，您发送的图片宽度不应超过 500 像素。

在报告中，点击适当调整图片大小，查看哪些图片应调整大小。这 4 张图片似乎都比需要的尺寸大。
返回编辑器标签页，打开 src/model.js。
将 const dir = 'big' 替换为 const dir = 'small'。此目录包含已调整大小的相同图片的副本。
请再次审核该网页，看看此更改对加载性能有何影响。

这项更改似乎只对总体效果得分有轻微影响。不过，该得分无法清楚显示您为用户节省了多少网络流量。旧照片的总大小约为 6.1 MB，而现在只有大约 633 KB。您可以在网络面板底部的状态栏中查看此信息。

调整图片大小前后传输的数据量。

在现实世界中调整图片大小

对于小型应用，执行一次性调整大小操作可能就足够了。但对于大型应用，这显然无法扩缩以下是在大型应用中管理图片的一些策略：

在构建过程中调整图片大小。
在构建过程中为每个图片创建多种尺寸，然后在代码中使用 srcset。在运行时，浏览器会负责选择最适合其所运行设备的大小。请参阅相对大小的图片。
使用图片 CDN，以便在您请求图片时动态调整图片的大小。
至少要优化每张图片。这通常可以带来巨大的节省。优化是指通过可缩减图片文件大小的特殊程序运行图片。如需更多提示，请参阅图片优化必备知识。

消除阻塞渲染的资源

最新报告指出，现在最大的机会是移除阻塞渲染的资源。

阻塞渲染的资源是外部 JavaScript 或 CSS 文件，浏览器必须先下载、解析和执行该文件，然后才能显示网页。目标是仅运行正确显示网页所需的核心 CSS 和 JavaScript 代码。

因此，第一项任务是找出不需要在网页加载时执行的代码。

点击移除阻塞渲染的资源，查看阻塞的资源：lodash.js 和 jquery.js。
根据您使用的操作系统，按以下键打开命令菜单：
- 在 Mac 上，按 Command + Shift + P
- 在 Windows、Linux 或 ChromeOS 上，按 Ctrl + Shift + P
开始输入 Coverage，然后选择显示覆盖率。

抽屉中会打开“覆盖率”标签页。
依次点击 重新加载。覆盖率标签页概要介绍了在网页加载期间 bundle.js、jquery.js 和 lodash.js 中的代码执行了多少。

此屏幕截图显示，jQuery 和 Lodash 文件分别有大约 74% 和 30% 未被使用。
点击 jquery.js 行。DevTools 会在 Sources 面板中打开该文件。如果一行代码旁边有绿色条，则表示已执行该代码。如果代码行旁边有一个红色条，则表示该代码未执行，在网页加载时肯定不需要。
滚动浏览一下 jQuery 代码。其中一些“被执行”的行实际上只是注释。通过会剥离注释的缩减器运行此代码是减小此文件大小的另一种方法。

简而言之，当您使用自己的代码时，覆盖率标签页可以帮助您逐行分析代码，并仅交付网页加载所需的代码。

加载页面是否甚至需要 jquery.js 和 lodash.js 文件？请求屏蔽标签页可显示资源不可用时会发生的情况。

点击网络标签页，然后再次打开命令菜单。
开始输入 blocking，然后选择显示请求屏蔽。系统随即会打开请求屏蔽标签页。
点击 Add Pattern（添加格式），在文本框中输入 /libs/*，然后按 Enter 键进行确认。
重新加载页面。 jQuery 和 Lodash 请求显示为红色，表示它们已被阻止。网页仍会加载并可进行互动，因此这些资源似乎完全没有用处！
点击 移除所有模式以删除 /libs/* 屏蔽模式。

通常，请求屏蔽标签页非常有用，可用于模拟在任何给定资源不可用时网页的行为方式。

现在，从代码中移除对这些文件的引用，并再次审核网页：

返回编辑器标签页，打开 template.html。

删除相应的 <script> 标记：

<head>
    ...
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <script src="/libs/lodash.js"></script>
    <script src="/libs/jquery.js"></script>
    <title>Tony's Favorite Foods</title>
</head>

等待网站重建并重新部署。
请从 Lighthouse 面板再次审核此页面。您的总体得分应该又有所提升。

优化真实环境中的关键渲染路径

关键渲染路径是指加载网页所需的代码。一般来说，您可以通过仅在网页加载期间提交关键代码，然后延迟加载所有其他代码来加快网页加载速度。

您不太可能找到可以直接移除的脚本，但您经常会发现，许多脚本在页面加载期间不需要请求，而是可以异步请求。请参阅使用 async 或 defer。
如果您使用的是框架，请检查它是否有生产模式。此模式可能会使用摇树优化等功能，以消除阻止关键渲染的不必要代码。

减少主线程工作

您的最新报告显示 Opportunity 部分可以略微节省一些费用，但如果您向下滚动到 Diagnostics 部分，最大的瓶颈似乎是主线程活动过多。

在主线程中，浏览器会执行显示网页所需的大部分工作，例如解析和执行 HTML、CSS 和 JavaScript。

目标是使用性能面板分析主线程在网页加载期间执行的工作，并找出推迟或移除不必要工作的方法。

依次打开 Performance > Capture Settings，然后将 Network 设置为 Slow 3G，并将 CPU 设置为 6xSlowdown。

与笔记本电脑或台式机相比，移动设备通常具有更强的硬件限制，因此这些设置可让您体验网页加载时设备性能欠佳的情况。
点击 重新加载。 DevTools 会重新加载该网页，然后以可视化方式显示为加载该网页而必须执行的所有操作。此可视化图表将称为“轨迹”。

轨迹会按时间顺序（从左到右）显示活动。顶部的 FPS、CPU 和 NET 图表可让您大致了解每秒帧数、CPU 活动和网络活动。

轨迹的“概览”部分。

如果您在概览部分看到一片黄色，则表示 CPU 完全在处理脚本活动。这表明，您或许可以通过减少 JavaScript 工作来加快网页加载速度。

调查跟踪，以找到减少 JavaScript 工作量的方法：

点击时间安排部分以将其展开。

有许多来自 React 的用户时间衡量指标，Tony 的应用似乎在使用 React 的开发模式。切换到 React 的生产模式可能会轻松提升性能。
再次点击时间可收起该部分。
浏览主要部分。此部分显示了主线程活动的时间顺序日志（从左到右）。Y 轴（从上到下）显示了事件发生的原因。

在此示例中，Evaluate Script 事件导致 (anonymous) 函数执行，进而导致执行 __webpack__require__，进而执行 ./src/index.jsx，依此类推。
向下滚动到 Main 部分的底部。使用框架时，大多数上层 activity 都是由框架引起的，这通常超出了您的控制范围。您的应用导致的活动通常位于底部。

在此应用中，名为 App 的函数似乎导致对 mineBitcoin 函数的大量调用。听起来 Tony 似乎在使用粉丝的设备挖掘加密货币...

注意：虽然框架进行的调用通常不受您的控制，但有时您可能以某种方式构建应用，导致框架运行效率不高。通过重构应用以高效使用框架，可以减少主线程工作。这需要深入了解您的框架的工作原理，以及您可以在自己的代码中进行哪些类型的更改，以便更高效地使用该框架。
打开底部的自下而上标签页。此标签页会按活动对所占用时间进行细分。如果您在自下而上部分中没有看到任何内容，请点击主要部分的标签。

Bottom-Up 部分仅显示您当前所选的任何活动或活动组的信息。例如，如果您点击了其中一个 mineBitcoin 活动，自下而上部分将仅显示该活动的信息。

自用时间列会显示直接在各项活动中花费的时间。在本例中，大约 82% 的主线程时间都花在了 mineBitcoin 函数上。