在所有的代码设计中，我们都可以渐进增强的思考模式，去指导我们的开发。渐进增强🔗的核心原则是：基础的内容和功能开始，逐层添加表现层和行为层，确保每一层的增强都不会破坏基础层的功能。当增强功能不可用时，核心功能仍然可以正常工作。
从渐进增强的角度，我们可以很好地找到那些优先需要衡量的性能指标。浏览器的基础层是 html，而衡量 Html 是否开始渲染的指标，便是 FCP。当 html 接收并开始渲染后，一般最大最明显的核心内容（如文章正文），是用户感知加载速度的重要指标，也就是 FCP。在渲染过程中，一些广告，异步渲染的 js 组件，是否影响了整体页面的跳动。比如正文内容的 loading 组件所占区块很小，但最终的正文所占区块很大，加载后页面跳动。这里的衡量指标便是 CLS。内容的增强后，我们可以考虑交互的增强，也就是点击事件的可用性和流畅度，也就是 FID。
由于采集事件不能阻塞用户主页面的渲染，我们必须采用的是我们必须使用异步的 PerformanceObserver API，而不是同步的 performance.getEntries()，以此避免阻塞主线程。
PerformanceObserver 中有一个回调函数，函数参数可以通过 getEntries() 拿到一个对象列表，每一个 entry 的 entryType 都对应一个性能指标。比如 largest-contentful-paint 对应 lcp，layout-shift 对应 CLS，first-input 对应 FID。
我们要做的是，把数据存储在本地列表中，而这些数据中，又有一些数据是不可用的。
比如当页面切换到后台时，会导致 lcp 非常大。我们应该忽略 visibilityState 为 hidden 时发生的绘制。
又比如 cls 在 spa 切换界面时，会持续累积。通常我们只关心加载阶段的累积变化。