# SEO核心性能优化指南（2026最新版）

> 📝 摘要：SEO核心性能(Core Web Vitals)重要吗?这几个指标,说白了就是Google在拿放大镜看你的网站到底"好不好用"。它们不仅影响用户体验，更是Google搜索排名算法中的重要信号。本文将深入探讨 Core Web Vitals的方方面面，从其定义、发展历程，到每个指标的详细解析、优化策略，以及如何通过无障碍设计进一步提升网站表现。

作者：小魏博客  
发布时间：2026-07-28 14:02  
评论：0  
阅读：21  
更新时间：2026-07-28 14:02  

Core Web Vitals重要吗?这几个指标,说白了就是Google在拿放大镜看你的网站到底”好不好用”。

它们不仅影响用户体验，更是Google搜索排名算法中的重要信号。

本文将深入探讨 Core Web Vitals的方方面面，从其定义、发展历程，到每个指标的详细解析、优化策略，以及如何通过无障碍设计进一步提升网站表现。

---

## Core Web Vitals到底是什么

简单讲,这是Google拿来衡量用户打开你网页时,到底流不流畅的一组指标。

属于Google”页面体验”信号里的核心部分。

**三个指标分别管三件事:**

LCP(最大内容绘制):管加载速度,页面主要内容多久能看到

INP(与下一次绘制的交互):管响应速度,你点了按钮多久有反应

> 顺带说一句,原来还有个FID(首次输入延迟),不过2024年3月就被INP取代了，如果你现在还在看老教程里提FID,那基本是过时资料了,直接跳过就行。

CLS(累积布局偏移):管稳不稳,页面会不会莫名其妙跳来跳去

Google搞这套东西的初衷其实挺直白的——光有相关性高的内容还不够,还得让用户真的用得舒服。

一个加载慢、点哪儿都卡半天的网站,内容写得再好,用户也留不住。

---

## Core Web Vitals 的发展历程

2020 年：Google 首次宣布推出Core Web Vitals，并预告其将在 2021 年成为排名因素。

