如何提高 Core Web Vitals？提高 Core Web Vitals 最有效的方法

今天来讲一下提高 Core Web Vitals 最有效的方法

多年来，网络社区攒下了超多网页性能优化的干货。虽说随便挑一项优化，都能让不少网站提速，但要是想把所有优化手段都用上，估计你会直接懵圈 —— 毕竟不是所有方法都适合你的网站。

要是你不是搞 Web 性能的专业选手，大概率很难判断哪招对你的网站影响最大。咱们时间精力都有限，与其瞎忙活，不如先想清楚：哪些优化手段性价比最高，能实实在在提升用户体验？

这里要跟大家说个大实话：评判优化效果，不能只看技术牛不牛，还得考虑人力和团队因素 —— 这些都会影响你能不能把优化落地。理论上，有些性能改进效果炸裂，但现实里没几个开发者有时间和资源去搞；反而有些人人都能上手的最佳实践，能带来意想不到的大提升。

今天这篇指南，就给大家分享一批 “接地气” 的 Web 性能优化方法，它们满足三个条件：实际影响最大、适配大多数网站、绝大多数开发者都能搞定。总的来说，这些就是帮你搞定 Core Web Vitals（核心网页指标）的制胜法宝。要是你刚接触网站性能优化，或者想找投资回报率最高的方法，看这篇就对了！

一、Interaction to Next Paint (INP)：互动响应速度的新标杆

作为 Core Web Vitals 家族的新成员，INP（互动到下一次绘制的时间）的优化空间还很大。不过和它被淘汰的前辈比起来，能达到 “良好” 体验阈值的网站少得可怜 —— 估计你也是第一次琢磨怎么优化互动响应能力的开发者之一。先吃透下面这几招，帮你最高效提升 INP。

1.用 yield 拆分长任务，别让主线程 “累瘫”

首先得搞懂啥是 “任务”—— 浏览器干的任何一件独立活儿，比如渲染页面、计算布局、解析代码、执行脚本，都叫任务。只要任务耗时超过 50 毫秒，就成了 “长任务”。

长任务就是个大麻烦，它会霸占浏览器的主线程，导致用户点个按钮、滑个页面，浏览器都没法及时响应。

当然，咱们肯定要尽量减少 JavaScript 的工作量，但退一步说，就算有长任务，也能通过拆分让主线程 “喘口气”。关键就是经常用 yield 让出主线程，这样浏览器就能更快处理渲染更新和用户互动了。

这里给大家安利个好用的工具 ——Scheduler API，它能通过优先级系统给任务排队。尤其是scheduler.yield()这个 API，拆分长任务的同时，还能保证不丢任务队列里的位置，用户互动的处理也不会受影响。

把长任务拆解开，浏览器就有更多精力处理那些会阻塞用户操作的关键工作。想了解更多？可以去看《优化长时间运行的任务》这篇文章。

2.砍掉没必要的 JavaScript，给代码 “瘦个身”

现在的网站，加载的 JavaScript 越来越多，而且这趋势好像还刹不住车。要是你家网站的 JS 代码太多，这些任务就会抢着占主线程，网站响应速度肯定会变慢，尤其是刚打开网页的启动阶段，影响特别明显。

不过这事儿也不是没法解决，教你三招：

• 优先用浏览器原生支持的 Web 平台功能，别再写那些重复的 JS 代码实现 —— 原生功能效率更高，还不用额外加载代码。
• 用 Chrome DevTools 里的覆盖率工具，找出脚本里没用到的代码，直接删掉！减少启动时加载的资源大小，网页解析和编译代码的时间就会变短，用户打开网页的初始体验也会更丝滑。
• 搞代码分块 —— 把初始渲染用不上、但后面会用到的代码，打包成单独的文件，这样不用一开始就加载所有代码，减轻启动压力。
• 要是用了跟踪代码管理器，记得定期优化！删掉那些没用的旧代码，减小 JS 的体积。

