提升网站访问速度优化策略

2024年3月12日那天，谷歌把衡量交互速度的FID换成了INP。西班牙一家房产网站Fotocasa，在Search Console里的网址一夜之间从优质变成需要改进，还有一部分掉进欠佳。尺子换了。在秒出海看来，网站访问速度优化这件事，标准从来不在你自己打开网页的手感里，在谷歌手里。

这套标准叫Core Web Vitals，就三项：LCP不超过2.5秒、INP不超过200毫秒、CLS不超过0.1，按真实用户的第75百分位看，手机和电脑分开算。谷歌的排名系统会采用Core Web Vitals，可它排在内容相关性后面。同一个词下面，大家的内容差不多，它才是那个裁判。

所以内容还没写起来的站，先花力气折腾速度，多半是白折腾。

• 达标线三条：LCP2.5秒、INP200毫秒、CLS0.1，手机和电脑分开算，三项全过才算通过。
• INP在2024年3月12日取代FID，Search Console当天就换了指标，PageSpeed Insights和Chrome用户体验报告给了6个月过渡。
• PageSpeed Insights上半截和Search Console都是最近28天的真实用户数据；下半截是Lighthouse跑一次模拟，TechCrunch首页3分钟里从46分掉到25分，上半截的Core Web Vitals照样是通过。
• LCP拆成四段，两段带「延迟」的应该接近0，首屏大图千万别加loading=”lazy”。
• Shopify官方2023年5月9日公开的Carpe店铺案例里，LCP改善52%，改版后流量涨了10%。

这篇只写两件事：Core Web Vitals怎么测、怎么改。WordPress那边缓存插件、图片压缩插件、数据库清理、GZIP、PHP版本这些插件级的操作，CDN的原理和配置，主机怎么选，都另有专门的文章，本篇链过去，不在这里展开，也不教配置。

网站速度对谷歌排名有多大影响：Core Web Vitals算排名信号，但内容相关性排第一

谷歌的帮助文档里有一句原话：我们的排名系统会采用Core Web Vitals。同一篇文档里还有两句得一起读。在Search Console核心网页指标报告里结果好，并不保证您的网页一定能排在Google搜索结果的最前面；仅仅出于SEO原因而试图获得完美的得分，可能并非对宝贵时间的最有效利用。

文档里还有一句：即使网页体验不佳，Google搜索也会尽可能展示最相关的内容。道理不复杂，搜索的前提是先答对问题。答不对，页面再快也排不上去。文档也写了，没有单一的页面体验信号，核心排名系统看的是一组跟整体页面体验相符的信号。

Core Web Vitals以外的那些页面体验项，是不是用HTTPS、移动端显示好不好、广告多不多、有没有插页广告，都不直接帮排名。但做到位能让网站更好用，方向跟排名系统想奖励的一致。评估单位也得分清，通常按网页评估，也有一些网站级评估，所以同一个站里有网址过了、有网址没过，是正常状态。

秒出海的判断是，Core Web Vitals是同等内容质量下的排名裁判，不是决定因素。而且移动端比电脑端更要紧，谷歌收录主要按手机版来。内容还没写好的站，先去把网站内容更新这件事理清楚，比研究速度有用。排名掉了也别第一个怪速度，SEO诊断有它自己的排查顺序。整张清单在技术SEO优化教程那篇里，速度只是其中一节，这篇算那一节的展开。

Core Web Vitals是什么：LCP、INP、CLS三项指标和达标线

Core Web Vitals是一组衡量加载性能、交互性、视觉稳定性的指标，量的是真实用户的体验，不是你自己那台电脑上打开一次的感觉。三项的达标线，Search Console帮助页里有一张状态定义表，直接照抄。

