core web vitals 值不值得做：两处有文档支撑的影响，和一个该看的数

速度确实影响 SEO，有两条有文档支撑的路径，而它们分属两个系统。core web vitals 是排名系统读的一个信号，和其他信号并列；服务器响应慢则直接减少 Google 抓你的量。两条都不会把一个慢页面变成一个更好的答案，而且都不是大多数人打开的那个工具在测的东西。

读这篇前

抓取那一半只有到了某个规模才真的成为约束，而多数站一辈子到不了。还没看过的话，crawl budget 到底归不归你管 里有 Google 自己给的两条门槛，那是更快确认「这整个话题是别人的事」的路。

速度通过两个互不相干的系统影响搜索

几乎所有写这个题目的文章都混在一起，问题就出在把速度当成一件事。它进入搜索有两条路，两条路之间什么都不共享：数据来源不同，后果不同，修法也不同。

第一条路是排名。core web vitals 描述的是真实访客在你页面上经历了什么，采自现场，按 28 天聚合。它是「页面体验」这个宽泛评估的一个输入，而 Google 一直很小心地把它说成若干信号之一，不是一个开关。

第二条路是抓取。这一条和访客毫无关系。它说的是你的服务器多快回应 Googlebot 的一次请求，而这会改变 Google 愿意发多少次请求。回应慢的站被抓得少，新页面和改过的页面被发现的速度就往后拖。

速度不会让一个页面更贴题。它改变的是这个页面被取走的频率，以及在同样好的候选之间怎么破平局。

core web vitals：Google 到底说了什么

三段引用就把事情说完了，而且它们比建在它们之上的那些建议要克制得多。

排名这一侧，Google 的页面体验文档写的是：「Core Web Vitals are used by our ranking systems.」紧接着同一页就把这句话收窄：「There is no single signal. Our core ranking systems look at a variety of signals that align with overall page experience.」而优先级那句，把多数审计的顺序整个反过来：「Google Search always seeks to show the most relevant content, even if the page experience is sub-par. But for many queries, there is lots of helpful content available. Having a great page experience can contribute to success in Search, in such cases.」

抓取这一侧，抓取预算文档对因果的表述要直白得多：「If the site slows down (latency increases or response times become longer), or responds with server errors (5xx HTTP status codes) or rate-limiting signals (such as HTTP 429), the limit goes down and Google crawls less.」对应的建议是：「Make your pages efficient to load. If Google can load and render your pages faster, we might be able to read more content from your site.」

把这几句放在一起，形状就清楚了。贴题决定你有没有资格入场。页面体验是并列信号之一。服务器速度决定的是吞吐量，不是质量。

做出海站的人还要额外注意一件事：这两条路的数据都带地理属性，而你的测试环境往往不在受众那一侧。从国内测一个部署在美西的站，测到的延迟里有一大截是跨境链路，跟海外访客真实经历的完全不是一回事；反过来，现场数据报告聚合的是真实访客，所以它反而比你手边任何一次本地测量都更接近事实。两者对不上时，以报告为准，然后再想办法在受众所在的区域自己测一遍。

两条路里，哪一条才是你的问题

四行，绝大多数站落在第一行。在打开任何性能工具之前先找到自己那一行——工具没法告诉你你走的是哪条路。

第一行才是真正值得争的那一行。一个页面凭实力该排上却停在第二页，卡住它的不是 200 毫秒。Google 自己的排序就是这么写的：贴题在前，页面体验是候选拥挤时的加分项。

第二行和第三行在报告里长得很像，底下却毫无共同之处。体验报告标红说的是人在浏览器里看到了什么，修法在前端——图片、版面、页面稳定下来之前主线程干了多少活。抓取变慢说的是这一切开始之前你的服务器做了什么，修法在主机、缓存和容量。同一个「慢」字，两笔预算，把一笔花到另一笔上，是这个话题最常见的浪费一周的方式。

怎么拿到那个该看的数，三步

真正值得握在手里的是你自己服务器在可复现测量下的响应时间——它是唯一你能直接控制的，也是唯一两条路都会受影响的。