相关内容可以戳《移除未使用的代码》深入了解。

3.避免大规模渲染更新，别让布局 “瞎折腾”

JavaScript 执行只是影响网站响应速度的因素之一，渲染页面本身也超耗资源。要是搞大规模的渲染更新，网站对用户互动的响应速度会慢得离谱。

优化渲染不是个简单活儿，得看具体需求，但有几个通用技巧，能避免渲染任务变成 “长任务”：

• 调整 JS 代码里的 DOM 读写顺序，别搞出 “强制布局” 和 “布局抖动”—— 简单说就是别刚改完 DOM 样式，又立刻去读布局信息，这样浏览器会反复计算布局，白白浪费资源。
• 让 DOM 结构保持 “小巧”——DOM 大小和布局工作量直接挂钩，要是 DOM 太大，渲染程序更新布局时，计算量会暴增。
• 用 CSS 容器延迟渲染屏幕外的 DOM 内容 —— 这招虽然不是处处能用，但把复杂布局的区域隔离开，就能避免很多没必要的布局和渲染工作。

想知道更多细节？可以看《避免使用大型复杂布局和布局抖动》。

Browser Support：Chrome 129+；Edge 129+；Firefox 技术预览版支持；Safari 暂不支持

二、Largest Contentful Paint (LCP)：页面加载速度的关键指标

LCP（最大内容绘制时间）是开发者最难把控的 Core Web Vitals 指标 —— 根据 Chrome 用户体验报告，40% 的网站都达不到 LCP 的建议阈值，没法给用户提供良好的加载体验。Chrome 团队推荐的这几招，能帮你最有效地缩短 LCP。

1. 让 LCP 资源 “好找又优先”，别让用户等太久

先给大家甩一组来自 HTTP Archive 2025年网络年鉴的数据，看完你就知道问题出在哪了：

• 73% 的移动网页，LCP 元素都是图片；
• 分析 Chrome 真实用户数据发现，LCP 表现差的网站，75 百分位数的 LCP 时间里，只有不到 10% 用在下载 LCP 图片上；
• LCP 拉胯的网页中，75 百分位数的 LCP 图片，在客户端的加载延迟高达 1290 毫秒 —— 这都超过了快速体验预算的一半；
• 35% 的 LCP 图片网页，图片地址在初始 HTML 响应里根本找不到—— 浏览器的预加载扫描器没法及时发现这些图片，加载自然慢；
• 只有15% 的符合条件的网页，会用 fetchpriority HTML 属性给资源分配更高优先级，其实这招能轻松提升 LCP。

这些数据说明，开发者在缩短 LCP 图片的加载延迟和加载时长上，还有超大的提升空间！

想解决资源加载延迟的问题，得记住：要是网页得等 CSS 或 JS 完全加载完，才开始加载图片，那大概率没法达标 LCP 了。另外，用 fetchpriority HTML 属性调整 LCP 图片的优先级，能让它抢占更多带宽，加载更快。

如果你的 LCP 元素是图片，一定要让图片地址出现在 HTML 响应里，缩短加载延迟，这几招可以试试：

• 用带 src 或 srcset 属性的<img>标签加载图片，别用 data-src 这种需要 JS 才能渲染的非标准属性 —— 数据显示，7% 的网页会把 LCP 图片藏在 data-src 后面，加载速度肯定慢；
• 优先用服务器端渲染（SSR），别用客户端渲染（CSR）——SSR 的 HTML 源代码里包含完整的网页标记，包括图片；CSR 得先运行 JS 才能发现图片，慢一步就输了；
• 要是图片地址在外部 CSS 或 JS 文件里，就在 HTML 里用<link rel="preload">标记预加载 —— 内嵌样式引用的图片，预加载扫描器找不到，这种情况预加载就很有必要。

除了降低延迟，还要让 LCP 资源尽早加载、优先级拉满，缩短加载时长：