指标	量什么	优质（帮助文档里叫良好）	需要改进	欠佳
LCP 最大内容渲染时间	加载：视口里最大那块内容画出来的时间	不超过2.5秒	2.5秒到4秒	超过4秒
INP 交互到下次绘制	交互：点下去到画面有反应	不超过200毫秒	200毫秒到500毫秒	超过500毫秒
CLS 累积布局偏移	稳定：元素意外挪位的累计分数	不超过0.1	0.1到0.25	超过0.25

表上这三行，还得配三条规则一起看：按真实用户的第75百分位取值，手机和电脑分开统计，三项全部达到优质，Core Web Vitals评估结果才写通过。缺一条都不算。

LCP：首屏最大那块内容画出来的时间

LCP量的是从用户请求网址，到视口里最大那块可见内容画出来的时间。最大的元素通常是一张图或者一段视频，也可能是一大块文字。

常有人问网站打开速度多少毫秒算正常。官方的页面加载速度标准里没有整页打开时间这一项，给的是LCP不超过2.5秒，就是上表那三行。

INP在2024年3月12日取代FID

INP量的是整个访问期间所有交互的响应速度，点击、点按、键盘操作都算，悬停、缩放、滚动不算。它从你开始交互算到浏览器下一次画出一帧。用户没点过，这个页面就没有INP数据。

它跟FID的差别在范围。FID只量第一次交互的延迟，后面卡不卡，一概看不见。谷歌2023年5月宣布用INP替换FID，2024年3月12日正式生效，Search Console当天就删掉FID改用INP，PageSpeed Insights和Chrome用户体验报告给了6个月过渡期。谷歌当时还写了一句：为FID做的优化是改INP的好基础，以前做过的活儿不算白干。

现在网上还有文章写FID要控制在100毫秒以内。看到这种标准，直接按INP不超过200毫秒来理解就行。2024年3月12日那天，Fotocasa在Search Console里一夜之间从优质变成需要改进，是尺子换了，FID看不见的那些慢交互被INP量了出来。细节放到下面INP那一节。

CLS：元素意外挪位的累计分数

CLS量的是页面元素意外挪位的累计分数。你正读着一段文字，广告加载出来把正文推下去，图片加载完把下面的内容顶开，分数就是这么一点点攒出来的。

FCP、TTFB、TBT不在这三项里，它们是诊断用的辅助指标，TBT还是实验室指标。FCP是首次内容绘制的时间，TTFB是第一字节时间，TBT是总阻塞时间，看报告的时候有用，但不是Core Web Vitals。

网站速度测试怎么做：PageSpeed Insights看上半截真实用户数据，下半截Lighthouse分数会跳

PageSpeed Insights上半截：真实用户的28天数据决定评估结果

打开PageSpeed Insights，一份报告分上下两半。上半截写的是了解您的真实用户的体验，数据来自Chrome用户体验报告最近28天的真实访问，右上角可以切「此网址」和「源」。Core Web Vitals评估结果是「通过」还是「未通过」，看的就是这里。

拿2026年10月17日测的TechCrunch首页举个例子。那是一家美国的科技新闻网站，跟秒出海没有关系。手机端上半截显示的是此网址、最近28天、各种移动设备，样本很多，评估结果通过，LCP1.6秒、INP162毫秒、CLS0.06，另外两个重要指标FCP1.6秒、TTFB0.7秒。这一半是真实用户数据，也是排名系统会看的那部分。

下半截是Lighthouse模拟一次，量不了INP

下半截写的是诊断性能问题，是Lighthouse拿一台模拟的中端手机、在低速4G节流下跑一次。它量不了INP，因为没有真人交互，只能用TBT这个实验室指标顶着。页面自己也写着，这些都是估算值，且可能会因时而异。

同一份TechCrunch报告的下半截是性能46分，落在0到49的红色档，FCP2.7秒、LCP5.0秒、TBT940毫秒、CLS0.073、Speed Index11.4秒。诊断里还有几条：渲染阻塞请求预计缩短860毫秒、最大限度地减少主线程工作6.1秒、缩短JavaScript执行用时3.1秒、应避免出现长时间运行的主线程任务发现了20项。

