The claim that “improving page speed raises your search ranking” is widely circulated. Yet how much it matters, and how it is actually treated in today’s Google Search, is rarely stated with precision. In this article, regarding the impact on SEO, we rely solely on Google’s published official documentation (Google Search Central) and official blog to map out the current state of the relationship between page speed and SEO. We also introduce measurement tools (for these, in addition to Google’s own tools, we also refer to the official documentation of hosting providers and others).

The Conclusion First — What the Current Documentation Says

“Speed is used in ranking. But it is not a single decisive factor, and it carries less weight than relevance.” — This is the current positioning that can be read from the official materials. In this section, we verify the basis for this single sentence, following the wording of Google Search Central’s current documentation, “Understanding page experience in Google Search results”.

First, on the front half, “used in ranking.” The same document positions Core Web Vitals (discussed below), the group of metrics measuring display quality including speed, as follows.

Core Web Vitals are used by our ranking systems.

(Core Web Vitals are used by Google's ranking systems.)

That Core Web Vitals, the group of metrics including page display performance, is used by ranking systems is stated explicitly even in Google’s current documentation. Note that what is used here is not a single “speed” value, but a group of metrics that includes not only loading speed but also responsiveness and visual stability (the composition is discussed below).

Next, on the latter half, “not a single decisive factor, weaker than relevance.” The FAQ in the same document states the following two points explicitly.

First, there is no single “page experience signal.”

There is no single signal. Our core ranking systems look at a variety of signals that align with overall page experience.

(There is no single signal. Google's core ranking systems look at a variety of signals that align with overall page experience.)

Second, the relevance of the content always takes precedence.

Google Search always seeks to show the most relevant content, even if the page experience is sub-par.

(Google Search always seeks to show the most relevant content, even if the page experience is sub-par.)

Below, after confirming the history that led to this positioning through a timeline, we look at the magnitude of the effect and the measurement methods.

The History — Sixteen Years of the Speed Signal

The relationship between page speed and search ranking has been announced by Google’s official blog at each milestone.

April 2010 — Speed becomes a ranking signal (desktop). The official blog announced that site speed had begun to be used in search ranking. However, the scope of application at the time was quite limited, described as affecting only the English-language Google.com and fewer than 1% of queries.

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.

(Site speed is a new signal, but it does not carry as much weight as the relevance of a page. At present, fewer than 1% of search queries are affected.)

July 2018 — The “Speed Update” (mobile). The official blog of January 2018 announced that from July of that year, page speed would also become a ranking factor in mobile search. Here too, application was limited to “the slowest pages.”

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.

(The "Speed Update" affects only pages that deliver the slowest experience to users, and only a small percentage of queries.)

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.

(The intent of the search query is still a very strong signal, so a slow page can still rank highly if it has great, relevant content.)

May 2020 — The announcement of Core Web Vitals. The official blog previewed a plan to combine Core Web Vitals, the group of metrics measuring loading speed, responsiveness, and visual stability, with existing signals such as mobile-friendliness and HTTPS to form the “page experience signal.” This article contains a sentence important for thinking about the magnitude of the effect.

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.

(A good page experience does not override having great, relevant content. However, when there are multiple pages with similar content, page experience becomes much more important for visibility in Search.)

June 2021 to March 2022 — Gradual rollout. The reflection of page experience into ranking was rolled out gradually: on mobile from mid-June to the end of August 2021, and on desktop from February to the end of March 2022.

April 2023 — Resolved as a “single system.” The official blog reorganized the positioning, stating that page experience is not an independent, single ranking system, but part of the variety of signals that the core ranking systems reference. The FAQ from the current documentation quoted at the opening (“there is no single signal”) reflects this reorganization.

March 2024 — INP replaces FID. An update note in the same article records that, as of March 12, 2024, the responsiveness metric was replaced from FID (First Input Delay) to 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.

(Update on March 12, 2024: As a part of Core Web Vitals, INP has replaced FID.)

The Magnitude of the Effect — Two Interpretations Easy to Get Wrong

Given the history, it becomes clear that both extreme interpretations are inconsistent with the official materials.

“The faster, the higher the ranking” does not hold. The 2018 Speed Update explicitly stated that it affects only “the slowest pages,” and the current documentation likewise states explicitly that getting good results in measurement reports does not guarantee top rankings.

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.

(Even if you get good results in reports like Search Console's Core Web Vitals report or third-party tools, it does not guarantee that your pages will rank at the top of Google Search results. A great page experience is not determined by Core Web Vitals scores alone.)

“Speed is unrelated to ranking” also does not hold. As noted above, the current documentation states explicitly that “Core Web Vitals are used by our ranking systems,” and the Core Web Vitals explanatory page “highly recommend[s]” achieving good values.

The current documentation expresses this intermediate positioning as follows.

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.

(But for many queries, there is a great deal of helpful content available. In such cases, having a great page experience can contribute to success in Search.)

Taking the official materials together, the actual positioning is as follows. Relevance always takes precedence. On top of that, in situations where there is a large amount of highly relevant content, a great page experience (including speed) is more likely to contribute to success in Search. From this one can also read that “the more competitive the field, the greater the relative significance of speed improvements,” but this latter part is an inference from the official wording; Google’s own phrasing is as cautious as quoted above.

The Evaluation Metrics — Core Web Vitals

Currently, the group of metrics used to evaluate speed, responsiveness, and visual stability is Core Web Vitals. According to the explanation on web.dev, Google’s official site for web developers, the composition consists of the following three metrics.

MetricWhat it measuresThe “good” threshold
LCP (Largest Contentful Paint)Loading speed (completion of main content display)Within 2.5 seconds
INP (Interaction to Next Paint)Responsiveness (from action to on-screen response)200 milliseconds or less
CLS (Cumulative Layout Shift)Visual stability (layout shift)0.1 or less

The standard is to judge not by individual accesses but by the 75th percentile of real-user measurement values aggregated separately for mobile and desktop. The 75th percentile is the point at which 75% of all accesses fall at or below that value. The Search Console help also explains, for LCP for example, in the form that “75% of page requests over the past 28 days reached the display of the main content within this time.” In other words, it is designed to see “whether the threshold is met for the majority of users.”

A PageSpeed Insights Score of 100 Is Not a Search-Ranking Score of 100

Applying the positioning so far to practice, the order of priority is as follows. First, arrange content that matches search intent. On top of that, start improving from pages judged “poor” in Search Console. For a site whose Core Web Vitals are already good, the priority of continuing to chase a perfect score on measurement tools for SEO purposes alone is not high. The current documentation contains the following sentence.

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.

(These scores are meant to help you 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.)

Measurement Methods

Tools provided by Google

The means of measuring Core Web Vitals are, first of all, provided and explained officially by Google itself.

PageSpeed Insights — A web tool that lets you measure any public page simply by entering a URL. According to the official explanation, it displays both the experience data of actual Chrome users (field data) and measurements in a simulated environment (lab data). However, displaying field data requires enough real measurement data to be included in the CrUX dataset, and the official explanation states explicitly that it may not be displayed for pages just after publication or pages with few real-user samples. Regarding lab data, it is explained that “because it is collected in a controlled environment it is useful for isolating problems, but it may fail to capture real-world bottlenecks,” and it is the field data that carries meaning in the context of search.

The Core Web Vitals report in Search Console — A report that classifies groups of URLs with sufficient real-user data into “Good,” “Needs improvement,” and “Poor” based on actual usage data. According to the help, URLs without enough data to report on are omitted from the report, so not all pages of a site are always covered. The aforementioned page-experience documentation also guides users to this report as a means of checking their own site’s evaluation.

Lighthouse — An open-source auditing tool that can be run as Chrome DevTools, from the command line, or as a Node.js module. Because it can measure unpublished pages or pages requiring authentication, it is suited to diagnosis during development (what it measures is lab data).

Chrome UX Report (CrUX) — The dataset that serves as the supply source for the field data above, aggregating the experiences of actual Chrome users. The reports of PageSpeed Insights and Search Console are based on this data.

Tools from hosting providers and third parties

The means of measurement are not limited to Google’s own tools. Hosting providers also offer measurement features built into their own platforms.

Cloudflare Observatory — A measurement feature included in the Cloudflare dashboard. According to the official documentation, in addition to synthetic testing (browser testing), which loads pages with a headless browser and runs Google Lighthouse, it also supports Real User Monitoring (RUM), which collects data from actual visitors. For a site operated on Cloudflare, as this site is, continuous monitoring is possible without introducing additional tools.

Cloudflare Web Analytics — A privacy-focused web analytics service. According to the official documentation, it collects the Core Web Vitals of actual visitors and automatically evaluates and displays each metric in the categories of “Good,” “Needs improvement,” and “Poor.”

Vercel Speed Insights — A feature for sites hosted on Vercel that lets you check real-user performance data based on Core Web Vitals in a dashboard. According to the official documentation, based primarily on the trend of the 75th percentile, you can also see breakdowns by device, by route, and by country.

Besides these, third-party measurement services independent of hosting include WebPageTest, among others. None of these tools replaces the check of the evaluation as seen from Google Search’s side (the Core Web Vitals report in Search Console), but they serve as a means of monitoring the same metrics on a daily basis and verifying the effect of improvements.

Summary

  • Page speed has been used in search ranking since 2010, and the current documentation states explicitly that “Core Web Vitals are used by our ranking systems”
  • However, no single “speed signal” or “page experience signal” exists; the positioning is that it is part of the variety of signals referenced by the core ranking systems (reorganized in 2023)
  • Google has consistently stated explicitly that “content relevance takes precedence,” and page experience, including speed, is most likely to take effect in situations where there is a large amount of highly relevant content. Nor does a good score guarantee top rankings
  • The evaluation metrics are Core Web Vitals (LCP within 2.5 seconds, INP 200 milliseconds or less, CLS 0.1 or less), judged by the 75th percentile of real-user measurement values aggregated separately for mobile and desktop (the point at which 75% of all accesses fall at or below that value)
  • The entry points for measurement are PageSpeed Insights (a single page) and the Core Web Vitals report in Search Console (an entire site). Search Console is based on CrUX’s real-user data, while PageSpeed Insights displays CrUX field data when data is sufficient and also runs a lab test with Lighthouse
  • For a site whose Core Web Vitals are already good, the priority of continuing to chase a perfect score on measurement tools for SEO purposes alone is not high. “Trying to get a perfect score just for SEO reasons may not be the best use of your time” is what the official documentation states

References