• 给 LCP 图片的<img>或<link rel="preload">标签加fetchpriority="high"属性，提升图片优先级，让它更快开始加载；
• 删掉 LCP 图片<img>标签里的loading="lazy"属性 —— 别让浏览器花时间判断图片是否在视口内，避免加载延迟；
• 尽量推迟非关键资源的加载 —— 把这些资源移到文档末尾，延迟加载非首屏图片或 iframe，用 JS 异步加载，给 LCP 图片腾带宽。

2. 实现即时导航，让用户 “零等待”

理想的用户体验是啥？用户点进网页，根本不用等加载 —— 这就是即时导航。前面说的 LCP 资源优化能缩短等待时间，但网络传输有物理限制，想突破上限，得换个思路：在用户开始导航前，就加载并渲染好网页。

恢复和推测是实现即时导航的两大方法：

• 恢复：用户返回或前进到之前访问过的网页，浏览器从内存缓存里快速恢复页面，和用户离开时一模一样。这就用到了往返缓存（bfcache），想启用它，得确保网页符合 bfcache 资格条件 —— 很多网站不符合，就是因为用了 no-store 缓存指令，或者加了 unload 事件监听器；
• 推测：Web 应用预测用户下一步会访问的页面，提前加载渲染，用户一点，页面直接显示。这可以用 Speculation Rules API 实现，但要注意别瞎猜 —— 猜错了会浪费服务器和客户端资源，反而影响性能。建议结合数据分析，优先预渲染用户最可能访问的页面。

Browser Support：bfcache 在 Chrome 109+、Edge 109 + 支持；Firefox、Safari 暂不支持

恢复完全渲染的页面，不仅能提升加载性能，还能提高布局稳定性，对优化 CLS 也有帮助。想了解更多 bfcache 的内容，可以看《确保网页符合 bfcache 使用条件》。

3. 用 CDN 优化 TTFB，缩短首字节响应时间

前面的即时导航能给用户顶级体验，但有时候 bfcache 和推测加载用不了 —— 比如用户通过跨源链接访问你的网站，这时候初始 HTML 文档的响应速度，就成了影响 LCP 的关键。

浏览器得等收到 HTML 响应的第一个字节，才能开始加载其他子资源，这个时间就是首字节时间（TTFB）。想减少 TTFB，最好的办法就是两点：内容离用户越近越好、内容缓存越久越好，而 CDN（内容分发网络）正好能同时做到这两点。

CDN 会把你的资源分发到全球的边缘服务器，用户访问时，不用从遥远的源服务器拉取，距离近了，速度自然快。而且 CDN 的缓存控制功能很强大，能根据网站需求调整。

但数据显示，只有 33% 的 HTML 文档请求是由 CDN 提供的—— 这意味着绝大多数网站，都错过了用 CDN 提速的机会！

给大家几个配置 CDN 的小技巧：

• 就算是短时间，也要缓存静态 HTML 文档 —— 先想清楚：你的内容需要实时更新吗？还是可以延迟几分钟？
• 试试把源服务器的动态逻辑，移到 CDN 边缘执行 —— 这是现在新型 CDN 的标配功能，能减少回源次数；
• 只要能从边缘服务器直接提供内容，就别回源 —— 就算必须回源，CDN 的优化链路也比直接访问源服务器快。

想知道更多？可以看《优化加载第一个字节所需时间》。

三、Cumulative Layout Shift (CLS)：衡量页面视觉稳定性的核心

CLS（累积布局偏移）用来衡量网页的视觉稳定性 —— 虽然很多网站的 CLS 表现不错，但仍有四分之一的网站达不到建议阈值，提升空间还很大。

1. 给所有加载内容设明确尺寸，别让页面 “乱跳”

布局偏移的元凶，就是现有内容被后加载的内容挤得挪位置。想提升 CLS，最核心的办法就是：提前给内容预留好空间。

