独立站Mobile Optimization：用PageSpeed Insights查移动端三项指标

移动端速度自查，最快的路子就是打开PageSpeed Insights，输入独立站网址，切到移动端，把LCP、INP、CLS三项的字段数值记下来，对照2.5秒、200毫秒、0.1三个门槛看哪项没达标，再决定改什么。前提只有一个：你查的得是移动版页面，因为Google索引和排名用的就是它。

桌面端做得再漂亮，手机端慢一拍，用户从搜索结果点进来看到的就是另一回事。如果你还没把整个站的框架搭起来，独立站运营可以先过一遍。这些工具的入口都在Google那边，能不能正常打开，按官方入口查。

• Google用智能手机代理抓的移动版内容做索引和排名，这称为mobile-first indexing。
• Core Web Vitals被排名系统使用，但没有单一的page experience信号。
• 门槛是LCP2.5秒或更短、INP200毫秒或更短、CLS0.1或更小，按75百分位、分移动端和桌面端。
• 先看字段数据，再用实验室工具复现，按LCP、INP、CLS分别改。
• 拿到好分数不保证排名靠前。

这篇只讲移动端速度与Core Web Vitals的自查、改进和回查顺序，响应式布局和移动端结账流程不在这篇展开。

独立站移动端优化到底在优化什么

移动优先索引：索引和排名用的是移动版内容

Google用智能手机代理抓页面，索引和排名依据的是移动版内容。桌面版写得再全，手机版缺了，Google看到的就是缺的那一份。

有移动版页面不是内容被收录的必需条件，缺了也能被收录，但推荐程度很高。Google推荐响应式网页设计，因为最容易实现和维护。这里有个容易漏的点：移动版内容要和桌面版一致，移动版内容更少，可能带来流量损失，因为Google从页面上拿到的信息变少了。

内容在手机上放不下，用折叠面板或标签页收起来，别删。删内容来省空间，对索引没好处。响应式布局和触控适配的具体做法，移动端适配的9个步骤从布局到触控逐项讲了一遍。

Core Web Vitals是三项：加载、交互性、视觉稳定性

Core Web Vitals是Web Vitals的子集，适用于所有网页，所有站长都应该测，它会在所有Google工具里出现。当前聚焦三个方面：加载、交互性、视觉稳定性，分别对应LCP、INP、CLS三个指标。

LCP管加载，INP管交互，CLS管视觉稳定。三个指标各有各的门槛，下一节单独讲。

官方口径：被排名系统使用，但没有单一信号

Core Web Vitals被排名系统使用，建议站长做到良好。也说得很清楚：没有单一的page experience信号，核心排名系统看的是多种信号。

自查看页面是否有良好的Core Web Vitals，也看页面是否以安全方式提供、内容在移动设备上是否显示良好。只盯一个方面，不算把移动端优化做完。

响应式布局和触控适配前面指了路，移动端结账流程的优化另开题讲，这篇只收在速度与Core Web Vitals这一块。

先看哪三个数：LCP、INP、CLS各测什么

LCP：视口内最大图片、文本块或视频的渲染时间

LCP报告视口内最大图片、文本块或视频相对首次导航的渲染时间。用户打开页面，眼睛最先落到的那个大块内容多久出来，LCP量的就是这个。

它衡量的是加载性能。一张首屏大图、一段标题、一个视频封面，谁占在这个位置谁就是LCP候选元素。改LCP之前先找到这个候选元素，别对着整页乱改。

INP：所有交互的延迟，报一个几乎所有交互都低于的值

INP观察用户对页面所有交互的延迟，报一个几乎所有交互都低于的值。点按钮、轻触卡片、键盘输入，这些动作从发生到界面给出反馈，中间卡了多久，INP都记。

它衡量的是交互性。Chrome使用数据显示，用户90%的页面时间花在加载之后，页面打开之后卡不卡，直接影响用起来顺不顺。INP只观察鼠标点击、触屏轻触、键盘按键三类交互，悬停、缩放、滚动不观察。

CLS：意外布局偏移的频率，量化视觉稳定性

CLS量化用户遇到意外布局偏移的频率。页面正在看，图片突然撑开把文字顶下去，或者广告位加载完把按钮挤走，这类跳动就是布局偏移。

它衡量的是视觉稳定性。用户没点任何东西，页面自己动了，CLS就记一笔。偏移越频繁、幅度越大，分越高，越差。

为什么不是FID了：FID只测首次交互的输入延迟

INP是FID的继任指标。FID只测首次交互的输入延迟，用户第一次点之前卡不卡、点完之后处理慢不慢，它不管。INP看的是所有交互的完整时长，比FID更贴近真实体验。

