⚡ 30 秒速记
- 先描述用户感受到的慢，再选对应指标
- 内容慢看
LCP，交互慢看INP，跳动看CLS - 网络瀑布与主线程记录互相印证
- 线上按设备、网络与版本分组
- 修改一个主要瓶颈后，用同条件复测
性能定位先问用户在等什么，再沿时间线找到那段等待。 内容出得晚可能是资源发现、下载或渲染，点击没反馈可能是主线程被占，画面乱跳则要看布局偏移来源。用网络和性能记录建立因果，再按设备与网络确认影响范围。优化后复测同一流程，并观察其他指标，避免只把等待从加载阶段搬到第一次交互。
版本校准： 原理文章中的代码代表特定实现与写作时间。应用到当前项目时，应先确认浏览器、框架或工具的主版本，再区分稳定的规范语义、可变化的内部实现和项目自身约束。
# 性能优化的意义
# 性能是留住用户很重要的一环
- pinterest 重建了他们的页面以实现性能，使感知等待时间减少了 40％，从而将搜索引擎流量和注册量提高了 15％。
- 通过将平均页面加载时间减少 850 毫秒，COOK 发现他们能够将转化率提高 7％，将跳出率降低 7％，并将每个页面的页面数量增加 10％。
- BBC 发现，他们在网站加载的每一秒钟内就会损失 10％ 的用户。
- DoubleClick by Google 发现，如果网页加载时间超过 3 秒，则会有 53％ 的用户放弃移动网站的访问。
# 性能是改善转换率至关重要的一环
- 对于 Mobify，主页加载速度每减少 100 毫秒，基于会话的转换增加 1.11％，平均年收入增加近 380,000 美元。此外，结账页面加载速度减少 100 毫秒，基于会话的转换增加了 1.55％，从而使年均收入增长近 530,000 美元
- DoubleClick 发现在 5 秒内加载网站的发布商的广告收入是在 19 秒内加载的网站的两倍。. 当 AutoAnything 将页面加载时间缩短一半时，他们的销售额增长了 12-13％。
# 用户角度的性能标准是什么
# 著名的 2-5-8 原则
- 当用户能够在 2 秒以内得到响应时，会感觉系统的响应很快；
- 当用户在 2-5 秒之间得到响应时，会感觉系统的响应速度还可以；
- 当用户在 5-8 秒以内得到响应时，会感觉系统的响应速度很慢，但是还可以接受；
- 而当用户在超过 8 秒后仍然无法得到响应时，会感觉系统糟透了，或者认为系统已经失去响应，而选择离开这个 Web 站点，或者发起第二次请求。
综上所述：一个网站的性能好坏是留住用户和实现变现的基础
而我们的目标就是力争 1s，保住 2s
1s 的差距，看似微乎其微，但这 1s，浏览器实际上可以做非常多的事情 接下来让我们来看看如何对一个网站进行性能分析
# RAIL模型
RAIL是Response，Animation，Idle和Load的首字母缩写，是一种由Google Chrome团队于2015年提出的性能模型，用于提升浏览器的用户体验和性能。
