作者：京东科技 郝梁
前言：作为 C 端前端研发，除了攻克业务难点以外，也要有更深层的自我目标，那就是性能优化。这事儿说大不大，说小也不小，但难度绝对不一般，所涉及的范围优化点深入工程每个细胞。做好前端性能优化绝非简单之事！文章主要内容介绍前端性能考核指标及优化方案。
一、前端性能指标有哪些？
根据 chrome Lighthouse 最新规则，前端性能指标考量主要有 FCP（First Contenful Paint）、SI（Speed Index）、LCP（Largest Contentful Paint）、TBT（Total Blocking Time）、CLS（Cumulative Layout Shift） ，占比分别如下。
二、什么是 FCP ？
FCP： First Contentful Paint 首次内容绘制是指测量页面从开始加载到页面内容（文本、图片、背景图、svg 元素或非白色 canvas 元素）的任何部分在屏幕上完成渲染的时间，是测量加载速度感知的重要指标之一。
示例：
从上图可以观察到，页面加载开始到页面渲染完成的时间轴中，FCP 发生在第二帧，首批文本和图片在屏幕上已经渲染完成。
虽然页面一部分内容已完成渲染，但这并非页面所有内容全部完成渲染；这就是首次内容绘制（FCP）与最大内容绘制（LCP）最重要的区别。
FCP 性能值：首次内容绘制完成渲染时间应控制在 1.8s 以内。
我们可以从以下方向点优化 FCP ：
•消除阻塞渲染的资源：
◦<script> 标签：在 <head> 标签内的，并且没有 defer/async 属性
◦<link rel="stylesheet"> 标签：没有 disabled 属性，有 media="all" 属性被认为是渲染阻塞
•缩小 CSS 体积：写法，压缩 CSS
•移除未使用的 CSS
•预连接到所需的来源： <link rel="preconnect">
•减少服务器响应时间（TTFB）
•避免多个页面重定向：浏览器请求已定向的资源时，服务器会返回一个 HTTP 响应，然后浏览器必须在新位置发出另一个 HTTP 请求来检索资源。这种额外的网络传输会使资源加载延迟数百毫秒。
•预加载关键请求：<link rel="preload" href="styles,css" as="style" />
•避免巨大的网络负载：网络负载的中位数在 1700 到 1900 KiB 之间。 Lighthouse 会标记总网络请求超过 5000 KiB 的页面。将总字节大小保持在 1600 KiB 以下。
◦缩小和压缩网络有效负载：缩小（代码），数据压缩（Gzip，Brotli）
◦图片使用 Webp
◦JPEG 图片压缩级别设置为 85
•对静态资源使用高效的缓存策略：可缓存资源
◦字体、图像、媒体文件、脚本或样式表
◦资源具有 200 、 203 、 206 HTTP 状态码
◦资源没有明确的无缓存策略
•避免 DOM 过大：
◦会造成网络效率和负载性能差
◦页面交互时，会导致重新计算节点的位置和样式，降低渲染速度
◦可能会不知不觉存储大量节点的引用，造成内存过大
•最小化关键请求深度：链的长度越长，下载量越大，对页面加载性能的影响就越大
◦减少关键资源数量（删除，推迟下载，标记 async 等）
◦优化关键字节数减少下载时间
◦优化剩余关键资源的加载顺序，尽早下载所有关键资源，缩短关键路径长度
•确保文本在网页字体加载期间保持可见：预加载网络字体
•保持较低的请求数和较小的传输大小： CSS 和 JavaScript ，图片，字体，文件，媒体
三、什么是 Speed Index ？
SI：Speed Index 衡量页面加载期间内容以视觉方式显示的速度。 Lighthouse 首先捕获浏览器中页面加载的视频，并计算帧之间的视觉速度。通俗的讲，就是网页从有东西到完全显示内容的可见填充速度。
Speed Index 指标值：
我们可以从以下方向点优化 Speed Index 的方法：
•减少主线程工作
•减少 JavaScript 执行时间
•确保文本在 webfont 加载期间保持可见
四、什么是 LCP ？（重点）
LCP： Largest Contentful Paint 最大（最有意义）内容绘制，是指根据页面首次开始加载的时间点来报告可视区域内可见的最大图像或者文本块完成渲染的相对时间。
LCP 指标值：
•LCP <= 2.5s 合格
•2.5s < LCP <= 4s 需要优化
•LCP > 4s 劣质
1. LCP 考量的元素有哪些？
主要考量以下几种相关元素：
•<img> 元素
•内嵌在 <svg> 元素内的 <image> 元素
•video 元素（使用封面图片）
•通过 url（）函数加载的带有背景图像的元素
•带有文本或其他行内元素文本的块级元素
2. LCP 元素大小是如何定义的？
最大内容绘制（LCP）的元素大小是指用户在可视区域内可见的大小，所以考量都是基于可视区域为准，如果元素有延伸到可视区域外，或者元素被裁剪或包含不可见的溢出，这些部分不计入元素大小；
对于图像元素的大小，指标会对比可见尺寸与原始尺寸，取尺寸小者为准；例如双倍图以可见尺寸为准，拉伸放大图则以原始尺寸为准；
对于文本元素，元素的大小为文本节点的大小（包含所有文本节点的最小矩形）；
WARNING： 所有元素通过 CSS 设置的任何边距、填充或边框都不在考量范围内。另外如果设置了满屏背景图，但屏幕可视区域内有占比较大的元素（浮在背景图上的元素），导致背景图暴漏可视范围较小，那么最大内容会选择可视区域内最大元素。
并且，一个元素只有在渲染完成后对用户可见后才能视为最大内容元素。
3. LCP 绘制时间上报
因为网络或技术原因，网页的加载通常是分段进行的， 所以最大元素也在发生变化。
为了应对这种变化，浏览器在绘制第一帧后立即分发一个 largest-contentful-paint 类型的 PerformanceEntry （代表了 performance 时间列表中单个 metric 数据；performance.getEntries() 获取时间列表数据），用于识别最大内容元素。渲染后续帧之后，浏览器会在最大内容元素发生变化时分发另一个 PerformanceEntry 。
页面的元素（某一个元素）只有在渲染完成后并且对用户可见后才能视为最大内容元素。未加载的图像不会视为渲染完成，也就不能视为最大内容元素。字体阻塞期使用字体的文本也是如此。这些情况下，较小的元素会被报告为最大的元素，但一旦更大的元素渲染完成，则会上报另一个 PerformanceEntry 对象。
除了延迟加载的图像与字体外，页面可能会在新内容（接口请求等）可用时向 DOM 添加新元素内容。如果有一个新元素大于先前的最大内容元素，则浏览器还会上报一个新的 PerformanceEntry 对象。
如果当前的最大内容元素从可视区域被移除（甚至从 DOM 中被移除），那么除非有一个更大的元素完成渲染，否则该元素将持续作为最大内容元素，不会更改 performanceEntry 对象。
当用户与页面进行交互（通过轻触、滚动或按键）时，浏览器将立即停止上报 PerformanceEntry 对象，因为用户交互通常会改变页面原有内容。
浏览器出于安全考虑，对于缺少 Timing-Allow-Origin 标头的跨域对象来说，是无法得到图像渲染时间戳的，只有图像加载时间戳。正确的设置 Timing-Allow-Origin 标头，可以获取更准确的指标值。
4. 当元素布局和元素大小更改时，哪些情况会影响 LCP
情况1：对元素大小或位置修改不会生成新的 LCP 候选对象，只有元素在可视区域内的初始大小和位置会被纳入考量范围；
情况2：最初在可视范围内渲染，然后被移除可视区域外的元素仍将报告他在可视区域内的初始大小；
情况3：而在屏幕可视范围外渲染完成，过度到屏幕上的元素则不做报告。
示例：最大元素随着内容加载完成而发生改变
第一个示例中，新内容渲染完成，因此使最大元素发生了改变。
第二个示例中，由于布局的改变，先前的最大内容从可视区域中被移除了。
如果延迟内容没有初始最大元素大，则 LCP 取初始值。
5. 最大元素并非重要元素
页面上最重要元素并非最大元素，这个时候开发者考核指标是最重要元素。
6. 更快的渲染主要内容，降低 LCP 值
影响页面渲染性能主要原因有以下几点，通过优化它们可以降低 LCP 指标值
（1） 服务器响应速度：
是指浏览器从服务器接收内容所需的时间越长，用户在屏幕上所渲染内容的时间就越长。更快的服务器将直接影响包括 LCP 各项指标的加载值。
可优化方向：
•优化服务器性能
•将用户路由到附近的 CDN
•缓存资源
•优先使用缓存提供 HTML 页面
•尽早建立第三方链接
•使用签名交换
（2） 阻塞渲染的 JS 和 CSS ：
浏览器渲染内容之前需要先解析 DOM 树，解析过程中，如果遇到任何外部样式表（<link rel="stylesheet">）或同步 JavaScript 标签（<script src="main.js">），则会暂停解析。
所以脚本跟样式都是阻塞渲染的资源，这些资源都会导致 FCP 延迟，从而导致 LCP 延迟。所以延迟加载非必要的 JS 和 CSS ，从而提高网页主要内容加载速度。
减少 CSS 阻塞时间的方法：
•消减 CSS ： 删除 CSS 中的空格、换行、缩进、注释等字符
•延迟加载非关键 CSS ： 将初始渲染时不需要的 CSS 提取到一个文件，进行异步加载
•内联关键 CSS ： 把首屏内容的关键 CSS 直接包在 <head> 中，将 CSS 内联； Critters 是一个 webpack 插件，能够内联关键 CSS 并对其余部分进行懒加载
减少阻塞渲染的 JavaScript 数量能够让渲染速度更快，降低 LCP 值
减少 JS 阻塞时间的方法：
•消减压缩 JavaScript 文件
•延迟加载未使用的 JavaScript 文件
•最大限度的减少未使用的 polyfill
（3） 缓慢的资源加载速度 ：
虽然 CSS 或 JavaScript 阻塞时间的增加会直接导致性能下降，但加载许多其他类型资源所需的时间也会影响绘制时间。
影响 LCP 的元素有以下几种：
•<img> 标签
•内嵌 <svg> 的 <image> 标签
•<video> 元素的封面图
•通过 url() 函数加载的带有背景图的元素
•包含文本节点或其他行内级文本元素的块级元素
优化方法：
•优化图片： 压缩图片，使用 webp 格式，图片资源上传 CDN ；当然能用代码实现尽量不使用图片；、
•预加载重要资源： 使用 <link rel="preload"> 提高优先级进行下载和缓存；
•压缩文本文件： Gzip、Brotli （google 出版）
•基于网络连接交付不同资产（自适应服务）： navigator.connection.effectiveType （有效连接类型 4G）， navigator.connection.saveData （启用/禁用数据保护程序）， navigator.hardwareConcurrency （cpu 核心数）， navigator.deviceMemory （设备内存）
•缓存资源： service woker 在 worker 上下文中运行： 因此它没有 DOM 访问权限，并且是运行在不同线程上，因此它是非阻塞的。
（4） 客户端渲染：
如 React 、 Vue 、 Angular 这类框架所搭建的单页面应用，是完全在客户端中处理逻辑的。
优化方法：
•最小化关键 JavaScript ： 精简 JavaScript ， 延迟加载未使用的 JavaScript ， 最大限度减少未使用的 polyfill
•使用服务端渲染： 用服务器将主要内容首先在服务器渲染为 HTML ， 客户端将所有 JavaScript 及所需数据"水合"到相同的 DOM 内容中
•使用预渲染： 使用无头浏览器，提前搭建每个路由的静态 HTML 文件，然后将这些文件与应用程序所需的 JavaScript 包一起运送
五、什么是 TBT ？
TBT： Total Blocking Time 总阻塞时间，是页面被阻塞响应用户交互的总时间。 TBT = LCP （首次最大内容绘制）和可交互时间之间所有长时间任务的阻塞部分之和。是测量页面加载响应的重要指标。
超过 50 毫秒的任务即为长任务。 超出 50 毫秒的时间量为阻塞部分。
例如：检测到一个 90 毫秒的任务，则阻塞部分为 40 毫秒（90 - 50 = 40）
TBT 指标：
优化方法：
•减少不必要的 JavaScript 加载、解析或执行。减少 JavaScript 负载、删除未使用的代码或有效加载第三方 JavaScript 可以提高 TBT 分数。
•减少低效的 JavaScript 语句。例如： document.querySelectorAll('a') 会返回所有符合的节点
六、什么是 CLS ？
CLS： 累计布局偏移（CLS）是测量视觉稳定性的重要指标。是整个页面声明周期内发生的所有意外布局偏移中最大一连串的布局偏移分数。
页面内容的意外偏移大多是由于异步资源加载，或者动态添加 DOM 元素到页面现有内容上方导致的。罪魁祸首可能是未知尺寸的图像或视频、实际渲染后比后备字体更大或更小的字体等。
CLS 指标：
注意： 只有当现有元素的起始位置发生变更时才算做布局偏移。如果将新元素添加到 DOM 或是现有元素更改大小，则不算做布局偏移。只有当元素的变更会导致其他可见元素的起始位置发生变化，才叫偏移。
计算公式： 布局偏移分数 = 影响分数 x 距离分数
影响分数： 前一帧和当前帧的所有不稳定元素的课件区域集合（占总可视区域的部分）就是当前帧的影响分数。
距离分数： 指的是任何不稳定元素在一帧中位移的最大距离（水平或垂直）除以可视区域的最大尺寸维度（宽度或高度，以较大者为准）。
产生 CLS 的常见原因：
•无尺寸的图片
•无尺寸的广告，嵌入和 iframe
•动态注入的内容
•导致不可见文本闪烁（FOIT）、无样式文本闪烁（FOUT）的网络字体
•在更新 DOM 之前等待网络响应的操作
优化方法：
•在图片和视频元素上包含尺寸属性
•非用户交互响应的情况下，都不要在现有的内容上方插入其他内容
•首选转换动画，而不是触发布局偏移的属性动画
以上五个指标就是目前前端性能指标考量点，以及产生问题原因，优化方法等。每个优化点都可以扩展出很多知识以及学习点，所以前端优化这个工作链路依然很长；单一点的优化效果可能并不明显，但五个点全部优化，定然会有质的飞跃。
在实际项目中，优先从前端自身出发，优化完自身后，再去优化协同项。
另外前端优化是一件可持续，并长久的事情，工具技术升级的迭代也会提升项目性能，针对优化这样的工作一定要持续下去，而不是做一次就OK了。
前端性能优化这条路，道阻且长，行则将至，专研就会有进步，最终定然会成功达到目标。
