Google will not say what page speed is worth in rankings. The measured gains show up in conversion

The site that loaded instantly on my own laptop

I built my clinic's website myself. The pages, the Google Business Profile, the analytics and the tracking were all mine, done on a small budget with no agency, around work as a prescribing pharmacist. I published the Search Console data from that work as a case study on this site.

One habit from that period is worth admitting to. I judged the site on my own screen, on a good connection, in a browser that already had every image cached. It felt immediate. Whether it was immediate for a woman standing outside the building on an older Android handset was a question I was not asking, because the tool I was looking at was not answering it.

That gap, between the speed an owner experiences and the speed a visitor experiences, is where most of the confusion about page speed lives. It also explains why the advice arrives in two incompatible forms: that speed barely matters to ranking, or that a slow site is invisible.

The evidence about ranking is thin, and Google has chosen not to quantify it. The evidence about whether people finish a booking is stronger, better controlled and almost entirely separate from search.

What the three metrics actually measure

Google defines Core Web Vitals as "the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools" ^[1]. There are three, and each describes a different kind of annoyance.

Largest Contentful Paint records when the biggest piece of content in the opening view has been painted, which on most small business pages means the hero image or the main heading. The guidance is that "LCP should occur within 2.5 seconds of when the page first starts loading" ^[1]. Interaction to Next Paint measures responsiveness, and "pages should have a INP of 200 milliseconds or less" ^[1]. Cumulative Layout Shift scores how much the content jumps about while the page settles, and "pages should maintain a CLS of 0.1 or less" ^[1].

Responsiveness changed definition recently. Interaction to Next Paint became a Core Web Vital on 12 March 2024, replacing First Input Delay, which measured only the delay before the first interaction began to be handled. The newer metric "takes all interactions into account" and runs until the browser can paint the next frame, which the Chrome team called "a much more comprehensive measure of user-perceived responsiveness than FID" ^[5].

None of the three is read as a single number. Google's advice is that "a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices" ^[1], a percentile chosen so that "a majority of visits to a page or site experienced the target level of performance" ^[2].

The thresholds are often repeated as though they were facts about human perception. They are partly that and partly a negotiation with what the web can deliver. The documented reasoning cites research describing user focus thresholds as "a range, from roughly 0.3 to 3 seconds", then settles on 2.5 seconds because that figure is "consistently achievable" for better performing sites ^[2]. So passing is not a synonym for fast, and failing is not a synonym for broken.

Where the numbers come from, and why a small site may have none

Everything here turns on a distinction the tooling states plainly: "CrUX is a collection of real-user experiences from the field, while Lighthouse is a controlled test in the lab" ^[7]. The field data is the Chrome User Experience Report, and Google’s own reporting is built on it.

That dataset is narrower than most owners assume. A visit counts only if the user has enabled usage statistic reporting, syncs their browser history, has no sync passphrase set and is on a supported platform ^[6]. Nobody browsing in Safari or Firefox is in it. There is also a traffic floor: pages and origins "that don't meet the popularity threshold are not included in the CrUX dataset", and the exact number "is not disclosed" ^[6].

For a single location clinic, a two partner firm or a tradesperson's five page site, that floor is the fact that matters most, and it is almost never mentioned in a performance sales pitch. When a site falls below it, Search Console says so. A "No data available" screen "means either that your property is new in Search Console, or that there is not enough data available in the CrUX report to provide meaningful information for the chosen device type" ^[8]. For a large share of UK small business sites, the honest position is that Google holds no field measurement of their pages at all, which leaves the commercial argument as the only one that can be tested.

The reporting window matters too. PageSpeed Insights "aggregates new data every day encompassing the previous 28 days" ^[7], and where responsiveness data is thin "the page is assessed on the other two Core Web Vitals metrics" ^[7]. An owner who refreshes the score the day after a fix and concludes nothing happened is reading the window, not the result.

The score an owner is shown is not the measurement that counts

The number that arrives in a cold email is almost always the Lighthouse performance score, the figure out of 100 with a coloured ring around it. In Lighthouse 10 it is a weighted average in which Total Blocking Time carries 30 per cent, Largest Contentful Paint 25 per cent, Cumulative Layout Shift 25 per cent, First Contentful Paint 10 per cent and Speed Index 10 per cent ^[9]. The heaviest component is a laboratory metric and not a Core Web Vital. Interaction to Next Paint, which is one, does not appear at all, because responsiveness cannot be observed without a real person clicking something ^[9].

The score also moves on its own. The documentation notes that "When your Performance score fluctuates it's usually because of changes in underlying conditions", listing A/B tests, changes in the adverts served, traffic routing and browser extensions ^[9]. Its own advice is to think of "your site performance as a distribution of scores, rather than a single number" ^[9]. A red score in an email says something real about how a page is built and nothing reliable about how it performs for visitors.

