CWV全绿实战：用pstack诊断LCP、INP、CLS优化

在 Web 性能优化里，“CWV 全绿”是不少团队的目标，但真正做起来却很容易陷入一个尴尬局面：本地用 Lighthouse 跑分很好，线上真实用户指标依然飘红。CWV 是 Core Web Vitals 的缩写，它衡量的是真实用户访问页面时感受到的加载速度、交互响应和视觉稳定性。要想让这些指标稳定达到绿色区间，不是靠一两个优化技巧，而是要把指标拆解到资源、渲染、交互和网络链路里逐层排查。pstack 这类免费诊断工具的价值，正是把指标从“得分”变成“问题清单”，让优化不再靠猜。

这篇文章会沿着一条完整链路展开：先讲清 CWV 的测量口径，再说明如何搭建可信的测量环境，然后借助 pstack 定位问题，分别处理 LCP、INP、CLS 三块优化点，最后给出验证方法和持续维护机制。适合负责前端性能、需要给管理层产出优化结果的同学，也适合想系统掌握 Web Vitals 的开发者。

1. 搞清 CWV 为什么难全绿，才能理解 pstack 要解决什么问题

1.1 Core Web Vitals 是用户体验指标，不是跑分指标

很多团队对性能优化的理解还停留在“页面加载要快”这个模糊概念上。Core Web Vitals 把体验拆成三个可量化、可监控的维度：加载体验、交互体验、视觉稳定性。分别对应 LCP、INP、CLS 三个指标。

这三个指标不是实验室里跑出来的理论值，而是从真实用户浏览器上采集的数据。也就是说，用户手机性能差、网络慢、内存不足，这些都会反映到 CWV 数据里。pstack 这类工具在定位问题时，也会优先关注真实用户数据分布，而不是只看模拟环境下的跑分。

1.2 LCP、INP、CLS 的测量口径与阈值

CWV 三个指标各有明确测量边界，优化前必须先把阈值和口径记清楚。

LCP 曾经被很多人简单理解成“首屏加载时间”，这是不对的。LCP 只关注最大内容元素何时渲染完成，如果首屏有一张大图，LCP 就看这张图何时加载并绘制完成。INP 是 2024 年正式替代 FID 的指标，FID 只测量用户首次交互的输入延迟，INP 则统计整个页面生命周期内所有交互，取最差值，所以它更真实。CLS 则是一个计算分数，单位不是毫秒，而是偏移距离和影响面积的乘积累计。

1.3 为什么实验室数据全绿，线上数据仍然飘红

很多团队在优化时先打开 Lighthouse，发现分数接近满分，就认为 CWV 已经全绿。上线后发现 CrUX 数据依然不好看，问题通常出在三个维度：

第一，Lighthouse 跑分用的是固定模拟环境，网络、CPU、设备都相对理想。真实用户用的手机可能是中低端机型，CPU 降频、网络抖动都会让指标明显变差。

第二，实验室数据只覆盖一个页面加载过程，真实用户会在页面上停留、点击、滚动，这些交互都会影响 INP 和 CLS。实验室页面加载完就结束采集，反馈不了交互阶段的问题。

第三，统计口径不同。实验室看到的是中位数或平均值，CrUX 看到的通常是 P75 分位。p75 意味着有 25% 的用户体验比这个值更差，优化时要按高百分位数据做判断，不能只盯着平均值。

所以，让 CWV 全绿的前提是先建立一套可信的数据采集体系，知道用户真实端上发生了什么。否则优化方向容易跑偏。

2. 优化之前先搭好测量环境，数据可信才能谈全绿

2.1 学习环境用哪些采集方式最方便

在本地开发环境，建议三种方式配合使用：

• Chrome DevTools 的 Performance 面板，可以录制页面加载和交互过程，看主线程任务、长任务、布局和绘制耗时。
• Lighthouse 面板，跑一次快速审计，拿到 LCP、CLS、TBT 等指标和优化建议。
• web-vitals 库，在页面里输出实时指标，适合在开发环境直接观察。

web-vitals 库的接入方式非常简单，在页面中动态引入后调用即可：

