乐趣区

关于前端:前端性能指标

jiezi

传统性能规范

初始化阶段

  • navigationStart：申请开始工夫，返回 0
  • unloadEventStart：等于用户代理程序开始前一个文档的卸载事件之前的工夫
  • unloadEventEnd：等于用户代理程序实现前一文档的卸载事件之后的工夫
  • redirectStart：重定向开始工夫的工夫戳，没产生则为 0

  • redirectEnd：重定向实现工夫的工夫戳，没产生则为 0

    申请阶段

  • fetchStart：表征了浏览器筹备好应用 HTTP 申请来获取 (fetch) 文档的工夫戳，这个工夫点会在查看任何利用缓存之前
  • domainLookupStart：是一个无符号 long long 型的毫秒数，表征了域名查问开始的 UNIX 工夫戳。如果应用了继续连贯(persistent connection)，或者这个信息存储到了缓存或者本地资源上，这个值将和 PerformanceTiming.fetchStart 统一。
  • domainLookupEnd：是一个无符号 long long 型的毫秒数，表征了域名查问完结的 UNIX 工夫戳。如果应用了继续连贯(persistent connection)，或者这个信息存储到了缓存或者本地资源上，这个值将和 PerformanceTiming.fetchStart 统一。
  • connectStart：申请连贯被发送到网络之时的 Unix 毫秒工夫戳。如果传输层报告谬误并且连贯的建设从新开始，则把最初建设连贯的开始工夫作为该值。如果一个长久连贯被应用，则该值与 PerformanceTiming.fetchStart 雷同。
  • secureConnectionStart：为平安连贯握手开始的时刻的 Unix 毫秒工夫戳。如果只有你过的连贯没有被申请，则它返回 0。
  • connectEnd：代表了网络链接建设的工夫节点。如果传输层报告了谬误或者链接又被从新建设，则采纳最初一次链接建设的工夫。如果链接是短暂的，那么这个值等同于 PerformanceTiming.fetchStart。链接被认为关上以所有的链接握手，SOCKS 认证完结为标记。
  • requestStart：为浏览器发送从服务器或者缓存获取理论文档的申请之时的 Unix 毫秒工夫戳。如果传输层在申请开始之后产生谬误并且连贯被从新关上，则该属性将会被设定为新的申请的相应的值。
  • responseStart：为浏览器从服务器、缓存或者本地资源接管到响应的第一个字节之时的 Unix 毫秒工夫戳。

  • responseEnd：为浏览器从服务器、缓存或者本地资源接管响应的最初一个字节或者连贯被敞开之时的 Unix 毫秒工夫戳

    解析渲染阶段

  • domLoading：返回以后网页 DOM 构造开始解析时
  • domInteractive：为在主文档的解析器完结工作，即 Document.readyState 扭转为 ‘interactive’ 并且相当于 readystatechange (en-US) 事件被触发之时的 Unix 毫秒工夫戳。
  • domContentLoadedEventStart：为解析器收回 DOMContentLoaded 事件之前，即所有的须要被运行的脚本曾经被解析之时的 Unix 毫秒工夫戳。
  • domContentLoadedEventEnd：这个时刻为所有须要尽早执行的脚本不论是否按程序，都曾经执行结束，即 DOM Ready
  • domComplete：为主文档的解析器完结工作，Document.readyState 变为 ‘complete’ 且相当于 readystatechange 事件被触发时的 Unix 毫秒工夫戳。
  • loadEventStart：为 load 事件被当初的文档触发之时的 Unix 工夫戳。如果这个事件没有被触发，则他返回 0。

  • loadEventEnd：为 load 事件处理程序被终止，加载事件曾经实现之时的 Unix 毫秒工夫戳。如果这个事件没有被触发，或者没能实现，则该值将会返回 0

    各个阶段计算形式

    页面加载总工夫
    loadEventEnd – startTime
    onload 事件触发
    DNS 解析工夫
    domainLookupEnd – domainLookupStart
    TCP 连贯耗时
    connectEnd – connectStart
    SSL 连贯耗时
    connectEnd – secureConnectionStart
    https 协定才有
    网路申请耗时
    responseStart – requestStart
    数据传输耗时
    responseEnd-responseStart
    DOM 解析耗时
    domContentLoadedEventEnd – responseEnd
    资源加载耗时
    loadEventEnd – domContentLoadedEventEnd
    页面渲染耗时
    loadEventEnd – responseEnd
    页面齐全加载工夫
    loadEventEnd – startTime
    HTML 加载完工夫
    responseEnd – startTime
    首次可交互工夫
    domInteractive – startTime

    以用户为核心的性能指标

    传统的性能指标，比拟关注技术细节；疏忽用户所真正关怀的指标；如果仅仅只是页面加载很快，但用户体验很差，也是不行的。

    FP & FCP

    First Paint 首次绘制，指浏览器从开始申请网站内容（导航阶段）到首次向屏幕绘制像素点的工夫，刚到 Painting 阶段（如下图所示），所以 FP 也能够了解为是白屏工夫。

    // 更举荐应用 Promise 封装获取
