性能优化之详解各种指标

,上篇文章最后提到了我们可以通过「performance」的一些属性对性能做统计，我们会发现performance对象下有非常多的属性，远不止上篇文章提到的DOMContentLoaded与Load这两个事件。,或许你在浏览器控制台见过它们这些身影：DCL、LCP、FP、FCP、L,,这里的DCL与L就是我们上篇文章介绍的DOMContentLoaded与Load这两个事件，那剩下的LCP、FP、FCP又分别代表什么呢？,在早期前端三剑客的时代或者现在的服务端渲染，DCL与L确实可以很好地衡量首屏内容展示时间，但对于现代各种框架盛行的单页应用，由于都是通过JS操作DOM向页面添加主要内容，DCL和L事件就不能很好地衡量首屏显示时间了。,于是有FP、FCP、FMP被提出来，它们关注的不是「加载」，而是「渲染」，因此能更好地表现用户看到的情况。,FP、FCP这两个指标虽然表达了渲染的事件，但对“用户关注的内容”没有体现，比如首屏渲染出来一个背景，或者一个loading，可能对于用户来说和白屏区别不大。FMP虽然体现了“关键内容”的要素，但它是复杂的、模糊的，甚至是错误的，并不能准确识别页面主要内容的加载时机。,后来LCP指标被提出来，表示“「用于度量视口中最大的内容元素何时可见」”，它用来代替FMP，表征页面的关键元素何时可以被用户看到。,除了加载性能，还有可交互时间、稳定性指标、流畅性指标，在不同的业务场景都可以被监控用来作为提升用户体验的依据。,上面我们提到了各种性能相关的事件，那么它们各种代表的含义是什么呢？,「load」 事件在整个页面及所有依赖资源如样式表和图片都已完成加载时触发。它与 DOMContentLoaded 不同，后者只要页面 DOM 加载完成就触发，无需等待依赖资源的加载。,很多人可能会误以为Load的触发一定会在DCL之后，虽然绝大多数我们看到的确实是这样，但你从两者的MDN解释上来看，DCL关注的时HTML文档的加载与解析，而Load只关注资源的加载，所以两者触发的先后顺序并不是绝对的。,比如下面两种情况：,「第一种：」页面非常简单，没有引入任何外部资源,,从图中可以看到此时的Load触发在DCL之前，这是因为load不包含对文档解析的时间,「第二种：」我们引入一张图片,,从这张图上我们可以看到此时DCL比Load先触发，并且很明显可以看到在两者之前多了个图片的下载过程。,所以两者触发的先后顺序并不是固定的，如果页面有许多外部资源需要加载，那么load事件会后触发，如果页面内容较多，外部资源较少，那么load事件可能先触发。」,为了应对现在框架盛行的单页应用新增了下面这几个指标，它们关注的不再是页面的「加载」过程，而是页面的「渲染」过程。,为了方便，这两个放一起讲：,简单点理解就是FCP事件指渲染出第一个内容的事件，而FP指渲染出第一个像素点，渲染出的东西可能是内容，也可能不是。,需要注意的是，FCP一定不会比FP晚触发，但可能会一起触发，绝大多数情况是FP在FCP之前触发！」,「第一种：」无FP,是不是很奇怪，怎么会有这种情况？其实我们上面DCL与Load那里的第一个案例就出现了这种情况,,页面上有节点但没有样式，很显然这种情况是不需要渲染页面的，所以也就没有FP,当然这里需要注意的是这里的节点不包括一些自身可见的节点（比如img、input、video等）,还有一种情况就是「如果要渲染的内容在视口之外，那么也不会触发 FP」,「第二种：」有FP无FCP,同时为了验证第一种说法的注意点，这里我就写一个input来试试,,从这里我们就能发现，此时页面只会触发FP，因为没有内容,浏览器不一定等到所有的DOM都解析完再开始渲染，如果DOM节点少，浏览器会加载完再渲染，但是如果节点很多，浏览器解析一部分节点后就会开始渲染（这时候就会触发FP）。也就是说，当需要渲染的节点数少的时候，DCL会在FP前面；当需要渲染的节点数很多时候，DCL会在FP后面。,现在来说，绝大部分的项目都是FP在DCL之前触发，这样用户可以更快的看到页面内容。,为了提供良好的用户体验，我们应努力将最大内容绘制时间控制在「2.5 秒」或更短。,图片,随着更多研究的进行，未来可能会添加其他元素。,这里可以通过performance面板，在Timings这一行找到LCP，点击它再找到下面的summary，就能找到LCP对应的节点元素了。,,谷歌一直十分重视网站的用户体验，移动友好性，页面加载速度和HTTPS是Google已经使用的页面排名因素，而2020年，谷歌将Core Web Vitals新纳入的用户体验指标。,测量TTI一般需要按以下步骤：,为了方便理解，可以对照这张图,,只要存在「long task」（在主线程上运行超过 50 毫秒 (ms) 的任务），主线程就会被视为“阻塞”。我们说主线程被“阻塞”，因为浏览器无法中断正在进行的任务。因此，如果用户在长时间任务中确实与页面进行交互，则浏览器必须等待任务完成才能响应。,测量TBT可以使用谷歌Lighthouse,为了提供良好的用户体验，在「平均移动硬件」上进行测试时，网站应努力使总阻塞时间低于「200 毫秒」。,只要可视区域中可见元素的起始位置（例如，元素在默认书写模式下的顶部和左侧位置）在两帧之间发生了变更，该 API 就会报告layout-shift条目。这样的元素被视为不稳定元素。,请注意，只有当现有元素的起始位置发生变更时才算作布局偏移。如果将新元素添加到 DOM 或是现有元素更改大小，则不算作布局偏移，前提是元素的变更不会导致其他可见元素的起始位置发生改变。,浏览器在计算布局偏移分数时，会查看可视区域大小和两个已渲染帧之间的可视区域中不稳定元素的位移。布局偏移分数是该位移的两个度量的乘积：影响分数和距离分数（两者定义如下）。,为了提供良好的用户体验，网站应该努力将 CLS 分数控制在「0.1」 或以下。为了确保您能够在大部分用户的访问期间达成建议目标值，一个良好的测量阈值为页面加载的「第 75 个百分位数」，且该阈值同时适用于移动和桌面设备。,这里需要注意的是在写动画时优先考虑使用CSS transform属性，因为它能够在不触发布局偏移的情况下为元素设置动画：,为了更准确的统计性能数据，可以使用web-vitals库来测量各项性能指标,「可以获取的指标有：CLS、FID、LCP、以及 FCP、TTFB」,