Core Web Vitals：如何优化 LCP

通过解决 TTFB、资源发现、加载时长和渲染阻塞问题来修复较低的 LCP 评分,涵盖 CDN 缓存与图片预加载策略。

Sep 22, 2025 · 3 min read

Largest Contentful Paint (LCP) 衡量主要内容的加载速度——用户首先看到的主图、标题或视频。当加载时间超过 2.5 秒时，用户会认为您的网站很慢，跳出率会增加，Core Web Vitals 得分也会下降。本指南详细介绍了如何在加载过程的四个阶段中诊断和修复 LCP 问题。

要点总结

LCP 衡量用户交互前最大可见内容元素的渲染时间
Google 要求 75% 的页面访问需要在 2.5 秒内实现 LCP，才能获得良好的 Core Web Vitals 评分
优化涉及四个阶段：TTFB、资源发现、加载持续时间和渲染延迟
永远不要对首屏内容使用懒加载——这是最常见的 LCP 错误

什么是 Largest Contentful Paint (LCP)？

LCP 跟踪用户交互前视口中最大可见内容元素的渲染时间。这可能是 <img>、<video> 或文本块。与抽象指标不同，LCP 反映了用户的实际体验——页面何时”感觉”已加载完成。

Google 设定了明确的阈值：

良好：2.5 秒以下
需要改进：2.5-4.0 秒
较差：超过 4.0 秒

要通过 Core Web Vitals 评估，75% 的页面访问必须达到”良好”的 LCP 得分。这直接影响 SEO 排名，因为 Google 将 Core Web Vitals 作为排名信号。

LCP 优化的四个阶段

LCP 不是单一指标——它是四个不同阶段的总和。理解这种分解对于有针对性的优化至关重要：

Time to First Byte (TTFB)：服务器响应时间（约占总 LCP 的 40%）
资源加载延迟：TTFB 和 LCP 资源开始下载之间的时间（<10%）
资源加载持续时间：实际下载时间（约 40%）
元素渲染延迟：从下载完成到视觉渲染的时间（<10%）

“延迟”阶段应该接近零。任何等待时间都是纯粹的浪费。

阶段 1：优化服务器响应时间 (TTFB)

缓慢的 TTFB 会破坏其他所有优化。如果您的服务器需要 3 秒才能响应，那么实现 2.5 秒的 LCP 就变得不可能。

常见的 TTFB 问题：

多次重定向（每次增加 100-500 毫秒）
服务器距离用户太远
后端代码效率低下
数据库瓶颈

解决方案：

实施服务器端缓存
使用 CDN 从边缘位置提供内容
最小化重定向——直接使用最终 URL 格式
优化数据库查询和后端处理

专业提示：CDN 可能会掩盖服务器问题。使用 URL 参数（如 ?test=123）来绕过 CDN 缓存，揭示真实的服务器性能。

阶段 2：消除资源发现延迟

浏览器必须立即找到您的 LCP 资源。任何发现延迟都是浪费时间。

关键错误：对 LCP 图像使用懒加载。永远不要在首屏内容上使用 loading="lazy"——这会故意延迟您最重要的元素。

让资源可发现：

<!-- 好的做法：图像在 HTML 中 -->
<img fetchpriority="high" src="/hero.webp" alt="...">

<!-- 不好的做法：隐藏在 CSS 中 -->
.hero { background-image: url('/hero.webp'); }

对于 CSS 背景图像（尽可能避免将其用于 LCP），请预加载它们：

<link rel="preload" fetchpriority="high" as="image" href="/hero.webp" type="image/webp">

fetchpriority="high" 属性告诉浏览器优先处理此资源。没有它，图像通常默认以”低”优先级下载。

阶段 3：减少资源加载持续时间

文件越小，下载越快。这个阶段是纯粹的物理定律——减少字节数，减少时间。

图像优化：

使用现代格式（WebP、AVIF）
使用 srcset 实现响应式图像
在不影响可见质量的情况下压缩
正确调整图像大小——不要为移动设备加载 4K 图像

文本 LCP 的字体优化：

使用 font-display: swap 立即显示文本
将字体子集化为所需字符
预加载关键字体

CDN 考虑因素：

图像 CDN 自动优化格式和压缩
同源服务避免连接开销
在可用时使用 CDN 代理功能

阶段 4：最小化渲染阻塞

即使资源已下载，由于主线程拥塞，渲染仍可能停滞。

常见阻塞因素：

<head> 中的渲染阻塞 CSS
同步 JavaScript 执行
第三方脚本的长任务

解决方案：

内联关键 CSS：

<style>
  /* 仅首屏样式 */
  .hero { /* styles */ }
</style>

延迟非关键 JavaScript：

<script defer src="/app.js"></script>

对于被 Web 字体阻塞的基于文本的 LCP 元素，确保回退渲染：

@font-face {
  font-family: 'Custom';
  font-display: swap; /* 立即显示回退字体 */
  src: url('/font.woff2') format('woff2');
}

特殊情况：视频和背景图像

视频元素：海报图像或第一帧成为 LCP 候选。像优化任何其他图像一样优化海报图像，并确保视频编码高效。

CSS 背景图像：这些会产生固有的发现延迟。浏览器无法预加载尚未解析的内容。将关键背景图像转换为 <img> 元素，或显式预加载它们。

测量和监控 LCP

实验室数据（PageSpeed Insights、Lighthouse）有助于诊断问题，但现场数据（CrUX、RUM）显示真实的用户体验。始终优先考虑现场数据——这是 Google 用于排名的数据。

使用 Chrome DevTools 性能面板在本地查看 LCP 分解。web-vitals JavaScript 库支持自定义监控：

import {onLCP} from 'web-vitals';

onLCP(({value, entries}) => {
  console.log('LCP:', value, entries[0].element);
});

结论

优化 LCP 需要系统性地关注所有四个阶段。从 TTFB 开始——如果您的服务器很慢，任何优化都无关紧要。确保立即发现资源，最小化文件大小，并消除渲染阻塞资源。最重要的是，永远不要对您的 LCP 元素使用懒加载。有了这些优化措施，实现 2.5 秒以下的 LCP 不仅成为可能，而且是可预测的。

常见问题

为什么我的 LCP 得分在 PageSpeed Insights 和真实用户之间存在差异？

PageSpeed Insights 等实验室工具在受控条件下测试，具有特定的网络速度和设备。真实用户有不同的连接、设备和地理位置。来自 CrUX 的现场数据反映了实际的用户体验，这是 Google 用于排名的数据。

JavaScript 框架会影响 LCP 性能吗？

是的，如果 JavaScript 框架在客户端渲染内容，它们可能会延迟 LCP。浏览器必须下载、解析和执行 JavaScript 才能显示内容。服务器端渲染或静态生成可以显著改善基于框架的网站的 LCP。

除了 LCP 元素，我应该对所有图像使用懒加载吗？

通常是的。对首屏以下的图像使用懒加载可以减少初始页面重量并提高性能。只要确保永远不要对首屏内容使用懒加载，特别是您的 LCP 元素。对初始视口外的图像使用 loading=lazy。

第三方脚本如何影响 LCP？

第三方脚本可能阻塞主线程，延迟资源加载和渲染。它们也可能注入渲染阻塞资源。异步加载第三方脚本，延迟非关键脚本，并考虑使用 Web Workers 处理繁重的处理任务。

Open-source session replay

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data.

Star on GitHub12k