ITMay 26, 2026

网站速度优化 2026：如何让 Core Web Vitals 达到 90+

Google Core Web Vitals 优化完整 2026 指南。涵盖 LCP、INP 和 CLS 的测量与改进：图片优化（WebP/AVIF）、字体预加载、JavaScript 包拆分、CDN 配置。包含一份 30 项清单，帮助通过 Next.js 代码示例实现 Lighthouse 90+。

> **核心摘要** 2026 年的 Google Core Web Vitals：LCP（Largest Contentful Paint）< 2.5s，INP（Interaction to Next Paint）< 200ms，CLS（Cumulative Layout Shift）< 0.1。这三项指标会直接影响 Google 搜索排名。影响最大的优化方式：① 将图片转换为 WebP/AVIF ② 预加载字体 ③ JavaScript 代码拆分 ④ CDN 边缘部署。Next.js 用户通过正确的默认配置即可达到 Lighthouse 90+。

什么是 Core Web Vitals？

Core Web Vitals 是 Google 的三项核心用户体验指标，自 2021 年起被纳入 SEO 排名信号。

三项核心指标

| 指标 | 全称 | 衡量内容 | 良好 | 需要改进 | 较差 |

|---|---|---|---|---|---|

| **LCP** | Largest Contentful Paint | 渲染最大图片或文本所需时间 | < 2.5s | 2.5–4s | > 4s |

| **INP** | Interaction to Next Paint | 从用户点击到视觉响应的时间 | < 200ms | 200–500ms | > 500ms |

| **CLS** | Cumulative Layout Shift | 加载期间的意外布局移动 | < 0.1 | 0.1–0.25 | > 0.25 |

注意：FID（First Input Delay）已在 2024 年被 INP 取代。

为什么 Core Web Vitals 很重要

**直接影响 SEO**：已纳入 Google 排名算法 —— 内容相同的情况下，速度更快的网站胜出

**跳出率**：LCP > 3s 会使移动端跳出率增加 53%（Google 研究）

**广告收入**：AdSense RPM 与页面停留时间相关 → 网站越快 = RPM 越高

**转化率**：延迟 1 秒 = 转化率下降 7%（Akamai 研究）

LCP 优化

LCP 通常由首屏主视觉图片或最大文本块的加载时间决定。

图片优化（影响最大）

**格式对比：**

| 格式 | 体积减少 | 浏览器支持 |

|---|---|---|

| JPEG | 基准 | 100% |

| WebP | 小 25–35% | 98%+ |

| AVIF | 小 40–50% | 90%+（2026） |

```html

</picture>

```

**Next.js Image 组件：**

```typescript

import Image from 'next/image'

// LCP images must have priority prop

<Image

src="/hero.jpg"

alt="Hero image"

width={1200}

height={628}

priority // critical — eliminates LCP delay

quality={85}

```

资源预加载

```html

```

服务器响应时间（TTFB）

| 方法 | 影响 | 实现方式 |

|---|---|---|

| CDN | 全球边缘缓存 | Cloudflare, Vercel Edge |

| 缓存头 | 回访用户可即时加载 | Cache-Control: max-age=31536000 |

| SSG/ISR | 预渲染 HTML | Next.js generateStaticParams |

INP 优化

INP 衡量从任何用户交互（点击、轻触、键盘输入）到浏览器渲染下一帧所需的时间。

减少主线程阻塞

```javascript

// Bad: heavy sync computation blocks click response

button.addEventListener('click', () => {

const result = heavyComputation(data) // blocks main thread

updateUI(result)

})

// Good: offload to Web Worker

const worker = new Worker('heavy-worker.js')

button.addEventListener('click', () => {

worker.postMessage(data) // runs in separate thread

})

worker.onmessage = (e) => updateUI(e.data)

```

代码拆分（Next.js）

```typescript

import dynamic from 'next/dynamic'

// Defer components not visible on first load

const HeavyChart = dynamic(() => import('./HeavyChart'), {

loading: () => <div>Loading chart...</div>,

ssr: false

})

```

Tree Shaking

```javascript

// Bad: imports entire lodash (70KB+)

import _ from 'lodash'

// Good: imports only what you need (1KB)

import chunk from 'lodash/chunk'

```

CLS 优化

当广告、图片或动态内容在加载过程中发生位置偏移时，就会产生 CLS。

始终指定图片尺寸

```html

```

预留广告空间

```css

.ad-container {

min-height: 250px; /* pre-reserve ad space */

display: flex;

align-items: center;

justify-content: center;

}

```

字体加载

```css

@font-face {

font-family: 'MyFont';

src: url('/fonts/myfont.woff2') format('woff2');

font-display: swap; /* show system font immediately, swap when loaded */

}

```

Lighthouse 90+ 检查清单（30 项）

**LCP（10 项）**

[ ] 识别 LCP 元素（DevTools → Performance 选项卡）

[ ] 为 LCP 图片添加 priority 或 preload

