Core Web Vitals 从排名信号的猎奇转变为能将转化网站与流失用户的网站区分开来的最可衡量的差异因素。这不是夸大其词 — 我是认真的。在 2026 年，INP 完全取代 FID，传闻中的平滑性指标即将推出，门槛再次提高。本指南精炼了我们在 Social Animal 进行的数百次性能审计中的内容 — 真实的修复、真实的数据，没有关于「优化图片」的空话而不展示确切的方法。

目录

2026 年 Core Web Vitals 是什么？

Core Web Vitals 是 Google 标准化的一组直接影响搜索排名的用户体验指标 — 坦白说？更重要的是用户行为。它们衡量用户实际 感受 到的内容：内容显示速度有多快、点击某些东西时页面响应速度有多快、布局是否保持原位或跳动得像被控制一样。

INP 在 2024 年 3 月正式取代了 FID。到 2025 年中期，Chrome 使用数据显示 38% 的源仍然未能通过 INP 阈值 — 相比之下 FID 享受的舒适的 92% 通过率。这不是 Google 移动目标线。他们终于在衡量真正重要的东西。

2026 年初的情况：

  1. 最大内容绘制 (LCP) — 加载性能
  2. 交互到下一次绘制 (INP) — 响应性
  3. 累积布局偏移 (CLS) — 视觉稳定性

Google 也表示对 平滑性 指标感兴趣（考虑动画帧丢弃和滚动卡顿），不过它还没有被提升为 Core Web Vital 状态。聪明的团队已经通过长动画帧 (LoAF) API 跟踪它了。如果你没有 — 现在就开始。

当前指标及其阈值

指标 良好 需要改进 较差 测量内容
LCP ≤ 2.5s 2.5s – 4.0s > 4.0s 最大可见元素渲染前的时间
INP ≤ 200ms 200ms – 500ms > 500ms 会话中最坏的交互延迟
CLS ≤ 0.1 0.1 – 0.25 > 0.25 意外布局偏移分数的总和

这是人们经常忘记的。这些阈值在来自真实 Chrome 用户体验报告 (CrUX) 数据的实际页面加载的 第 75 个百分位数 处测量。这意味着 75% 的 实际访问者 需要达到「良好」。不是你在 MacBook Pro 上通过光纤网络进行的测试。你的真实用户 — 在他们的三年前三星手机上，通过斑点状 LTE 地铁出行。巨大的差异。

最大内容绘制 (LCP) 优化

LCP 通常是团队最理解的指标 — 然而这仍然是大多数网站失败的指标。HTTP Archive 的 2025 年底数据显示只有 63% 的移动源通过 LCP。这很……不理想。

理解 LCP 子部分

Google 在其 2024 年文档中将 LCP 分为四个子部分。这个框架是我们找到的最有效的诊断工具 — 没有其他的接近它：

子部分 目标 涵盖内容
首字节时间 (TTFB) < 800ms 服务器响应、DNS、TLS、重定向
资源加载延迟 < 10% LCP TTFB 和 LCP 资源开始加载之间的时间
资源加载持续时间 < 40% LCP 下载 LCP 资源的时间
元素渲染延迟 < 10% LCP 资源加载和像素渲染之间的时间

服务器端修复

通过转向边缘计算来减少 TTFB。仍然从单个源提供服务？你正在免费交出 200-800ms 的时间给离你的服务器远的用户。完全白白送出去。

// Next.js 中间件，用于边缘优先渲染
// next.config.js
export default {
  experimental: {
    runtime: 'edge',
  },
};

// middleware.ts — 在边缘运行
import { NextResponse } from 'next/server';
export const config = { matcher: ['/((?!api|_next/static|favicon.ico).*)'] };

export function middleware(request) {
  const response = NextResponse.next();
  // 添加服务器计时报头以便调试
  response.headers.set('Server-Timing', `edge;desc="Edge Middleware"`);
  return response;
}

对于使用 Astro 或 Next.js 的团队，边缘渲染页面始终在全球范围内达到 TTFB 低于 200ms。我们的 Next.js 开发 和 Astro 开发 实践默认为边缘部署。

资源发现优化