过了3分钟，同一个网址再跑一次。上半截的真实用户数据一个字没变，下半截变成性能25分，FCP8.4秒、LCP16.1秒、TBT4,680毫秒、CLS0.029、Speed Index13.3秒。这家网站的性能分只有46和25，上半截的Core Web Vitals照样是通过。

这一节要记住的就一句：Lighthouse分数会浮动，排名看的是上半截。

下半截的用处是找问题、改完当场验证，不是拿去当成绩单。顺带说一句，Lighthouse的SEO那一栏，页面自己就写了还有很多其他因素可能会影响网页排名但没有被纳入评估，其中就包括核心网页指标衡量结果。

PageSpeed Insights显示没有足够的真实用户数据怎么办

新站或者流量还小的页面，上半截经常提示没有足够的真实用户数据。这时候右上角的源就是退路，它显示的是整个网站最近28天的真实用户表现，粒度粗，比什么数据都没有强。整站数据也拿不到，就先用下半截找问题，上线前把明显的毛病改掉。

秒出海的AI Agent里，SEO/GEO优化员工管的正是这块。页面在上线前先跑一遍检查，首图有没有被加懒加载、有没有阻塞渲染的资源，在这一步就过掉，不留给以后补。

Search Console核心网页指标报告怎么看：按网址群组、取最差那项、28天才有结论

报告在哪、怎么点进去，Google Search Console使用教程那篇有从登录到看报告的完整步骤，这里不重复。这一节只讲这份报告怎么读，以及它跟PageSpeed Insights为什么经常对不上。

进来先看手机那一张。谷歌收录以手机版为准，所以先看手机这张，这个背景在移动优先索引那篇里有完整说明。报告按网址群组划分，一个群组是一批体验相近的网页，群组的状态取的是LCP、INP、CLS三项里最差的那一项。

一项拖后腿，整个群组都跟着难看。

群组的数值是过去28天里75%的访问达到的值。数据不够的群组会并进源组，源按协议加主机名分，http和https算两个。群组下面列的例网址按展示次数从高到低排，先修排在前面的，先修状态是欠佳的，再修需要改进里影响网址多的。

PageSpeed Insights和Search Console对不上是正常的

PageSpeed Insights一般按单个网址测，Search Console按群组看，单个网址很可能就是群组里的异常值。一边显示未通过、另一边显示优质，不用怀疑哪个坏了。要判断整站情况，以Search Console的群组为准；要研究某一个页面，看PageSpeed Insights那个网址的上半截。

没改网站，状态却整批变了

没动过网站，很多网页的状态整批变了，先别慌。这些网页可能本来就在达标线的边上，一次流量激增、图片服务的响应变一下，就能把它们推过线。这跟2024年3月12日Fotocasa那种整批变黄是两回事，那次是谷歌换了指标，属于标准变了。

改完点「开始跟踪」

修完以后在报告里点开始跟踪，会启动28天的监控，28天里没有任何网址再出现这个问题，才算修好。开始跟踪不会触发重新编入索引，别指望点一下谷歌就重新来抓。

数据是28天滚动的，不要按天看。今天改完，明天进来瞅一眼没变化就以为白改了，是没搞明白这个窗口。真正该回看的时间点是28天以后。

LCP优化：先拆成四段，看慢在哪一段再改

LCP不是一个数，它是四段时间加起来的。官方把每个页面的LCP拆成不重叠、不留空档的四段，加起来就是LCP总时长。

子部分	是什么	优化好的页面大约占LCP
第一字节时间（TTFB）	从开始访问到收到HTML第一个字节	约40%
资源加载延迟	第一字节之后，到浏览器开始加载LCP资源，比如首图	不到10%
资源加载时长	LCP资源本身下载的时间	约40%
元素渲染延迟	资源下完到LCP元素真正画出来	不到10%

