|
本文旨在整理平常Web前端性能优化的思路，可供前端研发参考。由于力求精简，限于篇幅，因此并未详述详细实施方法。
基于现代Web前端框架的应用，其原理是经过浏览器向服务器发送网络请求，获取必要的index.html和打包好的JS、CSS等资源，在浏览器内执行JS，动态获取数据并渲染页面，从而将结果呈现给用户。
在这个过程中，有两个过程可能较为耗时，一个是网络资源的加载，另一个是浏览器内代码执行和DOM渲染。
而耗时的增多会引起页面响应慢，卡顿，影响用户体验。
针对以上两种耗时的状况，平常的优化方向有： 缩短请求耗时；减少重排重绘；改善JS性能。
1 缩短请求耗时
网络资源是Web应用运行的基本，改善网络资源加载速度会明显改善前端性能。
1.1 优化打包资源
总体原则： 减少或延迟模块引用，以减少网络负荷。
常用工具： webpackwebpack-bundle-analyzer可视化分析工具
常用办法： 减小体积：减少非必要的import；压缩JS代码；配置服务器gzip等；运用WebP照片；按需加载：可按照“路由”、“是不是可见”按需加载JS代码，减少初次加载JS体积。例如能够运用import()进行代码分割，按需加载；掰开打包：利用浏览器缓存机制，依据模块更新频率分层打包。
其他办法： 雪碧图：每一个HTTP/1.1请求都是独立的TCP连接，最大6个并发，因此合并照片资源能够优化加载速度。HTTP/2已然不需要这么做了。
1.2 CDN加速
总体原则：
经过分布式的边缘网络节点，缩短资源到终端用户的拜访延迟。
常用工具：CloudflareAWS CloudFrontAliyun CDN
常用办法： 加速照片、视频等大体积文件
1.3 浏览器缓存
总体原则：避免重复传输相同的数据，节省网络带宽，加速资源获取。
常用办法：能够通过设置HTTP Header来掌控缓存策略，通常有如下几种。 强缓存Expires：HTTP/1.0Cache-Control：HTTP/1.1协商缓存ETag + If-None-MatchLast-Modified + If-Modified-Since
拿ETag举例，倘若浏览器给的If-None-Match值与服务端给的ETag值相等，服务器就直接返回304，从而避免重复传输数据。
ETag示例：
倘若几个配置同期存在，则优先级为：Cache-Control > Expires > ETag > Last-Modified。
1.4 更高版本的HTTP
总体原则：运用高版本HTTP提高性能。
常用工具： HTTP/2
HTTP/2较HTTP/1.1最大的改进在于： 多路复用：单一TCP连接，多HTTP请求，有Demo；头部压缩：减少HTTP头体积；请求优先级：优先获取重要的数据；服务端推送：主动推送CSS等静态资源。
其他办法： HTTP/3
HTTP/3基于UDP，有非常多方面的性能改进，如多路复用无队头阻塞，响应更快。感兴趣的朋友可参考Wiki。
1.5 Web Socket
总体原则：处理HTTP协议没法实时通信的问题。
Web Socket是一条有状态的TCP长连接，用于实现实时通信、实时响应。
1.6 服务器端渲染（SSR）
总体原则：第1次拜访时，服务器端直接返回渲染好的页面。
通常流程： 浏览器向 URL 发送请求；服务器端返回“空白”index.html；浏览器不可呈现页面，需要继续下载依赖；加载所有脚本后，组件才可被渲染。
SSR流程： 浏览器向 URL 发送请求；服务器端执行JS完成首屏渲染并返回；浏览器直接呈现页面，而后继续下载其他依赖；加载所有脚本后，组件将再次在客户端呈现。它将对现有View进行合并。
常用工具： Node.js，用于服务器端执行代码，输出HTML给浏览器，支持所有主流前端框架Next.js，用于服务器端渲染React的框架gatsby，用React生成静态网站的工具
除了能够提高页面用户体验，还能应用于seo。
2 减少重排重绘
除了网络资源以外，另一个影响前端性能的原因便是前端页面的渲染绘制效率。
虽然区别的前端框架有有些差异，但整体的优化思路是一致的，这儿将以React举例。
2.1 减少渲染量
总体原则：不渲染未展示的部分。
常用工具： react-windowreact-loadableJS原生，如IntersectionObserver框架供给，如React.lazy、react-intersection-observer
常用办法： 虚拟列表：只渲染可见区；惰性加载：无限滚动；按需加载：页面仅在切换过去时才加载。
以虚拟列表举例，以下是运用react-window库，仅仅渲染了可见区的数据：
2.2 减少渲染次数
总体思路：避免重复的渲染。
常用工具： lodashJS或框架自带
常用办法： 防抖与节流；针对React函数组件来讲，恰当运用副功效，拆分无相关的副功效；针对React类组件来讲，能够运用shouldComponentUpdate或运用PureComponent来优化渲染；利用缓存，如React.memo；运用requestAnimationFrame替代setInterval执行动画。
3 改善JS性能
由于浏览器是单线程异步模型，长期的运算会阻塞渲染过程，因此改善繁杂运算有助于改善前端的整体性能。
3.1 缓存繁杂计算
总体思路：避免重复计算。
常用办法： 针对React函数组件来讲，能够运用useMemo缓存繁杂计算值。
举例如下，memoizedValue需要经过繁杂计算才可得到，此时就能够运用useMemo缓存，仅仅在输入参数出现变化时才重新计算，避免计算阻塞页面渲染，从而避免页面卡顿。 1const MyFunctionalComponent = () => {
2 const memoizedValue = useMemo(() => {
3computeExpensiveValue(a, b);4 }, [a, b]);
5
6 return <AComponent value={memoizedValue}/>;
7}
但useMemo自己亦有性能消耗，需要视状况运用，某些场景能够利用React的渲染机制避免性能问题，能够参考《Before You memo()》。
3.2 Web Worker
总体原则：多线程思想。
常用办法： Dedicated Workers，处理与UI无关的密集型数学计算：大数据集合排序、数据压缩、音视频处理；Service Worker，服务端推送，或PWA中协同CacheStorage在前端掌控缓存资源；Shared Worker，Tab间通信。
JS语言在设计之初便是单线程异步模型，好处是能够有效处理I/O操作，但坏处是没法利用多核CPU。
Web Worker会起步系统级别的线程，可进行多线程编程，发挥多核的性能。
3.3 Web Assembly
总体原则：将繁杂的计算规律编译为Web Assembly，避免JS类型推断过程中的性能开销，可用于性能的极限优化。
适用范围有限：
曾在网上看到，有人运用自顶向下非优化的斐波那契数列算法来举例，说Web Assembly比原生JS快一倍，实测之后似乎亦无。
在同一台设备测试，其中求第48个值的耗时如下： C（Ubuntu+GCC）：18sJS（V8）：32sWeb Assembly（V8+EMCC）：39s
一种可能的猜想是，斐波那契计算中无海量的类型推断，况且V8内部有有些优化机制，使得此处JS执行速度快于Web Assembly。
简而言之，并非所有场景都适用于Web Assembly。
另一种运用场景是，把区别语言编写的代码（C/C++/Java等）编译为Web Assembly，能以接近原生的速度在Web中运行，并且与JS共存。
总结
引起前端性能问题的原因是多方面的。
倘若是前端资源加载慢，引起页面慢，则应该思虑怎样缩短请求耗时。而倘若是前端页面规律笨重，UI数据量太大，则能够试着从减少重排重绘的方向去优化。针对耗时长的繁杂计算，缓存计算结果常常是见效较快的优化方式。
最后需要重视的是，在实质应用研发过程中，由于受限于研发成本，因此需要平衡优化所花的代价与其对应产生的成效。能够有针对性地对性能瓶颈进行分析和处理，同期亦需要避免引入不必要的优化办法，以保证最后优化效果。
文/Thoughtworks严文
原文链接： https://insights.thoughtworks.cn/web-frontend-performance-tuning/
更加多精彩洞见，请关注微X公众号Thoughtworks洞见。
| 
发表于 2024-8-31 13:08:11