作者：京东科技 郝梁
前言：作为 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 了。
前端性能优化这条路，道阻且长，行则将至，专研就会有提高，最终定然会胜利达到目标。
文章参考：https://web.dev/ https://developer.chrome.com/