教程的目标
本教程介绍了如何使用 Chrome 开发者工具提升网站加载速度。
请继续阅读或观看本教程的视频版本:
前提条件
您应具备基本的 Web 开发经验,这与 “网络开发简介”课程。
您无需了解有关加载性能的任何信息。
简介
我是 Tony。托尼在猫咪界非常有名。他打造了一个 网站,方便粉丝了解他最喜欢什么 他的粉丝非常喜欢这个网站,但 Tony 不断听到抱怨, 。Tony 请您帮他提高网站速度。
<ph type="x-smartling-placeholder">![](https://developer.chrome.google.cn/static/docs/devtools/lighthouse/image/tony-cat-e1c9e37033804.jpg?authuser=9&hl=bg)
第 1 步:审核网站
无论何时着手改善网站的加载性能,都务必从 审核。此项审核具有两项重要职能:
- 它为您衡量后续更改创建基准。
- 它为您提供了富有实用价值的提示,让您了解哪些更改会带来最佳效果。
设置
首先,您需要为 Tony 的网站,以便可以做出更改 :
在 Glitch 上混剪网站项目。您的新项目将在一个标签页中打开。 此标签页称为“编辑器”标签页。
项目名称从 tony 更改为一个随机生成的名称。现在,您便拥有了自己的可修改代码副本。稍后,您将更改此代码。
在编辑器标签页的底部,点击预览 >在新窗口中预览。该演示将在新标签页中打开。该标签页称为演示标签页。网站可能需要一段时间才能加载完毕。
在演示旁边打开开发者工具。
建立基准
基线是在您进行任何性能改进之前网站性能的记录。
打开 Lighthouse 面板。它可能隐藏在
更多面板后面。将您的 Lighthouse 报告配置设置与屏幕截图上的相应设置相匹配。以下是关于 不同的选项:
- check_box 清空存储空间。选中此复选框将在每次审核之前清除与该网页关联的所有存储空间。如果您想审核初访者在您网站上的体验,请将此设置保持开启状态。如果您想提供重复访问体验,请停用此设置。
- check_box 启用 JS 采样。此选项在默认情况下处于停用状态。开启该功能后,系统会将详细的 JavaScript 调用堆栈添加到性能跟踪记录中,但可能会减慢报告生成速度。轨迹文件可在 more_vert 工具菜单下找到 >生成 Lighthouse 报告后,查看未节流的跟踪记录。
- 模拟节流(默认) 。此选项可模拟在移动设备上浏览的典型条件。这称为“模拟”因为在审核过程中,Lighthouse 实际上不会进行限制。而是推断网页在移动设备上的加载时间。另一方面,DevTools 节流(高级)设置实际上会限制 CPU 和网络,但需要较长的审核过程。
- 模式 >三种模式。 导航(默认)。此模式将分析单个网页加载,而我们在本教程中需要此模式来分析。如需了解详情,请参阅
- 设备 > 移动设备。移动选项会更改用户代理字符串并模拟移动设备, 视口“桌面设备”选项几乎会停用移动设备更改。
- 类别 >check_box 性能。启用单一类别后,Lighthouse 仅会生成包含一组相应审核的报告。如果您想查看其他类别提供的建议类型,可以将其保持启用状态。停用不相关的类别可稍微加快审核过程。
点击分析网页加载。10 到 30 秒后,Lighthouse 面板会显示该网站的效果报告。
处理报告错误
如果你在 Lighthouse 报告中遇到错误,请尝试运行演示标签页 在不打开其他标签页的无痕式窗口中打开。这样可以确保您 从干净状态运行 Chrome尤其是 Chrome 扩展程序 会干扰审计流程
解读报告
报告顶部的数字是网站的总体效果得分。稍后, 对代码进行更改后,您应该会看到该数字逐渐增加。得分越高,效果越好。
指标
向下滚动到指标部分,然后点击展开视图。如需阅读有关某个指标的文档,请点击了解详情...。
此部分提供了对网站性能的量化衡量标准。 每个指标都可以让您深入了解效果的一个不同方面。例如 First Contentful Paint 会告知您内容首次绘制到屏幕上的时间,这是用户 而“可交互时间”标记的是网页加载的时间点 看起来足以处理用户互动
屏幕截图
接下来是一组屏幕截图,向您展示网页在加载后的显示效果。
商机
接下来是“优化”部分,该部分提供了有关如何提高此特定网页的加载速度的具体提示 性能
点击相应优化建议即可了解详情。
点击了解详情...可查看相关文档,了解优化建议的重要性以及具体原因 有关如何解决这个问题的建议。
诊断
诊断部分可详细了解导致网页排名下降的因素 加载时间。
已通过的审核
已通过的审核部分会显示网站正常运行的内容。点击展开 部分。
第 2 步:实验
Lighthouse 报告的优化部分提供了有关如何改进网页 性能在本部分中,您将对代码库实施建议的更改,并审核 以衡量这些更改对网站速度的影响。
启用文本压缩
您的报告显示,启用文本压缩是改进 网页性能
文本压缩是指先缩减或压缩文本文件的大小,然后再通过 。就像在通过电子邮件发送文件夹之前压缩文件夹的大小一样。
在启用压缩之前,您可以通过以下几种方式手动检查文字 资源。
打开 Network 面板,然后勾选 使用大型请求行。
Settings >每个 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'))
之前。等待 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 会重新加载页面,然后直观呈现其加载页面所需的所有操作。我们将这种可视化方式称为“跟踪记录”。
轨迹按时间顺序从左到右显示活动。下面的 FPS、CPU 和 NET 图表 简要介绍每秒帧数、CPU 活动和网络活动。
您在概览部分看到的黄色墙表示 CPU 完全忙于执行脚本活动。 这表明您可以通过减少 JavaScript 工作量来加快网页加载速度。
调查跟踪,以找到减少 JavaScript 工作量的方法:
点击计时部分将其展开。
React 提供了许多 User Timing 衡量指标,Tony 的应用似乎使用的是 React 的开发模式。切换到 React 的生产模式可能会轻松获得一些性能提升。
再次点击计时可收起该部分。
浏览主要部分。此部分按时间顺序展示主线程活动日志, 从左到右y 轴(从上到下)显示事件发生的原因。
在此示例中,
Evaluate Script
事件导致(anonymous)
函数执行,进而导致执行__webpack__require__
,进而执行./src/index.jsx
,依此类推。向下滚动到 Main 部分的底部。使用框架时 大部分的上层活动都是由框架导致的, 完全由您控制应用产生的 activity 通常位于底部。
在此应用中,名为
App
的函数似乎导致对mineBitcoin
函数的大量调用。看来 Tony 可能在使用粉丝的设备进行加密货币挖矿...打开底部的 Bottom-Up 标签页。此标签页细分了哪些活动耗时最长。如果 Bottom-Up 部分中未显示任何内容,请点击 Main 部分的标签。
自下而上部分仅显示您拥有的任何活动或活动组的信息 。例如,如果您点击了一个
mineBitcoin
activity, 自下而上部分将仅显示该活动的信息。自用时间列会显示直接在每项活动中花费的时间。在本例中,大约 82% 的主线程时间花在了
mineBitcoin
函数上。
现在来看看是否使用生产模式并减少 JavaScript 活动 从而加快网页加载速度从生产模式开始:
- 在编辑器标签页中,打开
webpack.config.js
。 - 将
"mode":"development"
更改为"mode":"production"
。 - 等待新构建部署完成。
再次审核该网页。
通过移除对 mineBitcoin
的调用来减少 JavaScript 活动:
- 在编辑器标签页中,打开
src/App.jsx
。 - 注释掉
constructor
中对this.mineBitcoin(1500)
的调用。 - 等待新构建部署完成。
- 再次审核该网页。
与往常一样,您仍需进行一些调整,例如减少 Largest Contentful Paint 和 Cumulative Layout Shift 指标。
在现实世界中减少主线程工作
一般来说,要了解网站所执行的活动,最常用的方式是查看效果面板 并设法移除不必要的 activity。
如果您倾向于使用更像 console.log()
的方法,可以使用 User Timing API
随意标记应用生命周期的某些阶段,以跟踪其中每个阶段的时长
各个阶段所需要的时间。
摘要
- 每当您着手优化网站的加载性能时,始终从 进行审核。此项审计旨在确立一个基准,并为您提供有关如何 改进。
- 一次进行一项更改,并在每次更改后审核网页,以确定 了解孤立的变化对性能有何影响。
后续步骤
对您自己的网站进行审核!如果您在解读报告或寻找提升加载性能的方法方面需要帮助,请查看向开发者工具社区获取帮助的所有方式:
- 在 developer.chrome.com 代码库中提交有关此文档的错误。
- 在 Chromium Bugs 中提交有关开发者工具的错误报告。
- 讨论邮寄名单中的功能和变更。请勿将邮寄名单用于 支持问题。请改用 Stack Overflow。
- 在 Stack Overflow 上获取有关如何使用开发者工具的常规帮助。若要提交 bug 请求,请一律使用 Chromium bug。
- 请发送电子邮件至 @ChromeDevTools 与我们联系。