这是大多数人错过的 — 2026 年最大的 LCP 杀手不是缓慢的服务器。这是对 LCP 资源的 晚期发现。如果你的英雄图片 URL 埋在 CSS 文件中或躲在 JavaScript 包内，浏览器甚至无法 开始 获取它，直到整个链解决完毕。你基本上是在隐藏页面上最重要的东西，藏在寻宝游戏后面。

<!-- 使用 fetchpriority 预加载 LCP 图片 -->
<link
  rel="preload"
  as="image"
  href="/hero-2400.webp"
  fetchpriority="high"
  media="(min-width: 768px)"
/>
<link
  rel="preload"
  as="image"
  href="/hero-800.webp"
  fetchpriority="high"
  media="(max-width: 767px)"
/>

<!-- 在图片元素本身 -->
<img
  src="/hero-2400.webp"
  alt="Product dashboard"
  width="2400"
  height="1200"
  fetchpriority="high"
  decoding="async"
  sizes="100vw"
  srcset="/hero-800.webp 800w, /hero-1600.webp 1600w, /hero-2400.webp 2400w"
/>

关键规则：

  • 绝不懒加载 LCP 元素。这是不可协商的。
  • 在 LCP 图片上使用 fetchpriority="high" — 从 2025 年起在所有现代浏览器中都支持。
  • 内联关键 CSS 或 <link rel="preload"> 阻止渲染的字体。
  • 以 AVIF 格式提供图片，使用 WebP 回退。AVIF 比相同质量的 WebP 小 30-50%。如果你在 2026 年仍然以 WebP 作为主要格式发货，你正在浪费字节。

基于文本元素的 LCP

当你的 LCP 元素是标题或段落（内容网站上非常常见）时，渲染阻止资源变成你的敌人：

<!-- 预加载你的主要字体 -->
<link rel="preload" as="font" type="font/woff2" href="/fonts/inter-v.woff2" crossorigin />

<!-- 使用 font-display: optional 以获得最快的绘制 -->
<style>
  @font-face {
    font-family: 'Inter';
    src: url('/fonts/inter-v.woff2') format('woff2');
    font-display: optional; /* 消除字体交换造成的布局偏移 */
  }
</style>

font-display: optional 通过在网页字体未被缓存的情况下回退到系统字体，防止 FOIT 和 FOUT。权衡？首次访问者看到系统字体。收益：字体交换不会产生 CLS，LCP 更快。我们每次都接受这个权衡。

交互到下一次绘制 (INP) 优化

INP 是 2026 年将良好网站与优秀网站区分开来的指标。大多数机构都搞错了这个。与 FID 不同，FID 仅测量 第一次 交互的输入延迟，INP 捕获 每次交互的完整生命周期：输入延迟、处理时间和呈现延迟 — 然后报告大致最坏的一个（第 98 个百分位数）。

交互解剖

[用户点击] → [输入延迟] → [事件处理] → [呈现延迟] → [下一帧被绘制]
            ↑               ↑                ↑
            被主线程阻止    你的点击        浏览器渲染
                           处理器运行       DOM 更改

减少输入延迟

当用户点击时主线程忙于做其他事情时会发生输入延迟。通常的嫌疑人：

  1. 第三方脚本 — 分析、聊天小部件、A/B 测试工具。你的典型企业网站加载 15-30 个第三方脚本，每一个都争夺主线程时间。这是一个暴徒场景。
  2. 水化风暴 — 一次性为整个页面注水的 SPA 阻止主线程 200-2000ms。当有人试图点击按钮时，这是永恒的。
  3. 长任务 — 任何超过 50ms 的 JavaScript 任务延迟输入。句号。
// 使用 scheduler.yield() 打破长任务 — 在 Chrome 129+ 中可用
async function processLargeDataset(items) {
  for (let i = 0; i < items.length; i++) {
    processItem(items[i]);
    
    // 每 5 项产生给主线程
    if (i % 5 === 0) {
      await scheduler.yield();
    }
  }
}

对于不支持 scheduler.yield() 的浏览器，这是回退方案：

function yieldToMain() {
  return new Promise(resolve => {
    setTimeout(resolve, 0);
  });
}