两段带「延迟」的，应该尽量接近0。比例只是指南，不是硬规定，LCP一直在2.5秒以内就不用管比例。官方还提醒过，别把这几个百分比换算成毫秒去凑。

还有一个官方例子值得记住。只把图压小或者换成AVIF、WebP，缩短的是资源加载时长，省下来的时间会被挪到元素渲染延迟上，LCP不变。

四段都要动，光压图解决不了问题。

看一份实测里的LCP细分。同一份TechCrunch报告，LCP元素是一张文章配图，标签上已经写了width、height和fetchpriority=”high”，图片地址在wp-content/uploads下面，class里有wp-post-image，是WordPress文章特色图的写法。

它的四段是：第一字节时间10毫秒、资源加载延迟1,320毫秒、资源加载时长50毫秒、元素渲染延迟120毫秒。四段里最长的是资源加载延迟1,320毫秒，按官方说法这一段应该接近0。这张图已经有fetchpriority=”high”了，可见光加这个属性不一定够，具体卡在哪，要到Chrome开发者工具的性能面板里看这次加载记录。

四段各对应改什么

第一字节时间慢

官方列了四种原因：多次服务器重定向、访客离最近的服务器远、访客网络差、带查询参数的地址用不了缓存。官方还有一句很实在的话，TTFB高的时候，2.5秒的LCP很难甚至不可能做到。

这一段有多长，决定了后面几段还剩多少余量。

能动手的方向有三个：页面缓存、主机、CDN。缓存让服务器不用每次重新算一遍页面，主机决定服务器本身的响应能力，CDN把内容放到离访客更近的节点上。CDN是什么、它怎么把内容搬到离访客更近的地方，那篇有完整说明；主机怎么选、配置怎么看，国外VPS那部分更细。补一句自己的经历，我做SEO十几年，2024年起转做英文独立站，自己买域名、买VPS、装主题。主机和主题是速度的底子，这两样选差了，后面插件怎么调都补不回来。

Carpe店铺那个案例里，TTFB超过1秒，模板分析显示大约85%的时间耗在主布局文件上，细节放到案例那一节讲。

资源加载延迟长

这一段长，是首图被浏览器发现得太晚。官方在这段给了一句很不客气的原话：千万别给LCP图加懒加载（Never lazy-load your LCP image）。给首屏最重要那张图加loading=”lazy”，一定会带来不必要的延迟。还有一种做法也会踩坑，用CSS背景图放首屏主图，浏览器的预加载扫描器看不到它，等于把发现时间往后推。

能做的动作有两个：把那句loading=”lazy”删掉，给LCP图加上fetchpriority=”high”，让浏览器早点、优先去拿它。WordPress用户这里有个好消息，官方开发者说明（2023年7月13日）写得很清楚：WordPress6.3起会自动给判断为最可能是LCP的那张图加fetchpriority=”high”，自动懒加载的修正是从5.9版开始的，更可靠地不给首屏图加loading=”lazy”。

但它不会覆盖主题或者插件已经写好的属性。主题和插件自己给首图加的懒加载照样生效，要自己去源码里查一遍。这也是秒出海的AI Agent里网站开发员工负责的部分，它的站从零开发、不套现成主题，首图不懒加载、图片写宽高、少装插件这些在建站阶段就做进模板，10个建站阶段每段一道闸门，不会等到上线三个月之后再回来查哪张图被加了懒加载。Carpe踩的正是这个坑，首屏大图在资源列表里排到第19个才被请求。

资源加载时长长

这一段是LCP资源本身的下载时间。方向是把体积压下去、把距离缩近：压缩、换成合适的格式、按实际显示尺寸出图、走CDN、用缓存把网络时间消掉。压缩工具和插件怎么配，本篇不展开。

元素渲染延迟长

资源下完了但画面没出来，问题就在渲染这一段。官方给的改法：减少或者内联阻塞渲染的CSS，延后或者内联阻塞渲染的JS，服务端渲染，拆分长任务。只压图的话，前面省下的时间可能挪到这里，所以改完要再看一次LCP细分，别以为压完图就完事。

