前端性能的计算方式与优化方案

文章目录

- 1.Navigation Timing
- - 1.1 什么是Navigation Timing
  - 1.2 Navigation Timing具体说明
  - - 1.2.1 缓存处理阶段
    - 1.2.2 网络请求阶段
    - 1.2.3 dom渲染阶段
  - 1.3 使用
  - - 1.3.1 如何查看
    - 1.3.2 项目中的使用
- 2.Core Web Vitals - CWV 网页性能三大指标
- - 2.1 Largest Contenful Paint(LCP)
  - - 扩展：关于图片上传
  - 2.2 First Input Delay(FID)
  - 2.3 Cumulative Layout Shift(CLS)
  - 2.4 Core Web VItals Annotetions - 衡量CWV的工具
- 3. performance - 性能评估神器
- - 3.1 什么是performance ？
  - 3.2 performance的使用
  - *3.1 大厂监控体系
  - *3.2 性能优化的另一种可能 - bigpipe —— 页面分解成若干的pagelet

1.Navigation Timing

1.1 什么是Navigation Timing

Navigation Timing是一个性能优化方面为我们提供精准数据的工具，之前测试页面加载的时间都是在相应的位置打Date.now()，通过计算时间差来实现。这种做法有很多弊端

需要在许多地方添加额外的代码
记录的时间并不准确
测试完之后需要找到每一个地方删除，容易落下且麻烦

W3C引入了 Navigation Timing API 帮我们自动，精准的实现了性能测试的打点问题。不仅帮我们省去了繁琐的手动打点的操作，而且提供了以前我们无法获取到的数据，比如DNS和TCP连接所需的时间。

加载一个页面时，一步一步怎么去做的。

图解
在这里插入图片描述
可分为以下三个阶段：

1.2 Navigation Timing具体说明

1.2.1 缓存处理阶段

navigationStart
前一个文档卸载的时间戳

注：无上一层页面时，从fetchStart开始

unloadEventStart
与前一个网页unload时的时间戳（卸载上一个网页），无上一个网页的时候，默认是0
unloadEventEnd
执行完毕的时间戳
redirectStart / redirectEnd
redirectStart：代表重定向的开始。表征了第一个HTTP重定向开始时的时间戳。如果没有重定向，或者重定向中的一个不同源，这个值会返回0.
redirectEnd：代表重定向的结束

做差值，用来计算重定向完成的时间

fetchStart
表征了浏览器准备好使用HTTP请求来获取(fetch)文档的时间戳。

可聊点：
1.结合navigationStart，如果没有上一个页面的时候，fetchStart是整个全新开始页面的start
2.浏览器网络层ready的时间（可通过某个点减去fetchStart，计算出该点所用的时间）

1.2.2 网络请求阶段

domainInLookupStart / domainInLookupEnd
DNS
connectStart / connectEnd
TCP

网络的建立连接过程：connectEnd减去domainInLookupStart ，就是网络建立连接的耗时

secureConnectionStart
返回浏览器与服务器开始安全链接的握手时的Unix毫秒时间戳。如果当前网页不要求安全连接，则返回0。

建立安全链接 =>发散： http1.0 与 http2.0

请求requestStart /响应responseEnd

整个请求的发起开始到完成接受的耗时

1.2.3 dom渲染阶段

domLoading
开始解析渲染dom的时间(即Document.readyState属性变为“loading”、相应的 readystatechange事件触发时)
domInterActive
完成了dom树的解析(即Document.readyState属性变为“interactive”、相应的readystatechange事件触发时)，domInterActive减去domLoading就是解析dom树的时间。

可聊点：
1.完成dom树的解析，是不是整个页面的资源都加载完毕？
不是。只是完成了dom树的解析，并没有开始加载网页资源。
2.dom树的层级多了，会影响dom树解析的速度。