What Google says about speed and ranking, and what it declines to say

Google's documentation is careful here, and the care is informative. Its page on Core Web Vitals says that achieving good scores, "along with other page experience aspects, aligns with what our core ranking systems seek to reward" ^[3]. That is a statement about alignment, not about weight.

The page experience documentation closes off the usual follow up question. Asked whether there is a page experience signal, it answers: "There is no single signal. Our core ranking systems look at a variety of signals that align with overall page experience" ^[4]. The same page sets the order of priority without ambiguity.

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

It also warns against the single fix approach the performance industry depends on: "Site owners seeking to be successful with our systems shouldn’t focus on only one or two aspects of page experience" ^[4]. The aspects listed alongside good Core Web Vitals are secure HTTPS serving, mobile friendly display, minimal and non intrusive advertising, no intrusive interstitials, and a clear distinction between the main content and everything around it ^[4].

Two things follow. Nobody can tell an owner what a given improvement in loading time is worth in ranking positions, because the figure has never been published. And a page that is the best available answer can rank well while failing all three metrics, because relevance comes first ^[4].

The commercial evidence is stronger than the ranking evidence

If the ranking case is weak, the commercial case is the opposite, and the best piece of it is a controlled test rather than a correlation. Vodafone in Italy split its traffic evenly between a performance optimised landing page and the existing one, with "no functional or visual differences between the two versions" beyond the performance work ^[16]. Rendering logic moved from the browser to the server, critical HTML was rendered server side, and images were resized, compressed and lazy loaded ^[16].

The optimised version improved Largest Contentful Paint by 31 per cent and produced "An 8% increase in sales", a 15 per cent improvement in the lead to visit rate and an 11 per cent improvement in the cart to visit rate ^[16]. Google's own summary records the same pairing, a 31 per cent improvement and 8 per cent more sales ^[15].

One detail deserves more attention than it gets. The improvement took the page from 8.3 seconds to 5.7 seconds ^[16], still more than twice the 2.5 second threshold Google calls good ^[1]. The gain came from moving a very slow page to a merely slow one. Nothing in the test shows what happens when a page that already passes is made faster still.

The most quoted study in the field needs the same reading. The research known as Milliseconds Make Millions was "commissioned by Google and conducted by 55 and Deloitte", examining 37 leading European and American brand sites and over 30 million user sessions across 30 days at the end of 2019 ^[17]. For a 0.1 second improvement in load time it reports an 8.4 per cent rise in retail conversion and a 21.6 per cent improvement in the number of users reaching a form submission page ^[17]. Those are large numbers attached to a small time saving, which is when a reader should slow down. The study is observational, it was paid for by the company that benefits from the conclusion, and its subjects are major brands rather than a clinic taking twelve bookings a week.

How most sites actually perform

The web wide picture is measured annually from the same field dataset. In 2025, 48 per cent of mobile websites and 56 per cent of desktop websites had good Core Web Vitals overall, with mobile up from 44 per cent the year before ^[13].

Broken down on mobile, 62 per cent of pages had good loading, 77 per cent had good responsiveness and 81 per cent had good stability ^[13]. On desktop the first two stood at 74 per cent and 97 per cent ^[13]. Loading is therefore the usual point of failure on a phone, and responsiveness shows the widest gap between a phone and a desktop ^[13].

The platform figures sharpen this. WordPress powers "roughly 64% of CMS-driven sites" ^[14], and among content management systems it "remains among the lowest-ranked with a pass rate of 45%", with good loading on 53 per cent of sites, having gained around 4 per cent year on year ^[14].

Put those together and the portrait of a typical UK small business website appears without much effort. It is a WordPress installation with a purchased theme, a page builder, a slider, a large uncompressed hero image and a handful of plugins. On a phone it most likely fails on loading, and its owner has probably never seen field data for it ^[6].

What is worth fixing, and in what order

Loading is the first target because it is the commonest failure and because its parts are documented. Google breaks Largest Contentful Paint into four stages: time to first byte, the delay before the browser starts loading the largest resource, the time taken to load it, and the delay before the element appears ^[10]. On a well optimised page it suggests roughly 40 per cent of the time in time to first byte and roughly 40 per cent in loading the resource ^[10]. The named causes of a slow result are familiar: render blocking stylesheets, synchronous scripts in the document head, JavaScript that adds the largest element after the fact, and redirects ^[10].

