前端性能优化1

1.Navigation Timing API

1. unloadEventStart / end

前一个页面的unload时间戳

=> 无前置页面时？ => 值为0

=> 前置页面域不同 => 值为0

2. redirectStart / end

第一个http重定向发生的时间 / 最后一个http重定向完成的时间

=> 有跳转且是同域名 => 否则值为0

3. fetchStart

浏览器准备好使用HTTP请求抓取文档的事件

4. domainLookupStart / end

开始/重新建立连接的时间

=> 只是建立

=> 如果是长链接 => 值等于fetchStart

5. connectStart / end

TCP建立握手的开始 、 完成

=> 如果是长链接 => 值等于fetchStart

6. secureConnectionStart

HTTPS连接建立开始时间

7. requestStart / end

请求发起的真实时间

=> 包含了本地缓存的读取

8. responseStart / end

回包真实时间

=> 包含了本地缓存的读取

9. domLoading

开始解析渲染DOM树 => 抛出readystatechange事件

10. domInteractive

完成了DOM树的解析 => 抛出readystatechange事件

=> 这个时候并没有开始加载网页资源

11. domContentLoadedEventStart / end

DOM解析完成后，开始 / 结束加载网页内资源的时间

12. domComplete

整体DOM树解析完成 => 抛出readystatechange事件

13. loadEventStart / end

load事件发送给文档 / 回调执行完成的时间

网络请求的时间 从 domainLookupStart 到 responseEnd

静态页面渲染时间(不包含网络请求) 从 domLoading 到 domComplete

动态页面渲染时间 从 loadEventStart 到 loadEventEnd

静态页面+动态页面渲染时间 从 responseEnd 到 loadEventEnd

```js

<script>

javascript:(() => {

{/* 整个页面加载时间 */}

cosnt perfData = window.performance.timing;

const pageLoadTime = perfData.loadEventEnd - perfData.navigationStart;

window.trace('当前页面加载耗时：', pageLoadTime, 'ms');

})();

</script>

```

2. Core Web Vitals - 网页核心的性能指标

* Google提出 => 可衡量的、能够反应真实体验的：加载、交互、视觉稳定性

3. LCP - Largest Contentful Paint 衡量装载性能

* 前2.5s内进行最大内容的渲染

a. 最大内容包含了哪些？

- <img>元素

- <svg>元素

- <video>元素

- 通过url()函数加载背景图片的元素

- 包含文本整体节点的块级元素

b. LCP值低下的原因

- 服务器响应慢

- 阻断渲染的JS和css

- 资源加载慢

- 客户端渲染机器性能影响

c. 针对性改造呢

- 服务器优化

缓存HTML离线页面，缓存页面资源，减少浏览器对于资源的请求

=> 强缓存、协商缓存

尽量减少资源阻断渲染：CSS和JS做级联、内联、合并

=> 浏览器原理

对图片进行优化 JPG WEBP => 降低资源大小 => 加快请求速度

使用CDN加快请求速度 云资源管理

利用工程化做项目层级优化 => HTML进行重写优化、压缩空格、去除注释、去除打印、调整格式

提升首屏优化 => 懒加载、资源按需加载、service worker、服务端渲染

4.FID - First Input Delay

衡量交互性。

* 页面首次输入的延迟应该小于100ms

a. 减少JS执行时间

- 缩小并压缩JS文件

- 延迟执行不需要的JS

- 尽量减少用不到的polyfill

b. 分解耗时的任务

- 任何阻塞主线程超过50ms => 长任务

- 长任务拆分成较小的异步任务

c. worker

- web worker / service worker

```js

// 1. web worker

// main.js

const myWorker = new Worker('worker.js');

// 与mainthread之间通信

myWorker.postMessage('hello');

myWorker.onmessage = function(e) {

console.log(e.data);

}

// worker.js

self.onmessage = function(e) {

console.log(e.data);

self.postMessage(workerResult);

}

// 2. service worker

// main.js

navigator.serviceWorker.register('./service-worker.js');

// serveice-worker.js

self.addEventListener('install', event => {})

self.addEventListener('activate', event => {})

self.addEventListener('fetch', event => {

event.respindwith(

caches.match(event.request)

)

})

```

5. CLS - cumulative layout shift

衡量视觉稳定性 => CLS页面应当保持在小于0.1

* 布局的移动可能发生在可见元素从一帧到下一帧改变的位置

a. 不使用无尺寸元素

=> srcset & sizes

```js

<img srcset="yy-320w.jpg 320w,

yy-480w.jpg 480w

yy-800w.jpg 800w"

sizes="(max-width: 320px) 280px,

(max-width: 480px) 440px,

800px"

src="yy-800w.jpg" alt='yyimg'>

```

b. 减少内容的插入 => 影响整体的布局

c. 动态字体控制

<!-- => <link rel="preload">预加载字体 -->

#### CWV 工具 - core web vitals annotations

#### 基石 => performance

#### 性能优化的另一种可能 - bigpipe —— 页面分解成若干的pagelet

1. 服务前端接收来自客户端HTTP请求

2. 存储层去获取数据 => 组装HTML => 响应给客户端