如何利用 Chrome DevTools 优化网页性能

这篇内容是极客时间每日一课的学习笔记，本来是记录在了幕布上面，但分享到部落之后发现体验效果并不好，写作平台这么好的东西不能再束之高阁了。

为啥要做性能优化？

前端性能直接关系到产品的用户体验与经营结果。

解决前端性能的关键点

如何定义前端性能的标准，并获取到标准对应的指标值，从而发现影响页面性能的问题。

如何定义页面性能的指标体系？

我们需要关注的性能指标

request数、打包大小、load时间、FCP:首次内容绘制、LCP:最大内容绘制，代表最核心的内容被加载的时间、TBT:累积阻塞时间评估网站资源加载在执行和阻塞的时间。

使用ChromeDevTools来测试性能指标

性能分析的插件Lighthouse

生成Performance报告后，重点关注以下指标

• First Contentful Paint（FCP）

当用户启动页面加载与呈现首屏内容之间的时间,时间越长，白屏时间越长。可以通过骨架屏等手段，尽量将页面分批分层逐步加载，加强用户的体验感受。尽可能少得等待。

• Largest Contentful Paint(LCP)

测量网站中最大的元素，何时呈现在屏幕上，可以近似理解为最主要的内容对用户的可见时间，LCP主要受服务器响应时间、存在渲染阻止的JavaScript和CSS、资源加载时间、客户端渲染时间四个因素的影响。

• Total Bloking Time(TBT)

总阻塞时间。用来量化加载的响应能力，累积主线程被阻塞并会影响用户操作反馈的总时间。



为了找到FCP与LCP的阻塞点，建议打开Chrome DevToos过滤器的Capture screenshots选项。

我的Chrome版本是 85.0.4183.83，勾选Performance中的Screenshots选项，在访问目标页面之前，点击Record，就能很直观得得到页面的各个阶段的性能情况。

华为内部性能指标的建议值

四个性能优化方向

• 减少第三方代码的影响

• 减少主线程工作，我们可以使用LightHouse里面的long main-thread task来看

• 减少JS执行时间，我们可以使用LightHouse里面的JavaScript execution time

• 保持低请求的数量和小传输

Chrome团队的RAIL模型(https://web.dev/rail/)

• RAIL是以用户为中心的性能模型，它将性能分解为以下四个方面：

• Response

• Animation

• Idle

• Load

写在最后

最后，我想说的是，以前只会去学买的专栏，很少打开《每日一课》这个产品，最近发现能学到不少东西。

15分钟的分享，我花了差不多两个小时来消化。不管是解决问题的思路、还是一个工具，都是能立即就能用得上的，所以，千万不要错过。