const observerWithPromise = new Promise<PerformanceObserverEntryList>((resolve, reject) => {new PerformanceObserver(resolve).observe({entryTypes: ['paint'],
});
});
  
observerWithPromise
.then(entryList => {return entryList.getEntries().filter(entry => {return entry.name === 'first-paint';})[0];
})
.then(entry => console.log(entry.startTime));

    First Contentful Paint，首次内容绘制，指浏览器渲染出第一个内容的工夫，内容能够是文本、img 标签、SVG 元素等，然而不包含 iframe 和红色背景的 Canvas 元素

    // 更举荐应用 Promise 封装获取
const observerWithPromise = new Promise<PerformanceObserverEntryList>((resolve, reject) => {new PerformanceObserver(resolve).observe({entryTypes: ['paint'],
});
});
  
observerWithPromise
.then(entryList => {return entryList.getEntries().filter(entry => {return entry.name === 'first-contentful-paint';})[0];
})
.then(entry => console.log(entry.startTime));

    FCP 工夫如果在

  1. 0-1.8 秒之间就是一个比拟优良的指标；
  2. 1.8-3.0 秒之间就比拟中等了，略微有点儿慢；

  3. 超过 3 秒就是十分慢了

    FMP & SI

First Meaning Paint，首次要害内容绘制，指浏览器渲染出第一个要害内容的工夫。不过“要害内容”是难有一个明确定义的，依据利用不同其要害内容也是不一样的
FMP 通常也被用来掂量 首屏工夫。不过 FMP 的计算过于简单，所以无奈应用 API 间接获取，就算计算出来了也不肯定就精确，所以连 Lighthouse 在 6.0 版本之后都不再计算这个指标了，取而代之的是 LCP。

TTI

Time to Interactive，可交互工夫，该指标用于测量页面从开始加载到次要子资源实现渲染，并可能疾速、牢靠地响应用户输出所需的工夫。简略的讲，TTI 是宁静窗口之前最初一个长工作（超过 50 毫秒的工作）的完结工夫（如果没有找到长工作，则与 FCP 值雷同）
TTI 工夫如果在

  1. 0-3.8 秒之间就是一个比拟优良的指标；
  2. 3.9-7.3 秒之间就比拟中等了，略微有点儿慢；

  3. 超过 7.3 秒就是十分慢了。

    FID

    First Input Delay ，首次输出提早，测量从用户第一次与页面交互（例如当他们单击链接、点按按钮或应用由 JavaScript 驱动的自定义控件）直到浏览器对交互作出响应，并理论可能开始处理事件处理程序所通过的工夫，FID 是 掂量交互性的外围指标

    const observerWithPromise = new Promise<PerformanceObserverEntryList>((resolve, reject) => {new PerformanceObserver(resolve).observe({entryTypes: ['first-input'],
});
  });
  observerWithPromise
