前端性能监控相关指标在面试中经常被问及，你知道吗FP、FCP、FMP、LCP代表什么事件？它们的顺序是什么？如何计算？前端性能监控中常用的指标是什么？

本文将介绍前端项目中常用的性能指标、计算方法及实际应用场景。

前端页面加载性能的评价有两个指标：DOMContentLoaded和load分别代表事件DOM完成结构和首屏资源加载。

我们知道，当我们使用浏览器访问页面时，浏览器将页面从网络下载到本地，主要做几件事：分析HTML，创建DOM，同时所依赖的资源：CSS、图片等。(加载资源的过程不会堵塞DOM分析)，然后将渲染过程调用到界面。

这里需要注意的是，在当前的浏览器中，为了减缓渲染被阻塞，现代浏览器使用猜测预加载。当分析被阻塞时，浏览器将有一个轻量级HTML（或CSS）扫描器（scanner）继续扫描文档，找到未来可能使用的资源文件url，在使用渲染器之前下载。

多个事件将在整个加载和渲染过程中触发

• load（Onload Event），它代表了页面上所依赖的所有资源加载的事件。
• DCL（DOMContentLoaded），DOM解析完毕。
• FP（First Paint），表示渲染第一个像素点。FP一般在HTML分析完成或部分分析触发。
• FCP（First Contentful Paint），这里的内容可以是文本、图片、canvas。
• FMP（First Meaningful Paint），第一次渲染有意义内容的时间，有意义没有标准定义，FMP计算方法也很复杂。
• LCP（largest contentful Paint），最大内容渲染时间。

下面详细说明每个事件和特点

白屏时间 = 地址栏输入网站后回车 - 浏览器出现第一个元素

首屏时间 = 地址栏输入网站后回车 - 浏览器第一屏渲染完成

根据白屏和首屏的定义，我们可以使用它FP和FCP计算白屏和首屏。

白屏结束时间 = FP事件触发时间

首屏结束时间 = FCP事件触发时间

\

当然FCP这意味着第一个内容被渲染出来些业务希望用更关键的内容渲染来表示第一个屏幕，这个时候可以用FMP或者LCP作为首屏的计算指标。

Onload Event所有依赖代表页面的资源：DOM、图片、CSS、Flash加载后等，window.onload注册回调将在load事件触发时被调用。

有时候FCP比Onload Event首先触发，因为渲染第一个内容可能不包括图片显示，只包括文本内容。

所有依赖的资源包括异步加载资源，但不包括延迟加载资源。

\

DOMContentLoaded事件，当 HTML 文档完全加载和分析后，DOMContentLoaded 事件被触发，无需等待样式表、图像和子框架的加载。

可通过注册回调监控事件

  document.addeventListener('DOMContentLoaded', function() {}, false); 

document.onload和document.body.onload这也是事件的回调。

\

若要渲染的内容不多，DCL在load以前，如果有很多内容需要渲染，那么DCL会在load之后。

浏览器不一定等到所有的DOM都解析完再开始渲染，如果DOM节点少，浏览器会加载完再渲染，但是如果节点很多，浏览器解析一部分节点后就会开始渲染（这时候就会触发FP）。也就是说，当需要渲染的节点数少的时候，DCL会在FP前面；当需要渲染的节点数很多时候，DCL会在FP后面。

例如下面的代码，只有一个div，会先触发DCL然后再触发FP。

而下面的代码，有10000个div，FP会在DCL前面。

FP、FCP和L时间都可以通过performance API计算

// load
// loadEventStart是load事件发送给文档，也即load回调函数开始执行的时间
// loadEventEnd是load回调函数执行完成的时间
const loadTime = performance.timing.loadEventStart - performance.timing.fetchStart

// DCL
const dcl = performance.timing.domContentLoadedEventEnd - performance.timing.domContentLoadedEventStart

// FP
const fp = performance.getEntries('paint').filter(entry => entry.name == 'first-paint')[0].startTime;

// FCP
const fcp = performance.getEntries('paint').filter(entry => entry.name == 'first-contentful-paint')[0].startTime;

// Onload Event
const l = performance.timing.loadEventEnd - performance.timing.navigationStart;

// LCP
new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('LCP candidate:', entry.startTime, entry);
  }
}).observe({type: 'largest-contentful-paint', buffered: true});

// LCP也可以通过web-vitals计算
import {getLCP, getFID, getCLS} from 'web-vitals';

getCLS(console.log);
getFID(console.log);
getLCP(console.log);

FMP计算比较复杂，lighthouse的计算的大体思路是，将页面中最大布局变化后的第一次渲染事件作为FMP事件，并且计算中考虑到了可视区的因素。