2021 年：[Core Web Vitals 正式纳入Google排名信号](https://backlinko.com/hub/seo/core-web-vitals)，成为页面体验更新的一部分。

2024 年 3 月：[Google 宣布](https://developers.google.com/search/blog/2023/05/introducing-inp) Interaction to Next Paint (INP) 正式取代 First Input Delay (FID) 成为新的核心网页指标，以更全面地衡量页面响应能力 。

2026 年：Core Web Vitals 持续演进，Google 不断完善其衡量标准和算法，以适应不断变化的网页技术和用户期望。

例如，有迹象表明 Google 正在探索更细致的页面体验评估方式，可能不再纯粹基于页面进行评估，而是考虑用户在整个网站上的体验

---

## Core Web Vitals是否影响SEO排名

算,而且是Google明说了的。

从2021年开始,Core Web Vitals就正式进了排名算法,是”页面体验更新”的一部分。

**但这里有个误区我得提一下:**

很多人以为把这三个指标做到满分就能起飞,其实没那么简单。

Google考虑的排名因素有几百个,内容质量、相关性、外链这些权重都比性能高。

Core Web Vitals更像是个”加分项”或者说”决胜局”——两个网站内容差不多的时候,谁的体验更好,谁能占点便宜。

指望靠性能优化把烂内容顶上去,基本不现实。

**页面体验不只是这三个指标**

除了LCP、INP、CLS,Google对”良好页面体验”的定义还包括[HTTPS](https://xiaoweiboke.com/https-zheng-shu/)、移动端友好度、别整那些烦人的插页式广告、还有安全浏览(不能有恶意软件)。

这几项加一起才算完整的页面体验信号。

**为什么不能死磕Lighthouse满分**

Lighthouse是一个强大的工具，可以帮助你评估网站性能(Core Web Vitals)，并提供优化建议。

但是Lighthouse跑出来100分,不代表真实用户体验就好。

原因是Lighthouse用的是实验室数据,模拟出来的理想环境;

而Google真正看的是Field Data(真实数据),也就是真实用户在各种网络、各种设备下的实际表现。

我见过不少网站,Lighthouse跑分很漂亮,结果Search Console里的真实用户数据惨不忍睹。

反过来的情况也有。

所以我一般建议客户,Lighthouse拿来当诊断工具用没问题,但别把它当终极目标,CrUX(真实用户数据)才是Google真正在意的东西。

---

## LCP、INP、CLS三个核心指标讲解

### LCP:用户觉得”加载完了”是什么时候

LCP测的是视口里最大的内容元素什么时候画出来。

可能是一张图,可能是视频海报,也可能是一大块文字。

这个指标想抓的其实是用户的主观感受——大部分人觉得”页面加载完了”,不是等所有资源都加载完,而是主要内容一出现就觉得可以看了。

**评分标准是这样的**

| 状态 | LCP 时间 |
| --- | --- |
| 良好 | ≤ 2.5 秒 |
| 需要改进 | 2.5 秒 – 4.0 秒 |
| 不佳 | 4.0 秒 |

> 实际测试发现,很多网站卡在3秒左右这个尴尬区间,原因五花八门,服务器响应慢、图片太大、渲染阻塞资源太多都有可能。

**哪些元素会被算成LCP?**

常见的有img标签、svg里的image元素、带海报图的video标签、CSS background-image加载的背景图,还有包含大段文字的块级元素。

### INP:交互流不流畅

INP衡量的是页面对用户操作的整体响应能力,记录所有点击、轻触、键盘交互的延迟,取里面最差的那个(排除异常值)。

之所以用INP取代FID,是因为FID只看第一次交互,后面的交互延迟全部被忽略了,这明显不够全面。

**评分标准**

| 状态 | INP 时间 |
| --- | --- |
| 良好 | ≤ 200 毫秒 |
| 需要改进 | 200 毫秒 – 500 毫秒 |
| 不佳 | 500 毫秒 |

INP过高的网站,我见过最多的原因是插件太多导致JavaScript执行时间爆表,尤其是WordPress站点,装了十几个插件,每个都往主线程塞脚本,不卡才怪。

### CLS:页面会不会突然”跳一下”

CLS衡量的是页面加载过程中,那些用户没预料到的布局偏移加起来有多严重。

你正准备点一个按钮,结果它突然往下挪了,你点到别的地方去了——这就是CLS在作祟,体验相当糟心。

**评分标准**

| 状态 | CLS 分数 |
| --- | --- |
| 良好 | ≤ 0.1 |
| 需要改进 | 0.1 – 0.25 |
| 不佳 | > 0.25 |

常见诱因是图片视频没设置尺寸、广告位没预留空间、字体加载导致文字跳动,还有JavaScript在页面加载后动态改动DOM结构。

---

## Core Web Vitals 为什么重要

不只是为了排名。

一个响应快、稳定的网站,能实实在在提升转化率。

[亚马逊之前有个说法](https://blog.kissmetrics.com/loading-time/),页面加载每慢100毫秒,销售额就掉1%——这数字听着夸张,但做电商的应该都懂那种”多等一秒就少一个订单”的焦虑。

移动端这块尤其明显。

现在大部分流量都来自手机,网络环境复杂,设备性能参差不齐,用户对速度的容忍度反而更低。

一个网站在PC上跑得挺顺,手机上卡成PPT,这种情况我见得太多了。

还有个容易被忽略的点,就是品牌形象。

网站卡顿会让用户下意识觉得这个品牌不靠谱、不专业,哪怕产品本身没问题。这种印象一旦形成,挺难扭转的。

---

## Core Web Vitals 的优化策略

**服务器这一关先过了**

TTFB(服务器响应时间)太长,基本就是LCP不佳的第一大元凶。

用户等页面出内容等得越久,体验越差,这个道理不用多说。

解决办法无非那几样:

选择高性能主机，购买可靠、响应迅速的服务器或虚拟主机;

上CDN把内容分发到离用户近的服务器;

升级到HTTP/2或者HTTP/3,支持多路复用效率更高;

配置服务器端缓存,别每次请求都重新查数据库;

确保数据库查询高效，避免慢查询;

这些都是基础操作,但很多网站至今没做全。

**图片是重灾区**

未压缩的大图,几乎是LCP和整体加载速度最常见的杀手。

这块的优化思路也算成熟了:

用WebP或者AVIF这种现代格式,压缩率比JPEG、PNG好不少

响应式图片,用<picture>元素或者srcset,根据设备给不同尺寸的图,别让手机加载PC端的大图

非首屏的图片延迟加载(loading=”lazy”)

首屏图片优先加载(fetchpriority=”high”)，千万别延迟,延迟反而拖慢LCP

> 我刚开始也踩过这个坑——把首屏关键图也设成了lazy load,结果LCP不降反升,后来才意识到首屏图片应该是优先加载,不是延迟。

图片该压缩的压缩,TinyPNG、ShortPixel这类工具随手就能用

**CSS别拖后腿**

没处理过的CSS会阻塞渲染,拖慢LCP,弄不好还会引发CLS。

常见做法是把首屏必需的关键CSS内联进HTML

非关键的异步加载，用PurgeCSS一类工具分析清掉没用到的样式;

css文件该压缩就压缩;

还有,使用 <link> 标签引入 CSS文件，避免 @import，因为它会串行加载 CSS 文件，影响性能。。

**JavaScript的优化空间最大**

这块我觉得是最容易出成果的地方,尤其对INP的改善特别明显。

具体来说:

defer 属性：将脚本标记为 defer，使其在 HTML 解析完成后执行，不阻塞渲染。

async 属性：将脚本标记为 async，使其异步加载和执行，不阻塞 HTML 解析，但执行顺序不确定。

代码分割 (Code Splitting)：将 JavaScript 代码分割成小块，按需加载，减少初始加载的 JavaScript 量。

摇树优化 (Tree Shaking)：移除未使用的 JavaScript 代码，减小打包后的文件大小。

减少长任务 (Long Tasks)：将耗时较长的 JavaScript 任务分解成小任务，或使用 Web Workers 在后台线程执行，避免阻塞主线程，从而改善 INP。

优化事件监听器：避免在主线程上执行复杂的事件处理逻辑，使用事件委托，并确保事件处理函数高效。

**字体加载也得留心**

字体这块不注意,容易搞出FOIT/FOUT(文字闪烁),顺带引发CLS。

预加载关键字体(用<link rel=”preload” as=”font” crossorigin>提前加载),配合font-display: swap或者optional来控制加载行为,能省不少麻烦。

有条件的话,尽量用系统自带字体,少依赖第三方字体服务。

**其他几个容易被忽视的点**

浏览器缓存头设置得当,能省不少重复请求;

第三方脚本(广告、统计工具之类)尽量延迟加载,别让它们抢主线程;

DOM节点太多也会拖慢渲染和布局计算,该精简的HTML结构就精简;

网络请求数量也是,能合并的小文件合并一下。

---

## 如何优化 LCP (Largest Contentful Paint)

优化LCP的核心在于确保页面主要内容能够快速加载并呈现在用户面前。

以下是具体的优化策略：

**1.降低服务器响应时间 (TTFB)**

选择高性能主机：确保你的服务器配置能够快速响应请求。

使用CDN：将静态资源分发到离用户最近的服务器，减少物理距离造成的延迟。

启用服务器端缓存：减少每次请求的计算量。

优化数据库查询：确保后端数据获取高效。

升级HTTP协议：使用HTTP/2或HTTP/3提升传输效率。

**2.优化首屏图片**

压缩和使用现代格式：将首屏图片转换为WebP或AVIF格式，并进行适当压缩。

响应式图片：为不同设备提供不同尺寸的首屏图片。

避免延迟加载首屏图片：确保首屏关键图片立即加载，而不是延迟加载。

**3.使用 preload、fetchpriority**

preload关键资源：使用<link rel=”preload”>预加载首屏所需的关键图片、字体或CSS文件。

fetchpriority=”high”：为LCP元素（如首屏大图）设置fetchpriority=”high”，告知浏览器优先加载该资源。

**4.消除渲染阻塞资源**

关键CSS内联：将首屏所需的关键CSS直接嵌入HTML 中。

异步加载非关键CSS：使用 <link rel=”stylesheet” media=”print” onload=”this.media=’all'”> 或JavaScript异步加载非关键CSS。

延迟加载JavaScript：将不影响首屏渲染的 JavaScript 脚本使用defer或async属性加载。

**5.精简CSS与JavaScript**

移除未使用的代码：定期清理CSS和JavaScript中未使用的代码。

压缩代码：对所有CSS和JavaScript文件进行压缩。

---

## 如何优化 INP (Interaction to Next Paint)

优化INP的关键在于确保页面在用户交互后能够快速响应，提供流畅的体验。

以下是具体的优化策略：

**1.减少 JavaScript 执行时间**

代码分割 (Code Splitting)：将大型JavaScript包拆分为更小的块，按需加载。

摇树优化 (Tree Shaking)：移除未使用的JavaScript代码。

延迟加载非关键脚本：将不影响核心交互的JavaScript脚本（尤其是第三方脚本）延迟加载。

**2.Web Worker**

将耗时较长的计算密集型任务（如数据处理、复杂动画）转移到Web Worker中执行，避免阻塞主线程，从而提高页面的响应性。

**3.延迟第三方脚本**

广告、分析工具、聊天插件等第三方脚本常常会占用大量主线程时间。

使用defer或async属性，或在用户同意后才加载这些脚本。

**4.减少长任务 (Long Tasks)**

分解任务：将超过 50 毫秒的JavaScript任务分解成更小的、异步执行的任务。

使用 requestIdleCallback或setTimeout：在浏览器空闲时执行非关键任务。

**5.优化事件监听**

事件委托 (Event Delegation)：将事件监听器附加到父元素而不是每个子元素，减少监听器数量。

节流 (Throttling) 和防抖 (Debouncing)：对于频繁触发的事件（如滚动、输入），使用节流和防抖技术限制事件处理函数的执行频率。

避免在事件处理函数中执行复杂计算：将复杂逻辑移出事件处理函数，或异步执行。

**6.减少DOM节点**

过多的DOM节点会增加浏览器计算样式、布局和绘制的负担。

精简HTML结构，移除不必要的嵌套和元素。

---

## 如何优化 CLS (Cumulative Layout Shift)

优化CLS的目标是消除页面加载过程中所有非预期的布局偏移，确保视觉稳定性。

以下是具体的优化策略：

**1.为图片指定width/height**

在<img>标签中明确指定图片的width和height属性，或在CSS中设置aspect-ratio，让浏览器在图片加载前预留空间。

**2.使用aspect-ratio**

对于响应式图片，使用 CSS 的aspect-ratio属性可以根据图片的宽高比自动计算高度，避免布局偏移。

**3.广告位预留空间**

为广告、嵌入内容或其他动态加载的元素预留足够的空间。

即使广告未加载，也应保持其占位符的尺寸，避免内容跳动。

**4.iframe 固定尺寸**

为<iframe>元素设置固定的width和height，或使用CSS确保其尺寸稳定。

**5.font-display 属性**

使用 font-display: optional; 或 font-display: swap; 来管理Web字体的加载行为，减少字体加载导致的文本布局偏移。

**6.动态内容占位**

对于在页面加载后才显示的内容（如用户评论、推荐商品），应提前为其创建占位符，并设置最小高度或宽度，防止内容突然出现导致布局偏移。

**7.避免页面加载后插入元素**

尽量避免在页面加载完成后，通过JavaScript动态插入会影响现有内容布局的元素。

如果必须插入，确保有足够的空间预留。

---

## 页面体验与无障碍阅读

Accessibility(无障碍)本身不算Core Web Vitals的指标,但它跟页面体验关系密切,Lighthouse评分里也占一块。

2026年这个话题的分量只会越来越重。

**什么是 Accessibility (无障碍)？**

网页无障碍 (Web Accessibility) 旨在确保残障人士（如视力、听力、肢体或认知障碍者）能够感知、理解、导航和与网站进行交互。

这包括为使用辅助技术（如屏幕阅读器、语音识别软件）的用户提供支持，以及为有特殊需求的用户提供替代交互方式。

**WCAG 标准简介**

Web Content Accessibility Guidelines (WCAG) 是由万维网联盟 (W3C) 发布的国际公认的网页无障碍标准。

WCAG 提供了详细的指南和成功标准，帮助开发者创建无障碍的网页内容。

它基于四个核心原则：

可感知 (Perceivable)：信息和用户界面组件必须以用户可以感知的方式呈现。

可操作 (Operable)：用户界面组件和导航必须是可操作的。

可理解 (Understandable)：信息和用户界面操作必须是可理解的。

稳健 (Robust)：内容必须足够稳健，以便各种用户代理（包括辅助技术）能够可靠地解释它。

**为什么越来越多的网站重视 Accessibility(无障碍)？**

法律合规性：许多国家和地区都有法律要求网站必须符合无障碍标准。

扩大用户群体：无障碍网站能够服务更广泛的用户，包括残障人士和老年人，从而扩大潜在受众。

提升品牌形象：关注无障碍设计体现了企业的社会责任感和包容性，有助于提升品牌形象。

改善用户体验：无障碍实践往往也能改善所有用户的体验，例如清晰的导航、良好的颜色对比度等。

**Accessibility(无障碍) 与 Core Web Vitals 的区别**

Core Web Vitals 关注的是网站的技术性能，如加载速度、响应性和视觉稳定性。

而 Accessibility(无障碍)关注的是网站的可用性和包容性，确保所有用户都能访问和使用网站。

两者虽然侧重点不同，但都共同服务于提升用户体验的目标。

**Accessibility (无障碍)与 SEO 的关系**

无障碍优化对 SEO 有着积极的间接影响：

1.提高页面可读性：清晰的结构、良好的颜色对比度、适当的字体大小等无障碍实践，使得内容更易于阅读和理解，这不仅对残障用户有益，也提升了所有用户的体验，并可能降低跳出率。

2.提升用户体验：Google 越来越重视用户体验。无障碍网站提供更好的用户体验，这会带来更长的停留时间、更低的跳出率和更高的用户参与度，这些都是积极的 SEO 信号。

3.帮助搜索引擎理解页面结构：语义化的 HTML 结构（如正确使用标题标签、列表、地标区域等）不仅对屏幕阅读器友好，也帮助搜索引擎更好地理解页面内容和结构，从而提高索引效率和相关性。

4.提高辅助技术兼容性：为辅助技术（如屏幕阅读器）提供支持，意味着网站内容可以被更广泛的工具访问和解释，间接提升了内容的可发现性。

5.降低跳出率，提高用户参与度：当网站对所有用户都友好时，他们更有可能找到所需信息，减少因体验不佳而离开的情况。

**无障碍阅读优化实践**

以下是一些关键的无障碍阅读优化实践：

图片 Alt 属性：为所有非装饰性图片提供有意义的 alt 属性，描述图片内容，方便屏幕阅读器用户理解。

Heading 标题层级 (H1~H6)：正确使用标题标签，按照逻辑顺序组织内容结构，帮助用户和搜索引擎理解页面层次。

Link Name (链接具有可识别名称)：确保链接文本清晰描述链接目标，避免使用“点击这里”等模糊文本。

Button Name (按钮具有可识别名称)：为按钮提供清晰的文本或 aria-label，表明其功能。

Label 与表单关联：使用 <label> 标签与表单输入框关联，提高表单的可用性。

iframe 设置 title：为 <iframe> 元素提供描述性 title 属性，帮助屏幕阅读器用户理解其内容。

HTML lang 语言属性：在 <html> 标签中声明页面的主要语言，例如 <html lang=”zh-CN”>，有助于屏幕阅读器正确发音。

Landmark 语义标签：使用 HTML5 语义标签（如 <header>, <nav>, <main>, <aside>, <footer>）定义页面区域，帮助辅助技术用户快速导航。

ARIA 属性：使用 WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) 属性为动态内容和自定义控件提供额外的语义信息，例如：

aria-label：为没有可见文本的元素提供标签。

aria-labelledby：引用其他元素的 ID 作为标签。

aria-expanded：指示可折叠内容的展开/折叠状态。

aria-current：指示当前页面或元素。

aria-hidden：隐藏辅助技术不需要访问的元素。

前景色与背景色对比 (Color Contrast)：

什么是颜色对比度：文本颜色与背景颜色之间的亮度差异。

WCAG 推荐标准：普通文本的对比度至少为 4.5:1，大文本（18pt 或 14pt 加粗）至少为 3:1。

如何提高文字可读性：使用对比度检测工具确保颜色组合符合标准，避免使用对比度过低的颜色。

焦点状态 (Focus Visible)：确保所有可交互元素（链接、按钮、表单）在获得键盘焦点时有清晰的视觉指示，方便键盘用户导航。

键盘导航 (Keyboard Navigation)：确保网站所有功能都可以仅通过键盘操作，无需鼠标。

Skip Link (跳过导航)：提供一个“跳过导航”链接，允许键盘用户直接跳到主要内容区域，避免重复导航。

响应式字体：

字体大小：使用相对单位（如 em, rem, vw）设置字体大小，使其在不同设备上都能良好显示。

行高：设置合适的行高，提高文本可读性。

字距：调整字距，避免文本过于拥挤或稀疏。

点击区域 (Tap Target)：确保移动设备上的可点击区域足够大，方便用户准确点击。

prefers-reduced-motion (减少动画)：尊重用户的系统设置，为有运动敏感的用户提供减少动画的版本。

视频字幕 (Caption)：为视频提供同步字幕，方便听力障碍用户和在无声环境下观看的用户。

音频文字稿 (Transcript)：为音频内容提供文字稿，方便听力障碍用户和需要阅读的用户。

**Lighthouse Accessibility 常见扣分项**

Lighthouse 工具会检测网站的无障碍性，并列出常见的扣分项。

关注并修复这些问题，可以显著提升网站的无障碍性评分：

Background and foreground colors do not have a sufficient contrast ratio：背景色与前景色对比度不足。

Links do not have a discernible name：链接没有可识别的名称。

Buttons do not have an accessible name：按钮没有可访问的名称。

Image elements do not have alt attributes：图片缺少 alt 属性。

Form elements do not have associated labels：表单元素没有关联的 label 标签。

Heading elements are not in a sequentially descending order：标题元素未按顺序降序排列。

Document does not have a lang attribute：文档缺少 lang 属性。

iframe elements do not have a title：iframe 元素缺少 title 属性。

Interactive controls are not keyboard focusable：交互式控件无法通过键盘聚焦。

---

## WordPress 如何优化 Core Web Vitals

WordPress用户基数巨大,这块单独说说。

主机方面,Kinsta、WP Engine、SiteGround这类针对WordPress优化过的托管服务商,TTFB表现普遍更好。

缓存插件是刚需,WP Rocket、LiteSpeed Cache这些能生成静态HTML,减轻服务器压力。

CDN也是标配,Cloudflare、Bunny.net接一下,静态资源加载能快不少。

图片这块用Imagify、ShortPixel这类插件自动压缩转格式,顺便开启延迟加载。

CSS和JS的优化也交给缓存插件来做,合并压缩、生成关键CSS这些功能基本都自带。

数据库要定期清理,冗余数据、修订版本、垃圾评论堆多了也拖慢速度。

插件这块我建议严格把关,能不装就不装,装了也要定期审查,发现拖后腿的果断卸载或者换掉。

---

## Core Web Vitals 检测工具

PageSpeed Insights应该是最常用的,移动端桌面端都能测,实验室数据和真实用户数据都给你。

Google Search Console里的”体验”板块能看到全站的Core Web Vitals概览,方便定位问题页面。

Lighthouse集成在Chrome DevTools里,适合开发阶段快速自查。

第三方工具里,GTmetrix、WebPageTest这两个用得比较多,能看到详细的瀑布图和多地点测试结果。

DebugBear和SpeedCurve偏向持续监控,适合长期跟踪。

无障碍检测方面,WAVE、Lighthouse和axe DevTools都是免费好用的选择,装个浏览器扩展就能实时查问题。

---

## Core Web Vitals 优化案例

之前有个博客网站,LCP一直卡在4.5秒左右,查下来发现是文章首图太大又没优化。

处理办法也不复杂:首图转WebP、压缩、设置width/height、加srcset做响应式、首图preload加fetchpriority=”high”、再接个CDN。

折腾一圈下来,LCP降到1.8秒,跳出率降了15%左右。

另一个是WordPress电商站,INP高到600毫秒,原因是装了太多插件,JS执行时间爆表。

审查一遍插件,能删的删掉,用WP Rocket的JS优化功能把脚本延迟加载和压缩合并,关键交互(比如加入购物车按钮)的逻辑优先加载,非关键的第三方脚本(客服插件之类)全部延迟。

INP最后降到150毫秒,购物车转化率提升了8%左右。

不过这个效果也因站而异,插件基数、服务器配置都会影响最终提升幅度。

---

## Core Web Vitals 优化自查清单

**LCP**

TTFB是否控制在600毫秒以内

是否上了CDN

首屏关键图片是否压缩并转成了WebP/AVIF

首屏图片是否设置了width/height或者aspect-ratio

关键资源是否用了preload或fetchpriority=”high”

关键CSS是否内联,非关键CSS是否异步加载

非关键JS是否延迟加载

**INP**

JS执行时间是否已经最小化

是否用了代码分割和摇树优化

耗时任务是否转移到了Web Worker

第三方脚本是否延迟加载

长任务是否已经拆分

事件监听器是否优化(事件委托、节流防抖)

DOM节点数量是否精简

**CLS**

图片视频是否都设置了尺寸或aspect-ratio

广告位和动态内容是否预留了空间

iframe是否固定了尺寸

字体加载是否用了font-display

是否避免了加载后动态插入影响布局的元素

**Accessibility(无障碍)**

图片是否有alt属性

颜色对比是否符合 WCAG 标准 (普通文本 ≥ 4.5:1，大文本 ≥ 3:1)？

链接按钮是否有可识别名称

Heading 标题是否按层级使用 (H1-H6)？

键盘导航是否顺畅,焦点是否可见

是否正确使用了语义标签 (header, nav, main, aside, footer)？

html的lang属性是否设置

表单是否关联了label

iframe是否有title

是否提供了跳过导航 (Skip Link)？

视频是否提供字幕，音频是否提供文字稿？

---

**写在最后**

Core Web Vitals这套东西,做起来其实没有传说中那么玄乎,大部分工作都是些具体、琐碎的技术细节——图片压一压、脚本延迟加载一下、给元素留个位置。

难的不是知道怎么做,是愿不愿意花时间把这些细节一项项抠出来。

2026年这个节骨眼上,用户对速度和流畅度的期待只会更高,不会更低。

与其等排名掉了再回头补,不如现在就拿PageSpeed Insights或者Search Console跑一遍,看看自己网站哪块拖了后腿。

剩下的,就是把这篇里提到的方法挨个落地,慢慢磨。