Blog
Page Speed and SEO: How Load Time Affects Rankings
Page speed for SEO is field Core Web Vitals, not a Lighthouse score. See what Google uses in ranking, why relevance still wins, and what to fix first.
Muhammad Zubair Akhtar
Page speed for SEO is whether load time changes where a URL ranks. I am Zubair Akhtar, a senior software engineer in Lahore, Pakistan. Google's page says Core Web Vitals are used by its ranking systems, a good report does not guarantee a top result, and the most relevant page can still win when the experience is poor. This article is that distinction. I read the pages linked below on 24 October 2026. I am not publishing a measurement of this domain.
The fixes already have their own posts. LCP, INP, and CLS by stack are the Core Web Vitals guide. Fifteen website speed optimization changes are how to improve website speed. WordPress caching and plugins are WordPress speed optimization. Crawl, canonicals, and the sitemap come first, in the technical SEO checklist.
Figure 1. What Search names as a ranking input, and what it says does not directly raise rank. The split is from Google's page experience documentation, not from a test I ran.
What page speed for SEO actually means
People say "page speed" as if Google stored one number. It does not. The docs split the idea into page experience, and Core Web Vitals inside that set.
There is no single page experience score
Understanding page experience says core ranking systems look to reward content that provides a good page experience, and that owners should not focus on one or two aspects. The FAQ says there is no single "page experience signal." The systems look at a variety of signals that align with overall page experience.
The April 2023 post by Danny Sullivan says the "page experience update" was not a separate ranking system. It introduced Core Web Vitals as a signal the core systems considered, along with signals such as HTTPS they were already considering. It did not fold those into one score. The post says to use the current docs if the two disagree. An update on that post, dated 12 March 2024, says Interaction to Next Paint replaced First Input Delay. A report that still leads with FID is measuring a metric that has left the set.
Core Web Vitals are the part ranking systems use
That FAQ says Core Web Vitals are used by Google's ranking systems. It also says a good Core Web Vitals report, or a good third-party score, does not guarantee top rankings. There is more to page experience than those scores, and chasing a perfect score only for SEO may not be the best use of time.
The next answer is the one I use with clients. Beyond Core Web Vitals, other page experience aspects do not directly help a site rank higher. They can make the site more satisfying, which aligns with what ranking systems seek to reward. I still ship HTTPS, a layout that fits a phone, and pages that are not covered by interstitials. I do not describe them as ranking levers.
Google's self-assessment questions are good Core Web Vitals, HTTPS, content that displays well on mobile, ads that do not drown the page, no intrusive interstitials, and a design where the main content is easy to tell apart. Only the first is named as an input the ranking systems use.
Core Web Vitals: what Google actually measures
Search Central names the three metrics. PageSpeed Insights publishes the buckets. web.dev, updated 31 October 2024, is the definition I point developers at, including the 75th percentile.
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP | When the largest image or text block finishes | 0 to 2.5 seconds | Above 2.5 seconds, up to 4 seconds | Over 4 seconds |
| INP | Delay from a tap, click, or key press to the next paint | 0 to 200 milliseconds | Above 200 milliseconds, up to 500 milliseconds | Over 500 milliseconds |
| CLS | Unexpected movement of visible content | 0 to 0.1 | Above 0.1, up to 0.25 | Over 0.25 |
Search Central asks for LCP within 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1. PageSpeed Insights puts that boundary in Good. web.dev says INP of 200 milliseconds or less and CLS of 0.1 or less. A report that lands on the boundary is Good in PageSpeed Insights. I do not call it poor over the wording gap.
The 75th percentile is the number that counts
web.dev says to judge those targets at the 75th percentile of page loads, on mobile and desktop separately. A page passes when it hits all three there. PageSpeed Insights adds one case: if INP lacks data, the URL can still pass when LCP and CLS are both Good at that percentile. If LCP or CLS lacks data, that page or origin cannot be assessed. A desktop pass does not clear a failing phone.
Field data and lab data are not the same number
Field data in PageSpeed Insights comes from the Chrome UX Report: real Chrome users, and only URLs that are public and have enough visits. Chrome's overview says Google Search uses that dataset to inform the page experience ranking factor. The current Search page, which I follow when those sentences differ, says there is no single page experience signal and names Core Web Vitals as what ranking systems use. CrUX is the field source. It is not a second ranking system.
That field block is a trailing 28 days. PageSpeed Insights updates it daily. If the URL is too thin, the tool falls back to the origin, every page on the host mixed together. If the origin is also too thin, the field section is empty. Empty is not permission to treat the lab score as the ranking number.
Lab data is one Lighthouse run. PageSpeed Insights says mobile is currently a mid-tier Moto G4 on a mobile network, and desktop is an emulated desktop on a wired connection, from a datacenter in North America, Europe, or Asia. A category score of 90 or above is called good, 50 to 89 needs improvement, and below 50 is poor. The same page says good lab data does not mean real users had a good experience. web.dev says Lighthouse cannot measure INP, because a lab load has no input. Total Blocking Time is the proxy. I use the lab to name an element. Time to First Byte and First Contentful Paint help diagnose a slow LCP. They are not Core Web Vitals. PageSpeed Insights lists TTFB as experimental, good from 0 to 800 milliseconds. A faster TTFB can be the right engineering fix. It is not the ranking input Google named.
How to collect your own field data when CrUX is empty, and the per-stack fixes, stay in the Core Web Vitals guide.
What page speed for SEO does not change
Relevance still wins a poor experience
The page experience FAQ does not publish a weight. It says Google Search always seeks to show the most relevant content, even if the page experience is sub-par. For many queries, lots of helpful content is available, and a great page experience can contribute to success in those cases.
That is as close as the public docs get to a tie-breaker. They do not use the word, and they do not publish a percentage. My reading, labeled as mine: when several pages are already helpful, experience can separate them. When one page is the relevant answer, a slower experience does not automatically lose. I have no study that quantifies that gap, so this article does not invent one.
The same FAQ says ranking systems generally judge page experience on a page, with some site-wide assessments. An origin that passes in CrUX is not a pass for every URL. A fast homepage does not clear a slow article. Read the URL that should rank.
A green lab score is not the ranking input
A Lighthouse score of 100 is one device, and it cannot see INP. A green circle on a staging URL that CrUX has never seen is a debugging result. It is not evidence that rankings moved. I have not measured a ranking change from a lab score on this site, and I will not imply one. If a tool is not showing the 75th percentile of LCP, INP, and CLS for that URL, it is not showing the speed signal Search describes.
HTTPS and mobile layout are a different claim
HTTPS, a usable phone layout, and fewer interstitials are on Google's self-assessment list. The current page says those other aspects do not directly help you rank higher. The April 2023 FAQ was softer: not every one of those signals may directly inform ranking, and they still align with success. Where they differ, I follow the current page. I still remove an interstitial that hides the answer, because the page is worse to use. The ranking sentences I can cite are the Core Web Vitals sentence and the relevance sentence.
What to fix first for page speed for SEO
This is a ranking order, not the cheapest code change. Images, compression, and scripts, ranked by hour, are the website speed post. I am not restating those rows.
Figure 2. What to fix first when the complaint is rankings. Steps 1 and 2 are not a warm-up for a cache plugin.
| Order | Question | If the answer is no |
|---|---|---|
| 1 | Is this the indexable canonical, and is it in the sitemap? | Checklist and audit, before any speed edit |
| 2 | Does this page answer the query? | Content and intent, not a cache plugin |
| 3 | Does CrUX have this URL on mobile and on desktop? | Do not treat the lab score as the ranking number |
| 4 | Is LCP, INP, or CLS short of Good at the 75th percentile? | Fix that metric on the template |
| 5 | Are the Core Web Vitals that have data Good? | Stop chasing a perfect lab score for SEO |
A fast URL with the wrong status, the wrong canonical, or no sitemap entry is not the URL in the result. I run crawl, index, and render before Core Web Vitals. If the page does not answer the query, the relevance sentence sits above any plugin. Then read Search Console and PageSpeed Insights on the URL that should rank, and note whether the field block is that URL, the origin, or empty.
Fix one template and the metric that fails. The stack fixes, the fifteen website speed optimization changes, and the WordPress cache pass are the posts linked above. Once mobile and desktop are Good, more Lighthouse points are for the visitor. Search Central already says a perfect score chased only for SEO may be the wrong use of time. A cached page can still lose to a more relevant result, and a lab gain can stay invisible to CrUX until the 28-day window moves.
FAQ
Does page speed affect Google rankings?
Core Web Vitals do. Search Central says ranking systems use them, a good report does not guarantee a top ranking, and the most relevant page can still win when the experience is poor. Load time can matter when many helpful pages exist. It does not replace relevance. Those docs do not describe a single page-speed score.
Is a Lighthouse score of 100 a ranking boost?
No page linked here says that. Lighthouse does not measure INP. A good lab result does not mean real users had a good experience, and a strong field report still does not guarantee rankings. Use the lab to find a cause. Use the 75th percentile of field LCP, INP, and CLS when you talk about Search.
Do HTTPS and a mobile layout directly raise rankings?
The current page experience page says aspects beyond Core Web Vitals do not directly help a site rank higher. HTTPS, a phone layout, and fewer interstitials stay on the self-assessment list. I ship them because the page is worse without them. I do not describe them as a direct ranking increase.
Which Core Web Vital should I fix first?
The one that is not Good at the 75th percentile, on the URL that should rank, on the device type that fails. No published weight says LCP outranks INP. If the field section is empty, there is no failing metric yet. If the URL is not the canonical, fix that first.
How long until a speed fix shows in field data?
PageSpeed Insights describes field data as a trailing 28-day window. A deploy does not replace that window the same day. Your own collection can move sooner. How to collect it is the Core Web Vitals guide.
If load time is the ranking question
I treat page speed for SEO as field Core Web Vitals on a URL that is already the right result. Relevance wins when the pages are not equal. A lab score does not stand in for CrUX. Checking that, and changing the template when the field data fails, is part of my technical SEO services. I do not promise a position. Send the PageSpeed Insights link for the URL you want to rank, and say whether the field section is the URL, the origin, or empty.