「提升页面加载速度就能提高搜索排名」这一说法广为流传。然而,它究竟有多大影响,以及在当前的Google搜索中是如何处理的,却出人意料地很少被准确地表述。本文关于对SEO的影响,仅以Google公开的官方文档(Google Search Central)与官方博客为依据,梳理页面速度与SEO之间关系的现状。同时也介绍测量工具(这部分除Google自家工具外,还参考托管服务商等的官方文档)。
先说结论 — 现行文档中的表述
「速度用于排名。但它并非唯一的决定性因素,权重弱于相关性。」——这是从官方资料中可以读出的当前定位。本节将依照Google Search Central现行文档《Understanding page experience in Google Search results》的表述,确认这一句话的依据。
首先是前半句「用于排名」。该文档对包含速度在内、衡量显示质量的指标群Core Web Vitals(后述)作了如下定位。
Core Web Vitals are used by our ranking systems.
(Core Web Vitals 用于 Google 的排名系统。)
包含页面显示性能在内的指标群Core Web Vitals被用于排名系统,这一点在Google的现行文档中也有明确说明。需要注意的是,这里所用的并非「速度」这一单一数值,而是除加载速度外,还包含响应性与视觉稳定性的指标群(其构成后述)。
接着是后半句「并非唯一的决定性因素,弱于相关性」。同一文档的FAQ明确指出了以下两点。
第一,不存在单一的「页面体验信号」。
There is no single signal. Our core ranking systems look at a variety of signals that align with overall page experience.
(不存在单一的信号。Google 的核心排名系统会参考与整体页面体验相符的多种信号。)
第二,内容的相关性始终优先。
Google Search always seeks to show the most relevant content, even if the page experience is sub-par.
(即使页面体验欠佳,Google 搜索也始终力求展示相关性最高的内容。)
下面,我们先通过年表确认走到这一定位的来龙去脉,再来看影响的大小与测量方法。
来龙去脉 — 速度信号的16年
页面速度与搜索排名的关系,在每个节点都由Google的官方博客加以公布。
2010年4月 — 速度成为排名信号(桌面端)。 官方博客宣布,开始将网站速度用于搜索排名。不过当时的适用范围极为有限,据说明仅影响英语版的Google.com,且影响不到查询的1%。
While site speed is a new signal, it doesn’t carry as much weight as the relevance of a page. Currently, fewer than 1% of search queries are affected by the site speed signal.
(网站速度是一个新信号,但其权重不及页面的相关性。目前受影响的搜索查询不到1%。)
2018年7月 — 「Speed Update」(移动端)。 2018年1月的官方博客宣布,自同年7月起,移动搜索也将把页面速度作为排名因素。这里的适用同样被限定于「最慢的页面」。
The “Speed Update”, as we’re calling it, will only affect pages that deliver the slowest experience to users and will only affect a small percentage of queries.
(我们称之为「Speed Update」,它只影响向用户提供最慢体验的页面,并且只影响一小部分查询。)
The intent of the search query is still a very strong signal, so a slow page may still rank highly if it has great, relevant content.
(搜索查询的意图仍然是非常强的信号,因此若页面拥有优质且相关的内容,即使较慢也可能排名靠前。)
2020年5月 — Core Web Vitals的发布。 官方博客预告了一项计划:将衡量加载速度、响应性与视觉稳定性的指标群Core Web Vitals,与移动友好性、HTTPS等既有信号相结合,构成「页面体验信号」。这篇文章中有一句对思考影响大小很重要的话。
A good page experience doesn’t override having great, relevant content. However, in cases where there are multiple pages that have similar content, page experience becomes much more important for visibility in Search.
(良好的页面体验并不能凌驾于优质且相关的内容之上。然而,当存在多个内容相近的页面时,页面体验对于在搜索中的可见性就会变得重要得多。)
2021年6月~2022年3月 — 分阶段适用。 页面体验向排名的反映是分阶段推出的:移动端自2021年6月中旬至8月底,桌面端自2022年2月至3月底,分别逐步铺开。
2023年4月 — 作为「单一系统」被消解。 官方博客重新厘清了定位:页面体验并非独立的单一排名系统,而是核心排名系统所参考的多种信号中的一部分。开头引用的现行文档FAQ(「不存在单一信号」)正是这一梳理的体现。
2024年3月 — INP取代FID。 同一文章的更新注记中记录着,自2024年3月12日起,响应性指标已由FID(First Input Delay)替换为INP(Interaction to Next Paint)。
Update on March 12, 2024: Interaction to Next Paint (INP) has replaced FID as a part of Core Web Vitals.
(2024年3月12日更新:作为 Core Web Vitals 的一部分,INP 已取代 FID。)
影响的大小 — 两种容易出错的解读
结合来龙去脉可以看出,两种极端的解读都与官方资料不相符。
「越快排名越高」并不成立。 2018年的Speed Update明确表示只影响「最慢的页面」,现行文档也明确指出:在测量报告中取得良好结果,并不能保证靠前展示。
Keep in mind that getting good results in reports like Search Console’s Core Web Vitals report or third-party tools doesn’t guarantee that your pages will rank at the top of Google Search results; there’s more to great page experience than Core Web Vitals scores alone.
(请记住,即使在 Search Console 的 Core Web Vitals 报告或第三方工具中取得良好结果,也不能保证您的页面会在 Google 搜索结果中排名靠前;优质的页面体验并不仅仅取决于 Core Web Vitals 分数。)
「速度与排名无关」同样不成立。 如前所述,现行文档明确写道「Core Web Vitals are used by our ranking systems」,Core Web Vitals的说明页面则「强烈推荐(highly recommend)」达成良好数值。
现行文档将这一居中的定位表述如下。
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.
(但对于许多查询而言,存在大量有用的内容。在这种情况下,拥有优质的页面体验有助于在搜索中取得成功。)
综合官方资料的表述,其实际定位如下。相关性始终优先。在此之上,当存在大量相关性高的内容时,优质的页面体验(含速度)更容易对搜索中的成功有所助益。 由此也可以读出「竞争越激烈的领域,速度改善的相对意义越大」,但这后半部分是从官方表述作出的推论,Google自身的措辞则如上所述地审慎。
评价指标 — Core Web Vitals
目前,用于评价速度、响应性与视觉稳定性的指标群就是Core Web Vitals。据Google面向网页开发者的官方网站web.dev的说明,其构成为以下三项指标。
| 指标 | 测量对象 | 「良好」的标准 |
|---|---|---|
| LCP(Largest Contentful Paint) | 加载速度(主要内容显示完成) | 2.5秒以内 |
| INP(Interaction to Next Paint) | 响应性(从操作到画面反应) | 200毫秒以下 |
| CLS(Cumulative Layout Shift) | 视觉稳定性(布局偏移) | 0.1以下 |
评价的标准并非针对单次访问,而是以分移动端、桌面端汇总的真实用户测量值的第75百分位来判定。所谓第75百分位,即全部访问中有75%落在该值及以下的那个点。Search Console的帮助也以类似形式说明,例如就LCP而言,「过去28天内75%的页面请求在此时间内完成了主要内容的显示」。也就是说,其设计是查看「对于大多数用户是否满足标准」。
PageSpeed Insights的100分,不是搜索排名的100分
将至此的定位落到实务上,优先顺序如下。首先,整备符合搜索意图的内容。在此之上,从Search Console中被判定为「不良」的页面开始改善。对于Core Web Vitals已经良好的网站而言,仅为SEO而持续追求测量工具满分的优先级并不高。现行文档中有如下一句。
These scores are meant to help you to improve your site for your users overall, and trying to get a perfect score just for SEO reasons may not be the best use of your time.
(这些分数旨在帮助您从整体上为用户改善网站,仅仅出于 SEO 的理由去追求满分,也许并非对您时间的最佳利用。)
测量方法
Google提供的工具
测量Core Web Vitals的手段,首先由Google自身官方提供并加以说明。
PageSpeed Insights — 只需输入URL即可测量任意公开页面的Web工具。据官方说明,它会同时显示实际Chrome用户的体验数据(现场数据)与模拟环境下的测量(实验室数据)。不过,显示现场数据需要有足以被纳入CrUX数据集的充分实测数据,官方说明明确指出:对于刚发布的页面或真实用户样本较少的页面,可能无法显示。关于实验室数据,说明称「因在受控环境中收集,故有助于分离问题,但有时无法捕捉真实环境中的瓶颈」,而在搜索这一语境中具有意义的是现场数据一方。
Search Console的Core Web Vitals报告 — 将拥有充分真实用户数据的URL分组,基于实际使用数据分类为「良好」「需要改善」「不良」的报告。据帮助,数据量不足以支持报告的URL会从报告中略去,因此网站的全部页面并不总是被覆盖。前述的页面体验文档中,也将此报告作为确认自家网站评价的手段加以介绍。
Lighthouse — 可作为Chrome DevTools、命令行或Node.js模块运行的开源审计工具。因其能够测量尚未发布的页面或需要认证的页面,适合开发中的诊断(所测量的是实验室数据)。
Chrome UX Report(CrUX) — 作为上述现场数据供给源的数据集,汇总了实际Chrome用户的体验。PageSpeed Insights与Search Console的报告均基于这一数据。
托管服务商与第三方的工具
测量的手段并不局限于Google自家工具。托管服务商也提供内建于自身平台的测量功能。
Cloudflare Observatory — 包含在Cloudflare仪表板中的测量功能。据官方文档,除了以无头浏览器加载页面并运行Google Lighthouse的合成测试(浏览器测试)外,还支持收集真实访客数据的真实用户监测(RUM)。像本站这样在Cloudflare上运营的网站,无需引入额外工具即可进行持续监控。
Cloudflare Web Analytics — 注重隐私的访问分析。据官方文档,它收集真实访客的Core Web Vitals,并将各指标以「良好」「需改善」「不良」的分区自动评价并显示。
Vercel Speed Insights — 面向在Vercel托管的网站,可在仪表板中查看基于Core Web Vitals的真实用户性能数据的功能。据官方文档,它以第75百分位的走势为基础,还可查看按设备、按路径、按国家的细分。
除此之外,不依赖托管的第三方测量服务还有WebPageTest等。上述任何工具都不能取代从Google搜索一侧所见评价的确认(Search Console的Core Web Vitals报告),但它们都可作为日常监控同一指标、验证改善效果的手段。
小结
- 页面速度自2010年起已被用于搜索排名,现行文档也明确写道「Core Web Vitals 用于排名系统」
- 但并不存在单一的「速度信号」或「页面体验信号」,其定位是核心排名系统所参考的多种信号中的一部分(2023年加以梳理)
- Google一贯明确表示「内容的相关性优先」,含速度在内的页面体验最容易见效的场合,是存在大量相关性高的内容之时。良好的分数也并不保证靠前展示
- 评价指标为Core Web Vitals(LCP 2.5秒以内、INP 200毫秒以下、CLS 0.1以下),以分移动端、桌面端汇总的真实用户测量值的第75百分位(全部访问中有75%落在该值及以下的那个点)判定
- 测量的入口是PageSpeed Insights(单个页面)与Search Console的Core Web Vitals报告(整个网站)。Search Console基于CrUX的真实用户数据,PageSpeed Insights在数据充分时显示CrUX的现场数据,并同时执行由Lighthouse进行的实验室测试
- 对于Core Web Vitals已经良好的网站,仅为SEO而持续追求测量工具满分的优先级并不高。「仅仅出于 SEO 的理由去追求满分,也许并非对您时间的最佳利用」,这正是官方文档的表述
参考资料
- Understanding page experience in Google Search results — Google Search Central
- Understanding Core Web Vitals and Google search results — Google Search Central
- Using site speed in web search ranking(2010年4月9日) — Google Search Central Blog
- Using page speed in mobile search ranking(2018年1月17日) — Google Search Central Blog
- Evaluating page experience for a better web(2020年5月28日) — Google Search Central Blog
- More time, tools, and details on the page experience update(2021年4月19日) — Google Search Central Blog
- Timeline for bringing page experience ranking to desktop(2021年11月4日) — Google Search Central Blog
- The role of page experience in creating helpful content(2023年4月19日) — Google Search Central Blog
- Web Vitals — web.dev
- PageSpeed Insights / About PageSpeed Insights — Google for Developers
- Core Web Vitals report — Search Console 帮助
- Introduction to Lighthouse — Chrome for Developers
- Overview of CrUX — Chrome for Developers
- Observatory — Cloudflare Docs
- Core Web Vitals — Cloudflare Web Analytics Docs
- Speed Insights Overview — Vercel Docs
- WebPageTest
