此页面由 Cloud Translation API 翻译。

Lighthouse：优化网站速度

Kayce Basques

Sofia Emelianova

概览

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

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

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

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

如需详细了解 Lighthouse 可以通过哪些其他方式提升网站质量，请参阅我们的 Lighthouse 文档。

教程的目标

本教程介绍了如何使用 Chrome 开发者工具提升网站加载速度。

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

前提条件

您应具备基本的 Web 开发经验，这与 “网络开发简介”课程。

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

简介

我是 Tony。托尼在猫咪界非常有名。他打造了一个网站，方便粉丝了解他最喜欢什么他的粉丝非常喜欢这个网站，但 Tony 不断听到抱怨，。Tony 请您帮他提高网站速度。

第 1 步：审核网站

无论何时着手改善网站的加载性能，都务必从审核。此项审核具有两项重要职能：

它为您衡量后续更改创建基准。
它为您提供了富有实用价值的提示，让您了解哪些更改会带来最佳效果。

设置

首先，您需要为 Tony 的网站，以便可以做出更改：

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

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

。

建立基准

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

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

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

处理报告错误

如果你在 Lighthouse 报告中遇到错误，请尝试运行演示标签页在不打开其他标签页的无痕式窗口中打开。这样可以确保您从干净状态运行 Chrome尤其是 Chrome 扩展程序会干扰审计流程

包含错误的报告。

解读报告

报告顶部的数字是网站的总体效果得分。稍后，对代码进行更改后，您应该会看到该数字逐渐增加。得分越高，效果越好。

总体表现得分。

指标

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

“指标”部分。

此部分提供了对网站性能的量化衡量标准。每个指标都可以深入了解广告效果的不同方面。例如 First Contentful Paint 会告知您内容首次绘制到屏幕上的时间，这是用户而“可交互时间”标记的是网页加载的时间点看起来足以处理用户互动

屏幕截图

接下来是一组屏幕截图，向您展示网页在加载后的显示效果。

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

商机

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

“优化”部分。

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

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

点击了解详情...可查看相关文档，了解优化建议的重要性以及具体原因有关如何解决这个问题的建议。

诊断

诊断部分可详细了解导致网页排名下降的因素加载时间。

“诊断”部分。

已通过审核

通过的审核部分会显示网站正确执行了哪些操作。点击展开部分。

“已通过的审核”部分。

第 2 步：实验

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

启用文本压缩

您的报告显示，启用文本压缩是改进网页性能

文本压缩是指先缩减或压缩文本文件的大小，然后再通过。这有点类似于您在通过电子邮件发送文件夹之前压缩文件夹以减小其大小。

在启用压缩之前，您可以通过以下几种方式手动检查文字资源。

打开 Network 面板，然后勾选 Settings > 使用大型请求行。

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

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

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

点击 bundle.js 并打开标头标签页。
在响应标头部分搜索 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 部署网站的新版本。左下角显示开心表情符号表示部署成功。

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

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

对于 bundle.js 等文本资源，Size 列现在应显示两个不同的值。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 中的代码执行了多少。

此屏幕截图显示，分别大约有 74% 和 30% 的 jQuery 和 Lodash 文件未被使用。
点击 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。
如果您使用的是框架，请检查它是否有生产模式。此模式可能会使用如下功能：摇树优化，以消除阻塞关键渲染的不必要代码。

减少主线程工作

您的最新报告显示，优化部分显示有少许费用节省，但如果您滚动页面诊断部分显示，最大的瓶颈似乎是主线程太多活动。

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

目标是使用 Performance 面板来分析主线程在进行加载网页，并设法推迟或移除不必要的工作。

打开效果 > 捕获设置，并将网络设置为 Slow 3G，并将 CPU 设置为 6 倍慢速。

移动设备通常比笔记本电脑或台式机有更多硬件限制，因此通过这些设置，您可以获得与使用性能较低的设备类似的网页加载体验。
点击 重新加载。 DevTools 会重新加载页面，然后直观呈现其加载页面所需的所有操作。我们将这种可视化方式称为“跟踪记录”。trace

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

跟踪记录的“概览”部分。

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

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

点击计时部分将其展开。

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

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

在此应用中，名为 App 的函数似乎导致对 mineBitcoin 函数的大量调用。看来 Tony 可能在使用粉丝的设备进行加密货币挖矿...

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

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

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