1. 打开 Google Search Console 的核心网页指标报告，读的是网址分组，不是单条网址。这是来自真实访客的现场数据，也正是排名系统读的那份输入。所有分组都是绿的，第一条路对你就结束了。
2. 自己测服务器，测很多次。一次读数不是一个数。我们自己那份 26 个首页的面板 2026-08-20 测过：同一个站重测一遍，中位数就差了 542 毫秒，全样本首字节耗时的中位数是 1,118 毫秒，细节在 网站速度实测 26 个首页。

   for i in 1 2 3 4 5; do
     curl -s -o /dev/null -w '%{time_starttransfer}\n' \
       -A 'Mozilla/5.0' https://example.com/
   done

3. 打开 Search Console 的抓取统计报告，看平均响应时间和状态码分布。5xx 或 429 只要占了可观的比例，那就是上表最后一行，任何前端优化都救不回来。

停手规则，和四件不该做的事

速度这件事没有天然终点，所以它特别能吃掉下午。给它定一个。

停手规则：当核心网页指标报告里没有标红的网址分组，并且连测五次的服务器响应中位数低于半秒，就停。再往下的收益对访客是真的，对搜索是看不见的。把这两个数字写下来，回到决定上表第一行的那件事——内容。

• 不管清单上还有什么，先修 5xx 和 429。按 Google 自己的描述，它们直接减少抓取量
• 同一件事测五次再相信任何单次结果
• 别去追一个合成性能分。那是对一台设备、一条网络的实验室模拟；排名读的是你真实访客的现场数据
• 别为了消掉一个阻塞请求就把整份样式表内联。五个大站正是这么干的，代价是每次页面加载都拿不到浏览器缓存 —— 数字在 render blocking 实测 26 个首页
• 别为了让页面变轻去删内容。Googlebot 自己那条体积线相当宽松：它只管未压缩的 HTML，而 27 个首页的中位数是 574,601 字节

这套判断到什么地方就不管用了

三条边界，第三条决定你到底该不该待在这一页上。

第一条：这里没有任何一个数量。我们说不出核心网页指标全绿值几个名次，也不会编一个出来。Google 公开的表述只到「与页面体验相关的若干信号之一」，公开记录的精度就到这里为止。

第二条：抓取那条路有规模门槛。Google 点名了两种情况——「Large sites (1 million+ unique pages) with content that changes moderately」和「Medium or larger sites (10,000+ unique pages) with very rapidly changing content」。在门槛之下，抓得慢通常是别的问题的症状，把服务器提速也不会让它动。

第三条：不渲染的检索型客户端根本经历不到这些。它取到 HTML 就停，所以一张会挡住浏览器首屏的样式表对它一分钱都不花。对这类客户端要问的是另一个问题——你的正文在投递的文档里到底有没有——那是另一章的事，而且便宜得多。

常见问题

网页速度是不是排名因素？

core web vitals 会被 Google 的排名系统使用，而 Google 把它描述成与页面体验相关的若干信号之一，不是单一因素。同一份文档还写了：即使页面体验不佳，搜索仍然会去展示最贴题的内容。

速度和内容哪个更重要？

内容。Google 把顺序写得很明确：贴题在前，页面体验是在有大量有用内容竞争时的加分项。一个页面如果在它真正能回答的问题上排不上去，原因几乎从来不是几百毫秒。

到底该盯哪个速度指标？

两个。Search Console 的核心网页指标报告，因为那是现场数据，也是排名系统读的那份；以及你自己服务器连测五次的响应中位数，因为那是改变 Google 抓取量的那个数，而且从头到尾归你管。

站慢了是不是真的会被少抓？

会，而且这是 Google 唯一说得很明确的因果：延迟上升、返回 5xx、或者出现 429 限流，抓取上限就会下调。修法是服务器容量，不是前端优化，而且它会先出现在抓取统计报告里，再出现在别的地方。

AI 答案引擎在乎网页速度吗？

我们两个方向的证据都没有，也不打算猜。能说的是：一个取到 HTML 就停、不渲染的客户端，从来不为样式表或脚本等待，所以浏览器侧那套指标根本没有在描述它的经历。想看这类客户端从你的页面上拿到了什么，可以 查一下 AI 爬虫能不能读到你的站。