[ ] 将首屏主图转换为 WebP/AVIF

[ ] 使用 next/image 进行自动优化

[ ] 通过 srcset 提供响应式图片

[ ] 使用 CDN（Cloudflare Pages、Vercel Edge）

[ ] 验证 TTFB < 600ms

[ ] 尽可能使用 SSG/ISR

[ ] 移除不必要的重定向

[ ] 延迟加载所有第三方脚本

**INP（10 项）**

[ ] 在 Lighthouse 中检查 INP 分数

[ ] 移除 Long Tasks（50ms+）— DevTools Performance 选项卡

[ ] 将繁重计算移到 Web Workers

[ ] JavaScript bundle < 200KB（压缩后）

[ ] 移除不必要的 polyfills

[ ] 在 React 中应用 useMemo/useCallback

[ ] 对事件处理器进行防抖/节流

[ ] 使用 CSS transitions 代替 JS animations

[ ] 为第三方 script 标签添加 async/defer

[ ] 针对 LCP 元素优化 JS 执行顺序

**CLS（10 项）**

[ ] 为所有图片和视频设置 width/height

[ ] 为广告容器预留最小高度

[ ] 将动态注入的内容放在底部

[ ] 在 @font-face 规则中应用 font-display: swap

[ ] 添加字体 preload 链接标签

[ ] 只对 transform/opacity 做动画（不要使用会改变布局的属性）

[ ] 使用骨架屏加载器预先保留内容空间

[ ] 确认 sticky/fixed 元素不会挤压内容

[ ] 在无限滚动插入内容时保持滚动位置

[ ] 使用 overflow: hidden 修复标签切换动画的高度

测量工具

| 工具 | 用途 | URL |

|---|---|---|

| PageSpeed Insights | 真实用户 LCP/INP/CLS 数据 | pagespeed.web.dev |

| Lighthouse | 基于实验室环境的性能评分 | Chrome DevTools → Lighthouse |

| WebPageTest | 全球不同地区测试 | webpagetest.org |

| Chrome DevTools | 详细性能分析 | F12 → Performance tab |

| Core Web Vitals Report | 用于 SEO 的 CrUX 现场数据 | Search Console |

常见问题

**Q1. Core Web Vitals 对 Google 排名影响有多大？** A. Google 将 CWV 描述为“决胜信号”——当内容质量相同时，速度更快的网站会胜出。移动端 Page Experience 将 CWV 作为排名组成部分。具体权重并未公开，但真实测试持续显示，LCP > 4s 与 < 2s 的网站之间存在排名差异。

**Q2. Lighthouse 90+ 是否等同于通过 Core Web Vitals？** A. 不是。Lighthouse 使用实验室模拟；Core Web Vitals 使用真实用户数据（CrUX / Field Data）。即使 Lighthouse 满分 100，也不能保证现场 CWV 表现良好。请在 Google Search Console 中查看 Core Web Vitals 报告，那里才是实际影响 SEO 排名的数据。

**Q3. Next.js 会自动带来良好性能吗？** A. 部分会。Next.js 开箱提供图片优化（next/image）、字体优化（next/font）、代码拆分和 SSG/ISR。不过，开发者仍必须正确实现 priority 属性、移除不必要的第三方脚本，并指定图片尺寸。实现得当时，可以达到 Lighthouse 85–95+。

**Q4. 转换为 WebP 会降低图片质量吗？** A. 在 quality=80–90 时，人眼几乎无法察觉差异。在相同视觉质量下，WebP 相比 JPEG 可减少 25–35% 的文件大小。AVIF 的压缩效果更好。Squoosh、Cloudinary 或 next/image 等工具可以自动处理转换。

**Q5. 如何找出导致 CLS 的元素？** A. 在 Chrome DevTools → Performance tab 中，录制后查找“Layout Shift”标记。PageSpeed Insights 也会列出“Avoid large layout shifts”，并指出导致移动的具体元素。常见原因包括：未设置尺寸的图片、广告加载后挤压内容、字体替换（FOUT）、动态注入的内容。

**Q6. 第三方脚本（GA、Hotjar）会对性能造成多大影响？** A. 影响很明显 — 第三方脚本可能会让 Lighthouse 分数降低 10–20 分。GA4 通过异步加载，相对轻量；而 Hotjar 或 Intercom 这类较重的工具会严重影响 INP。使用 next/script，并设置 strategy="afterInteractive" 或 "lazyOnload"，将这些脚本延后到主页面可交互之后再加载。

**Q7. 移动端 LCP 总是比桌面端慢 — 该如何优化？** A. 移动设备的网络和 CPU 更慢，因此移动端 LCP 天然更难优化。改进方法：① 通过 srcset 为移动端提供更小的首屏主图 ② 在移动端隐藏非必要图片 ③ 内联关键 CSS ④ 在 CDN 边缘缓存 HTML。目标：即使在移动端也将 LCP 控制在 2.5s 以下。