减少处理时间

这是你的事件处理器所在的地方。修复是架构性的，而不是装饰性的：

  • 防抖和限制 昂贵的处理器（滚动、调整大小、输入）。
  • 将计算转移出主线程 使用 Web Worker 或 scheduler.postTask() API。
  • 为动画使用 CSS 而不是 JavaScript。transform 和 opacity 更改不会触发布局或绘制。
// 使用 scheduler.postTask() 用于非紧急工作
button.addEventListener('click', async () => {
  // 紧急：立即视觉反馈
  button.classList.add('active');
  
  // 非紧急：分析、状态更新
  scheduler.postTask(() => {
    analytics.track('button_clicked');
  }, { priority: 'background' });
  
  // 用户可见但不是立即
  scheduler.postTask(() => {
    updateDashboard();
  }, { priority: 'user-visible' });
});

减少呈现延迟

呈现延迟是你的事件处理器完成和浏览器实际绘制下一帧之间的间隔。什么导致它：

  • 过度的 DOM 大小 — 拥有超过 1,400 个 DOM 元素的页面显示明显更坏的 INP。2025 年 HTTP Archive 中位数？移动设备上有 1,600 个元素。大多数网站都太臃肿了。
  • 复杂的 CSS 选择器 — 深层嵌套的选择器在每次更改时都强制昂贵的样式重新计算。
  • 布局抖动 — 在写入 DOM 后立即读取 offsetHeight 等布局属性会强制同步布局。这个经常咬人。他们从不看到它的到来。
// 不好：布局抖动
elements.forEach(el => {
  const height = el.offsetHeight; // 强制布局
  el.style.height = height + 10 + 'px'; // 使布局无效
});

// 好：先批量读取，再批量写入
const heights = elements.map(el => el.offsetHeight); // 所有读取优先
elements.forEach((el, i) => {
  el.style.height = heights[i] + 10 + 'px'; // 所有写入在后
});

累积布局偏移 (CLS) 优化

CLS 测量视觉不稳定性 — 当页面加载或交互期间东西到处跳动。Google 使用「会话窗口」方法：在彼此 1 秒内的偏移，上限为每个窗口 5 秒，被分组在一起。CLS 报告最大的会话窗口。

常见的嫌疑人

原因 修复 影响
没有维度的图片 添加 width 和 height 属性 高
动态注入的内容（广告、嵌入） 使用 min-height 或 aspect-ratio 保留空间 高
导致 FOUT 的 Web 字体 使用 font-display: optional 或 size-adjust 中等
晚期加载的 CSS 内联关键 CSS，预加载其余的 中等
触发布局的动画 使用 transform 而不是 top/left/width/height 低-中等

`aspect-ratio` CSS 属性

当我说这一个属性一夜之间消除了整个一类 CLS 问题时，我不是在夸大其词。随处使用它：

/* 为图片保留空间 */
img {
  aspect-ratio: attr(width) / attr(height);
  width: 100%;
  height: auto;
}

/* 为视频嵌入保留空间 */
.video-embed {
  aspect-ratio: 16 / 9;
  width: 100%;
  background: #1a1a1a;
}

/* 为广告槽保留空间 */
.ad-slot-leaderboard {
  aspect-ratio: 728 / 90;
  min-height: 90px;
  contain: layout;
}

`content-visibility` 属性

content-visibility: auto 告诉浏览器跳过渲染屏幕外内容。这显著降低初始布局成本，可以改进 CLS 和 INP：

.below-the-fold-section {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px; /* 估计高度以防止 CLS */
}

我们在长篇文章中使用这个技术测得 30-50% 的渲染时间减少。近乎免费的性能。没有理由不在内容繁重的页面上使用它。

框架特定策略

Next.js（App Router，v15+）

Next.js 15 将部分预渲染 (PPR) 作为稳定版本发货，坦白说 — 这对 LCP 是一个真正的游戏规则改变者。静态外壳在边缘即时渲染；动态内容通过 React Suspense 边界流入。

// app/page.tsx — 具有动态岛的静态外壳
import { Suspense } from 'react';
import { HeroSection } from '@/components/HeroSection'; // 静态
import { PersonalizedOffers } from '@/components/PersonalizedOffers'; // 动态