.then(entryList => {for (const entry of entryList.getEntries()) {
    // eslint-disable-next-line no-undef
    const delay = (entry as PerformanceEventTiming).processingEnd - entry.startTime;
    console.log(delay);
  }
});

    FID 工夫如果在

  4. 0-100 毫秒之间就是一个比拟优良的指标；
  5. 100-300 毫秒之间就比拟中等了，略微有点儿慢；
  6. 超过 300 毫秒就是十分慢了

TBT

Total Blocking Time，总阻塞工夫，指 FCP 与 TTI 之间的总工夫，这期间，主线程被阻塞的工夫过长，无奈做出输出响应。工作持续时间小于 50 毫秒的阻塞工夫记为 0，超过 50 毫秒的工作阻塞工夫就是这个工作执行的工夫减去 50 毫秒失去的工夫，一个页面的总阻塞工夫是在 FCP 和 TTI 之间产生的每个长工作（超过 50 毫秒的工作）的阻塞工夫总和。
TBT 工夫如果在

  1. 0-200 毫秒之间就是一个比拟优良的指标;
  2. 200-600 毫秒之间就比拟中等了，略微有点儿慢；

  3. 超过 600 毫秒就是十分慢了

    LCP

    Largest Contentful Paint，最大内容绘制，指可视区内容最大的可见元素呈现在屏幕上的工夫，

    const observerWithPromise = new Promise<PerformanceObserverEntryList>((resolve, reject) => {new PerformanceObserver(resolve).observe({entryTypes: ['largest-contentful-paint'],
 });
  });
  observerWithPromise
 .then(entryList => {const entries = entryList.getEntries();
   const lastEntry = entries[entries.length - 1];
   console.log(lastEntry.startTime);
 });

    LCP 工夫如果在

  4. 0-2.5 秒之间就是一个比拟优良的指标；
  5. 2.5-4 秒之间就比拟中等了，略微有点儿慢；

  6. 超过 4 秒就是十分慢了

    CLS

    Cumulative Layout Shift，累积布局偏移，测量整个页面生命周期内产生的所有意外布局偏移中最大一连串的布局偏移分数。
    简略的讲就是页面因为一些动静扭转的 DOM 或者一些异步的资源加载，导致页面元素产生了位移，这样就会让用户找不到先前浏览的地位或者点击到不冀望点击的中央。

    let clsValue = 0;
let clsEntries = [];

let sessionValue = 0;
let sessionEntries: PerformanceEntry[] = [];
const observerWithPromise = new Promise<PerformanceObserverEntryList>((resolve, reject) => {new PerformanceObserver(resolve).observe({entryTypes: ['layout-shift'],
  });
});
observerWithPromise
  .then(entryList => {for (const entry of entryList.getEntries()) {
   // 只将不带有最近用户输出标记的布局偏移计算在内。// @ts-ignore
   if (!entry.hadRecentInput) {const firstSessionEntry = sessionEntries[0];
     const lastSessionEntry = sessionEntries[sessionEntries.length - 1];

     // 如果条目与上一条目标相隔工夫小于 1 秒且
     // 与会话中第一个条目标相隔工夫小于 5 秒，那么将条目
     // 蕴含在以后会话中。否则，开始一个新会话。if (sessionValue &&
         entry.startTime - lastSessionEntry.startTime < 1000 &&
         entry.startTime - firstSessionEntry.startTime < 5000) {
       // @ts-ignore
       sessionValue += entry.value;
       sessionEntries.push(entry);
     } else {
       // @ts-ignore
       sessionValue = entry.value;
       sessionEntries = [entry];
     }

     // 如果以后会话值大于以后 CLS 值，// 那么更新 CLS 及其相干条目。if (sessionValue > clsValue) {
       clsValue = sessionValue;
       clsEntries = sessionEntries;

       // 将更新值（及其条目）记录在控制台中。console.log('CLS:', clsValue, clsEntries);
     }
   }
 }
  });

    CLS 如果在

  7. 0-0.1 之间就会有一个比拟好的稳定性；
  8. 0.1-0.25 之间就比拟中等了；

  9. 超过 0.25 就是十分不稳固了。

    总结

    参考：

  10. https://web.dev/metrics/
  11. https://juejin.cn/post/7104310605091176456#heading-2
退出移动版