网店核心网页指标详解：LCP、INP 与 CLS

核心网页指标（Core Web Vitals）中 LCP、INP、CLS 衡量什么，第 75 百分位的良好与较差阈值，实验室数据与实测数据的区别，以及 Shopify 和 WooCommerce 网店的常见优化方法。

FixReports 编辑团队阅读约需 5 分钟

核心网页指标（Core Web Vitals）是 Google 用来描述真实访问者页面体验的三项指标：衡量加载速度的最大内容绘制（LCP）、衡量响应速度的与下一次绘制的交互（INP），以及衡量视觉稳定性的累积布局偏移（CLS）。当至少 75% 的访问处于“良好”区间时，页面即为达标：LCP 不超过 2.5 秒，INP 不超过 200 毫秒，CLS 不超过 0.1，移动端和桌面端分别衡量。在网店中，指标不达标通常源于体积过大或被延迟加载的首屏大图和产品图片、应用和跟踪脚本、网页字体，以及在页面显示后把内容往下推的横幅或评价插件。

要点

核心网页指标的阈值是多少？

当一个页面的三项指标在页面加载的第 75 百分位都落在良好区间时，该页面就通过了核心网页指标评估。

指标衡量内容良好需要改进较差
LCP视口中最大的图片、视频或文本块完成渲染所需的时间2.5 秒或更短超过 2.5 秒，最多 4.0 秒超过 4.0 秒
INP从点击、轻触或按键到绘制出下一帧所需的时间200 ms 或更短超过 200 ms，最多 500 ms超过 500 ms
CLS可见内容意外移动的程度0.1 或更低超过 0.1，最多 0.25超过 0.25

阈值来自 web.dev 的 LCP （在新标签页中打开）、INP （在新标签页中打开） 和 CLS （在新标签页中打开） 指南，截至 2026 年 10 月。

第 75 百分位意味着结果反映的是大多数访问者的体验，而不只是速度最快的那部分人；Google 还会分别统计移动端和桌面端 （在新标签页中打开）。当三项指标都为良好时，PageSpeed Insights 会判定页面通过；如果 INP 数据不足，则只根据 LCP 和 CLS 来判断（PageSpeed Insights 文档 （在新标签页中打开））。Google 表示，稳定版的核心网页指标每年最多变更一次。

在网店中，LCP 元素往往是首屏横幅或主产品图片，这正是图片处理如此重要的原因。

为什么 INP 在 2024 年 3 月取代了 FID？

INP 之所以取代 FID，是因为 FID 只衡量第一次交互，而且只衡量其延迟的一部分，而 INP 关注的是整个访问过程中的交互。

Google 于 2023 年 5 月宣布 INP 将成为核心网页指标，这一变更于 2024 年 3 月 12 日 （在新标签页中打开）生效。FID 只报告第一次交互，而且只报告其输入延迟，不包括运行事件处理程序和绘制结果所花的时间。INP 会观察整个访问期间的点击、轻触和按键操作，并报告耗时最长的一次（忽略异常值）；滚动和悬停不计入。CrUX API 和 PageSpeed Insights API 的用户须在 2024 年 9 月 9 日之前完成切换（web.dev （在新标签页中打开））。

每次交互都包含三个部分：输入延迟（等待繁忙的脚本执行完毕）、处理时长（运行事件处理程序）和呈现延迟（绘制下一帧）（web.dev （在新标签页中打开））。

在网店中，这些交互包括变体选择器、数量按钮、加入购物车、购物车抽屉、筛选器和菜单。一个页面可能因为第一次轻触响应很快而通过 FID，但当顾客稍后打开筛选器时，仍然会感觉很卡。

实验室数据和实测数据有什么区别？

实验室数据来自在固定条件下进行的一次测试，而实测数据（field data）是长期从真实访问者那里收集的；Google 建议根据实测数据来决定优先修复什么（web.dev （在新标签页中打开））。

