2022 业务性能优化记录
业务做性能优化，社区资料可参考性有限。记录一下业务摸索过程，算是回馈社区。
内容不会过于详细，毕竟业务形态不一、性能指标侧重点不同，重要的是思路，而不是如何落地；再者社区关于如何落地的资料很多，不需要重复。
指标（KPI）
表示性能的指标（KPI）社区很多，挑几个符合业务形态的就行；不管多少，但是一定要有，不然怎么评估优化效果，有效果也好跟老板吹牛逼。
本文主要围绕着以下两个指标来优化（架构组确定的指标，这里不讨论合理性）：
- 首屏主要内容渲染时间
- 根组件（componentDidMount）执行时间
这两个指标不理解也没关系，可以简单理解为：页面白屏时间短、外联 js/css/img 加载快、用户可操作等待时间短。
页面白屏时间短
先上 SSR。还觉得首屏慢慢的话，要分析瓶颈在哪：
- 首屏依赖的接口是不是慢、是不是数量多
- 内联 js/css 是不是多、能不能缩减
再上 流式渲染，继续分析瓶颈：
- 首屏、次屏内容划分是否合理
- 首屏接口是不是足够快、数据量是不是足够小
- 慢接口有没有移到次屏时再请求
- 首屏的 html 有没有多余的，用户看不到的 html 是不是可以到 csr 渲染
接着上 loadable，持续分析瓶颈：
- 首屏组件 loadable 优化
- csr 才用到的组件，dynamic import 进来
- csr 才用到的样式，从 inline css 拆出来
到这里，总结起来是：首屏 html 体积要小、接口要快。
接着从 网络角度 分析：
- http2
- DNS Prefetch
- Preconnect
- Prefetch
- Prerender
还有 容器 角度：
- webview 预热
- webview 复用
静态资源加载快
- js/css 是不是真的体积小
- js/css 有没有能拆出去的，主页面少一些其他页面的公共代码
- webpack 的 minChunks 是否合理
- webpack 公共 chunk 是否合理
- polyfill/autoprefixer 配置，结合用户真实情况下，是否合理
- babel 的 loose 配置是否可以开启
- terser 的配置是否有优化空间
- 能不能根据 user agent 有多份打包配置，不同 ua 返回不同代码
- 客户端可否提前下发资源包，包含页面所需的 js/css/img
- 图片尺寸是否合理
- 图片格式可否开启 webp
用户可操作等待时间短
- 分析 performance 结果，看看前面都有哪些函数卡住页面 hydration
- lazy hydration
容灾/降级
ssr 虽好，但是要考虑异常，csr 兜底不能丢。