import { onLCP, onINP, onCLS } from 'web-vitals'; onLCP((metric) => { console.log('LCP:', metric.value, metric.rating); }); onINP((metric) => { console.log('INP:', metric.value, metric.rating); }); onCLS((metric) => { console.log('CLS:', metric.value, metric.rating); });

代码块里的三个监听函数分别绑定到三个指标。metric.value 是实际测量值，单位分别是毫秒、毫秒和分数，metric.rating 会给出 good、needs-improvement、poor 三个评级。开发环境建议保留这份日志，改动代码后可以直接在控制台看到指标波动。

学习环境不需要把数据上报到远端，只要能在本地量化每一次优化的效果即可。

2.2 生产环境要采集真实用户数据

生产环境不能依赖开发者的本机和模拟网络。推荐的做法是使用 PerformanceObserver 采集 RUM 数据，或者直接上报到 CrUX 等平台服务。

web-vitals 库底层就是基于 PerformanceObserver 实现的，生产环境可以只保留必要字段，把指标值、页面路径、设备类型、网络类型等信息打包发送到后端，或者接入现有监控平台。这里给出一个精简的采集片段：

import { onLCP, onINP, onCLS } from 'web-vitals'; function reportMetric(metric) { const body = { name: metric.name, value: metric.value, rating: metric.rating, path: location.pathname, device: navigator.userAgentData ? navigator.userAgentData.mobile ? 'mobile' : 'desktop' : 'unknown', effectiveType: navigator.connection ? navigator.connection.effectiveType : 'unknown', }; if (navigator.sendBeacon) { navigator.sendBeacon('/api/perf', new Blob([JSON.stringify(body)], { type: 'application/json', })); } else { fetch('/api/perf', { method: 'POST', body: JSON.stringify(body), keepalive: true, }); } } onLCP(reportMetric); onINP(reportMetric); onCLS(reportMetric);

这里使用 sendBeacon 而不是普通 fetch，是因为页面关闭或跳转时，sendBeacon 的发送成功率更高。生产环境不要只在 window.onload 时上传一次，INP 指标需要在页面生命周期内持续采集，用户任何一次交互都可能刷新最差值。

2.3 用一份基线报告确认问题指标

拿到原始数据后，先别急着改代码。要按页面、设备、网络类型汇总出一份基线报告，确认当前最严重的问题指标和主要用户场景。

一份基线报告至少包含：

• 每个核心页面的 LCP、INP、CLS 的 P75 值。
• 移动端和桌面端的数据拆分。
• 4G、3G、Wi-Fi 等不同网络类型的分布。
• 问题最严重的 Top 5 页面。

pstack 在生成报告时，也会按类似结构输出问题定位结果。基线报告的核心作用不是展示现状，而是给优化提供对比基准。没有基线，后面所有“优化成功”都缺少依据。

3. 借助 pstack 免费工具定位 CWV 优化点

3.1 pstack 在优化链路里的定位

pstack 作为免费工具，在 CWV 优化链路里主要承担诊断和分析的角色。它不直接替开发者改代码，而是把采集到的性能数据和页面资源信息做交叉分析，输出类似“LCP 受单张 1.2MB 图片影响”“INP 最慢交互来自某个点击事件处理器”这样的结论。

工具的价值在于节省人工排错时间。一个真实页面的资源可能有上百个请求，主线程任务可能持续几百毫秒，如果只看 Performance 面板，定位问题非常耗时。pstack 的定位思路是先找到绩效最差的指标，再把指标关联到具体资源或代码路径上。

3.2 用诊断报告把指标拆到资源层面

一次典型的 CWV 诊断，输出结果大致可以按下面结构理解：

{ "page": "/product/detail", "metric": "LCP", "valueMs": 3800, "mainContributors": [ { "resource": "https://cdn.example.com/images/sku-1001.jpg", "resourceSizeKB": 1240, "loadDelayMs": 1200, "recommendation": "compress-image-or-use-avif", "priority": "high" } ], "secondaryContributors": [ { "resource": "/api/product/detail", "ttfbMs": 900, "recommendation": "optimize-server-response" } ] }

这个结构反映的是指标到资源的映射。LCP 指标值 3800 毫秒，其中最大单图延迟贡献了 1200 毫秒，接口 TTFB 又是另一个贡献点。开发者拿到报告后，能直接对某个资源做处理，而不是盲目地压缩所有图片。