实验室数据实测数据
来源一次模拟的页面加载（Lighthouse、Chrome DevTools、PageSpeed Insights 的实验室数据部分）真实的 Chrome 访问者（Chrome 用户体验报告），或您自己的真实用户监控
条件固定的设备和网络。Lighthouse 默认的移动端测试 （在新标签页中打开）使用“Slow 4G”（往返时间 150 ms，下行 1.6 Mbps）和 4 倍 CPU 降速访问者实际使用的各种设备、网络和所在地
INP普通的页面加载测试不衡量 INP。总阻塞时间（TBT）可作为粗略的替代指标根据真实交互测得
最适合调试问题，以及在发布前检查改动效果了解访问者实际获得的体验

TBT 会把每个主线程任务中超过 50 ms 的部分累加起来；web.dev 建议在普通移动设备上将其控制在 200 ms 以下，但也指出它不能替代 INP（web.dev （在新标签页中打开））。

Chrome 用户体验报告（CrUX）有三个细节对网店很重要：

  • 它是滚动 28 天的平均值 （在新标签页中打开），每天更新。
  • 它涵盖桌面版和 Android 版 Chrome 中符合 Chrome 报告条件的用户。iOS 上的 Chrome 不在统计范围内，所以如果一家网店的顾客大多使用 iPhone，看到的实测数据只来自部分受众（方法说明 （在新标签页中打开））。
  • 只有可公开发现且访问量足够的页面和来源（origin）才会出现在报告中，因此低流量网店可能只有来源级别的数据，甚至完全没有数据。

Shopify 的网站性能仪表板 （在新标签页中打开）也会报告真实用户 LCP、INP 和 CLS 的第 75 百分位数据，但统计周期是 30 天而不是 28 天，因此与 CrUX 的数据会有一些出入。

是什么拖慢了网店页面的 LCP？

网店的 LCP 偏慢，通常是因为主图太大、被浏览器发现得太晚，或者被延迟加载、动画效果刻意推迟了。

  • 延迟加载 LCP 图片。 web.dev 明确表示绝不要这样做（web.dev （在新标签页中打开））。它对 WordPress 页面的分析发现，使用原生延迟加载的网站第 75 百分位的 LCP 更慢，而不对首屏图片延迟加载就能消除这种退步（web.dev （在新标签页中打开））。
  • 图片被发现得太晚。 用 CSS background-image 设置的首屏大图，或由轮播脚本注入的图片，并不在浏览器最先扫描的 HTML 中。Shopify 建议不要用 CSS 背景来呈现首屏主内容，也不要对 LCP 图片使用淡入效果（Shopify （在新标签页中打开））。
  • 优先级过低。 在布局完成之前，图片都以低优先级加载，因此 Shopify 建议为 LCP 图片设置 fetchpriority="high"（Shopify （在新标签页中打开））。web.dev 指出，如果给一两张以上的图片设置该属性，它的作用就会打折扣（web.dev （在新标签页中打开））。
  • 阻塞渲染的 CSS 和脚本。 <head> 中的大型样式表和同步脚本，即使在图片下载完成之后也会延迟渲染（web.dev （在新标签页中打开））。
  • 文件大小和字体。 使用现代图片格式、srcset 和 sizes，以及 CDN。对于网页字体，请使用 auto 或 block 以外的 font-display 值。
<!-- Main product image: real src in the HTML, eager, high priority -->
<img src="/images/linen-shirt-1200.webp"
     srcset="/images/linen-shirt-600.webp 600w, /images/linen-shirt-1200.webp 1200w"
     sizes="(min-width: 990px) 50vw, 100vw"
     width="1200" height="1500"
     fetchpriority="high"
     alt="Natural linen shirt, front view">

<!-- Gallery images below the first screen: lazy -->
<img src="/images/linen-shirt-back-600.webp" loading="lazy"
     width="600" height="750" alt="Natural linen shirt, back view">

是什么让网店页面的 INP 变慢？

网店的 INP 慢，通常意味着主线程上的 JavaScript 太多（其中很多来自应用、跟踪代码和主题功能），顾客的轻触操作只能排队等待。