WordPress上的缓存插件、图片压缩插件、数据库清理、GZIP、PHP版本这些插件级操作，各有各的做法，这里只给一篇：WordPress速度优化那10个方法，需要照着做的时候再进去看。

INP优化：点了没反应，先查JavaScript和外部脚本

INP要先从实测里找出最慢的那次交互，再到实验室里复现。一次交互被官方拆成三段：输入延迟，从点下去到处理开始，这一段长，多半是启动期间有大段脚本在跑，或者主线程被长任务占着；处理时长，事件回调自己跑的时间；呈现延迟，处理完了到画出下一帧。

改法也按三段对应。减少输入延迟，就少在启动期跑大段脚本、把长任务拆开。优化事件回调，常让出主线程、让渲染早点发生、避免布局抖动。减少呈现延迟，控制DOM大小、用content-visibility把屏幕外的元素延后渲染、注意用JS渲染HTML的成本。

站长不写代码能做的，下面是本文的建议，不是官方原文。先把用不上的插件和外部脚本删掉，聊天窗口、统计、广告、社交分享按钮，每一个都会往主线程上加活。再拿手机实际点一遍菜单、筛选、按钮，感受一下哪一下卡。想复现得更准，用Chrome开发者工具性能面板里的CPU降速，模拟低端手机再点一次。

TechCrunch那份报告的下半截诊断里，最大限度地减少主线程工作6.1秒、缩短JavaScript执行用时3.1秒、发现20项长时间运行的主线程任务。同一份报告上半截的真实INP是162毫秒，还在200毫秒以内。实验室里的主线程问题，不等于真实用户的INP一定超标，先改什么、改到什么程度，还是以上半截的真实数据为准。

Fotocasa怎么把INP从832毫秒降到232毫秒

这是一个web.dev官方案例研究，2025年10月14日发布，主角是西班牙一家房产网站Fotocasa。替换前它的桌面和手机几乎所有页面都在优质。2024年3月12日INP上线那天起，几乎所有页面变成需要改进，一部分掉进欠佳，多数交互的INP超过200毫秒。

他们自己说，FID只量第一次交互，INP量所有交互还要算上处理和呈现的耗时，而且Search Console是28天汇总、不实时，所以他们另外搭了真实用户监控，先找出到底是哪一次交互慢。复现的办法是在Chrome开发者工具性能面板里把CPU降速，模拟中低端设备。

找到的最典型一处是搜索页的筛选弹窗。开关状态挂在整个搜索页上，一点就整页重渲染。4倍降速下这一下要440毫秒，属于需要改进；6倍降速下要832毫秒，属于欠佳。把状态挪到按钮组件上以后，4倍降速变成64毫秒，6倍降速降到232毫秒。

结果是桌面所有页面从需要改进回到优质，手机几乎所有欠佳和需要改进的页面也升到优质。原文还提到，这些改动和其他举措一起，带来联系和电话类线索增长27%。这是业务线索，不是流量，原文也没说搜索流量的变化。

CLS优化：图片写宽高、广告位预留空间、字体别让文字跳

CLS的原因就那么几类，官方列得很具体。图片没写尺寸，加载完把周围内容顶开；广告、嵌入内容和晚加载的内容，占的位置跟最后占的位置对不上；没有用户操作，就往已有内容上方插入新内容；动画用了会改变布局的方式；网页字体换过来的那一瞬间，文字跳一下。

对应的改法也直接：img标签写width和height；广告和嵌入内容提前预留空间，尽量放到视口靠下的位置；没有用户操作就别往上插入东西；动画改成不引起布局变化的属性；字体这块要么用系统字体，要么把字体文件提前拿到。另外，让页面能用往返缓存，也能降CLS。