domContentLoaddedEventStart / domContentLoaddedEventEnd
dom树解析完成后，资源的加载。domContentLoaddedEventEnd减去domContentLoaddedEventStart ，资源加载的时间。
domComplete
Dom树ready(即Document.readyState 变为 'complete’且相对应的readystatechange 被触发时的Unix毫秒时间戳)。

domComplete减去domLoading，dom初始化的时间。

loadEventStart / loadEventEnd
执行脚本开始与结束。
loadEventStart ： load事件被发送时的Unix毫秒时间戳。如果这个事件还未被发送，它的值将会是0。
loadEventEnd：当load事件结束，即加载事件完成时的Unix毫秒时间戳。如果这个事件还未被发送，或者尚未完成，它的值将会是0.

1.3 使用

页面的卡顿流畅都是感官上的，以上的数据会给我们理性的衡量标准。

1.3.1 如何查看

在页面load完之后我们可以从performance.timing对象中拿到我们需要的所有数据：

在这里插入图片描述

1.3.2 项目中的使用

例1：计算页面加载所需的总时长：

   // index.html
    <script>
        javascript:(() => {
            const performance = window.performance.timing;
            const pageLoadTime = performance.loadEventEnd - performance.navigationStart;

            // pageLoadTime 为所求时间，可进行 打印、上报、存储
            console.log('当前页面加载耗时：', pageLoadTime, 'ms');
        })()
    </script>

例2：计算请求返回时长：

   // index.html
    <script>
        javascript:(() => {
            var connectTime = perfData.responseEnd - perfData.requestStart;
            // connectTime 为请求返回时长
        })()
    </script>

2.Core Web Vitals - CWV 网页性能三大指标

什么是CWV ？
Core Web Vitals （核心页面指标）是一种速度指标，是 Google 用于衡量用户体验的页面体验信号的一部分。这些指标衡量是：最大内容绘制 (LCP) 的视觉负载、累积布局移位 (CLS) 的视觉稳定性、以及首次输入延迟 (FID) 的交互性。

加载、交互、视觉稳定 —— 代表不同方向的衡量标准 + 可衡量且接近真实体验的数据化参数

2.1 Largest Contenful Paint(LCP)

LCP 衡量加载性能——内容出现的速度。
最大内容绘制 (LCP) 报告视口内可见的最大图像或文本块的渲染时间。低于 2.5 秒的时间被认为是好的，而高于 4.0 秒的任何时间都被认为是差的。

要求：页面加载2.5s内，必须要进行最大内容的渲染。
什么是最大内容?

图片：<image>、<img>、<svg> 等
<video>
通过url加载内容的模块（包括带有使用 CSS url()属性加载的背景图像的元素）
主要文本模块以及其内联模块（包含文本节点的块级元素）

2.1.1 LCP低下的原因(提升LCP的感知程度)

1.资源慢
解决=>缓存：强缓存+协商缓存
2. 渲染被阻断
解决=> 对于复杂的结构：简化结构与逻辑、内联合并（结构、解析、脚本变简单，减少频繁的dom操作。如MVVM框架，做一些dom diff,合并对于dom的频繁操作，改成一次性操作，尽量不去打断渲染）
3. 资源交互
图片分类 - 同一个图片分成几种（最大化提效，小页面不需要高精度，如列表页，只需要略缩图，不需要高清图。降低图片的质量和大小，提升最大内容的可显示速度，提高用户主观感受）
4. 静态资源
走CDN

扩展：关于图片上传

方法维度
表单
ajax
存储源纬度：
直接推给后台：图片变成base64，发给后台
云资源管理：图片上传到第三方托管的仓库，或者云容器，云容器返回id，将id返给后台，后台通过id，将业务逻辑与远端的图做一个关联。

2.2 First Input Delay(FID)

FID 衡量响应能力——页面对用户操作的响应速度。
该指标记录从用户与页面交互（点击、点击、按键等）到浏览器开始处理该事件处理程序的时间。小于 100 毫秒的延迟被认为是好的，而超过 300 毫秒的任何延迟都被认为是差的。

注：它只测量事件处理的延迟——而不是运行处理程序或更新 UI 所花费的时间。

如果说LCP是衡量用户的第一眼感受的话，FID是衡量交互体验
要求：页面首次输入延迟小于100ms

2.2.1 FID的改进方式

1 减少 JavaScript 执行时间
a.优化算法
b. 尽量减少JS的占用（空间、时间）
空间：进行压缩，减少JS的体积
c. 首屏加载

如何优化SPA？

服务端渲染
解决SPA问题：不用SPA，后台渲染好，返回静态页
使用预加载、懒加载

2. 分解长时间运行的任务（解决长任务问题）
长任务：一个任务可能会阻塞整个渲染。阻塞渲染50ms以上。
解决：

尽量拆分
如果是纯前端的问题，超过50ms，尽量做拆分。一段一段去执行，每执行一段，渲染出来，有一个阶段性的样子
做交互弥补
比如有的网络请求没办法拆分，一个网络请求要很久，可以加loading框、加载中…

*3 提升性能来帮助提速（使用Web Worker在后台线程中运行任务）
JS workers：Web wor ·ker | service worker | worklet

 // 1. web worker
    /* main.js */
    // 新增一个worker
    const worker = new Worker('worker.js');

    // main thread 通信
    worker.postMessage('Come on & work~');
    worker.onmessage = function(e) {
        console.log(e.data);
    }

    /* worker.js */
    self.onmessage = function(e) {
        console.log(e.data);
        // 回调主人喊话 => 业务逻辑

        // 完成后发给main
        self.postMessage(/* 业务逻辑 */);
    }

    // 2. service worker - 网络 + 内存
    /* main.js */
    navigator.seviceWorker.register('service-worker.js');

    /* service-worker.js */
    self.addEventLister("install", function() {});
    self.addEventLister("activate", function() {});
    self.addEventLister("fetch", function(e) {
        e.respondwith(
            caches.match(event.request);
        )
    });

    // 3. worklet
    // 浏览器概念流程： JS => style => layout => paint => composite

    /* main.js */
    CSS.paintWorklet.addModule('worklet.js');

    /* worklet.js */ 
    registerPaint('myGradient', class {
        paint(ctx, size, prop) {
            var gradient = ctx.createLinearGradient(0, 0, 0, size.height - 5);

            gradient.addColorStop(0, "black");
            gradient.addColorStop(1, "white");

            ctx.fillStyle = gradient;
            ctx.fillRect(0, 0, size.width, size.height);
        }
    })

    /* app */
    .content {
        background-image: paint(myGradient);
    }

2.3 Cumulative Layout Shift(CLS)

CLS 测量视觉稳定性 -查看页面时内容的意外移动。

衡量视觉稳定向
要求：页面要保持CLS小于0.1(可见元素从前一帧到后一帧改变位置的动作就代表视觉稳定性)
可见元素已经在处于可见态，前一帧到后一帧位置动作的改变就是降低视觉稳定性的一种体验。页面点击一下或者加载的时候，本来出现在左边突然间往右移，闪烁和漂移，这是主观上的感受，量化之后就是CLS。

换句话说：如果页面上的元素随着页面加载而移动，那么CLS就会变高，这是不好的。相反，你应该希望页面元素在加载时相当稳定。这样，当页面完全加载时，用户不必重新学习链接，图像和字段的位置，或者错误地点击某些内容。

2.3.1 减少 CLS（如何保持视觉稳定性?）

1 不使用无尺寸元素
对任何媒体（视频、图片、GIF、信息图表等）使用设置大小属性维度：这样，用户的浏览器就可以确切地知道该元素将在该页面上占用多少空间。
扩展： 自适应并不是无尺寸，是一定衡量标准下的有尺寸
srcset & sizes

 <img srcset="zhaowa-320w.jpg 320w,
                zhaowa-480w.jpg 480w,
                zhaowa-800w.jpg 800w,"
        sizes="(max-width: 320px) 300px,
                (max-width: 480px) 440px,
                800px">

2 减少内容内部的插入
（减少重绘、重排）
会影响到整体的布局
3 字体控制
字体变化大小会导致外层容器的变化，font-style、font-family变化也会导致视觉上元素不稳定。

对于字体，目标是尽可能快地在屏幕上显示字体，而不是与其他字体交换。在加载网络字体时避免 FOUT（无样式文本的闪烁）和 FOIT（不可见文本的闪烁）。预加载或使用类似大小的后备字体将有所帮助

2.4 Core Web VItals Annotetions - 衡量CWV的工具

下载 Core Web VItals Annotetions 点击这里
2.4.1 使用
例：使用Core Web VItals Annotetions测试百度翻译
在这里插入图片描述
右侧展示为FID、LCP、CLS测量信息，页面中标注为CLS偏移部分。

2.4.2 高效的优化方法
评估 LCP、FID 和 CLS 指标可以帮助确定最关键的问题。解决快速而简单的问题——它们通常具有最大的投资回报：

激活服务器压缩和 HTTP/2 或 HTTP/3
通过设置 HTTP 过期标头确保使用浏览器缓存
尽早预加载资产
连接和缩小 CSS 和 JavaScript
删除未使用的资产
考虑使用 CDN 或更好的托管
使用适当的图像大小和格式
优化图像和视频文件大小（专业 CDN 可以提供帮助）

3. performance - 性能评估神器

3.1 什么是performance ？

performance定位神器：接到一个任务，这个页面比较慢、性能差。属于感官上的感受，不好量化。performance可以把它量化出来，并找到慢的原因。

可把performance理解为对性能评估领域的一个接口，可以通过performance拿到很多性能上的参数，通过performance去定位哪里有问题，哪里有问题改哪里。

一个页面性能评估的领域：
1.存储有没有问题：FPS（帧率），CPU（占用、资源的消耗）、网络请求（的多少）
2.网络请求有没有问题：网络任务队列（如何排列的，并行还是串行）
3.代码执行有没有问题：JS消耗时间、性能占用（确认代码的书写有没有需要改进的地方）
4.布局（layout）有没有问题：浏览器绘制页面的帧布局

点击刷新开始
在这里插入图片描述