如果顾客在评价、在线客服和数据分析脚本仍在运行时点按“加入购物车”，这次点按就得等待。会重新渲染整个产品表单的变体选择器会增加处理时长。庞大的下拉菜单和带有大量色块的产品系列网格则会增加呈现延迟。

web.dev 建议拆分长任务并让出主线程，先更新屏幕、再推迟处理其余工作，同时缩小 DOM 规模（web.dev （在新标签页中打开））。Shopify 还补充了针对网店的步骤：审查每个应用、像素（pixel）和主题脚本，推迟加载非关键内容，在用户交互时再加载相应功能，并在没有进行测试时关闭 A/B 测试的防闪烁代码片段（Shopify （在新标签页中打开））。

产品页和产品系列页的布局偏移是什么原因造成的？

网店的布局偏移主要来自在首次渲染后才出现或改变尺寸的内容：没有设置尺寸的图片、公告栏和 Cookie 提示栏、评价插件、应用区块以及字体替换。

web.dev 列出的常见原因包括：尺寸未知的媒体、插入到现有内容上方的内容、会自行调整大小的第三方插件，以及与后备字体尺寸不同的网页字体（web.dev （在新标签页中打开））。在网店中，这意味着插入页面顶部的免运费提示栏、在标题之后才加载的星级评分、价格下方的分期付款信息，以及推荐商品轮播。Shopify 指出，弹窗内容也可能导致偏移（Shopify （在新标签页中打开））。

用户输入后 500 ms 内发生的偏移不计入，但滚动时发生的偏移会计入，而实验室工具往往检测不到这类偏移（web.dev （在新标签页中打开））。请为图片设置 width 和 height 或 CSS aspect-ratio，为插件预留空间，以浮层形式显示横幅，用 size-adjust 减少字体替换造成的偏移，并用 transform 而不是 top 或 left 来实现动画。

/* Reserve space for a reviews summary that loads after the page */
.product-reviews-summary { min-height: 24px; }

/* Keep product cards from jumping while images load */
.product-card img { width: 100%; height: auto; aspect-ratio: 4 / 5; }

如何在 Shopify 上改善核心网页指标？

在 Shopify 上，大部分提升来自三件事：以高优先级立即加载第一张图片、精简应用脚本，以及在后台的网站性能报告中检查效果。

在后台查看数据

在线商店 > 模板（Online Store > Themes）页面上会显示摘要，完整的 LCP、INP 和 CLS 报告则位于 分析 > 报告（Analytics > Reports）下。数据最多可能延迟 36 小时，并且必须关闭私密模式（private mode）（Shopify 帮助中心 （在新标签页中打开））。

在 Liquid 中控制图片加载

除非您设置了 preload，否则 image_tag 过滤器会对页面靠下的分区中的图片进行延迟加载（image_tag 参考文档 （在新标签页中打开））：第 1 到第 3 个分区立即加载，从第 4 个分区起延迟加载。由于在主题编辑器中 section.index 的值为 nil，请用 > 3 而不是 <= 3 来判断：

{%- if section.index == 1 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'eager', fetchpriority: 'high', widths: '600, 900, 1200, 1600', sizes: '100vw' }}
{%- elsif section.index > 3 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'lazy', sizes: '100vw' }}
{%- else -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: sizes: '100vw' }}
{%- endif -%}

在产品网格中，Shopify 建议只对前几张卡片使用立即加载（例如 forloop.index <= 4）（Shopify （在新标签页中打开））。preload: true 要谨慎使用；Shopify 建议只预加载一到两个被浏览器较晚发现的资源。

清除应用留下的代码