还有一件事得知道，实验室和实测的CLS可能不一样。实测包含加载完成之后的偏移，用户往下滚了半分钟才加载出来的广告，实验室里根本看不到。所以不能只看实验室那个接近0的数就放心。

Carpe店铺修好首图懒加载和服务器响应：LCP改善52%，改版后流量涨10%

Carpe是什么店、原来慢在哪

Carpe是一家卖止汗产品的Shopify店铺，产品主打经过皮肤科和临床测试。它的速度在几个月里一直在掉，后来是Shopify官方性能团队和店铺自己的开发团队一起改的，案例2023年5月9日公开。改之前所有页面渲染都慢，TTFB、FCP、LCP全高，CLS的第75百分位已经逼近0.1的达标线。他们定的目标原话是，先让全站满足Core Web Vitals，让至少75%的访客体验到快，让它在谷歌搜索结果里排得稍高一点。

排查下来，先被排除的是阻塞渲染。阻塞渲染的外部资源只有一个，是必须留着的个性化脚本。真正的问题是另外两个。首屏大图在资源列表里排第19个才被请求，浏览器一开始发现不了它，原因是懒加载用错，首屏的重要图也被加了懒加载，加上站里大量用非装饰性的背景图，两样都让预加载扫描器看不到这张图。

第二个问题是TTFB超过1秒，模板分析显示大约85%的时间耗在主布局文件上，主题把所有商品和变体序列化成JSON给前端，商品和字段一多就越来越慢。

Carpe怎么改的

首屏图按图片性能的做法改：不懒加载，不用背景图。图片在HTML里写上尺寸，商品页顶部预留好空间，这两步同时把CLS压下去。TTFB那边只序列化需要的几个商品字段，按页面类型只保留必要的逻辑。改动拆成小步做，大重构留到后面，不赶。这套顺序跟前面LCP四段拆分是一回事，先让浏览器早点发现图，再让服务器别拖。

Carpe改完的数

3月那一期Chrome用户体验报告，三项Core Web Vitals全部达标。那一期的数是TTFB1.0秒、FCP1.9秒、LCP2.4秒、CLS0，INP125毫秒，当时INP还是实验指标。内部数据里，第75百分位的LCP改善52%、CLS改善41%，转化率提升5%，流量涨了10%，营收合计提升15%。

口径要说清楚：原文没拆流量来源，也不是对照实验，只能说改版后流量涨了，不能说是速度带来的。

5%和10%也不是一回事，别加在一起看。

补一句旁证。谷歌2021年那份Core Web Vitals商业影响汇总里提过一句：印度美妆电商Nykaa的LCP改善40%以后，来自二三线城市的自然流量多了28%。只有这一句，没有做法和日期细节，这里不展开。

用AI读PageSpeed Insights报告：AI排出先改哪三项，删哪个插件人来定

AI在这件事上能干的活，是帮你读报告、排顺序、查源码，不是替你做决定。它只能看你贴给它的报告和源码，量不出真实用户数据，也不能告诉你谷歌给速度多少权重。下面三段提示词可以直接复制去用。

让它读报告，就贴这段。下面是我一个页面的PageSpeed Insights报告文字。请分两部分回答：一、真实用户数据（上半截）里LCP、INP、CLS各是多少、哪项没达标；二、实验室数据里LCP元素是什么、LCP细分里哪一段最长。最后按影响大小列出最该先改的三项，每项写清对应哪个指标、改的是哪一段。只根据报告里的内容回答，不要编数字。

让它查源码，就贴这段。下面是我网页的HTML源码。请检查：首屏最大的那张图有没有loading=”lazy”、有没有fetchpriority=”high”、是不是用CSS背景图显示的；哪些图片没写width和height；head里有哪些会阻塞渲染的CSS和JS。只列你在源码里看到的，不要猜。

让它列外部脚本，就贴这段。下面是我网页的HTML源码。请列出所有外部加载的脚本，按统计、广告、聊天、社交分享、其他分类，每个写出加载地址和是否在head里同步加载。只列源码里有的，不判断该不该删。

