想实时监测网页在加载过程中的Core Web Vitals（核心网页指标）表现——比如LCP（最大内容绘制）究竟在哪个瞬间完成、CLS（累计布局偏移）是否随着页面渲染逐步累积、INP（交互到下一绘制的延迟）是否拖慢了响应速度——而不是等到页面完全加载后才看到一份静态报告？
不少开发者会同时开启多个工具进行追踪，但最容易上手、也最适合“边加载边观察”的方案，其实只需三个工具的组合：一个Chrome扩展、一个Chrome原生事件工具，以及开发者工具中的Performance面板。它们各有侧重，搭配使用基本能全面掌握页面的性能状况。
为了回答这个问题，我先介绍第一个方法：直接、简单，适合日常巡检。
用Web Vitals扩展实时监测页面加载过程中的Core Web Vitals变化
说实话，这是目前唯一能真正实现“边加载边查看”CWV动态变化的方法。该扩展在页面渲染的整个过程中持续抓取数据，并通过工具栏图标的颜色和数值直观展示当前状态。
具体操作并不复杂：打开Chrome浏览器，访问Chrome网上应用店，搜索“Web Vitals”并添加到Chrome。安装完成后，最关键的就是观察图标变化。当你在任意网页右上角看到工具栏图标变为绿色，说明LCP、CLS、INP三项指标均在健康阈值内（LCP＜2.5s、CLS＜0.1、INP＜200ms）。如果变成黄色或红色，则表示某项指标的实测值已接近或超出标准。
点击该图标，面板中会直接显示三项指标的当前实测值、评级以及本地测量时间戳。所有数据均来自当前页面的生命周期，完全基于真实环境，而非模拟数据，可信度很高。
通过chrome://net-internals抓取原始CWV事件流
当你怀疑LCP被误判，或想定位CLS突增的根源时，这个方法最为实用。它直接读取Chrome底层网络与渲染事件日志，精度可达毫秒级。
确保目标网页位于当前活跃标签页，然后在地址栏输入chrome://net-internals/#events并回车。左侧过滤器输入loading后，右侧事件列表会实时滚动更新，出现largestContentfulPaint、layoutShift、interaction三类事件。
需要特别注意：在页面仍在加载时，largestContentfulPaint事件可能触发多次——只有最后一次的startTime才是真正的LCP，此前出现的均为预估值，切勿提前记录。对于layoutShift事件，逐条点开查看详情，找到value字段（例如0.042），然后手动累加每个value，累计总和即为当前会话的CLS值。随着页面持续渲染，该值会不断增长。
使用Performance面板录制并定位LCP/CLS关键帧
如果你真正关心的是“为什么LCP这么慢”或“哪次重排导致CLS突然飙升”，Performance面板能直接给出答案。它不仅能定位LCP发生的具体帧，还能揭示哪些资源或渲染操作拖累了性能。
第一步：打开目标网页，按F12打开开发者工具，切换到Performance标签页。第二步：勾选Network、Screenshots、Main、Rendering这几个选项，点击左上角的圆形录制按钮后立即刷新页面，等待页面完全交互就绪，再点击停止录制。
第三步：在下方的火焰图区域，用鼠标选择你要分析的时间范围，然后按Ctrl+F（Windows）或Cmd+F（macOS）调出搜索框，输入LCP，面板会自动高亮标记LCP发生的帧节点。第四步：在底部Summary面板中，展开Layout Shifts分组，查看每次布局偏移发生的具体时间、受影响的元素以及位移分数。需要重点关注的是：位移分数大于0.01的条目应优先优化——这些才是真正影响用户体验的“痛点”。
