Speed & Visibility

Page Speed, Ranking And AI Answers

Core Web Vitals are used by Google's ranking systems, and Google also says it will show the most relevant content even when the page experience is poor. Both are true. What speed actually decides is narrower than the score implies, and it matters more to machines that never render your page than to the ranking you are watching.

Review my site speed What it actually moves

Start here

Where You Are Now

Three ways this subject arrives, and they do not have the same answer. Pick the one that sounds like your week.

  • 01

    The score came back red

    Before rebuilding anything, understand what the number is. It is a weighted simulation of one load on a throttled phone, not a measurement of your site and not a ranking.

    Read the number properly
  • 02

    It went green, nothing changed

    The most common outcome, and the least discussed. The lab score moved because the lab test moved. Whether anything real moved is a different question with a different data source.

    Lab against real users
  • 03

    You are told speed is why you lost

    Google says it seeks the most relevant content even when page experience is poor. Speed decides between pages that are already close. It does not promote a page past a better one.

    What it actually moves

The number

What The Score Is

The big coloured number is a lab score. It is produced by loading your page once, in a simulated browser, on a simulated slow phone, on a simulated slow connection, and combining five measurements into one figure.

The three score bands, and what the number is made of Three ring gauges showing a poor score of 34, a needs-improvement score of 71 and a good score of 96, with the band each belongs to. Zero to forty-nine is poor, fifty to eighty-nine is needs improvement, ninety to one hundred is good. Beneath them, the five metrics that make up the score, weighted: blocking time thirty per cent, largest contentful paint twenty-five, layout shift twenty-five, first contentful paint ten, speed index ten. 34 POOR 0 to 49 71 NEEDS IMPROVEMENT 50 to 89 96 GOOD 90 to 100 WHAT THE NUMBER IS WEIGHTED FROM TBT 30% LCP 25% CLS 25% FCP 10 SI 10 Blocking time and layout shift are 55 per cent of it, and neither is what people mean by slow.
An illustration of the score bands and weighting. Not a report on any real site, and not produced by Google.
  • 30%

    Total Blocking Time

    How long the main thread was busy enough to ignore a tap

  • 25%

    Largest Contentful Paint

    When the biggest thing above the fold finished drawing

  • 25%

    Cumulative Layout Shift

    How much the page moved under the reader after it appeared

  • 10%

    First Contentful Paint

    When anything at all appeared

  • 10%

    Speed Index

    How quickly the visible area filled in

On chasing the last few points

A "perfect" score of 100 is extremely challenging to achieve and not expected. For example, taking a score from 99 to 100 needs about the same amount of metric improvement that would take a 90 to 94.

What that meansTwo thirds of the score is decided by blocking time and layout shift, neither of which is what people mean by "the site feels slow". A page can load fast and score badly because one script held the main thread while it did.

The three

Where Good Stops

Three metrics carry the assessment. Google publishes exact boundaries for each, measured at the 75th percentile of real page loads, and separately for mobile and desktop.

Where each Core Web Vital stops being good Three threshold bars. Largest Contentful Paint is good at or under 2.5 seconds, needs improvement to 4 seconds, poor beyond. Interaction to Next Paint is good at or under 200 milliseconds, needs improvement to 500, poor beyond. Cumulative Layout Shift is good at or under 0.1, needs improvement to 0.25, poor beyond. All three are assessed at the 75th percentile of real visits. LCP Largest Contentful Paint GOOD NEEDS IMPROVEMENT POOR 2.5s 4.0s INP Interaction to Next Paint GOOD NEEDS IMPROVEMENT POOR 200ms 500ms CLS Cumulative Layout Shift GOOD NEEDS IMPROVEMENT POOR 0.1 0.25 All three are judged at the 75th percentile of real visits, and mobile is scored separately from desktop.
The published boundaries. Everything to the left of the first line passes, and there is no partial credit for being close.

