持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第14天，点击查看活动详情
一、 加载性能优化
如何更快地把资源从服务器中拉到浏览器，如 http 与资源体积的各种优化，都是旨在加载性能的提升。
1、更快的传输
（1）把静态资源CDN化
将资源分发到 CDN 的边缘网络节点，使用户可就近获取所需内容，大幅减小了光纤传输距离，使全球各地用户打开网站都拥有良好的网络体验。
（2）使用HTTP2替代HTTP1.1
-
HTTP2的并行请求原理可解决http1.1线头阻塞问题
-
如资源合并，拆分域名，雪碧图等均无需设置
查询网页资源是通过 HTTP1.1 还是 HTTP2 加载的，要怎么做呢？
从 GIF 中可以看出，除了 HTTP 协议版本外，还可以查看其他信息，例如 HTTP 请求的方法、域名等等。
（3） HTTP 缓存
更好的资源缓存策略，对于 CDN 来讲可减少回源次数，对于浏览器而言可减少请求发送次数。
1、缓存策略
强缓存
强缓存就是文件直接从本地缓存中获取，不需要发送请求。
协商缓存
-
协商缓存，也叫对比缓存。
-
它是一种服务端的缓存策略，即通过服务端来判断某件事情是不是可以被缓存。
-
服务端判断客户端的资源，是否和服务端资源一样，如果一致则返回
304，反之返回200和最新的资源。
2、分包加载
避免一行代码修改导致整个 bundle 的缓存失效
（4）减少 HTTP 请求及负载
对一个网站的资源进行压缩优化，从而达到减少 HTTP 负载的目的。
-
js/css/image 等常规资源体积优化
-
小图片优化，将小图片内联为 Data URI，减小请求数量
-
图片懒加载
2、更小的体积
（1）JS、CSS、HTML 等文本资源处理
-
gzip通过 LZ77 算法与 Huffman 编码来压缩文件，重复度越高的文件可压缩的空间就越大。 -
brotli通过变种的 LZ77 算法、Huffman 编码及二阶文本建模来压缩文件，更先进的压缩算法，比 gzip 有更高的性能及压缩率
可在浏览器的 Content-Encoding 响应头查看该网站是否开启了压缩算法，目前知乎、掘金等已全面开启了 brotli 压缩。
查询方式：Accept-Encoding: gzip, deflate, br
（2）压缩工具
压缩策略
- 长变量名替换短变量
- 删除空格换行符
- 预计算:
const a = 24 * 60 * 60 * 1000->const a = 86400000 - 移除无法被执行的代码
- 移除无用的变量及函数
工具
（1）可在 Terser Repl 在线查看代码压缩效果。
（2）swc 是另外一个用以压缩 Javascript 的工具，它拥有与 terser 相同的 API，由于它是由 rust 所写，因此它拥有更高的性能。
（3）html-minifier-terser 用以压缩 HTML 的工具
（3）使用Webpack减少JS体积
-
使用
webpack-bundle-analyze分析打包体积 -
对一些库替换为更小体积的库，如 moment -> dayjs
-
对一些库进行按需加载，如
import lodash->import lodash/get -
对一些库使用支持 Tree Shaking，如
import lodash->import lodash-es
增加体验 PWA（Progerssive Web App）
webapp用户体验差（不能离线访问），用户粘性低（无法保存入口），pwa就是为了解决这一系列问题让webapp具有快速，可靠，安全等特点
-
Web App Mainfset: 将网站添加到桌面、更类似native的体验 -
Service Worker: 离线缓存内容，配合cache API -
Push Api & Notification Api: 消息推送与提醒 -
App Shell & App Skeleton App壳、骨架屏
（4）图片资源处理
正常情况下图片体积大小排序：avif > webp > jpeg/png
可使用 picture/source 进行回退处理从而无缝兼容
<picture>
<source srcset="img/photo.avif" type="image/avif">
<source srcset="img/photo.webp" type="image/webp">
<img src="img/photo.jpg" width="360" height="240">
</picture>
-
更合适的尺寸: 当页面仅需显示 100px/100px 大小图片时，对图片进行压缩到 100px/100px
-
更合适的压缩: 可对前端图片进行适当压缩，如通过
sharp等
（5）其他处理
-
路由懒加载，无需加载整个应用的资源
-
Tree Shaking: 无用导出将在生产环境进行删除
-
browserlist/babel: 及时更新 browserlist，采用域名分片技术，将资源放到不同的域名下，同一个域名最多处理6个TCP链接问题
二、渲染性能优化
如何更快的把资源在浏览器上进行渲染。如减少重排重绘等都是旨在渲染性能的提升。
1、控制 HTTP 优先级，从而达到关键请求更快响应
<link rel="prefetch" href="style.css" as="style">
<link rel="preload" href="main.js" as="script">
preload 加载当前路由必需资源，优先级高。一般对于 Bundle Spliting 资源与 Code Spliting 资源做 preload prefetch 优先级低，在浏览器 idle 状态时加载资源。一般用以加载其它路由资源，如当页面出现 Link，可 prefetch 当前 Link 的路由资源。（next.js 默认会对 link 做懒加载+prefetch，即当某条 Link 出现页面中，即自动 prefetch 该 Link 指向的路由资源
拓展：dns-prefetch，可对主机地址的 DNS 进行预解析。
<link rel="dns-prefetch" href="//shanyue.tech">
2、防抖和节流
无论是防抖还是节流都可以大幅度减少渲染次数，在 React 中还可以使用 use-debounce 之类的 hooks 避免重新渲染
（1）防抖
指触发事件后指定时间后才执行函数，如果在指定时间内又触发了事件，则会重新计算函数执行时间(执行最后一次函数)。
（2）节流
在单位时间内多次触发事件只能执行第一次
（3）use-debounce
简单使用
const [text, setText] = useState('Hello');
// 一秒钟渲染一次，大大降低了重新渲染的频率
const [value] = useDebounce(text, 1000);
//输入内容则触发onChange事件
<input defaultValue={'Hello'} onChange={(e) => { setText(e.target.value); }} />
<p>Actual value: {text}</p>
//若改变1秒渲染1次
<p>Debounce value: {value}</p> </div>
3、虚拟列表优化
一般在视口内维护一个虚拟列表(仅渲染少量数据)，监听视口位置变化，从而对视口内的虚拟列表进行控制。
在 React 中可采用以下库:
4、请求及资源缓存
避免不必要的重复请求合理地对 API 进行缓存
- 对每一条 GET API 添加 key
- 根据 key 控制该 API 缓存，重复发生请求时将从缓存中取得
function Example() {
// 设置缓存的 Key 为 Users:xxx
const { isLoading, data } = useQuery(['users', userId], () => fetchUserById(userId))
}
三、JavaScript转换
1、Web Worker
在纯浏览器中，如何实现高性能的实时代码编译及转换？Babel Repl
如果使用Javascript 实现，将会耗时过多阻塞主线程，有可能导致页面卡顿。
如果使用 Web Worker 交由额外的线程来做这件事，将会高效很多，基本上所有在浏览器端进行代码编译的功能都由 Web Worker 实现
2、WASM
原理
-
JS 性能低下
-
C++/Rust 高性能
-
使用 C++/Rust 编写代码，然后在 Javascript 环境运行
注意：兼容性较差
举例:在纯浏览器中，如何实现高性能的图片压缩？
基本上很难做到，Javascript 的性能与生态决定了实现图片压缩的艰难。
而借助于 WASM 就相当于借用了其它语言的生态。
-
libavif: C语言写的 avif 解码编码库
-
libwebp: C语言写的 webp 解码编码库
-
mozjpeg: C语言写的 jpeg 解码编码库
-
oxipng: Rust语言写的 png 优化库
而由于 WASM，完全可以把这些其它语言的生态移植到浏览器中，从而实现一个高性能的离线式的图片压缩工具，但是有较为严重的兼容性问题。
如果想了解这种的工具，请看看 squoosh
