前端首屏优化指标
由于项目项目特殊性，需要对首屏做项目优化现记录如下
1首屏优化指标
想做优化，先要有做优化的指标，不然就没有太多目的性。
| name | 值 | 说明 | 备注 |
|---|---|---|---|
| 帧动画(animation) | 小于16ms （至少要保证每帧不能超过32ms） | 要保证30-60fps才能保证肉眼流畅度 | 暂时无法获取，对首屏来说目前不需要这个数据，除非首屏涉及到主内容就是大量动画 |
| 输入延迟(response) fid | 50ms （至少保证100ms以内） | 用户做交互到js开始执行时间差 | 可以获取performance.now() - event.timeStamp |
| 速度指标speedindex | 1250 | 速度指标是 一个页面呈现的总体时间的一个评价（计算公式可以理解成首屏每个阶段出现时间点*权重可以参考下这个） | 可以通过公式获取 |
| 可交互时间 tti | 5秒（这个5s相对的） | 用户对web可操作时间，第二次时间应该小于2秒 | 可以通过插件tti-polyfill.js获取 |
| 首次有效绘制fmp | 1s | 第一块对用户有意义和主要内容的呈现时间 | 可以根据PerformanceObserver跟踪主元素获取 |
| 用户首次感知页面时间fcp | <1s | 用户感觉有信息反馈 | 可以根据PerformanceObserver获取 |
| 核心包大小 | 通过压缩(gzip|Brotli)后应该在200kb以内（相对的） | 主要呈现内容的资源文件大小整合 | 核心功能，增强体验效果（DOMContentLoaded），附加功能（load）非首屏功能可以考虑动态加载 |
| html大小 | 14kb | 整合静态页面信息和css信息的资源大小 TCP慢启动（限制首次传输大小14kb） | |
| idle | 尽可能多的空闲时间 | 整个页面的主线上有多的空闲时间才不会阻塞交互 | |
| load | 1000ms | 尽量在1s内呈现交互内容 |
2.检测工具
检测页面性能工具很多，这里主要使用chrome-preformance,lighthouse。
数据采集插件，performance, PerformanceObserver,tti-polyfill,first-input-delay,analytics.js。
3.数据可视化
通过插件主要采集fmp，tti，fid的数据。在通过analytics数据转发到自己搭建的服务器上再通过分析数据做图形可视化，来对比前后优化的首页性能指标。analytics还可以做事件跟踪 ，错误日志跟踪，也可以自定义一些指标。
插件demo地址
数据采集后展示效果:
performance3.png
performance4.png
preformance1.png
performance2.png
4首屏优化
1.动态加载
项目使用vue-cli3。由于项目涉及到异步模块很多，（可以想象成那种对话形式一问一答的功能），项目依赖的所有模块都从功能上去重构，使每个功能颗粒度竟可能小，这样只在首次加载模块时加载必须要加载的包，而其他的组件全部靠异步加载来实现,主要是通过webpack import去加载异步模块。实际重构后首屏加载代码量减少30%。
2.引入servicework
项目依赖环境有可能是webvieiw 也有可能是pc，在app上已经做了自身的缓存策略（加载webivew会提前加载一些资源，资源也会进行二次缓存），在pc的项目会选择开启sw。在vue.config 引入workbox-webpack-plugin来控制缓存策略，没有使用vue-cli3自带pwa，怕打包后会有无用代码引入。
3.tree shake
项目虽然迭代了2个版本，但是项目组件各个依赖还是很重，是从webpack tree shake角度出发 做了些优化，不过对比前后效果不是很大，通过chrome-devtool-coverage 代码使用率还是偏低。主要代码首次加载用到了绝大部分核心通用模块，而模块颗粒度已经在设计的较小范围内了，再优化只能考虑重新设计推到重来了。
关于tree shake优化可以参考下这个。
4.ssr
有条件可以考虑ssr，奈何服务器环境不允许- -
