背景
性能优化的手段有很多，如果对现有页面用上所有性能优化手段的话成本太高，此时性能分析的重要性就体现出来了。笔者近日面试了web剪映的前端岗位，对web剪映的核心页面——剪映编辑页进行了简单的性能分析
性能分析工具
光靠肉眼很难客观地评价页面的性能，此时我们可以借助一些性能分析的工具：
- Google PageSpeed Insights：谷歌开发的页面在线性能分析工具。同类型的工具有 lighthouse、WebPageTest等。
- Chrome Developer Tools: 用于分析页面的运行时的性能。其中使用Chrome Performance工具可以知道更多资源请求细节，更容易分析出性能瓶颈。打开Chrome控制台就可以看到Performance的tab：
剪映编辑页
PageSpeed Insights的跑分
上图主要关注两个首屏数据：
- FCP：首次内容绘制，浏览器首次绘制DOM的时间，这是用户第一次看到的内容。最佳用户体验的FCP建议在2秒以内，如果超过4秒则表示页面首次内容绘制很慢。
- LCP：最大内容绘制，可视区域中最大内容元素显示到屏幕上的时间。与FCP相比，LCP表示最大有效内容出现的时间。最佳用户体验的LCP建议在2.5秒以内，超过4秒则表示最大内容绘制很慢。
从上图的跑分时间可知，剪映编辑页的FCP和LCP时间分别为4.5秒和5.5秒，都处于一个较慢的首屏时间。
首屏加载分析
PageSpeed Insights的跑分数据只能作为一个大概的参考数据。要想知道页面的首屏性能瓶颈，我们需要知道更多的页面加载细节，此时Chrome Permance工具可以排上用场了，如下图：
通过Chrome Performance工具的分析，可将剪映编辑页分为3个阶段：
- 白屏阶段：时间段为0秒~3.9秒。此时整个页面还没有渲染任何DOM。最佳体验白屏时间应该控制在2.5秒以内，但是该页面需要将近4秒。
- 视频加载阶段：时间段为3.9秒~7秒。此时页面虽然渲染了主体DOM，但是页面还在加载视频编辑器，整个页面处于不可交互状态，持续将近3秒。
- 可交互阶段：时间段为7秒以后，也就是说用户需要等待7秒才能真正对页面进行有效操作，这对任何用户来说都是一个比较难以接受的时间。
针对Chrome Performance工具所得出的阶段，下面给出一些分析和建议。
白屏阶段
在分析白屏阶段之前，先认识一下Chrome Permance工具的两大利器：Network和Main，前者用于分析页面资源的加载顺序，后者可以看到页面运行的火焰图
下面我们再来分析剪映编辑页白屏阶段的首屏性能瓶颈所在：
由上图可知，当HTML下载完毕后，会先运行一份脚本加载器JS。该脚本加载器加载了3个业务JS，然后才运行这3个业务JS。
白屏阶段优化1：去掉脚本加载器JS的阻塞
再看看上图，脚本加载器JS的运行时间用了差不多500毫秒。这5O0毫秒阻塞业务JS代码的加载，导致整体首屏时间多了500毫秒，如果能把业务JS放在脚本加载器之前应该可以省掉这部分时间。
白屏阶段优化2：懒加载非首屏的JS
3个业务JS的加载使用使用了1.2秒。实际上由Chrome Coverage工具可知，这3个业务JS在首屏阶段只使用了 25%~35% 的JS代码：
去掉非首屏的代码可以减少大部分的JS运行时间。如果你是使用webpack，可参考webpack的懒加载方式。
视频加载阶段
通过上图可知，在视频加载阶段加载了大量blob文件，推测剪映编辑页使用了 WebAssembly。为了分析 WebAssembly，整整阻塞了4秒的首屏时间！
而且每次刷新页面的时候，WebAssembly会重新加载。用户如果不小心刷新页面的话，又要多等待4秒时间。
笔者再分析了剪映的竞品腾讯智影，发现腾讯智影并没有使用WebAssembly，页面加载速度也很快。笔者猜测剪映web使用WebAssembly是为了与客户端共用同一份代码，减少开发成本。
优化建议：
- WebAssembly的资源能不能缓存起来或者预加载，不要每次刷新页面都加载。
- 要不就别用WebAssembly了吧。
非首屏分析
本章主要分析剪映编辑页的非首屏部分。
侧边栏tab切换分析与优化
剪映编辑页有一个侧边栏功能，点击后在右边会看到加载后的内容。但是点击后侧边栏看到主要内容的时平均时间为3秒，这是一个比较慢的数字。
老规矩，我们用Chrome Permance工具分析一下点击了“文本”tab后的页面加载流程：
由上图可知，在点击“文本”tab后整整加载了7个cgi！而且 getPanelInfo 和 getCategoryEffects 这两个cgi是串行的。整个cgi请求过程用了差不多2秒时间。
优化建议：建议和后端同学协商一下，将7条cgi合并成一个。
图片压缩
由上图可知，剪映编辑页的素材图片大部分使用的是png和jpeg图片，笔者尝试将上图红框的图片放到tinypng.com/ 压缩：
不出所料，图片完全没有压缩。和用户头像的动态图片不同，剪映编辑页的素材图片基本上不会变化，只需要前端同学手动压缩一下就行。这可能是成本最低的前端优化方式了。
图片格式
剪映编辑页使用了大量素材图片，格式都是png、jpg和gif。建议将这些图片换成apng、webp和avif格式，然后根据浏览器兼容程度可以降级到png、jpg和gif。
总结
我们通过Google PageSpeed Insights和Chrome Developer Tools两个工具，不用看源码就可以分析出剪映编辑页的部分性能问题。总体来说剪映编辑页的首屏性能并不理想，其性能瓶颈在于WebAssembly的加载。性能优化也讲求性价比，与推动后台修改cgi相比，压缩图片和替换图片格式的性价比很高。实际上我们可以将这套方法论用到其他页面分析上。
