import {getCLS, getFID, getLCP} from 'web-vitals';
​
function sendToAnalytics(metric) {
  const body = JSON.stringify(metric);
  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.
  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
      fetch('/analytics', {body, method: 'POST', keepalive: true});
}
​
getCLS(sendToAnalytics);
getFID(sendToAnalytics);
getLCP(sendToAnalytics);

new PerformanceObserver((list) => {
  console.log(list.getEntries());
}).observe({type: 'layout-shift', buffered: true});

{
    type: 'layout-shift',
    buffered: true
}

(list) => {
  console.log(list.getEntries());
}

duration: 0
entryType: "layout-shift"
hadRecentInput: false
lastInputTime: 0
name: ""
sources: (3) [LayoutShiftAttribution, LayoutShiftAttribution, LayoutShiftAttribution]
startTime: 11317.934999999125
value: 0.17508567530168798

// ...
  "sources": [
    {
      "node": "div#banner",
      "previousRect": {
        "x": 311,
        "y": 76,
        "width": 4,
        "height": 18,
        "top": 76,
        "right": 315,
        "bottom": 94,
        "left": 311
      },
      "currentRect": {
        "x": 311,
        "y": 246,
        "width": 4,
        "height": 18,
        "top": 246,
        "right": 315,
        "bottom": 264,
        "left": 311
      }
    }
  ]

一开始的大小、位置信息，可以看到previous和current变化的就是top属性的value，从76变成了246，所以就可以知道这一次的偏移是一个DOM元素从上往下偏移了

有了浏览器的API支持，我们就可以监听布局偏移，并且获取布局偏移的相关信息了

计分原理

duration: 0
entryType: "layout-shift"
hadRecentInput: false
lastInputTime: 0
name: ""
sources: (3) [LayoutShiftAttribution, LayoutShiftAttribution, LayoutShiftAttribution]
startTime: 11317.934999999125
value: 0.17508567530168798

我们可以看到Layout Shift返回了一个value值，那么这个value值是怎么计算出来的呢？因为这个value值越接近1就表示布局偏移越来越大，用户体验越来越差，value=0表示没有布局偏移，也就是用户体验最好。

LS的得分算法（计算的细节可以参考这篇大佬翻译的文章，里面有几个demo图片很好的解释了计算得分的方法：关于前端:前端性能指标Cumulative-Layout-Shift - 乐趣区 (lequ7.com)）

• 得分：影响小数与 间隔小数的乘积
• 影响小数：不稳固元素在之前渲染帧中的可视区域 和 以后帧可视区域的并集。这个并集占整个页面的百分比，影响小数就是这个百分比变成小数的值
• 间隔小数：不稳固元素在渲染帧中挪动的最大间隔（可能是横向可能是竖向）谁大就取谁，也是取这个挪动间隔距离占 宽/高的百分比，并转换成小数

有了上面的了解之后，我们来分析一下web-vital的获取CLS性能的getCLS方法就很清晰了

源码链接：github.com/GoogleChrom…

2.3、源码分析

LayoutShift与session

分区原理、计分原理

• 源码中，我们给observe第一个参数是'layout-shift'就是让PerformanceObserver这个行为观察者 观察LayoutShift布局偏移，并且传递了一个entryHandler的回调函数，也就是说，每一次监测到布局偏移了，就会把记录下来的这个布局便宜entry传递给entryHandler这个回调函数进行处理

const po = observe('layout-shift', entryHandler as PerformanceEntryHandler);

• 检测到布局偏移执行的回调函数entryHandler:

  let sessionValue = 0;
​
  let sessionEntries: PerformanceEntry[] = [];
​
  // layout shift每次变化的时候，都会把这个登记（entry）传递给这个回调函数
  const entryHandler = (entry: LayoutShift) => {
    // 500ms内如果用户输入的内容就不准了
    // 通过session分区处理
    if (!entry.hadRecentInput) {
      const firstSessionEntry = sessionEntries[0];
      const lastSessionEntry = sessionEntries[sessionEntries.length - 1];
​
      if (sessionValue &&
          entry.startTime - lastSessionEntry.startTime < 1000 &&
          entry.startTime - firstSessionEntry.startTime < 5000) {
        sessionValue += entry.value;
        sessionEntries.push(entry);
      } else {
        sessionValue = entry.value;
        sessionEntries = [entry];
      }
        
      // 策略:取最大值,所以每次面对一个新的session都要比对并更新metric的值
      if (sessionValue > metric.value) {
        metric.value = sessionValue;
        // 这个其实就是一个attribution的感觉
        metric.entries = sessionEntries;
        // 
        report();
      }
    }
  };

看到这个代码可能会有点懵逼，先看一下下面这篇大佬的文章就很清晰了（(34条消息) 前端监控 SDK 的一些技术要点原理分析_仙凌阁的博客-CSDN博客）