在 在线商店 > 编辑模板 > 应用嵌入（Online Store > Edit theme > App embeds）下关闭未使用的应用嵌入（Shopify 帮助中心 （在新标签页中打开））。卸载应用会移除其应用区块，但直接修改过主题文件的应用可能会留下“幽灵代码”，Shopify 表示这些代码可能导致质量和性能问题（Shopify （在新标签页中打开））。Shopify 还表示，script tag（脚本标签）将于 2027 年 3 月 1 日停止运行。在字体方面，Shopify 建议使用其自有 CDN 或系统字体，而不是外部字体服务（Shopify （在新标签页中打开））。

如何在 WooCommerce 上改善核心网页指标？

在 WooCommerce 上，要确保插件不会覆盖 WordPress 的图片优先级处理，对购物车和结账以外的所有页面启用缓存，并移除那些没有必要却在所有页面加载的脚本。

  • 保留 WordPress 核心的图片处理。 自 WordPress 6.3（2023 年 8 月 8 日发布）起，WordPress 核心会为可能的 LCP 图片（默认至少 50,000 平方像素）添加 fetchpriority="high"，并对前三张内容图片跳过延迟加载（Make WordPress Core （在新标签页中打开））。如果某个优化插件添加了自己的延迟加载，请确认它排除了首屏大图和主产品图片。
  • 缓存页面，不缓存购物车。 WooCommerce 的指南建议使用服务器或插件的页面缓存以及 CDN，同时不要缓存购物车和结账页面（WooCommerce 开发者文档 （在新标签页中打开））。
  • 检查 cart fragments。 自 WooCommerce 7.8 起，cart fragments 脚本只在页面上有购物车（Cart）小工具时才加载，但有些主题把这个小工具写死在代码里。Mini-Cart 区块不使用 cart fragments（WooCommerce 开发者博客 （在新标签页中打开））。
  • 找出拖慢速度的插件。 WooCommerce 建议用 Query Monitor 找出慢插件，并推迟加载非关键的 JavaScript。

如果您的布局在首屏显示超过三张图片，可以提高 WordPress 的这个阈值：

// functions.php: skip lazy loading for the first 4 content images (default is 3)
add_filter( 'wp_omit_loading_attr_threshold', function () {
    return 4;
} );

修复后多久才能看到效果？

实验室测试能立即显示修复效果，但实测数据最多需要大约四周才能完全反映出来，因为 CrUX 取的是过去 28 天的平均值。

由于单次测试的结果会有波动，请在改动前后分别多次运行实验室测试，然后在 PageSpeed Insights、Search Console 的核心网页指标报告或 Shopify 的报告中观察实测数据。免费扫描大约一分钟就能给出初步结果。性能修复报告会运行限速的移动端实验室测试（慢速 4G、4 倍 CPU 降速），并补充 Chrome 用户体验报告的实测数据；当 Google 拥有您店铺的足够数据时，还会包括 INP。

常见问题

核心网页指标会影响 Google 排名吗？

Google 表示，其排名系统会使用核心网页指标，但良好的分数并不能保证排名靠前，而且即使页面体验较差，Google 仍会展示最相关的内容（Google 搜索中心 （在新标签页中打开））。

为什么 PageSpeed Insights 没有显示我网店的实测数据？

CrUX 只收录可公开发现、且有足够多符合条件的 Chrome 访问者的页面和来源。低流量网店可能只有来源级别的数据，甚至完全没有，因此请依靠实验室测试和您所用平台自带的报告。

Lighthouse 得分必须达到 90 分以上才算通过核心网页指标吗？

不需要。Lighthouse 性能得分是实验室结果，而核心网页指标评估使用的是第 75 百分位的实测数据，因此页面可能 Lighthouse 得分一般却通过评估，也可能得分很高却未通过。

应该对所有产品图片进行延迟加载吗？

不应该。对首屏以下的图片进行延迟加载，但首屏大图和主产品图片要立即加载，并为其中一张设置 fetchpriority="high"。

为什么我的移动端结果比桌面端差？

Google 分别衡量移动端和桌面端，而手机的处理器和网络速度更慢。Lighthouse 的移动端测试使用 Slow 4G 网络配置和 4 倍 CPU 降速来模拟这种情况。

资料来源

全部指南