先看一组扎心的数据：66% 的网页至少包含一张未调整尺寸的图片。要是没给图片设明确的 width 和 height 属性，或者对应的 CSS 属性，图片初始高度就是 0px—— 等图片加载出来，浏览器才知道它的尺寸，这时候页面就会 “咯噔” 一下跳起来，CLS 直接飙升。

这招操作简单、效果显著，比其他优化手段省太多事儿了！

而且不只是图片，第三方广告、嵌入视频这些后加载的内容，也是布局偏移的重灾区。这时候 CSS 的 aspect-ratio 属性就派上用场了 —— 它能给图片和非图片元素设置宽高比，就算宽度是动态的（比如自适应屏幕），浏览器也能自动算出合适的高度，避免布局乱跳。

要是你不知道动态内容的准确尺寸怎么办？没关系，设置一个合理的 min-height 也比让浏览器用默认的 0px 好 —— 这样就算内容最终会撑开容器，偏移幅度也会小很多，用户体验会好很多。

2. 适配 bfcache，白嫖布局稳定性提升

前面讲 LCP 的时候提到过 bfcache，它不仅能提升加载速度，还能完全消除布局偏移—— 数据显示，2022 年 bfcache 的引入，是当年 CLS 改善幅度最大的因素！

可惜的是，大量网站都不符合 bfcache 的使用条件，白白错过了这个免费的性能提升机会。除非你的网页加载了敏感信息，不适合从内存恢复，否则一定要让网页适配 bfcache。

怎么检查网页是否符合条件？Chrome 开发者工具里有专门的 bfcache 测试工具，也可以用 Not Restored Reasons API，找出不符合的原因。相关内容可以看《往返缓存》。

3. 别给布局属性加动画，避免不必要的偏移

还有一个常见的布局偏移原因，就是元素动画 —— 比如从顶部滑下来的 Cookie 横幅、弹窗通知，这些元素很容易把其他内容挤走，导致 CLS 飙升。就算不挤其他内容，动画本身也可能影响 CLS。

HTTP 归档数据显示了一个很有意思的规律：给可能影响布局的 CSS 属性加动画的网页，CLS 达到 “良好” 的概率，比整体网页低 15%。更夸张的是，在 CLS 表现差的网页里，用 margin 或 border 宽度做动画的网页占比，几乎是整体网页的两倍！

这其实不难理解 —— 只要你对会触发布局计算的 CSS 属性做过渡或动画，就会导致布局偏移。而且如果这些偏移不是在用户互动后的 500 毫秒内发生的，就会被算进 CLS 里。

这里给大家划个重点：就算元素不在正常文档流里（比如绝对定位），给 top 或 left 属性做动画，也会导致布局偏移；但如果用transform:translateX或transform:translateY做动画，就不会让浏览器重新计算布局，自然也就不会有偏移了。

优先用浏览器合成线程处理的 CSS 属性做动画，是性能优化的老规矩了 —— 这样能把工作从主线程转移到 GPU，不仅能提升动画流畅度，还能帮你优化 CLS。

总的来说，除非是响应用户点击或按键操作（注意：hover 不算），否则别给会触发布局的 CSS 属性加动画或过渡，尽量用 transform 属性实现动画效果。要是你的网页用了性能差的 CSS 属性做动画，Lighthouse 会发出 “避免使用未合成的动画” 的警告。

总结

提升网页性能看着复杂，毕竟网上的优化攻略一搜一大把。但只要你聚焦这篇指南里的高性价比方法，就能少走弯路，精准提升 Core Web Vitals 三大指标。

从拆分 INP 长任务，到优化 LCP 资源优先级，再到给 CLS 预留内容空间，这些方法都是经过实践验证的 “刚需” 技巧，适配大多数网站，而且绝大多数开发者都能独立完成。

与其在海量优化技巧里挑花眼，不如先把这些基础招数学扎实 —— 毕竟，能落地的优化，才是真的优化！