教程的目标
本教程教你如何使用Chrome DevTools来寻找让网站加载更快的方法。
请继续阅读,或观看本教程的视频版本。
先决条件
- 你应该有基本的Web开发经验,类似于这门Web开发入门课所讲的内容。
- 你不需要了解任何关于负载性能的知识。你将在本教程中学习到它!
介紹
这是托尼。托尼在猫咪社会非常有名。他建立了一个网站,让他的粉丝可以了解他最喜欢的食物是什么。他的粉丝很喜欢这个网站,但是托尼一直听到抱怨说网站加载速度很慢。托尼要求你帮助他加快网站的速度。
图1.猫咪托尼
第一步:审计现场
每当你着手提高网站的加载性能时,总是从审计开始。审核有2个重要的功能。
- 它为您创建一个基线,以衡量后续的变化。
- 它为您提供了可操作的提示,让您知道哪些变化会产生最大的影响。
设置
但首先,你需要对网站进行设置,以便以后可以对其进行修改。
- 去chrome://version检查你使用的Chrome浏览器版本。本教程是用Chrome 68制作的。如果您使用的是更早或更晚的版本,一些功能可能看起来不同或不可用。你应该仍然能够完成本教程,只是要记住,你的用户界面可能看起来与截图不同。
- 打开网站的源代码。这个标签将被称为编辑器标签。
图2.编辑器选项卡
- 点击tony。出现一个菜单。
图3.点击tony后出现的菜单。
-
点击Remix This。项目名称从tony变成了某个随机生成的名称。现在你有了自己的可编辑的代码副本。稍后,你将对这段代码进行修改。
-
点击Show Live。演示将在一个新的标签页中打开。这个标签页将被称为演示标签页。网站可能需要一段时间才能加载。
图4. 演示标签页
- 按 Command+Option+J (Mac) Control+Shift+J (Windows, Linux, Chrome OS)。Chrome DevTools 将与演示一同打开。
图5.DevTools 和演示。
在本教程的其余截图中,DevTools将显示为一个单独的窗口。您可以通过按Command+Shift+P(Mac)或Control+Shift+P(Windows,Linux,Chrome OS)打开命令菜单,输入Undock,然后选择Undock进入单独的窗口。
图6.Undocked DevTools Undocked DevTools
确定基线
基线是您在进行任何性能改进之前网站性能的记录。
- 单击 "审计 "选项卡。它可能隐藏在更多面板更多面板按钮后面。这个面板上有一个Lighthouse,因为为Audits面板提供动力的项目叫做Lighthouse。
图7.Audits面板
- 将您的审计配置设置与图7中的设置相匹配。下面是对不同选项的解释。
- 设备。设置为Mobile会改变用户代理字符串并模拟移动视口。设置为Desktop几乎只是禁用Mobile的变化。
- 审核。禁用一个类别会阻止审计面板运行这些审计,并从您的报告中排除这些审计。如果你想看到它们提供的建议类型,你可以不启用其他类别。禁用类别可以稍微加快审计过程。
- 节流。设置为模拟快速3G,4倍CPU减速,可以模拟在移动设备上浏览的典型条件。之所以称为 "模拟",是因为审核面板在审核过程中并没有实际节流。相反,它只是推断出在移动条件下加载页面所需的时间。另一方面,"应用... "设置实际上会对你的CPU和网络进行节流,但代价是审计过程会更长。
- 清除存储。启用此复选框会在每次审核前清除与页面相关的所有存储。如果您想审计首次访问者对您网站的体验,请保留此设置。如果您想要重复访问的体验,则禁用此设置。
- 单击 "运行审核"。10至30秒后,审计面板会向您显示网站的性能报告。
图8.Audits面板的网站性能报告。审计面板的网站性能报告。
处理报告错误
如果您在审计面板报告中收到错误信息,请尝试在没有打开其他选项卡的情况下从隐身窗口运行演示选项卡。这可以确保你是在一个干净的状态下运行Chrome。特别是Chrome扩展程序经常会干扰审计过程。
图9.一个出错的报告
了解您的报告
你的报告顶部的数字是网站的整体性能得分。之后,当你对代码进行修改时,你应该会看到这个数字上升。分数越高,意味着性能越好。
图10. 整体性能得分
指标部分提供了网站性能的量化测量。每个指标都能深入了解性能的不同方面。例如,First Contentful Paint(首次内容绘制)告诉您内容何时首次绘制到屏幕上,这是用户感知页面加载的一个重要里程碑,而Time To Interactive(交互时间)则标志着页面出现在足以处理用户交互的时间点。
图11.指标部分
将鼠标悬停在一个度量上,可以看到对它的描述,并单击 "学习更多 "来阅读有关它的文档。
图12.将鼠标悬停在 "第一有意义的油漆 "指标上
下面的指标是一组截图,显示页面在加载时的样子。
图13.页面加载时的外观截图。加载时页面看起来如何的截图
机会部分提供了具体的提示,告诉你如何提高这个特定页面的加载性能。
图14. 机会部分
点击机会了解更多信息。
图15.文本压缩机会的更多信息
单击 "了解更多",查看关于为什么某个机会很重要的文档,以及关于如何修复它的具体建议。
图16.文本压缩机会的文档。文本压缩机会的文档
诊断部分提供了更多关于导致页面加载时间的因素的信息。
图17.诊断部分
已通过的审核 "部分向您展示了网站的正确做法。单击以展开该部分。
图18.已通过的审核部分 已通过的审核 "部分
第二步:实验
审核报告中的 "机会 "部分为您提供了关于如何提高页面性能的提示。在这一节中,您将实施对代码库的建议更改,在每次更改后对网站进行审计,以衡量其对网站速度的影响。
启用文本压缩
您的报告中说,启用文本压缩是提高页面性能的首要机会之一。
文本压缩是指在通过网络发送文本文件之前,减少或压缩其大小。就像你在发送电子邮件之前压缩一个文件夹以减小其大小一样。
在启用压缩之前,这里有几种方法可以手动检查文本资源是否被压缩。
- 点击 "网络 "选项卡。
图19.网络面板
- 点击使用大请求行。网络请求表中的行的高度会增加。
图20 网络请求表中的大行
- 如果在网络请求表中没有看到 "大小 "列,请点击表头,然后选择 "大小"。
每个 "大小 "单元格显示两个值。顶部的值是下载资源的大小。底部的值是未压缩资源的大小。如果这两个值相同,那么资源在通过网络发送时就没有被压缩。例如,在图20中,bundle.js的顶部和底部值都是1.4 MB。
你也可以通过检查资源的HTTP头来检查压缩情况。
- 点击 bundle.js。
- 点击Headers选项卡。
图21.Headers选项卡
- 在Response Headers部分搜索
content-encoding头。你不应该看到一个,这意味着bundle.js没有被压缩。当一个资源被压缩时,这个头通常被设置为gzip、deflate或br。关于这些值的解释,请参见 Directives。
解释到此为止。是时候做一些改变了 通过添加几行代码来启用文本压缩。
- 在编辑器选项卡中,点击server.js。
图22.编辑
server.js
- 在server.js中添加以下代码。确保将
app.use(compression())放在app.use(express.static('build'))之前。
...
const fs = require('fs')。
const compression = require('compression').app.use(compression());
app.use(compression())。
app.use(express.static('build'))。
...
注意:通常情况下,你必须通过类似npm i -S compression这样的东西来安装compression包,但这已经为你完成了。
- 等待Glitch部署新构建的网站。你在Logs和Show旁边看到的花哨的动画意味着网站正在进行重建和重新部署。当你再次看到Show Live时,变化已经准备好了。
图23.表示网站正在建设的动画。
使用之前学习的工作流程手动检查压缩是否有效。
- 回到demo选项卡,重新加载页面。现在,"大小 "一栏应该为bundle.js等文本资源显示2个不同的值。在图24中,
bundle.js的顶部值261 KB是通过网络发送的文件大小,底部值1.4 MB是未压缩的文件大小。
图24.大小栏现在显示了2个不同的文本资源值。
bundle.js的Response Headers部分现在应该包含一个content-encoding: gzip头。
图25.Bundle.js 的 Response Headers 部分现在包含了一个
content-encoding头
再次审计页面,以衡量文本压缩对页面的加载性能有什么样的影响。
- 单击 "审计 "选项卡。
- 单击 "执行审计 "。
- 保持设置与之前相同。
- 单击 "运行审核"。
图26.启用文本压缩后的审计报告。启用文本压缩后的审计报告
呜呼!这看起来像是进步。你的整体性能得分应该增加了,这意味着网站变得更快了。
现实世界中的文本压缩
大多数服务器真的有这样简单的修复方法来启用压缩功能!只要搜索一下如何配置你使用的任何服务器来压缩文本。只要搜索一下如何配置你使用的任何服务器来压缩文本。
调整图片大小
你的新报告说,适当调整图片大小是另一个大机会。
调整图片大小有助于通过减少图片的文件大小来加快加载时间。如果你的用户在500像素宽的移动设备屏幕上查看你的图片,那么发送1500像素宽的图片真的没有意义。理想情况下,你最多发送500像素宽的图片。
- 在你的报告中,点击适当大小的图片来查看哪些图片应该被调整大小。看起来所有4张图片都比需要的大。
图27. 关于 "适当大小的图像 "机会的详细信息
-
回到编辑器选项卡中,打开
src/model.js。 -
将
const dir = 'big'替换为const dir = 'small'。这个目录包含了相同图片的副本,这些图片已经被调整了大小。 -
再次审计页面,看看这个变化对加载性能的影响。
图28.调整图片大小后的审计报告 调整图片大小后的审计报告
看起来,这个变化只对整体性能得分有轻微影响。不过,有一点分数并没有明确显示,那就是你为用户节省了多少网络数据。旧照片的总大小约为5.3兆,而现在只有0.18兆左右。
在现实世界中调整图片大小
对于一个小应用来说,做这样的一次性调整大小可能已经足够好了。但对于一个大型应用来说,这显然是不可扩展的。下面是一些管理大型应用中图片的策略。
- 在构建过程中调整图片大小。
- 在构建过程中为每个图片创建多个尺寸,然后在代码中使用srcset。在运行时,浏览器会负责选择最适合它运行的设备的尺寸。参见相对大小的图像。
- 使用一个图像CDN,让你在请求图像时动态调整它的大小。
- 至少,优化每个图像。这通常可以创造巨大的节约。优化是指您通过特殊程序运行图像,以减少图像文件的大小。更多技巧请参见Essential Image Optimization。
消除渲染阻塞资源
你的最新报告说,消除渲染阻断资源是现在最大的机会。
渲染阻断资源是一个外部的JavaScript或CSS文件,浏览器在显示页面之前必须下载、解析和执行。我们的目标是只运行正确显示页面所需的核心CSS和JavaScript代码。
那么,第一个任务就是找到不需要在页面加载时执行的代码。
- 点击 "消除渲染阻塞资源 "来查看阻塞的资源:
lodash.js和jquery.js。
图29.减少渲染阻塞资源
- 按 Command+Shift+P (Mac) 或 Control+Shift+P (Windows、Linux、Chrome OS) 打开命令菜单,开始键入
覆盖率,然后选择显示覆盖率。
图30.从审计面板打开命令菜单
图31. "覆盖范围 "选项卡。
- 点击Reload重新加载。覆盖率选项卡提供了
bundle.js、jquery.js和lodash.js中多少代码在页面加载时被执行的概况。图32说,分别有大约76%和30%的jQuery和Lodash文件没有被使用。
图32. 覆盖率报告
- 点击jquery.js行。DevTools会在Sources面板中打开该文件。如果一行代码旁边有绿色的条状物,则表示该行代码被执行。红色的条形表示它没有被执行,并且在页面加载时绝对不需要。
图33.在Sources面板上查看jQuery文件
- 滚动一下jQuery的代码。一些被 "执行 "的行实际上只是注释。通过minifier运行这段代码,剥离注释是另一种减少文件大小的方法。
总之,当你在处理自己的代码时,Coverage选项卡可以帮助你逐行分析你的代码,并且只运送页面加载所需的代码。
jquery.js和lodash.js文件是否是加载页面所需要的?请求阻止选项卡可以显示资源不可用时的情况。
- 点击 "网络 "选项卡。
- 按Command+Shift+P(Mac)或Control+Shift+P(Windows、Linux、Chrome OS)再次打开命令菜单。
- 开始键入
blocking,然后选择显示请求阻塞。
图34. 请求拦截选项卡
- 点击添加模式,输入
/libs/*,然后按Enter确认。
图35. 添加模式以阻止任何对libs目录的请求。
- 重新加载页面。jQuery和Lodash的请求是红色的,意味着它们被阻止了。页面仍然在加载,并且是交互式的,所以看起来根本不需要这些资源。
图36.网络面板显示请求已被阻止。
- 点击移除所有模式以删除
/libs/*阻塞模式。
一般来说,请求阻塞选项卡对于模拟当任何给定资源不可用时,你的页面是如何表现的很有用。
现在,从代码中删除对这些文件的引用,并再次审核页面。
- 回到编辑器选项卡中,打开模板.html。
- 删除
<script src="/libs/lodash.js">和<script src="/libs/jquery.js"></script>。 - 等待网站重新构建并重新部署。
- 再次从审计面板中审计该页面。你的整体得分应该会再次提高。
图37.删除渲染阻塞资源后的审计报告。
优化现实世界中的关键渲染路径。
关键渲染路径指的是你需要加载页面的代码。一般来说,你可以通过只在页面加载过程中运送关键代码来加快页面加载速度,然后懒惰加载其他一切。
- 你不可能找到可以直接删除的脚本,但你会经常发现许多脚本不需要在页面加载期间被请求,而是可以异步请求。请看使用异步或延迟。
- 如果你使用的是一个框架,请检查它是否有生产模式。这种模式可能会使用剪枝等功能,以消除阻塞关键渲染的不必要代码。
减少主线程的工作
您最新的报告在 "机会 "部分显示了一些小的潜在节约,但如果您在 "诊断 "部分往下看,似乎最大的瓶颈是过多的主线程活动。
主线程是浏览器完成显示页面所需的大部分工作的地方,例如解析和执行HTML、CSS和JavaScript。
我们的目标是使用 "性能 "面板来分析页面加载时主线程正在做的工作,并找到推迟或删除不必要工作的方法。
- 单击 "性能 "选项卡。
- 单击 "捕获设置 "捕获设置。
- 将网络设置为慢速3G,CPU设置为6倍减速。移动设备通常比笔记本电脑或台式机有更多的硬件限制,因此这些设置可以让您体验到页面加载,就像您使用功能较弱的设备一样。
- 单击重载。DevTools会重新加载页面,然后生成一个可视化,说明为了加载页面所必须做的一切。这种可视化将被称为跟踪。
图38.性能面板对页面加载的跟踪。
轨迹按时间顺序显示活动,从左到右。顶部的FPS、CPU和NET图表显示了每秒帧数、CPU活动和网络活动的概况。在图39中,你看到的黄色墙意味着CPU完全忙于脚本活动。这是一个线索,你也许可以通过减少JavaScript工作来加快页面加载速度。
图39.跟踪的Overview部分
调查跟踪,找到减少JavaScript工作的方法。
- 点击User Timing部分来展开它。根据似乎有一堆来自React的User Timing措施的事实,似乎Tony的应用程序正在使用React的开发模式。切换到React的生产模式,可能会轻松获得一些性能上的胜利。
图40.用户计时部分
-
再次单击用户计时,折叠该部分。
-
浏览主要部分。该部分显示了主线程活动的时间顺序日志,从左到右。y轴(从上到下)显示了事件发生的原因。例如,在图41中,
Evaluate Script事件导致了(anonymous)函数的执行,导致了../rbd/pnpm-volume/...的执行,导致了__webpack__require__的执行,等等。
图41. 主要部分
- 向下滚动到主栏目的底部。当你使用一个框架时,大部分的上层活动是由框架引起的,这通常是你无法控制的。由你的应用程序引起的活动通常在底部。在这个应用中,似乎一个叫做
App的函数导致了对一个mineBitcoin函数的大量调用。听起来托尼可能会使用他的粉丝的设备来挖掘加密货币... ...
图42.将鼠标悬停在mineBitcoin活动上
注意:虽然您的框架所做的调用通常不受您的控制,但有时您可能会以一种导致框架运行效率低下的方式来构建您的应用程序。重组您的应用程序以有效地使用框架可以是一种减少主线程工作的方法。然而,这需要深入了解你的框架是如何工作的,以及你可以在自己的代码中做出什么样的改变来更有效地使用框架。
- 展开Bottom-Up部分。这个选项卡分解了哪些活动占用了最多的时间。如果你在Bottom-Up部分没有看到任何内容,点击Main部分的标签。自下而上 "部分只显示您当前选择的任何活动或活动组的信息。例如,如果你点击了其中一个活动 "
mineBitcoin","Bottom-Up "部分将只显示这一个活动的信息。
图43. 自下而上选项卡
自身时间一栏显示了在每个活动中直接花费了多少时间。例如,图43显示,大约57%的主线程时间花在了mineBitcoin函数上。
时间来看看使用生产模式和减少JavaScript活动是否会加快页面加载速度。先用生产模式。
- 在编辑器选项卡中,打开
webpack.config.js。 - 将
"mode":"development""改为"mode":"production"。 - 等待新版本的部署。
- 再次审核页面。
图44.配置webpack为生产模式后的审计报告
通过删除对mineBitcoin的调用来减少JavaScript活动。
- 在编辑器选项卡中,打开 src/App.jsx.
- 在构造函数中注释掉对this.mineBitcoin(1500)的调用。
- 等待新的构建部署。
- 再次审计页面。
图45.删除不必要的JavaScript工作后的审计报告
看来,最后的改变导致了性能的大幅提升!
注:本节对性能面板进行了相当简短的介绍。请参阅性能分析参考,了解更多关于如何使用它来分析页面性能的信息。
在现实世界中少做主线程的工作
一般来说,性能面板是了解你的网站在加载时做了哪些活动,并找到删除不必要活动的方法的最常用方法。
如果你更喜欢类似于 console.log()的方法,用户计时 API 可以让你任意标记应用程序生命周期的某些阶段,以便跟踪每个阶段所需的时间。
在此特别感谢Tony
托尼的粉丝喜欢现在网站的速度,托尼非常感谢您的帮助。点击下面的 "收到礼物",就可以收到托尼的特别礼物。
总结
- 每当你开始优化一个网站的加载性能时,总是从审计开始。审核可以建立一个基线,并为你提供如何改进的提示。
- 每次做一个改变,并在每次改变后对页面进行审计,以便了解该孤立的改变如何影响性能。
接下来的步骤
- 在您自己的网站上运行审计 如果您需要帮助解释您的报告,或找到改善负载性能的方法,请查看反馈,以获得DevTools社区的帮助。Stack Overflow、邮件列表或 Twitter 可能是解决此类问题的最佳途径。
- 请对本教程留下反馈。我真的会利用这些数据为您制作更好的教程。
反馈意见
本页对您有帮助吗?
- 有帮助
- 没有
如果还有什么我们应该知道的,请通过适当的渠道发送消息。
- 在Web基础知识仓库中提交本文档的错误。
- 在DevTools的Chromium Bugs上提交bug报告。
- 在邮件列表中讨论功能和变化。请不要使用邮件列表来讨论支持问题。请使用Stack Overflow。
- 在Stack Overflow上获得关于如何使用DevTools的一般帮助。请不要在Stack Overflow上提交错误。请使用 Chromium Bugs。
- 请发微博@ChromeDevTools。
通过( www.DeepL.com/Translator )(免费版)翻译