性能优化的本质
优化的目的是展示更快、交互响应快、页面无卡顿情况。做优化需要理解浏览器加载和渲染的本质，可以参考?浏览器进程 和?认识优化渲染性能的本质。
雅虎军规
包括7个类别35条军规：
- 减少DOM节点数量：当遍历查询500和5000个DOM节点，进行事件绑定时，会有所差别。 当一个页面DOM节点过多，应该考虑使用无限滚动方案来使视窗节点可控（视频列表使用滑动窗口）。
- 减少cookie大小：cookie 传输会造成带宽浪费，影响响应时间。消除不必要的cookies； 静态资源不需要 cookie，可以采用其他的域名，不会主动带上 cookie。
- 避免图片src为空：图片src为空时，不同浏览器会有不同的副作用，会重新发起一起请求。
性能指标
Google和W3C性能工作组提供了几种性能指标有：
- First contentful paint (FCP): 测量页面开始加载到某一块内容显示在页面上的时间。
- Largest contentful paint (LCP): 测量页面开始加载到最大文本块内容或图片显示在页面中的时间。
- First input delay (FID): 测量用户首次与网站进行交互(例如点击一个链接、按钮、js自定义控件)到浏览器真正进行响应的时间。
- Time to Interactive (TTI): 测量从页面加载到可视化呈现、页面初始化脚本已经加载，并且可以可靠地快速响应用户的时间。
- Total blocking time (TBT): 测量从FCP到TTI之间的时间，这个时间内主线程被阻塞无法响应用户输入。
- Cumulative layout shift (CLS): 测量从页面开始加载到状态变为隐藏过程中，发生不可预期的layout shifts的累积分数。
Google定义了3个最核心的指标——Core Web Vitals：
- Largest Contentful Paint (LCP): 测量加载性能。为了能提供较好的用户体验，LCP指标建议页面首次加载要在2.5s内完成。
- First Input Delay (FID): 测量交互性能。为了提供较好用户体验，交互时间建议在100ms或以内。
- Cumulative Layout Shift (CLS): 测量视觉稳定性。为了提供较好用户体验，页面应该维持CLS在0.1或以内。
对应的，Google官方库?web-vitals，可以再线上或本地测量这3个指标。
LCP可能被这四个因素影响：
- 服务端响应时间
- Javascript和CSS引起的渲染卡顿
- 资源加载时间
- 客户端渲染
FID可能被这四个因素影响：
- 减少第三方代码的影响
- 减少Javascript的执行时间
- 最小化主线程工作
- 减小请求数量和请求文件大小
CLS 能被这三个因素影响：
- 图片或视屏元素有大小属性，或者给他们保留一个空间大小，设置width、height，或者使用unsized-media feature policy。
- 不要在一个已存在的元素上面插入内容，除了相应用户输入。
- 使用 animation 或 transition 而不是直接触发布局改变。
更多详细优化请参考?web.dev
性能工具
Google开发的这些工具都支持Core Web Vitals的测量：web-vitals?。
结合这些工具做性能优化：
- 首先可以使用 Lighthouse，在本地进行测量，根据报告给出的一些建议进行优化；
- 发布之后，可以使用 PageSpeed Insights 去看下线上的性能情况；
- 接着，可以使用 Chrome User Experience Report API 去捞取线上过去30天的数据；
- 发现数据有异常，可以使用 DevTools 工具进行具体代码定位分析；
- 使用 Search Console's Core Web Vitals report 查看网站功能整体情况；
- 使用 Web Vitals 扩展方便的看页面核心指标情况；
做性能优化时，会通过各种埋点，来收集用户数据，进行性能分析，简单来说是事后监控。同样的，也应该考虑事前监控，否则，每次发布需求后，去线上看数据是否下降或异常，性能优化永远作为"追赶者/弥补者"的角色在查问题、做优化。那么如何做事前监控——建立流水线机制：
-
Lighthouse CI 或 PageSpeed Insights API：把Lighthouse或PageSpeed Insights API集成到CI流水线中，输出报告分析。
-
Puppeteer 或 Playwright：使用 e2e 自动化测试工具集成到流水线模拟用户操作，得到Chrome Trace Files，也就是平常录制 Performance 后，点击左上角下载的文件。Puppeteer和Playwright底层都是基于Chrome DevTools Protocol。
-
Chrome Trace Files：根据规则分析Trace文件，可以得到每个函数执行的时间。如果函数执行时间超过了一个临界值，可以抛出异常。如果一个函数每次的执行时间都超过了临界值，那么就值得注意了。但是还有一点需要思考的是：函数执行的时间是否超过临界值固然重要，但更重要的是这是不是用户的输入响应函数，与用户体验是否有关。
- 输出报告。定义异常临界值。如果异常过多，考虑是否卡发布流程。