使用 pstack 这类工具时，要把它当成辅助判断，不要完全替代人工分析。工具的推荐项只是基于通用规则，具体项目中还需要结合业务判断优先级。

3.3 按成本收益排序优化项

诊断报告会列出多个优化点，但不可能一次全部做完。建议按三个维度排序：

推荐先从“影响面大、成本低、风险小”的优化项开始。比如给 LCP 图片加 preload、压缩首屏图片、给关键接口加缓存，这些改动小，但能快速看到指标改善。等构建出完整的优化节奏后，再处理长任务拆分这类涉及代码结构的改动。

4. LCP、INP、CLS 三条优化路线的落地做法

4.1 LCP 优化：资源加载顺序比压缩更难控制

LCP 过快，只靠压缩图片远远不够。要让最大内容元素尽快出现在屏幕上，要同时关注资源能不能早发现、要不要优先加载、服务器响应是否够快。

给 LCP 图片添加 preload 是性价比很高的操作。浏览器在解析 HTML 时，遇到 preload 会提前开始加载该资源，而不是等解析到 标签时才发起请求。

<link rel="preload" as="image" href="https://cdn.example.com/images/sku-1001.jpg" fetchpriority="high" /> <img src="https://cdn.example.com/images/sku-1001.jpg" alt="商品主图" />

这里要注意两点。第一，preload 只推荐给首屏真正会加载的资源，如果 preload 的资源最终没有被使用，反而会浪费带宽。第二，fetchpriority="high" 是给浏览器一个加载优先级提示，不代表浏览器一定会按这个顺序加载，最终仍然由浏览器根据资源类型和位置决策。

LCP 图片的服务端响应也要检查。如果图片托管在 CDN 上，要确认 CDN 边缘节点是否命中缓存，回源耗时是否过高。常见的处理方式是让图片服务支持 WebP、AVIF 等现代格式，并按设备宽度输出对应尺寸。同样的图片，输出 750px 宽和输出 1600px 宽，体积差距可能在一倍以上。

4.2 INP 优化：交互延迟要追到事件处理和渲染阻塞

INP 测量的是从用户发起交互，到浏览器完成下一帧绘制的时间。这个时间主要由事件处理函数、布局计算、绘制和合成构成。优化 INP 不能只看宏观代码，要落到具体交互的调用链上。

第一步是拆长任务。主线程上超过 50 毫秒的任务会被浏览器标记为长任务，长任务会阻塞用户交互。常见的拆法是使用 setTimeout 或 scheduler.postTask 把大任务分段执行。

function processLargeList(items) { let index = 0; function processNextBatch() { const batch = items.slice(index, index + 50); renderBatch(batch); index += 50; if (index < items.length) { setTimeout(processNextBatch, 0); } } processNextBatch(); }

这段代码把一个大列表的渲染拆成多个小批次，每一批只处理 50 条数据，处理完后让出主线程，避免一次性占用过长时间。实际项目里批次的条数需要根据数据量测试，目标是让每个批次的执行时长控制在 16 到 50 毫秒之间。

第二步是检查事件处理函数里是否有同步请求、复杂计算或触发强制同步布局的代码。比如在 scroll 事件或 click 事件里读取 offsetTop、offsetHeight 等布局属性，会导致浏览器在事件处理过程中进行同步布局，显著增加交互延迟。

第三步是关注动态导入和脚本加载。如果某个点击交互时才加载一个很大的 JS 文件，用户会感觉到明显的卡顿。可以把初始化逻辑提前预加载，或者把交互时延敏感的逻辑拆分到独立模块。

4.3 CLS 优化：尺寸占位与偏移控制

CLS 超标的常见来源有三个：图片和视频没有预留尺寸、字体加载导致文本重排、动态插入内容把已有内容挤开。

图片和视频是首屏最常见的偏移来源。在 HTML 里给媒体元素设置 width 和 height 属性，浏览器在图片加载完成前就能计算出正确占位空间，从而减少布局偏移。

<img src="https://cdn.example.com/images/banner.jpg" alt="活动横幅" width="750" height="400" style="width: 100%; height: auto;" />

