配了三年性能优化，你猜 Lighthouse 分数挺好——今天 Chrome 新版 Performance 面板把真实用户数据和这件事彻底接上了

你测的分数挺好，用户说卡还是卡。这两件事之间隔着一道缝，裂了三年。

传统的性能调试流程是这样的：打开 DevTools，切到 Performance 面板，点录制，操作几秒后停止，然后面对一张密密麻麻的火焰图开始猜瓶颈。或者更”科学”一点——装一个 Web Vitals 扩展，跑一遍 Lighthouse，拿个 94 分，心满意足。结果用户反馈”首页好慢”，你再打开 Lighthouse，分数还是 94，气得想砸键盘。

这道缝的根因很简单：你测的是实验室数据，用户用的是真实环境。你在顶配 MacBook 的无痕标签里跑 Lighthouse，人家在五年前的 Android 机、地铁里的慢 4G、开着 150 个其他标签页的状态下用你的页面。这两个场景的 performance 数据根本不是一个宇宙的。

Chrome 129 的 Performance 面板把这件事彻底接上了。

实时 Core Web Vitals，不用录

新版 Performance 面板在打开的瞬间就开始抓 LCP、CLS、INP 三项核心指标的本地数值，不用点录制，不用等加载完成，直接看。你在页面上操作，INP 值实时更新；页面渲染，LCP 和 CLS 立即出数字。

这替代了 Web Vitals 扩展的功能——Google 已经宣布将在 2025 年 1 月 7 日停用 Web Vitals 扩展，Performance 面板就是这个扩展的官方继承者。

光有本地数字还不够。你需要知道真实用户看到的是什么。

CrUX 字段数据直接叠进来

Performance 面板现在支持接入 Chrome User Experience Report（CrUX），把你本地测试的 Core Web Vitals 数据和真实用户的 75 百分位数值并排对比。

配置很简单：在 Performance 面板的 Field data 区域填入生产环境 URL，面板会自动拉取该 URL 在真实用户群里的 LCP 和 CLS 分布。如果你填的是 localhost 地址，还能配置本地环境到生产环境的映射，面板会自动拉取对应生产页面的 CrUX 数据。

这个功能的价值在于：你在本地测的 LCP 是 1.2 秒，看起来还行；但真实用户的 75 百分位可能是 3.8 秒。这个落差不是你的代码变了，是网络、设备、并发量的差异。你现在不用靠猜了。

LCP 四阶段拆解：慢在哪一截，这次说清楚了

知道 LCP 慢还不够，还得知道慢在哪一截。

Chrome Performance 面板的 LCP by phase 功能把 LCP 时间拆成四个子阶段：

• Time to First Byte（TTFB）：浏览器收到服务器第一个字节的时间，受服务器响应速度和网络 RTT 影响
• Resource Load Delay：资源开始加载前到真正开始加载的等待时间，典型原因是 render-blocking 资源排队
• Resource Load Duration：资源本身加载耗时，图片/CDN/压缩质量相关
• Element Render Delay：资源加载完成到元素渲染到屏幕的最后一段，通常受主线程阻塞影响

点击 Insights 侧边栏里的 “LCP by phase”，每个子阶段的时间会在时间线上高亮，点击任意一段，面板自动 zoom 到对应区域。以前你得对照 Network 面板和 Main 面板的时间戳自己算，现在浏览器替你做了这件事。

配合 LCP request discovery 功能，面板还能标注”这张图片本应该在什么时间点加载”，重叠在时间线上，直接显示优化空间有多大。

第三方脚本的账这次也算清楚了

性能问题很大一块来源是第三方脚本——Analytics、A/B 测试、广告 SDK、聊天组件。你知道它们慢，但不知道慢在哪。

Performance 面板的 Third parties 洞察按第一方/第三方实体分类 CPU 消耗和网络请求，每个实体的耗时用可视化方式呈现，hover 上去直接在时间线上高亮对应事件。这个功能配合 “Dim 3rd parties” 过滤选项一起用，你可以在时间线上只显示自己代码的 activity，第三方的影响一目了然。

Insights 侧边栏：Lighthouse 的建议直接进了 Performance 面板

Chrome 131 开始，Performance 面板新增了 Insights 侧边栏，把 Lighthouse 风格的自动分析建议直接集成进性能时间线。面板会识别问题类型，给出修复建议，hover 到某条建议上，时间线自动 zoom 到相关事件位置。

这个设计的核心价值在于：以前你在 Lighthouse 报告和 Performance 面板之间来回切换，两边的上下文是断开的。现在建议和时间线在同一个视图里，你看到”渲染被某个 render-blocking 资源阻塞”，时间线同时高亮了这个阻塞点的精确位置和相关事件序列。根因定位的效率完全不是一个量级。

Insights 覆盖的范围包括 LCP 四阶段分析、INP 分阶段分析、DOM 体积评估、第三方资源分类、字体显示优化建议、图片交付优化建议、网络依赖链分析。对于大多数前端团队来说，这个侧边栏已经能覆盖 80% 的常见性能问题。

Lighthouse 和 Performance 面板：什么时候用哪个

这俩工具不是替代关系，是分工关系。

Lighthouse 跑的是受控的实验室环境——固定的设备型号、固定的网速、干净的无痕浏览器上下文。它适合：CI/CD 流水线里的自动化性能回归、首次做性能优化时的全面审计、没有真实用户数据时的基准参考。跑一下拿个分数，团队能对整体质量有个共同认知。

Performance 面板跑的是你当前的真实环境——本地 DevTools 的 CPU 节流、网络节流配置，或者是真实用户的 CrUX 数据。它适合：用户投诉”某页面慢”时的现场调试、需要定位 LCP/INP 根因时的深度分析、需要完整主线程活动时间线时的全量排查。Performance 面板不会给你一个分数，它给你一整条时间线和一整套分析工具。

实操中建议这样用：每天晨会打开 Performance 面板看一眼当天的真实用户 CrUX 数据有没有异常；CI/CD 流水线里跑 Lighthouse 做自动化卡点；用户投诉来了再切到 Performance 面板做根因分析。三件事配合着来，视野是完整的。

你的下一步

如果你的团队现在还在靠”装了 Web Vitals 扩展、跑 Lighthouse、看分数”这套流程做性能优化，今天就可以升级一下：打开 Chrome DevTools → Performance 面板 → 配置 CrUX Field data 指向你的生产域名 → 观察本地数据和真实用户数据的落差。这个落差，就是你接下来优化投入的方向。Chrome 155 已经把工具准备好了，你只需要开始用它。