排完顺序，剩下的是人的活。删哪个插件、删哪个脚本，会不会丢功能、会不会把统计也删掉，得你自己判断；换不换主机、换不换主题，也是人的决定，AI看不到你的预算和后面的计划。删插件最容易出的问题，是删完才发现某个功能跟着没了，动手前先想清楚它现在还在干什么。改完去Search Console点开始跟踪，这一步AI替不了。

中国人做英文站，网站速度按什么顺序做

顺序按你手上有没有流量分，不是按工具分。

建站阶段，把模板做对。首图不懒加载、图片写宽高、少装插件、主题别选太重的。这一步做对了，后面省掉大量回查的功夫。已经过了这一阶段的站也有办法，去源码里查一遍首屏图，把不该有的loading=”lazy”删掉就行。

上线了但还没什么流量，用Lighthouse找问题，别追分数。这时候真实用户数据往往不够，PageSpeed Insights上半截看不到东西，下半截跑一遍，把红色档里最粗的那几根刺拔掉，比如阻塞渲染的请求、主线程上的长任务。分数涨了多少，对排名没有直接意义，改完的页面更快了才有意义。

有流量了，重心换到Search Console。先看手机那张，按群组看，先修欠佳，再修需要改进里网址多的。这时候你要的是真实用户的第75百分位变好，不是实验室的分数变高。改完点开始跟踪，然后别天天刷报告，中间该干嘛干嘛。

顺序的最后一件事，是内容排在速度前面。同一个词下面，内容差不多，速度快的排前面；内容差一截，速度再快也追不上。提高网站加载速度这件事，做在内容做对之后最划算。

常见问题

网站打开速度多少毫秒算正常

官方没有一个整页打开时间的标准，有的是三项：LCP不超过2.5秒、INP不超过200毫秒、CLS不超过0.1，按真实用户的第75百分位看，手机和电脑分开算。你说的整页打开几秒，只是你自己那台设备上的感觉，不是这套标准。

PageSpeed Insights分数要到90分吗

没有这个要求。90到100只是性能分颜色档里的绿色档，跟排名不是一回事。上面举的TechCrunch首页，性能分只有46，上半截的Core Web Vitals照样是通过。分数是拿来定位问题的，不是拿来交作业的。

Lighthouse和PageSpeed Insights有什么区别

PageSpeed Insights是一份报告，上半截放的是Chrome用户体验报告的真实用户数据，下半截放的是Lighthouse跑出来的实验室结果。Lighthouse是那个模拟引擎，一次跑一遍，量不了INP，用TBT顶着。看排名信号就看上半截，看问题清单就看下半截。

用了CDN谷歌排名会涨吗

CDN能做的是把内容放到离访客更近的节点上，缩短官方说的那种访客离服务器远造成的时间，LCP第一段会跟着变短。排名系统看的是真实用户的Core Web Vitals，这一段变短了指标可能变好，但排名涨不涨，还取决于内容跟那个词对不对得上，没有人能保证。

网站测速还要不要用别的测速网站

不用。排名信号来自真实Chrome用户的数据，你在PageSpeed Insights上半截和Search Console里看的，就是这批数据。别的工具给出的分数，跟排名系统看的不是同一个东西，测出来的值也不一样，多测几处只会让自己更乱。

FID现在还要看吗

不用看了。2024年3月12日INP已经正式取代FID，Search Console当天就换了指标。手上如果有老文章写FID要控制在100毫秒以内，按INP不超过200毫秒来理解就行，注意INP量的是整个访问期间的所有交互，不只第一次。

报告、数据、监控都是死工具，人的判断和验收省不掉。改完点开始跟踪、到期回看这一段，秒出海的AI Agent里那个运营员工会自己拉数据，每周给一张单子写清先改哪篇，正好对着数据验收一轮。