Put your own numbers in

  • LCP Largest Contentful Paint
    s

    Needs improvement

    Usually the hero image, the headline block, or whatever occupies the most space when the page first settles.

  • INP Interaction to Next Paint
    ms

    Needs improvement

    Replaced First Input Delay as a stable Core Web Vital in 2024, and it is stricter: it measures every interaction, not just the first.

  • CLS Cumulative Layout Shift
    score

    Good

    Has no unit. It is a score for how far things moved and how much of the screen moved with them.

Core Web Vitals assessment Failed

Scored against the published thresholds. An illustration of how the assessment works, not a measurement of your site.

The sentence everyone skips

To ensure you're hitting the recommended target for most of your users, a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices.

What that meansThe 75th percentile is the sentence people skip. You do not pass because the average visit passed. You pass when three quarters of real visits passed, which means your worst quarter of traffic is what decides it.

Two data sets

Lab Or Real Users

PageSpeed Insights shows two things that look like the same thing and are not. Reading the wrong one is the most common mistake made with this tool, and it is what produces the score that goes green while nothing changes.

One simulated load against twenty-eight days of real visits On the left, the lab test: a single simulated load on a throttled device producing one score, available immediately. On the right, the field data: a distribution of thousands of real Chrome visits over a rolling twenty-eight day window, with the seventy-fifth percentile marked as the value that is actually assessed. A note shows that a fix made today only begins to appear in the field distribution weeks later. LAB · RUN ON REQUEST THROTTLED 71 One run. One number. Different again next time. FIELD · 28 DAY ROLLING WINDOW 75th PERCENTILE This is the value assessed FASTER SLOWER WHAT A FIX LOOKS LIKE IN EACH Lab: moves on the very next run. Field: up to 28 days behind you.
One of these reacts to your fix today. The other is still averaging in visits from before you made it.
Lab data compared with field data
LabField
Where it comes from One simulated load, run now, on request Real Chrome visits from real people
How much data A single run A 28 day rolling window
What it reports The performance score and its five metrics The Core Web Vitals assessment
How fast it reacts Immediately, on the next run Up to 28 days behind your fix
Needs traffic No Yes, or there is nothing to show
What ranking uses Not this This

Both are useful and they answer different questions. The lab run tells you what to fix, because it can point at the exact resource. The field data tells you whether it worked, and it takes weeks to say so. Judging a fix by re-running the lab test is judging the fix by the tool you used to find it.

The claim

What It Actually Moves

Four sentences from Google's own page experience documentation, read in order. They do not contradict each other, and together they settle the argument.

Speed separates results that are already level Two comparisons. In the first, a more relevant slow page sits above a fast page that answers the question less well, because relevance decides. In the second, two pages of equal relevance are separated by speed, which is where it genuinely acts. A footnote states that there is no single page experience signal to raise. WHEN ONE PAGE ANSWERS BETTER RANKS FIRST More relevant SLOW RANKS SECOND Less relevant FAST Speed does not overturn this. No amount of green moves a page past one that answers the question better. WHEN THEY ARE ALREADY LEVEL RANKS FIRST Equally relevant FAST RANKS SECOND Equally relevant SLOW This is the whole of the ranking effect, and it is worth having. It is a tiebreaker, not a lever. AND THE EFFECT NOBODY REPORTS ON After the click. A slow page loses the visitor it already won, and no ranking report will ever show you that.
Speed acts between results that a ranking system already treats as comparable. That is a real effect and a narrow one.
  1. 01

    Google says

    Core Web Vitals are used by our ranking systems.

    Read itThis is real and it is why the topic exists at all. It is also the whole of the claim: used by, not decisive in.

  2. 02

    Google says

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

    Read itThere is no page experience score inside the ranking system to raise. Anyone selling you one is selling the Lighthouse number back to you.

  3. 03

    Google says

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

    Read itThe sentence that settles the argument. Speed does not promote a page past a more relevant one. It separates pages that are already close.

  4. 04

    Google says

    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.

    Read itWritten by Google, on Google's own documentation, about Google's own report. It is the most quotable line in the entire subject and almost nobody quotes it.

  • 01

    Where speed genuinely decides

    Between two pages a ranking system already considers comparable. At that point a tiebreaker is exactly what it is, and it is worth having on your side.

  • 02

    Where speed decides nothing

    Against a page that answers the question better than yours. No amount of green moves a page past better content, and treating speed as the fix wastes the budget that should have gone on the content.

  • 03

    Where speed decides everything

    After the click. A slow page loses the visitor it already won, and that loss never appears in any ranking report. This is the effect worth chasing and the one nobody measures.