export default function HomePage() {
  return (
    <>
      <HeroSection /> {/* 在构建时渲染 — 即时 LCP */}
      <Suspense fallback={<OffersSkeleton />}>
        <PersonalizedOffers /> {/* 在外壳后流入 */}
      </Suspense>
    </>
  );
}

Next.js 的 <Image> 组件自动处理 srcset、AVIF/WebP 协商和懒加载。但 — 这经常绊倒人 — 你仍然需要在 LCP 图片上设置 priority。它不会为你猜测：

<Image
  src="/hero.jpg"
  alt="Hero"
  width={2400}
  height={1200}
  priority // 设置 fetchpriority="high" 并禁用懒加载
  sizes="100vw"
/>

我们的性能优先 Next.js 构建的完整方法在我们的 Next.js 开发功能 页面上。

Astro

Astro 的零 JavaScript 默认架构意味着大多数 Astro 网站开箱即通过 Core Web Vitals。2025 年 HTTP Archive Web Almanac 显示 Astro 网站在任何框架中都有最高的 Core Web Vitals 通过率，达到 82%。这不是巧合 — 这是当默认值是发货零客户端 JS 时发生的。

关键模式：

---
// src/pages/index.astro
import { Image } from 'astro:assets';
import heroImage from '../assets/hero.jpg';
---

<!-- Astro 在构建时优化为 AVIF/WebP 带 srcset -->
<Image
  src={heroImage}
  alt="Hero"
  widths={[400, 800, 1600, 2400]}
  sizes="100vw"
  loading="eager"
  fetchpriority="high"
/>

<!-- 交互式岛 — 仅在可见时加载 JS -->
<SearchBar client:visible />

client:visible 指令意味着搜索栏的 JavaScript 直到用户向下滚动到它才加载，在初始加载期间保持主线程清晰。更多关于我们的 Astro 开发 方法。

Headless CMS 考虑事项

使用 headless CMS — Contentful、Sanity、Storyblok，无论你运行的是什么 — CMS API 响应时间变成你的 TTFB 的一部分。直到它咬你之前，没有人会想到这个。

我们跨客户项目的基准：

CMS 平均 API 响应（缓存 CDN） 平均 API 响应（源） 注意
Contentful 45ms 180ms GraphQL API 略慢于 REST
Sanity 35ms 120ms GROQ 查询很快；CDN 很好
Storyblok 50ms 200ms V2 API 有了显著改进
Strapi（自托管） 可变 可变 完全取决于你的基础设施

关键模式：除非你真正需要个性化，否则不要在请求时调用 CMS API。使用 ISR 或按需重新验证来提供预构建页面。我们看到团队仅仅因为某人在应该被缓存的服务器组件中连接了 fetch 调用，就在他们的 TTFB 中增加 300ms+。令人愤怒。我们的 headless CMS 开发 实践默认包括这个。

生产环境中的测量和监控

实验室数据 vs. 字段数据

听着，实验室数据（Lighthouse、WebPageTest）告诉你 可能 会发生什么。字段数据（CrUX、RUM）告诉你 实际上 会发生什么。他们分化 — 有时很疯狂。当利益相关者挥舞 Lighthouse 100 分的分数，就像奖杯一样，而他们的 CrUX 数据在失败时？是的。我们比我们想要的更经常有那次对话。

这是实验室工具根本无法解释的：

  • 慢速设备（中位数 Android 手机的 CPU 能力大约是 iPhone 15 的 1/5）
  • 真实世界中的网络可变性
  • 浏览器扩展在做上帝知道什么
  • 第三方脚本在生产中的行为 — 在你的暂存环境中表现完全不同的东西

推荐的监控堆栈（2026）

工具 类型 成本 最佳用于
Google CrUX 字段（28 天） 免费 SEO 影响 — 这是 Google 实际使用的
web-vitals.js 字段（实时） 免费 自定义 RUM 管道
Vercel Speed Insights 字段 免费（使用 Vercel） Vercel 上的 Next.js 网站
SpeedCurve 实验室 + 字段 $12-200/mo 竞争基准、胶卷条
Sentry Performance 字段 $26+/mo 将性能与错误联系起来
DebugBear 实验室 + 字段 + CrUX $99+/mo 我们使用过的最好的 CrUX 变化跟踪

