此页面由 Cloud Translation API 翻译。

Lighthouse：优化网站速度

Kayce Basques

Twitter GitHub Glitch

Sofia Emelianova

GitHub

教程目标

本教程将教您如何使用 Chrome 开发者工具找到提高网站加载速度的方法。

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

前提条件

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

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

简介

我是 Tony。Tony 在猫社会中非常有名。他构建了一个网站，以便粉丝可以了解他最喜欢的食物是什么。他的粉丝非常喜欢这个网站，但 Tony 不断听到客户抱怨网站加载速度很慢。Tony 要求您帮助他提高网站速度。

第 1 步：审核网站

每当您打算提高网站的加载性能时，都要从审核入手。“审核”有两项重要功能：

它创建了一个基准，供您衡量后续更改。
该页面会为您提供一些切实可行的提示，让您了解哪些更改效果最好。

设置

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

在 Glitch 上对网站的项目进行混剪。您的新项目将在一个标签页中打开。此标签页将被称为编辑器标签页。

项目名称从 tony 更改为某个随机生成的名称。您现在拥有自己的可编辑代码副本。稍后，您将更改此代码。
在编辑器标签页的底部，依次点击预览 > 在新窗口中预览。演示将在新标签页中打开。此标签页将被称为“演示”标签页。网站可能需要一段时间才能加载完毕。
在演示旁边打开开发者工具。

建立基准

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

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

注意：此面板由其同名 Lighthouse 提供支持，这是一款用于提升 Web 应用质量的自动化工具。
将您的 Lighthouse 报告配置设置与屏幕截图上的设置相匹配。以下是对不同选项的说明：
- 清理存储空间。选中此复选框将在每次审核前清除与页面关联的所有存储。如果您想审核首次访问者对您网站的体验，请将此设置保留为启用状态。如果您想获得重访体验，请停用此设置。
- 模拟节流（默认） 。此选项模拟了在移动设备上浏览的典型条件。之所以称为“模拟”，是因为 Lighthouse 在审核过程中实际上并未进行节流。而只是推断网页在移动设备上需要多长时间才能加载完毕。另一方面，DevTools 节流（高级）设置实际上会限制您的 CPU 和网络，但需要更长的审核过程。
- Mode > Navigation (Default)。此模式分析的是单次网页加载，而这正是我们在本教程中需要的模式。如需了解详情，请参阅三种模式。
- 设备 > 手机。移动设备选项会更改用户代理字符串并模拟移动设备视口。桌面选项几乎可以禁用移动版更改。
- 类别 > 效果。启用单个类别会使 Lighthouse 仅生成包含相应审核组的报告。如果您想查看其他类别提供的建议类型，可以将其保留为启用状态。停用不相关的类别可以略微加快审核过程。
点击分析网页加载情况。10 到 30 秒后，Lighthouse 面板会显示网站性能报告。

处理报告错误

如果您在 Lighthouse 报告中遇到错误，请尝试从无痕式窗口中运行演示版标签页，同时不打开任何其他标签页。这可确保您从干净状态运行 Chrome。Chrome 扩展程序尤其会干扰审核过程。

出现错误的报告。

了解您的报告

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

总体性能得分。

指标

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

“指标”部分。

本部分提供了对网站性能的量化衡量标准。通过每个指标，您可以从不同方面深入了解效果。例如，First Contentful Paint 会告知您内容首次绘制到屏幕上的时间，这是用户感知到的网页加载时间的重要里程碑，而可交互时间则指明页面显示的时间已足以处理用户互动的时间点。

屏幕截图

接下来是一系列屏幕截图，显示页面加载时的外观。

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

性能提升机会

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

“优化建议”部分。

点击具体优化建议即可了解相关详情。

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

点击了解详情...可查看关于为什么优化建议重要的文档，以及有关如何解决该问题的具体建议。

诊断

诊断部分详细介绍了影响网页加载时间的因素。

“诊断”部分。

已通过的审核

已通过的审核部分会显示网站的运行情况。点击即可展开该部分。

“已通过的审核”部分。

第 2 步：实验

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

启用文本压缩

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

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

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

打开网络面板，然后勾选设置 > 使用大请求行。

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

每个 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 部署网站的新版本。左下角有一个愉快的表情符号表示部署成功。

使用您之前了解的工作流程手动检查压缩功能是否正常运行：

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

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

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

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

棒极了！看起来好像是有进步的感觉。您的整体性能得分应该会有所提高，这意味着网站速度变快了。

现实环境中的文本压缩

大多数服务器确实都使用这样的简单修复启用压缩功能！只需搜索一下如何配置用于压缩文本的服务器即可。

调整图片大小

您的新报告指出，适当调整图片尺寸是另一个巨大契机。

调整图片大小有助于缩减图片文件大小，从而缩短加载时间。如果用户是在宽度为 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 行。开发者工具会在 Sources 面板中打开该文件。如果一行代码旁边有绿色条形，则表示已执行。代码行旁边的红条表示代码未执行，在网页加载时绝对不需要。
滚动浏览 jQuery 代码。某些“执行”的行实际上只是注释。另一种缩减此文件大小的方法是通过删除注释的缩减器来运行此代码。

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

加载网页是否还需要 jquery.js 和 lodash.js 文件？Request Blocking 标签页可以显示资源不可用时发生的情况。

点击网络标签页，然后再次打开命令菜单。
开始输入 blocking，然后选择 Show Request 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 面板中再次审核该网页。您的总体分数应该又有所提高。

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

关键渲染路径是指加载网页所需的代码。一般来说，您可以只在网页加载期间传递关键代码，然后延迟加载所有其他内容，从而加快网页加载速度。

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

减少主线程工作量

您的最新报告会在优化建议部分显示一些潜在的节省幅度，但如果您向下滚动到诊断部分，似乎最大的瓶颈在于主线程活动过多。

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

目标是使用 Performance 面板分析主线程在页面加载时正在执行的工作，并找到推迟或移除不必要的工作的方法。

依次打开 Performance > Capture Settings，然后将 Network 设为 Slow 3G，将 CPU 设为 6 倍速慢。

与笔记本电脑或桌面设备相比，移动设备的硬件限制通常更严格，因此，通过这些设置，您可以像使用性能较低的设备一样加载网页。
点击 重新加载。开发者工具会重新加载页面，然后直观呈现加载页面所需执行的所有操作。此可视化图表称为“跟踪记录”。trace

跟踪记录从左到右按时间顺序显示活动。通过顶部的 FPS、CPU 和 NET 图表，您可以大致了解每秒帧数、CPU 活动和网络活动。

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

您在概览部分中看到的黄色墙表示 CPU 正完全忙于执行脚本活动。提示：您可以通过减少 JavaScript 工作量来加快网页加载速度。

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

点击计时部分以将其展开。

React 中有一系列“用户计时”衡量指标，看起来 Tony 的应用使用的是 React 的开发模式。切换到 React 的生产模式或许可以轻松提升性能。
再次点击计时，以收起该部分。
浏览 Main 部分。此部分按时间顺序显示主线程活动的日志，按时间顺序从左到右显示。y 轴（从上到下）显示事件发生的原因。

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

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

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

Bottom-Up 部分仅显示您当前选择的任何 activity 或 activity 组的信息。例如，如果您点击了一个 mineBitcoin activity，Bottom-Up 部分仅显示该 activity 的信息。

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