The newer reason

Read By Machines

The newer reason to care has nothing to do with the score. Answer engines, AI overviews and assistant crawlers read pages at scale, and reading at scale rewards a different property than a fast-feeling page does.

What survives a reader that never runs your scripts The same page twice. On the left, as a person sees it after scripts have run: a full article with headings, text and an image. On the right, as a fetcher that does not execute JavaScript receives it: the heading and an empty container, with the body absent. Gold marks the content that exists in the HTML and therefore survives either way. AFTER THE SCRIPTS RUN WHAT ARRIVES WITHOUT THEM RAW HTML EMPTY CONTAINER The article is assembled here, in the browser, later In the HTML, so every reader gets it. Built in the browser, so it depends who is asking.
The same page, fetched two ways. Gold marks what exists in the HTML and therefore reaches every reader.
  • 01

    What is in the HTML is what gets read

    A page that assembles its content in the browser is complete for a person and empty for anything that fetches without executing scripts. The heavier the reliance on client-side rendering, the more of your argument is invisible to whatever is summarising it.

  • 02

    Slow responses cost you crawl, not rank

    Server response time is the ceiling on how much of a site anything can read in the time it has. A slow origin does not get penalised. It simply gets read less, and what is not read cannot be cited.

  • 03

    Structure survives, styling does not

    Headings, lists, tables and structured data are what a machine reader keeps. A page whose meaning is carried by layout, colour or an image of text loses that meaning entirely on the way in.

  • 04

    The blocking work is a human problem only

    Total Blocking Time is thirty per cent of your score and means nothing to a crawler that never waits for a tap. This is the clearest case where the score and the machine-readability of your page diverge, and it is why chasing the number is not the same as being readable.

One honest caveat: how any specific answer engine crawls and renders is not published in the detail Google publishes for Search. What is safe to say is architectural rather than tactical. Content that exists in the HTML, arrives quickly, and is structured is readable by every one of them. Content that does not may or may not be, depending on a system whose behaviour nobody outside it can confirm.

The fix order

Where The Seconds Go

Almost every bad score comes from four places, and they are worth fixing in this order because each one caps what the next can achieve.

Where the seconds actually go, before and after Two request waterfalls on the same timescale. In the first, a slow server response is followed by blocking stylesheets and scripts, then a large hero image, and the largest contentful paint lands late. In the second, the server responds sooner, the blocking resources are deferred, and the hero image is prioritised, so the paint lands much earlier. 1s2s 3s4s5s BEFORE Server CSS Scripts Hero image Third party LCP AT 3.6s AFTER Server CSS Hero image Scripts, deferred LCP AT 1.3s
The same page before and after, on one timescale. Nothing downstream can start until the server has answered.
  1. 01

    The server took too long to answer

    Moves LCP, and everything after it

    What to doNothing downstream can start before the first byte arrives. Caching, a faster host and a content delivery network act on this, and no amount of front-end work compensates for it.

  2. 02

    Something blocked the first paint

    Moves FCP and LCP

    What to doStylesheets and scripts in the head stop the page drawing until they are fetched and parsed. Inline what the first screen needs, defer the rest, and stop loading fonts and frameworks the opening view never uses.

  3. 03

    The largest element was expensive

    Moves LCP

    What to doUsually an oversized hero image with no dimensions, no modern format and no priority hint. Serve it at the size it displays, in a current format, and tell the browser it matters.

  4. 04

    Third-party code took the main thread

    Moves TBT, and INP for real users

    What to doTag managers, chat widgets, consent tools and analytics. This is where blocking time comes from, and each one was added by someone who is not measuring it.