设置 web-vitals.js

import { onLCP, onINP, onCLS } from 'web-vitals/attribution';

function sendToAnalytics(metric) {
  const body = {
    name: metric.name,
    value: metric.value,
    rating: metric.rating, // 'good', 'needs-improvement', 'poor'
    delta: metric.delta,
    id: metric.id,
    navigationType: metric.navigationType,
    // 属性数据 — 告诉你为什么指标不好
    attribution: metric.attribution,
  };

  // 使用 sendBeacon 以获得可靠性
  if (navigator.sendBeacon) {
    navigator.sendBeacon('/api/vitals', JSON.stringify(body));
  }
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

/attribution 构建至关重要 — 它添加诊断信息，比如哪个元素是 LCP、哪个交互造成了最坏的 INP，以及哪些元素为 CLS 移动。没有它，你是瞎子飞行。只是盯着数字，不知道要修复什么。

2026 年高级技术

推测规则 API

推测规则 API（Chrome 121+，在 2026 年的浏览器支持约 75%）在用户实际点击之前预渲染页面。结果？后续导航中的近乎即时 LCP：

<script type="speculationrules">
{
  "prerender": [
    {
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/logout" } },
          { "not": { "href_matches": "/api/*" } }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

"eagerness": "moderate" 在悬停时预渲染 — 足够激进以感觉即时，保守到足以不会浪费用户带宽。我们在经历了大量的试错后落在了这个上。这是甜蜜点。

视图转换 API

原生视图转换（跨文档，在 Chrome 126+ 中支持）给你流畅的页面到页面动画，而无需 JavaScript 框架开销。他们直接改进感知性能并减少导航期间的 CLS：

@view-transition {
  navigation: auto;
}

::view-transition-old(root) {
  animation: fade-out 0.2s ease-out;
}

::view-transition-new(root) {
  animation: fade-in 0.2s ease-in;
}

长动画帧 (LoAF) API

LoAF 替代长任务并给你 很多 更多诊断能力。我真的希望我们三年前有过这个：

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.duration > 100) {
      console.log('长动画帧：', {
        duration: entry.duration,
        blockingDuration: entry.blockingDuration,
        scripts: entry.scripts.map(s => ({
          sourceURL: s.sourceURL,
          sourceFunctionName: s.sourceFunctionName,
          duration: s.duration,
        })),
      });
    }
  }
});
observer.observe({ type: 'long-animation-frame', buffered: true });

这告诉你正确的 哪个脚本 和 哪个函数 导致了长帧。我们整个审计会议都花在盯着 LoAF 输出上，在几分钟内找到明确的证据，而不是几小时。对于 INP 调试，它是现在存在的最好工具。没有其他的接近。

商业影响：真实数据

性能优化不是虚荣项目。这不是什么开发者认为很酷就认可的东西。从 2025 年案例研究：

  • Vodafone 将 LCP 提高了 31%，导致销售额增加 8%。
  • Tokopedia 将 INP 降低了 40%，增加了 15% 的会话时长。
  • NDTV 将 CLS 提高了 55%，将跳出率降低了 50%。
  • Rakuten 24 将 CLS 提高了 0.2 个点，导致每位访问者收入增加 33.1%。

我们在 Social Animal 的自有客户数据显示通过所有三个 Core Web Vitals 的网站与他们的优化前基线相比看到平均 23% 的跳出率降低 和 12% 的转化率更高。

对于电子商务，数学很简单：LCP 每改进 1 秒与转化率增加 2-5% 相关联。在 $10M/年的商店上，那是额外收入 $200K-$500K。优化的成本？那的一个小部分。检查我们的 定价页面 了解具体信息，或 直接联系 讨论你的情况。

常见问题

2026 年的 Core Web Vitals 指标是什么？ 三个 Core Web Vitals 是最大内容绘制 (LCP)、交互到下一次绘制 (INP) 和累积布局偏移 (CLS)。INP 在 2024 年 3 月回到取代了首次输入延迟 (FID)，它仍然是响应性指标。Google 暗示了一个平滑性指标但还没有将其添加为 Core Web Vital。