Stability is the cheapest fix available and almost always the one left undone. The documented causes are short: "Images without dimensions", "Ads, embeds, and iframes without dimensions", dynamically injected content and "Web fonts" ^[12]. The remedy is to "Always include `width` and `height` size attributes on your images and video elements", or reserve the space in CSS, so that "the browser can allocate the correct amount of space in the document while the image is loading" ^[12].

Responsiveness is the hardest to reason about without measurement, and its causes are structural: the work the browser does at startup to parse, compile and execute JavaScript, large page structures where rendering work "tends to scale with increasing DOM size", and forced synchronous layout ^[11]. On a small business site this usually means too many plugins and embedded widgets. A defensible order of work looks like this.

1. Open the page on a real mid range phone and identify the largest element in the opening view, then check it is in the HTML rather than inserted by a script ^[10].
2. Measure hosting response time and remove redirect chains, since time to first byte is around 40 per cent of the loading budget ^[10].
3. Compress and correctly size the hero image, and make sure the largest element is not being lazy loaded ^[10].
4. Add width and height attributes, or an aspect ratio, to every image, video, advert and embed ^[12].
5. Reserve space for anything that loads late, and avoid inserting content above existing content without a user action ^[12].
6. Remove plugins and widgets that run JavaScript at startup, and keep the page structure small ^[11].

One thing rarely worth fixing is the network, because in the United Kingdom it is seldom the problem. Ofcom's measurement of real handsets found 71 per cent of cellular connections on 4G and 28 per cent on 5G, with 3G down to 0.7 per cent ^[20]. Downloading a 2MB file took 0.3 seconds on 5G and 0.7 seconds on 4G, against 4.9 seconds on 3G ^[20]. A heavy page on a modern UK mobile network is a page problem, not a coverage problem.

What it means for a local business

Start from where the traffic is. Ofcom reports that UK adults now spend an average of four and a half hours online a day, that most of that time is on a smartphone, and that Google Search is used by 82 per cent of adults and handles 3 billion searches a month ^[19]. The visitor being argued about is holding a phone.

Then change the question. Asking what page speed is worth in ranking positions produces a guess or a sales pitch, because Google states there is no single page experience signal and has never published a weight ^[4]. Asking whether the page loses people between the click and the completed booking produces a number the business can obtain from its own analytics ^[6].

For a clinic, a practice or a firm, that reframing moves the work off the home page, where the score is measured and admired, and onto the pages carrying the booking form and the prices. If I were spending the first hour of a performance budget on my own clinic site, it would go to the booking page.

• Fix the mobile hero image and the layout shifts first, because loading is the commonest mobile failure ^[13] and dimensionless images are the first named cause of instability ^[12].
• Do not buy a performance retainer priced against a Lighthouse score, which is a laboratory number that moves for reasons including traffic routing and browser extensions ^[9].
• Do not accept a claim that a stated speed improvement will deliver a stated number of positions, because no published source supports that arithmetic ^[4].
• Treat the work as a conversion project with a possible search benefit, which is how the better controlled evidence reads ^[16].
• Check Search Console first to see whether field data exists at all, because if it does not, the only honest measure is the conversion rate of the pages being changed ^[8].

What remains uncertain

The size of the ranking effect is unknown, and it is unknown deliberately. Google has described alignment with its ranking systems ^[3] and refused the concept of a single signal ^[4], and it has never published a weight.

Attempts to measure the effect from outside run into a problem that is easy to state and hard to solve. One of the larger published attempts, an analysis of more than 5.2 million pages carrying Core Web Vitals data, set out to do exactly this ^[18] and then said plainly that it could not.

I wanted to study the impact of Core Web Vitals on rankings. But due to the timing of the rollout and other updates that happened at the same time, I don't think there's a good method that is conclusive.

The same analysis names the confound that undermines most correlational work here: "sites that are more likely to work on their SEO also rank better than those that don't" ^[18]. A tidy relationship between good vitals and good positions may be measuring how diligent a business is about its website in general.

The second open question is whether the commercial evidence transfers. The controlled test was run by a telecommunications company on a page receiving tens of thousands of visits a day ^[16], and the most cited study examined large brands ^[17]. I have not found a published randomised test on a single location UK clinic or professional practice.

The third is that the target moves. First Input Delay was a Core Web Vital until 12 March 2024, when Interaction to Next Paint replaced it ^[5]. The thresholds were set partly on what was "consistently achievable" when they were chosen ^[2], so they can tighten as the web improves. A site that passes comfortably today is passing against this year's line.

What is solid is narrower than either side of the usual argument suggests. The three metrics are defined, measured from real Chrome users rather than from a laboratory, and published where enough traffic exists ^[1][6]. Google says good scores align with what its ranking systems reward and that no single signal exists ^[3][4]. The best controlled evidence that fixing them pays is commercial rather than positional ^[16].