这也是为什么现在查移动端速度，盯的是INP不是FID。FID已经退出Core Web Vitals，继续拿它做判断，会漏掉大量用户实际遇到的卡顿。

怎么做：从PageSpeed Insights读到按优先级改完

三项指标各自怎么读、门槛多少，Core Web Vitals三项指标里有逐项说明。下面是从拿到数据到改完验收的完整顺序。

第1步 打开PageSpeed Insights，切移动端，先记字段数据

打开PageSpeed Insights，输入独立站的一个移动页面URL，切到移动端标签，把LCP、INP、CLS三项的字段数值抄下来，再把下面的机会项清单复制一份。

字段数据来自真实用户的Chrome访问，是用户实际体验到的数。实验室测量不能替代字段测量，这个顺序不能反。

字段区没数据，说明CrUX里没有足够样本。改看Search Console的Core Web Vitals报告里同一组URL。

第2步 在Search Console看移动端分组，定先改哪一组URL

打开Search Console的Core Web Vitals报告，切到移动端分组，看哪些URL组未通过，决定先改哪一组。

核心排名系统一般按页面逐一评估，也有全站评估。分组看能知道问题集中在产品页、分类页还是文章页，先修影响面最大的那组。

第3步 用DevTools或Lighthouse在实验室复现，找LCP候选元素和偏移来源

在Chrome DevTools或Lighthouse里对选定的移动页面跑一次实验室测量，看LCP候选元素是哪个，看布局偏移的来源条目。

CrUX能告诉你有没有问题，不能告诉你问题原因。实验室工具把页面加载过程拆开，能指出具体是哪个元素、哪次偏移拖了后腿。

实验室CLS可能低于字段CLS，实验室工具通常只测页面加载期间的偏移，真实用户在加载之后的交互里还会遇到偏移。别拿实验室的低分当成没问题。

第4步 按LCP到INP到CLS的顺序改，一次只动一项

LCP先处理候选元素本身，换图、压缩、预加载都行，先让那个大块内容早点出来。INP走常见用户流程，在页面加载时跟页面交互，找出主线程最忙时的慢交互。CLS给可能变化的异步请求预留空间，显示加载指示器，别让内容加载完把布局顶开。

三项互相牵连，混着改无法归因。改完LCP再改INP，出问题时能知道是哪次改动带来的。

改完回PageSpeed Insights看字段数据有没有移动。字段有滞后，别当天改完当天就下结论，至少等一段时间，样本更新了再看。商品页到结算路径设计讲的是从商品页到结算这条路怎么排，移动端上这条路也是用户会走的。

第5步 接入web-vitals库，自建真实用户监测

用web-vitals库的onLCP、onINP、onCLS三个函数上报，优先用navigator.sendBeacon，回退到fetch。数据汇总后，看页面是否在至少75%的访问中达到门槛。

Google强烈建议站点自建真实用户监测，CrUX不提供逐次访问的详细遥测数据。只看CrUX和Search Console，你不知道具体哪一次访问、哪一个交互出了问题。

数据汇总后，三项指标分移动端和桌面端看75百分位。如果移动端不达标而桌面端达标，改的方向就锁定在移动端。

三个门槛和几个要记住的数

三项指标的门槛按75百分位、分移动端和桌面端测量。先把这张表记住，后面看任何报告都对照它。

三项都在75百分位达标才算通过。任何一项没到，这次Core Web Vitals评估就不算过。

CLS的session window是相邻偏移间隔小于1秒、整个窗口最长5秒。用户输入后500毫秒内的偏移带hadRecentInput标记，可以从计算中排除。这个标记只对点击、轻触、按键这类离散输入为真，滚动、拖拽、捏合缩放不算。

INP计算时每50次交互忽略一次最高交互，再报75百分位。这样页面交互次数多的时候，不会被一两次极端卡顿拉偏。

常见误区和排查：分数好看不等于排名靠前

不少站把桌面端调得很顺，手机端一直放着没管。速度这块查完，下面这几个坑还得绕开。

误区一 拿到好分数就以为能排前面

在Search Console或别的工具里拿到好结果，不保证页面排在Google搜索结果顶部。分数好只说明速度这块达标了，排名还看内容是否相关、是否对用户有用。

误区二 为SEO追满分

只为SEO原因追求满分，可能不是最值得花时间的事。把LCP从没达标改到达标有意义，已经达标了再往上抠，可能不值。

误区三 只看实验室数据

实验室测量不能替代字段测量。实验室环境固定，真实用户的设备、网络、浏览器各不相同，实验室数据好看不等于真实用户觉得快。

误区四 用Lighthouse测INP

Lighthouse这类在模拟环境无用户加载页面的工具测不了INP，因为没有用户输入。可以看TBT作为代理指标，但TBT不是INP，别拿TBT的分数当INP达标。