这里给 img 设置了固定的 width 和 height 属性，同时用 CSS 把宽度设为 100%、高度自适应。浏览器的机制是：有 width 和 height 属性时，加载前就能按比例算出占位高度；CSS 设置 width: 100% 后，实际渲染宽度随容器变化，高度按比例自动调整，不会出现加载后突然变高或变矮。

字体加载导致的偏移也需要处理。使用 font-display: swap 可以让文本先用后备字体显示，等自定义字体加载完成后再切换，避免长时间空白。但 swap 也会带来字体重换时的偏移，所以更好的做法是同时设置合适的 fallback 字体尺寸指标，尽量让后备字体和自定义字体的行高接近。

@font-face { font-family: 'CustomFont'; src: url('/fonts/custom.woff2') format('woff2'); font-display: swap; size-adjust: 100%; }

size-adjust 属性可以调整字体度量，减少字体切换时的布局变化。不过它能解决的问题有限，如果页面中大量使用自定义字体，还是要把字体文件压缩并尽早加载。

动态插入内容时，推荐在容器上预留固定空间，或者把广告位、弹窗、券码等元素放在页面底部，避免把首屏内容向下挤。

5. 优化完怎么验证是真的全绿

5.1 同条件对比是验证的第一步

性能优化最容易出现的错误是“换了设备跑一次，分数变好了，就认为成功”。做前后对比时，必须保证测量条件一致，否则数据之间的差异无法归因。

建议控制以下变量：

• 使用同一台测试设备、同一个浏览器版本。
• 使用同样的网络节流配置。
• 使用同一组页面路径和交互步骤。
• 在同一时间段内重复跑 3 到 5 次，取中位数或 P75。

在本地验证时，可以在 Chrome DevTools 的 Network 面板里打开网络节流，并在 Performance 面板里设置 CPU 降速倍数。推荐用 4x CPU 降速模拟中端手机环境。

5.2 用 pstack 或开发工具导出前后对比

对比时可以沿用 pstack 诊断报告里的结构，记录前后两次的关键指标和主要贡献者差异。一次优化前后对比表可以这样设计：

对比表的价值是让优化效果可追溯。某个指标变好了，能对应到具体动作；某个指标回退了，也能快速定位是哪次改动引入的。

5.3 线上验证要避免把个例当趋势

本地验证通过后，线上数据没有那么快全绿。CrUX 数据是 28 天滚动窗口，优化发布后，新数据会逐步进入窗口，旧数据会慢慢滑出，通常需要 1 到 4 周才能看到明显变化。不要因为发布后两三天数据没变就质疑优化结果。

线上验证阶段建议做灰度发布。先让一部分用户访问优化后的页面，对比这部分的 RUM 数据和未优化用户的差异。如果效果稳定，再全量发布。如果发现问题，可以快速回滚，影响面可控。

5.4 监控与告警机制要同步上线

线上验证不是终点。CWV 本身会随业务迭代回退，某次新增一个首屏大图，或者某个接口变慢，都可能导致指标重新飘红。建议在监控平台里设置性能告警规则：

• LCP P75 超过 2.5 秒时告警。
• INP P75 超过 200 毫秒时告警。
• CLS P75 超过 0.1 时告警。

告警粒度按页面和入口拆分。全站平均指标容易掩盖单个页面的严重问题。比较好的方式是每个关键页面单独配置阈值，并且允许按版本、按灰度组筛选数据。

6. 常见误区和坑，直接影响 CWV 能否全绿

6.1 只优化 LCP，忽略 INP 和 CLS 的联动关系

CWV 是三个指标一起评级的。某个页面内容加载得非常快，但页面滚动或点击时频繁卡顿，INP 就会超标；图片加载完突然把按钮挤下去，CLS 也会超标。优化时建议三条线并行推进，而不是单独攻关一个指标。

6.2 preload 用太多，反而拖慢首屏

preload 是作用于当前页面的高优先级加载指令，不是预取所有资源的工具。一次性 preload 十几张图片或字体，会导致浏览器把有限带宽分配给非关键资源，真正影响 LCP 的资源反而加载变慢。preload 只推荐加在 LCP 候选元素上，一般不超过 3 个资源。

6.3 INP 优化时只查首屏脚本