FMP计算过于复杂，没有现成的performance API，如果希望在监控中上报这个指标，可以自己使用MutationObserver计算。

文档首次可交互时间可以用来衡量页面可交互的性能。

首次可交互，即DOM加载并解析完成后，界面上的元素可以交互（如输入框可以输入、按钮可以点击、超长元素可以滚动）。其时间用performance.timing.domInteractive计算。

performance.timing.domInteractive：当前网页DOM结构结束解析、开始加载内嵌资源的时间，document.readyState 变成interactive，并将抛出"readyStateChange"事件（注意只是DOM树解析完成，这时候并没有开始加载网页内的资源）\

const timeToInteractive = performance.timing.domInteractive - performance.timing.fetchStart, //首次可交互时间

用于标记应用已进行视觉渲染并能可靠响应用户输入的时间点

TTI的计算方法参考文章：深入浅出前端监控

这里定义一下什么是完全可交互状态的页面：

1. 页面已经显示有用内容。
2. 页面上的可见元素关联的事件响应函数已经完成注册。
3. 事件响应函数可以在事件发生后的 50ms 内开始执行（主线程无 Long Task）。

计算方法描述如下：

1. 从 FCP 时间开始，向前搜索一个不小于 5s 的静默窗口期。（静默窗口期定义：窗口所对应的时间内没有 Long Task，且进行中的网络请求数不超过 2 个）
2. 找到静默窗口期后，从静默窗口期向后搜索到最近的一个 Long Task，Long Task 的结束时间即为 TTI。
3. 如果一直找到 FCP 时刻仍然没有找到 Long Task，以 FCP 时间作为 TTI。

其实现需要支持 Long Tasks API 和 Resource Timing API。

longTask

Long Task：阻塞主线程达 50 毫秒或以上的任务，可以通过PerformanceObserver获取。

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log('longtask candidate: ', entry.startTime);
  }
});

observer.observe({entryTypes: ['longtask']});

\

FID（First Input Delay） 用于度量用户第一次与页面交互的延迟时间，是用户第一次与页面交互到浏览器真正能够开始处理事件处理程序以响应该交互的时间。

相对于TTI，FID表示实际的用户操作的延时，更能从用户角度反映网页的交互性能。

其计算使用简洁的 PerformanceEventTiming API 即可，回调的触发时机是用户首次与页面发生交互并得到浏览器响应（点击链接、输入文字等）。

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log('fid', entry.processingStart - entry.startTime);
  }
});

observer.observe({type: 'first-input', buffer: true});

CLS（Cumulative Layout Shift）是对在页面的整个生命周期中发生的每一次意外布局变化的最大布局变化得分的度量，布局变化得分越小证明你的页面越稳定。

听起来有点复杂，这里做一个简单的解释：

• 不稳定元素：一个非用户操作但发生较大偏移的可见元素称为不稳定元素。
• 布局变化得分：元素从原始位置偏移到当前位置影响的页面比例 * 元素偏移距离比例。

网站应努力使 CLS 分数小于 0.1 。

可以通过web-vitals获取CLS。

import {getCLS} from 'web-vitals';

getCLS(console.log);

减少CLS的方法，参考文章：页面视觉稳定性之CLS

Chrome DevTool 中有一栏 Rendering 中包含 FPS 指标，但目前浏览器标准中暂时没有提供相应 API ，只能手动实现。这里需要借助 requestAnimationFrame 方法模拟实现，浏览器会在下一次重绘之前执行 rAF 的回调，因此可以通过计算每秒内 rAF 的执行次数来计算当前页面的 FPS。

FPS过低会让用户感觉卡顿，因此这个计算可以用来监控页面卡顿情况。

长任务监听，PerformanceObserver 监听，参考上面TTI一节中长任务的监听。

Core Web Vitals是谷歌提出的，衡量用户体验的新指标，指标将被纳入谷歌搜索引擎的网页排名。

Core Web Vitals是用户体验和SEO的重要指标。

关键的指标包括

• LCP，用来衡量页面加载性能，为了提供良好的用户体验，LCP应该在页面首次开始加载后的2.5秒内发生
• FID，衡量交互性能，为了提供良好的用户体验，页面的FID应该小于100毫秒。
• CLS，测量视觉稳定性。为了提供良好的用户体验，页面应该保持CLS小于0.1。\

Chrome提供了web-vitals库获取3个关键指标的数值。

import {getLCP, getFID, getCLS} from 'web-vitals';

getCLS(console.log);
getFID(console.log);
getLCP(console.log);

更多前端面试真题可以查看前端大厂面试题库-灵题库