误区五 以为实验室CLS等于真实CLS

实验室工具报出的CLS可能低于真实用户体验，因为实验室通常只测页面加载期间的偏移。真实用户在加载之后的交互里还会遇到偏移，这部分实验室看不到。

排查清单：移动页被挡住或被漏掉

速度之外，移动页本身有没有被挡住，也要逐项过一遍。移动页被noindex标签挡了索引，内容再快也进不了搜索结果。移动页缺桌面页的结构化数据、缺重要图片、缺title，都是常见问题。多个桌面页重定向到同一个移动页，或者桌面站大部分页面重定向到移动站首页，也会出问题。主机负载不足，部分主机没有足够hostload，抓取会受影响。

排查用URL Inspection工具，看内容在渲染页上是否可见，渲染页是Google看到页面的方式。站点还没启用mobile-first indexing、启用后排名下降、或者Search Console收到消息，就对照常见错误清单逐项解决。

速度修完，想量化改动对转化的影响，GA4量出转化基线讲了怎么先量出一条线再对比。

AI能帮哪几步、哪几步必须人来做

AI能帮的是整理和归类这些体力活，有三四步可以交给它。

1. 把PageSpeed Insights导出的机会项清单按LCP、INP、CLS三类归堆，排出先改哪几项。
2. 把CrUX或Search Console的字段数据整理成移动端75百分位三项指标是否达标的对照表。
3. 针对LCP候选元素、布局偏移来源，让它列出可能原因清单，再由人去实验室验证。
4. 把web-vitals库的接入代码按站点现有分析端点改写。

能直接照抄的提示词有三条，是本文给的示例，不是官方模板。

第一条：下面是我从PageSpeed Insights复制的移动端机会项清单：[粘贴]。请按LCP、INP、CLS三类分组，每项标出它影响哪个指标，并按官方门槛（LCP2.5秒、INP200毫秒、CLS0.1）判断优先级，不要编造清单里没有的项。

第二条：这是我站点移动端75百分位的三项指标：[粘贴LCP、INP、CLS数值]。请对照官方门槛逐项判断达标与否，并指出哪一项离门槛最远，只根据我给的数据说，不要推测排名效果。

第三条：这是我的web-vitals接入代码和现有分析端点：[粘贴]。请改成用onLCP、onINP、onCLS三个函数上报，保留sendBeacon优先、fetch回退的写法，不要引入新依赖。

有三件事必须人来做。在PageSpeed Insights输入独立站URL，切到移动端，记下三项指标的字段数值和机会项清单。在Search Console打开Core Web Vitals报告，看移动端分组里哪些URL组未通过，决定先改哪一组。在Chrome DevTools或Lighthouse里对选定的移动页面跑一次实验室测量，看LCP候选元素和布局偏移来源，决定这一轮改哪一项。

AI的归堆不能编造清单里没有的项，达标判断只按你给的数说，不许推测排名效果。改完必须回PageSpeed Insights和实验室各验一次，这一步不能省。

判断和验收之外，剩下盯数据的活可以交给工具。猎者出海的AI Agent有一块是上线运营，自己拉数据，每周给一张改稿单，说清改哪几篇、先改哪篇。改哪几项、改完验收什么，还是人来做。

相关文章：移动端页脚怎么收，讲的也是页面这一块的收尾；改完速度想验证效果，A/B测试六步流程讲了怎么设计对照和看结果。

常见问题

Google搜索排名有没有一个单独的page experience信号？

没有。核心排名系统看的是多种信号，没有一个单独叫page experience的信号。

页面体验是按全站还是按页面评估？

核心排名系统一般按页面逐一评估，包括页面体验相关方面。但也有一些全站评估，不是纯粹的按页算。

页面为什么没有INP值？

常见原因有三个：页面加载了但用户从没点击、轻触或按键；用户只用滚动、悬停这类不被测量的手势；页面被搜索爬虫或无头浏览器访问，没有脚本化交互。

INP和FID有什么区别？

INP考虑所有交互的完整时长，FID只测首次交互的输入延迟。FID不管页面打开之后的卡顿，INP管整个过程。

PageSpeed Insights里INP数据不可用是什么原因？

CrUX数据集里Chrome用户的交互数据不足以算出有意义的INP值。页面访问量或交互量不够，PSI就给不出INP。

实验室里复现慢交互，最有效的做法是什么？

在页面加载时跟页面交互，走常见用户流程，找主线程最忙时的瓶颈。这两条一起用，比随便点几下更容易复现真实用户遇到的卡顿。

移动端速度这件事，查一次改一轮，改完看字段再进下一项。三项都到门槛之后，把精力放回内容和转化上，比继续抠分数划算。猎者出海的AI Agent能在每周的改稿单里把这一块盯住，判断和验收还是由你来做。