INP 覆盖整个页面生命周期。很多交互卡顿发生在用户滚动到页面底部、点击某个组件、打开弹窗之后，这些交互对应的脚本可能在首屏加载后才执行。排查 INP 时要把页面上所有可交互元素列出来，逐个录制交互性能，而不是只看首屏加速。

6.4 忽略第三方脚本对性能的影响

统计脚本、客服系统、广告 SDK、埋点脚本都可能成为性能杀手。一个 100KB 的第三方脚本，直接加载时会阻塞主线程；不同的第三方脚本之间还可能互相竞争网络资源。建议给第三方脚本统一走异步加载，并监控它们引入后的指标变化。如果某个 SDK 显著拖慢性能，可以考虑延迟加载或更换方案。

6.5 CLS 只看零，忽略偏移场景

CLS 是累积指标，一个页面的 CLS 可能在用户停留期间逐渐增加。测试时只刷新页面看首屏的 CLS，会漏掉滚动加载、底部表单、图片懒加载等场景。验证时要模拟真实用户的浏览路径和滚动行为。

下面用表格把常见坑和检查要点汇总：

7. 最佳实践：把“全绿”变成可维护的常态

7.1 发布前性能检查清单

每次发布前，把性能检查放进发布流程，而不是等线上变慢再排查。检查清单不需要覆盖所有细节，但至少要包含以下项目：

• 页面是否有新增的首屏大图或大体积脚本，是否有替代压缩方案。
• HTML 中是否有新增 preload 资源，是否真的会被首屏使用。
• 新增组件是否在可交互后立即加载了非必要 JS。
• 所有图片、视频是否设置了尺寸占位。
• 是否新增了第三方脚本，是否能异步加载。
• 发布后的灰度数据中，LCP、INP、CLS 是否保持在绿色区间。

维护这份清单的成本很低，但对防止性能退化很有效。每次发布都跑一遍，能避免大多数因为“业务需求优先”导致的性能回退。

7.2 设置性能预算并在 CI 中拦截

性能指标一旦进入绿色区间，就要防止再次变红。性能预算是一个可执行的拦截机制，在构建或者 MR 阶段检查资源体积和脚本包大小，超过预算则阻止合并。

可以先把预算设置成宽松值，比如主包体积不超过 300KB gzip、关键路径请求不超过 40 个，等团队适应后再逐步收紧。性能预算不是为了限制业务，而是让引入新功能时主动思考体积成本。

7.3 建立 CWV 问题响应流程

线上指标飘红后，处理节奏应该是：

1. 先确认影响范围：哪些页面、哪些设备、哪些地区。
2. 再定位贡献因素：是资源变大、接口变慢，还是新的逻辑阻塞主线程。
3. 再做最小的针对性优化，避免大范围重构引入新问题。
4. 最后回看灰度数据，确认指标回落后再全量发布。

整个流程需要前端、后端和基础设施团队共同参与。前端能解决资源加载和渲染逻辑，但接口慢、CDN 命中率低、DNS 解析慢等问题可能在后端。CWV 全绿是一个系统性的协同结果，不能只靠开发者在浏览器面板里跑分。

7.4 对新手最有价值的练习路径

如果刚开始接触 CWV 优化，先不要追求三个指标同时全绿。按下面的顺序练习：

1. 用 PageSpeed Insights 或 Chrome DevTools 跑一个真实页面的性能报告，读懂每个指标的口径。
2. 给自己常用的页面加一个 web-vitals 上报，在本地观察指标变化。
3. 选定一个 LCP 超标的页面，只做资源加载顺序优化，记录前后数据。
4. 再选定一个 INP 超标的交互，录制点击链路，拆解长任务。
5. 最后处理 CLS，给所有媒体元素补尺寸占位。

每一步都只改一个变量，记录数据变化，这样才能积累出可复用的优化判断力。等这套方法跑熟了，再引入 pstack 这类免费诊断工具，把效率进一步提升。

随着时间推移，CWV 的测量口径和浏览器行为还会变化。保持指标监控不断线，就能在浏览器版本、业务代码、用户设备变化的长期拉锯里，持续保住绿色区间。核心思路仍然是一致的：先量化，再定位，然后做针对性修复。pstack 是在这条链路上帮你快速定位问题的工具，而真正让指标全绿的，是团队里每个发布都按性能意识执行的人。