Improving Core Web Vitals in Practice — How I Cut LCP from 3s to 1.2s

USD/JPY分散は、為替急変局面で一方通貨の過大シェアを防ぎ、月次の再バランスと上限規則で感情的な一括投資を抑える実践設計です。

title_zh

Core Web Vitals 实战优化 — 我如何将 LCP 从 3 秒缩短到 1.2 秒

description_zh

LCP（最大内容绘制）直接影响 Google 搜索排名。通过依次应用图片优化、字体加载策略和代码分割，将 LCP 从 3.0 秒缩短至 1.2 秒，CLS 也从 0.28 降至 0.04。

content_md_zh

markdown

> **核心摘要**
>
> - LCP（最大内容绘制）是直接影响 Google 搜索排名的核心指标。
> - 通过依次应用图片优化、字体加载策略和代码分割，LCP 从 3.0 秒缩短至 1.2 秒。
> - 通过为图片和广告区域指定明确尺寸并消除布局偏移，CLS 从 0.28 改善至 0.04。
> - 基于实际生产中的 Next.js 项目——相同的原则也适用于 React 和 Vue 项目。

---

## 引言——为什么要关注 Core Web Vitals？

![monitor screengrab seo analytics seo analytics](https://images.unsplash.com/photo-1560472354-b33ff0c44a43?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3w5MDU5NzN8MHwxfHNlYXJjaHwxfHxzZW8lMjBhbmFseXRpY3N8ZW58MXwwfHx8MTc3OTI2MzgxMnww&ixlib=rb-4.1.0&q=80&w=1080)


当 Google 在 2021 年推出 Page Experience 更新时，Core Web Vitals 已经超越了简单的 UX 指标，成为 SEO 排名因素。从那时起，Google 持续提升这些信号的权重，截至 2024 年，INP（下一次绘制交互）已完全取代 FID 成为评估指标。

六个月前，我运营的一个电商项目在 PageSpeed Insights 移动端得分仅为惨淡的 38 分。LCP 为 3.0 秒，CLS 为 0.28，INP 为 320ms——所有三个指标都处于"需要改进"区域。本文记录了将这些数字扭转过来的整个过程。

---

## 如何快速理解三大 Core Web Vitals？

![computer screen bunch data on it](https://images.unsplash.com/photo-1686061594225-3e92c0cd51b0?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3w5MDU5NzN8MHwxfHNlYXJjaHwyfHxzZW8lMjBhbmFseXRpY3N8ZW58MXwwfHx8MTc3OTI2MzgxMnww&ixlib=rb-4.1.0&q=80&w=1080)


### LCP — 页面的"第一印象"速度

LCP 衡量视口中最大内容元素（通常是英雄图片或 H1 文本）的渲染时间。Google 的良好阈值是**2.5 秒或以下**；超过 4.0 秒则属于差。

在电商网站上，英雄横幅图片绝大多数情况下是 LCP 候选元素。如果这一张图片加载过慢，其他所有优化都将变得毫无意义。

### CLS — 布局是否会"跳动"？

CLS（累积布局偏移）衡量页面加载期间元素意外偏移的程度。延迟加载的广告横幅或没有明确尺寸的图片会导致 CLS 飙升。**0.1 或以下**是良好阈值。

### INP — 页面对用户输入的响应速度有多快？

INP 衡量所有交互（点击、轻触、键盘输入）的响应延迟。它在 2024 年 3 月取代了 FID，**200ms 或以下**是良好阈值。沉重的 JavaScript 包会阻塞主线程并恶化 INP。

---

## 诊断问题——初始测量

![close up computer screen blurry background](https://images.unsplash.com/photo-1686061593269-420785fb8fa0?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3w5MDU5NzN8MHwxfHNlYXJjaHwzfHxzZW8lMjBhbmFseXRpY3N8ZW58MXwwfHx8MTc3OTI2MzgxMnww&ixlib=rb-4.1.0&q=80&w=1080)


在优化之前准确记录指标是起点。按顺序使用了以下工具：

1. **PageSpeed Insights** — 同时提供现场数据（真实用户数据）和实验室数据（Lighthouse）
2. **Chrome DevTools > Performance 标签** — 检查渲染时间线和 LCP 候选元素
3. **WebPageTest** — 从 CDN 边缘服务器进行真实测量，通过胶片视图进行可视化确认
4. **Vercel Analytics / Sentry** — 从真实用户会话收集的 Core Web Vitals

诊断将瓶颈缩小到三个领域：

- **英雄图片** — 4.2MB JPEG，通过 `<img>` 标签直接插入，未做任何优化
- **Google Fonts** — 通过 `@import` 同步加载 3 种字体家族
- **包大小** — 1.8MB 主块，包含多个未做摇树优化的库

---

## 将 LCP 从 3.0 秒缩短到 1.2 秒的三种方法是什么？

### 方法 1 — 图片优化与预加载

这是影响最大的一步。英雄图片的处理完全重新设计。

**优化前**


**优化后 — Next.js Image 组件 + WebP 转换**

import Image from 'next/image';


仅添加 `priority` 属性就会让 Next.js 自动为图片注入 `<link rel="preload">` 标签。转换为 WebP 后，文件大小从 4.2MB 降至 340KB——大约减少 92%。

对于纯 HTML/React 项目，在 `<head>` 中直接添加预加载标签：


这一项变更将 LCP 从 3.0 秒降到 1.8 秒。

### 方法 2 — 字体加载策略

通过 `@import` 加载 Google Fonts 会让浏览器暂停 CSS 解析并发起字体请求。这一等待时间显著增加 LCP。

**优化前**


**优化后 — `<link rel="preconnect">` + `display=swap` + 自托管**


使用 `media="print"` 然后在加载时切换为 `media="all"`，可以让字体 CSS 异步加载而不阻塞渲染。`display=swap` 会在 Web 字体加载时立即显示后备字体，保持文本可见。

为了获得最高性能，自托管字体可以完全消除 Google Fonts 的往返延迟：

@font-face { font-family: 'Inter'; font-style: normal; font-weight: 400; font-display: swap; src: url('/fonts/inter-regular.woff2') format('woff2'); }


这一步骤将 LCP 从 1.8 秒降到 1.4 秒。

### 方法 3 — 代码分割与包优化

1.8MB 的主块意味着用户必须下载并解析近 2MB 的 JavaScript，页面才能变得可交互。

**采取的关键行动：**

1. **动态导入** — 沉重的库仅在需要时加载：

// 优化前：始终加载 import Chart from 'chart.js';

// 优化后：仅在实际渲染图表组件时加载 const Chart = dynamic(() => import('chart.js'), { ssr: false });


2. **摇树审计** — 将 `import _ from 'lodash'` 替换为单个函数导入：

// 优化前：加载整个 lodash 库 import _ from 'lodash';

// 优化后：仅加载 debounce import debounce from 'lodash/debounce';


3. **第三方脚本延迟加载** — 分析和聊天部件脚本延迟到页面可交互后加载：


经过包优化，主块大小从 1.8MB 降至 620KB，LCP 从 1.4 秒改善至 **1.2 秒**。

---

## CLS 是如何从 0.28 降至 0.04 的？

CLS 两个最大的元凶是广告和没有明确尺寸的图片。

### 广告区域：提前预留空间

/ 预留最小高度，使广告槽永远不会引起布局偏移 / .ad-container { min-height: 90px; / 横幅广告 / min-width: 728px; }


### 图片：始终指定宽度/高度

/ 优化前：无尺寸 → 加载期间引起布局偏移 / Product

/ 优化后：明确尺寸 → 浏览器预留空间 / Product


### 动态内容：使用占位符

// 数据加载期间显示骨架占位符 {isLoading ? (

) : ( )}


这三项变更将 CLS 从 0.28 降到 **0.04**。

---

## 结果总结

| 指标 | 优化前 | 优化后 | 变化 |
|:------:|:------:|:-----:|:------:|
| LCP | 3.0 秒 | 1.2 秒 | -60% |
| CLS | 0.28 | 0.04 | -86% |
| INP | 320ms | 95ms | -70% |
| PageSpeed 移动 | 38 | 91 | +53 分 |

---

## 检查您自己网站的 Core Web Vitals

使用这些工具测量您当前的得分：
- [PageSpeed 检查器](/tools/page-speed) — 立即检查 PageSpeed Insights 得分
- [Meta 标签检查器](/tools/meta-checker) — 同时验证 SEO 和 OG 标签配置

---

## 常见问题（FAQ）

### Q1. 改善 Core Web Vitals 会直接提升搜索排名吗？
Core Web Vitals 是 Google 官方排名因素之一。Google 已公开确认它们是 Page Experience 信号。然而，内容质量和外链等其他因素仍然占据更大权重，因此应将 Core Web Vitals 的改善视为必要条件而非保证。

### Q2. 哪个 Core Web Vitals 指标对排名影响最大？
LCP 对用户最显眼，对跳出率的影响最直接，进而间接影响排名。CLS 也直接影响 UX，因此两者都是高优先级目标。INP 作为较新指标，其影响力仍在确立中。

### Q3. 如何检查我的 LCP 元素？
打开 Chrome DevTools，前往 Performance 标签，录制一次页面加载，并在时间线中查找 "LCP"。或者，运行 PageSpeed Insights 会告诉您具体哪个元素是 LCP 候选元素。

### Q4. Google Fonts 会损害 Core Web Vitals 吗？
是的。通过 `@import` 加载 Google Fonts 会阻塞渲染，是 LCP 恶化的常见原因。强烈建议使用 `<link rel="preconnect">` 结合 `display=swap` 或自托管字体。

### Q5. Next.js 对 Core Web Vitals 有多大帮助？
相当显著。Next.js 提供自动图片优化（WebP 转换、懒加载、尺寸优化）、内置字体优化（`next/font`）以及基于路由的代码分割作为内置功能。仅这些就可以在无需额外配置的情况下带来 Core Web Vitals 的大幅改善。

### Q6. 应该多久检查一次 Core Web Vitals？
建议至少每月监控一次。PageSpeed Insights 反映的是过去 28 天收集的真实用户数据，因此变化需要时间才能显现。使用 Google Search Console 跟踪现场数据随时间的趋势，比一次性测量更实用。

🔧 Related Free Tools

⚡

Page Speed Test

Core Web Vitals analysis

🔍

Keyword Density Analyzer

SEO keyword density analysis

title_zh

description_zh

content_md_zh

🔧 Related Free Tools

相关