Core Web Vitals 影响 SEO 排名有多少？ 它们是 Google 页面体验信号中的确认排名信号，但它们更像是一个决胜局而不是主要因素 — 内容相关性仍然占主导地位。他们真正拳打超重的地方是用户行为：跳出率、参与度、页面停留时间。这些东西间接影响排名的方式很难直接归因，但不可能忽视。通过所有 Core Web Vitals 的网站始终显示更好的参与数字，这会随着时间推移而复合。

2026 年 INP 分数是多少？ 200 毫秒或更少，在真实用户数据的第 75 个百分位数处测量。在 200ms 和 500ms 之间需要改进。超过 500ms 较差。中位网站 INP 在移动设备上大约 280ms，截至 2026 年初 — 意味着大多数网站仍然没有通过。让这个充分沉没。

为什么我的 Lighthouse 分数与我的 CrUX 数据不同？ 因为他们在测量根本上不同的东西。Lighthouse 在模拟环境中以单个页面加载运行，CPU 和网络受限。CrUX 数据来自于超过 28 天滚动窗口的真实 Chrome 用户在你的源的所有页面。间隔来自设备多样性（真实用户在慢速 Android 手机上）、生产中的第三方脚本行为、与你的服务器的地理距离，以及 CrUX 捕获完整会话事实 — INP 的每个交互、CLS 的每个布局偏移 — 而 Lighthouse 捕获一个加载。我们看到网站 Lighthouse 评分 95+ 而在 CrUX 中通篇失败。不要单独信任实验室数据。

使用 headless CMS 有帮助还是伤害 Core Web Vitals？ Headless CMS 架构根本上有帮助，因为它将表现层与内容管理分离。你可以将其与现代框架（如 Next.js 或 Astro）配对，使用边缘渲染，以最小的 JavaScript 提供静态或服务器渲染的 HTML。传统单体平台 — 没有大量优化的 WordPress、开箱即用的 Drupal — 通常发货的 JavaScript 多得多，TTFB 更慢。关键事项：确保 CMS API 调用在构建时或被激进地缓存，而不是在每个单一请求上触发。

我如何修复由第三方脚本导致的较差 INP 分数？ 首先使用长动画帧 API 或 Chrome DevTools 的性能面板审计以识别哪些脚本占用主线程。然后：使用 async 或 defer 加载非关键脚本，使用 setTimeout 或 requestIdleCallback 延迟他们的初始化，考虑通过 web worker（Partytown 很好用于此）将第三方脚本转移到主线程之外，并且 — 这是部分没有人想听的 — 无情地删除任何不提供可衡量业务价值的东西。那个没人使用的聊天小部件？杀掉它。我们看到网站仅通过推迟聊天小部件和 A/B 测试工具就从 500ms+ INP 降到 150ms 以下。这几乎总是第三方臃肿。

在 Next.js 网站上改进 LCP 的最快方法是什么？ 按影响顺序：为静态外壳启用部分预渲染 (PPR)，部署到边缘运行时（Vercel Edge 或 Cloudflare），在你的 LCP <Image> 组件上设置 priority，停止使用不必要的客户端组件在折线上方来阻止渲染，以及预加载关键字体。但这是我们在实践中实际看到的：根本原因通常是应该是服务器组件的客户端数据获取。将单个组件从 'use client' 转移到服务器组件可以从 LCP 中剪掉 500ms 或更多。这有多疯狂都有多疯狂。

Google 多久更新一次 Core Web Vitals 阈值？ 不常。主要变化是交换 FID 为 INP，在 2023 年 5 月宣布，在 2024 年 3 月实行。实际阈值值 — 2.5s 对于 LCP、200ms 对于 INP、0.1 对于 CLS — 自他们被介绍以来就没有变过。Google 通常在任何东西更改之前提前 6-12 个月的通知。但是 Chrome 团队在幕后持续调整指标的计算方式，所以即使阈值持稳定，你需要继续关注你的字段数据。东西在没有任何人宣布的情况下转移。