要看懂session分区的一个概念。也就是把多个layout shift都划为同一个session会话来进行统计（是否会被划分为同一个session会话区就是通过 这个layout shift发生的时间来进行判断的）

摘录文章中大佬的话：

一个或多个快速连续发生的单次布局偏移，每次偏移相隔的时间少于 1 秒，且整个窗口的最大持续时长为 5 秒。

就是一个session窗口可以有多个layout shift发生后回调的entry信息，但是要满足当前这个layout shift发生的时机和上一个layout shift发生的时机小于一秒，并且 每个session的时间跨度只有五秒，如果当前这个layout shift发生的时机和上一个LS发生的时机小于一秒了，但是当前session已经超过5秒了，那么当前这个LS就会被划分到下一个新的session中。

正是通过下面这段代码来进行了时间判断 分session会话区的：

      const firstSessionEntry = sessionEntries[0];
      const lastSessionEntry = sessionEntries[sessionEntries.length - 1];
​
      if (sessionValue &&
          entry.startTime - lastSessionEntry.startTime < 1000 &&
          entry.startTime - firstSessionEntry.startTime < 5000) {
        sessionValue += entry.value;
        sessionEntries.push(entry);
      } else {
        sessionValue = entry.value;
        sessionEntries = [entry];
      }

• firstSessionEntry就是用来判断当前这个session的时间跨度是否大于5s了

• lastSessionEntry就是用来判断距离上一个LS的时间跨度是否小于1s
• sessionEntries就是一个用来存储一个session会话中发生的所有Layout Shift后记录的entry

那么首先第一个问题是，为什么要定义这个session，为什么会有1s和5s这个概念呢？

（这个会话窗口的特点是chrome团队经过实验和研究得到的特征结果）

那么又带来了一个问题，用户在进入应用的一个生命周期内，肯定会存在多个session会话，每个session会话会有一个评分，但是最后getCLS函数只会给我们呢返回以value，这个value又是怎么样计算出来的呢？

还是这篇大佬的文章点明了原理(34条消息) 前端监控 SDK 的一些技术要点原理分析_仙凌阁的博客-CSDN博客

目前统计所有session中最大的value是最能反应用户那边CLS性能的。因为大部分的CLS 布局偏移都是发生在了应用加载的时候，在用户后面使用的时候其实整体的布局偏移并不多。所以每次回调entryHandler的时候都把拿到的session的value值计算出来只会进行大小比较，每次都更新metric中的value

onHidden

const po = observe('layout-shift', entryHandler as PerformanceEntryHandler);
onHidden(() => {
      // takeRecords() 方法返回当前存储在性能观察器中的 性能条目  列表
      po.takeRecords().map(entryHandler as PerformanceEntryHandler);
      // 如果页面hidden了,那么就没有监控的必要了,获取之前已经获取到的监控数据然后立即返回结果
      // 不然监控可能会一直存在用页面中
      // 经过尝试可以看到,只有页面关闭了才会上报CLS和LCP的数据,因为在用户进入应用的时候我们并不知道应该什么时候进行触发CLS的回调,
      // 因为用户的一些操作都可能导致页面的相关DOM的重新渲染
      report(true);
    });

然后我们还可以看到这段代码。

首先看看在onHidden中我们做了什么？

export const onHidden = (cb: OnHiddenCallback, once?: boolean) => {
  const onHiddenOrPageHide = (event: Event) => {
    if (event.type === 'pagehide' || document.visibilityState === 'hidden') {
      cb(event);
      // 只触发一次,所以第一次就把监听器取消掉
      if (once) {
        removeEventListener('visibilitychange', onHiddenOrPageHide, true);
        removeEventListener('pagehide', onHiddenOrPageHide, true);
      }
    }
  }
  addEventListener('visibilitychange', onHiddenOrPageHide, true);
  // Some browsers have buggy implementations of visibilitychange,
  // so we use pagehide in addition, just to be safe.
  addEventListener('pagehide', onHiddenOrPageHide, true);
};

visibilitychange

这个其实就是我们类似于 tab切换、应用切到手机后台、手机锁屏的时候，我们的document就会显示为一种hidden的状态。

不同的浏览器又pagehide和visibilitychange两种监听方式，所以我们都做监听，这样就可以每次用户把网页/app切到后台的时候触发cb(event)

可以看到这个cb就是我们给onHidden传入的回调函数

      po.takeRecords().map(entryHandler as PerformanceEntryHandler);
      report(true);

执行回调函数 通过po.takeRecord方式，就可以从：

new PerformanceObserver((list) => {
  console.log(list.getEntries());
}).observe({type: 'layout-shift', buffered: true});

我们在PerformanceObserver里面定义的buffer区，里面存储了entry记录，takeRecords就是把所有的entry记录都拿出来，然后执行entryHandler函数，只会我们report(true)的意思

可以看看源码:

const bindReporter = (
  callback: ReportHandler,
  metric: Metric,
  reportAllChanges?: boolean,
) => {
  // 相当于是一个闭包，可以一直访问这个prevValue的值（这个值初始化是undefined）
  let prevValue: number;
  return (forceReport?: boolean) => {
    if (metric.value >= 0) {
      if (forceReport || reportAllChanges) {
        // 最后用到的时间
        metric.delta = metric.value - (prevValue || 0);
​
        // Report the metric if there's a non-zero delta or if no previous
        // value exists (which can happen in the case of the document becoming
        // hidden when the metric value is 0).
        // See: https://github.com/GoogleChrome/web-vitals/issues/14
        if (metric.delta || prevValue === undefined) {
          prevValue = metric.value;
          callback(metric);
        }
      }
    }
  }
}
​
report = bindReporter(onReportWrapped, metric, reportAllChanges);
​

这个bindReporter会返回一个函数，这个函数接收一个 forceReport 参数，如果我们传递forceReport = true的话，那么就立即执行函数，返回刚刚

po.takeRecords().map(entryHandler as PerformanceEntryHandler);

记录的metric给用户那边，也就是返回getCLS的结果了

所以这就是，用户把页面切到后台的时候，CLS返回结果的原因了

onBFCacheRestore

还有一个源码比较难理解：

// 如果是BFC返回的话就要重新进行计算了
    onBFCacheRestore(() => {
      sessionValue = 0;
      fcpValue = -1;
      metric = initMetric('CLS', 0);
      // bindReporter指的是绑定 
      // 但是似乎没有添加bfc:true的标记,那么这个数据不会影响吗?
      report = bindReporter(onReportWrapped, metric, reportAllChanges);
    });

首先要理解一下，什么叫做BFC

BFC（back forward cache）：浏览器往返缓存

就是用户使用浏览器进行 前进 后退 的时候，页面的转换速度很快，因为做了页面的缓存，这个缓存不仅保存了页面数据，还保存了DOM和JS的状态，实际上是将整个页面都保存在了内存各种。通过BFC返回的页面，不会触发onload事件，但是会执行pageShow事件（onload是页面第一次加载的时候触发的，pageshow是每次加载页面都会触发）

正是因为BFC不会执行onload的方法，而我们都是在页面onload的时候挂载web-vital的监听函数，但是如果页面是BFC缓存下来的，下次进入这个页面的时候就不会执行onload，那么就不会挂载web-vital监听函数，就监听不了。

所以为此，我们要为BFC的页面做一个额外的操作

来看看onBFCacheRestore函数内部都做了什么：

export const onBFCacheRestore = (cb: onBFCacheRestoreCallback) => {
  addEventListener('pageshow', (event) => {
    // 这个persisted字段表示的意思是这个页面是从bfc返回的
    if (event.persisted) {
      cb(event);
    }
  }, true);
};

我们监听pageshow，如果发现这个页面是bfc返回的，就执行cb回调（也就是我们的web-vital监听函数）—— 初始化相关内容、开启report监听回调。

2.3、小建议——减低CLS得分的方法

（参考文章：前端性能指标:Cumulative Layout Shift - SegmentFault 思否）

上面说完了CLS的计算方法，那么有方法可以提高CLS成绩的呢？ 有一个概念引入：预期LS和非预期LS

1、有些Layout Shift不会参与到计算中，比如我们网络请求开始的时候，展示骨架屏或者是loading用来占位，让用户知道哪个模块正在进行加载，这种就是一个比较好的用户体验。

2、还有就是我们通过transform的scale来让元素变大变小、听过translate来让元素渐入渐出，这种渐变和渐进的变化是一种引导用户的体验，用户不会觉得很奇怪。

基于此，所以我们可以在开发的时候：

• 给image、video提前预设好占位空间，不要等这些大文件请求加载好了再进行渲染
• 不要随意的已有的内容上，通过document访问的方式给已有内容插入内容
• 把触发布局变化的属性（width、height盒子大小。right left top等定位位置）改成transform或者translate的方式
• 需要网络请求的元素多用loading、骨架屏来进行占位

2.4、文章参考与推荐

这篇文章很给力：jishuin.proginn.com/p/763bfbd68…

图文并茂，学到很多：segmentfault.com/a/119000003…

web-vitals文档（可以看源码，源码还是比较简单，通俗易懂的，只要理解原理了基本都可以看懂了）：github.com/GoogleChrom…

浏览器行为Performance更多方法的学习：developer.mozilla.org/zh-CN/docs/…

LayoutShift学习资料： Layout Instability API (wicg.github.io) 以及中文的一些教程：www.mifengjc.com/api/LayoutS…

前端监控sdk学习的一篇优秀博文：(34条消息) 前端监控 SDK 的一些技术要点原理分析_仙凌阁的博客-CSDN博客

google的优秀博主的一篇关于layout-shift的优质文章：web.dev/debug-layou…