Layout shift sits outside that order because it has a different cause and a simpler fix: reserve the space. Width and height on every image, a defined box for anything injected late, and no banner that pushes the page down after the reader has started reading.

Questions

Page Speed Questions

What the sections above raise rather than answer: the competitor who is slower and winning, how long a fix takes to show, and what a caching plugin does not do.

Because relevance is doing the work and speed is not overriding it. Google states that it seeks the most relevant content even when the page experience is sub-par. If a slower page is winning, the honest read is that it answers the query better than yours, and the budget you were about to spend on performance belongs on the content instead.

No, and the tool's own documentation says so. Google notes that a perfect score is extremely challenging and not expected, and that moving from 99 to 100 takes roughly the same effort as moving from 90 to 94. The green band starts at 90 for a reason. Everything past it is a hobby.

All three, at the 75th percentile, on the device type being assessed. There is no partial credit and no averaging between metrics. A page with excellent loading and unstable layout is a page that fails, because the reader who lost their place does not care how fast it arrived.

No. The lab test simulates a throttled device and a throttled connection, and simulation varies between runs. That variance is a property of the method, not a fault. It is also the reason a single lab run is evidence about what to fix and not evidence about whether the fix worked.

Field data is collected and assessed separately for mobile and desktop, so both exist and both are real. For most local and service businesses the mobile figure is the one that describes your actual traffic, and it is the harder of the two, which is why the desktop number is the one people quote.

The lab score moves on your next run, immediately. The field data will not, because it is a 28 day rolling window of real visits. Three weeks after a genuine fix the field number is still averaging in visits from before you made it. Judging a fix in week one and reverting it is a common and expensive mistake.

That not enough real Chrome visits to that specific address have been recorded to report on. It is a statement about traffic volume, not about quality or eligibility. You may still see an origin-level summary covering the whole domain, which is useful directionally and will not tell you anything about the page in front of you.

It will help the first of the four causes and only that one. Caching attacks server response time, which is genuinely the ceiling on everything else, so the improvement is often real and immediately visible. It will not remove a render-blocking script, will not resize an image, and will not reserve space for a banner that arrives late.

It sets the floor that the site cannot beat. A well-built page on a slow origin waits for the first byte like everything else, and no front-end work recovers that time. Beyond the floor the site is where the remaining seconds are, so the honest answer is that hosting is the cheapest early win and the smallest total one.

Where this comes from

The Published Pages

Every threshold, weighting and quoted sentence on this page comes from Google and web.dev documentation. The reading of what it all means is mine.

Zammy Zaif

Zammy Zaif

Global Search & Business Growth Strategist

The score gauges and threshold bars on this page use the colour conventions the tools use, because those are the colours readers already know. They are illustrations drawn for this article. Nothing here is a report from PageSpeed Insights, and thresholds change: check the source pages before acting on any number.

This page, measured

  • Performance, 100 out of 100
  • Accessibility, 100 out of 100
  • Best practices, 100 out of 100
  • SEO, 100 out of 100

Not a claim about future work. Every page on this site is specified to a performance figure before it is designed, and measured against that figure before it ships.

On mobile the performance score measures 99 and the other three hold at 100. Lab runs vary by a point between them, which is the same caveat this page makes about everyone else.

The standard is mine and it goes into the brief as a number rather than a preference. Versa Forge builds to it. That order is the reason it holds across every page instead of on the one that was tuned for a screenshot.

Lighthouse, desktop preset, production configuration. Measured on every page of this site, not on the homepage alone. Run it yourself on the page you are reading.

Find out what the speed is costing you

Bring the site and whatever the tools told you. I will work out which of the four causes you actually have, whether the ranking you lost has anything to do with speed, and what is worth spending money on before anything gets rebuilt.

Review my site speed Read other notes