50 Real Websites: Core Web Vitals Results Nobody Talks About

A 1.2-second Largest Contentful Paint should be good news.

On National Express, it was. The main content loaded comfortably inside Google’s recommended 2.5-second threshold. Interaction to Next Paint was also fine at 123 milliseconds.

The website still failed Core Web Vitals on desktop.

Its Cumulative Layout Shift was 0.95. That is nine and a half times the threshold needed to pass.

The page loaded quickly. Then bits of it apparently moved around like the furniture in a pub five minutes before opening.

That result gets to the problem I have with a lot of Core Web Vitals reporting. We take three different measurements, collected from different people across a 28-day period, and squash them into one reassuring green badge or one alarming red badge.

Then someone says the website is fast or slow.

It is rarely that simple.

I reviewed the real-user Core Web Vitals data for 50 UK-facing business websites to see what was actually causing them to pass or fail. Not Lighthouse scores. Not one-off tests from a clean browser on a good connection. Field data from the Chrome User Experience Report, as displayed in PageSpeed Insights.

The biggest pattern was not slow loading.

It was what happened after the page looked ready.

What I actually measured

I selected five websites from each of ten sectors: retail, food and hospitality, financial services, professional services, travel, property, health, manufacturing, software and digital media.

This was a deliberately balanced sample by sector. It was not a random sample of every UK business website, and I am not pretending five travel websites represent the entire travel industry. That would be a bit daft.

For each site, I recorded the 75th-percentile real-user figures for:

• Largest Contentful Paint (LCP), which measures when the main content appears.
• Interaction to Next Paint (INP), which measures how quickly the page responds to user interactions.
• Cumulative Layout Shift (CLS), which measures unexpected movement on the page.

A site passes on a device only when all three are inside Google’s “good” thresholds: LCP at or below 2,500 milliseconds, INP at or below 200 milliseconds and CLS at or below 0.10. Google assesses these at the 75th percentile, separately for mobile and desktop (Web Vitals).

I requested origin-level data so the comparison would be as consistent as possible. Origin data combines eligible experiences from across a website. Where PageSpeed had mobile data for the submitted homepage but not the origin, I kept the URL result and marked it as a fallback.

That happened on nine mobile results. Three other sites had no mobile field data at all. All 50 had desktop data.

No field data does not mean a site passed. It does not mean it failed either. CrUX only includes pages and origins that are publicly discoverable, sufficiently popular and used by eligible Chrome users. Google does not publish the traffic threshold (CrUX methodology).

Missing means missing. Not “probably fine”.

Mobile and desktop were telling different stories

Here is the broad result.

Result	Mobile	Desktop
Field data available	47 of 50	50 of 50
Passed all three Core Web Vitals	16	33
Pass rate where data was available	34%	66%

Desktop passed almost twice as often as mobile.

That part is not especially shocking. Mobile devices, connections and usage conditions are more varied. What matters is how the difference appeared.

Seventeen sites failed on mobile while passing on desktop. Only one site, ITV, did the reverse.

If mobile were simply a slower version of desktop, I would expect the same problems with larger numbers attached. That is not what the data showed. Some websites had a loading problem on one device and a responsiveness or layout problem on the other.

Rotork is a good example. Its mobile LCP was 5.2 seconds, which is a clear loading failure. On desktop the LCP dropped to 2.3 seconds and INP was a very good 62 milliseconds.

Desktop still failed because CLS reached 0.53.

Same website. Different device. Different failure. Different job to fix.

A single performance score turns that into “Rotork is slow”, which is about as useful as a mechanic looking at a warning light and announcing that the car is poorly.

LCP was not the biggest mobile problem

When people talk about Core Web Vitals, LCP tends to swallow the conversation. It is easy to understand, easy to demonstrate and often comes with an obvious culprit such as a large hero image.

In this sample, it was not the most common mobile failure.

Across the 47 sites with mobile field data:

• 22 breached the INP threshold.
• 15 breached the LCP threshold.
• 9 breached the CLS threshold.

Those numbers overlap because a site can fail more than one metric. Greggs, for example, failed all three on its mobile URL result.

The more revealing group was the eleven websites that failed mobile only because of INP. Their loading and layout stability were already inside the good thresholds.

Tesco’s origin-level mobile LCP was 2.2 seconds and its CLS was 0.01. It failed because INP was 223 milliseconds.

Rightmove loaded in 1.1 seconds with a CLS of zero. Its INP was 257 milliseconds.

ASOS, Screwfix, Decathlon, Greene King, Starling Bank, Nationwide, Checkatrade, Specsavers and Gumtree showed the same basic pattern.

These are not pages waiting around for the main image to appear. They are pages that have appeared and then taken too long to respond when somebody tries to use them.

That distinction matters because Lighthouse cannot measure INP. A simulated lab run has no real person clicking, tapping, opening menus or wrestling with whatever consent layer has been dropped on top of the page. Lighthouse uses Total Blocking Time as a useful lab proxy, but Google is clear that lab measurement is not a substitute for field measurement (Web Vitals).

If the field data says INP is the problem and the optimisation plan starts with compressing the hero image again, the plan has wandered off.

Desktop had a layout-shift problem hiding in plain sight

Mobile produced more failures overall. Desktop produced some of the stranger ones.

Five websites had good desktop LCP and INP but failed solely because of CLS:

• Premier Inn
• National Express
• easyJet
• Rotork
• ITV

National Express was the extreme result: 1.2-second LCP, 123-millisecond INP and 0.95 CLS.

Rotork reached 0.53. Premier Inn reached 0.22. The pages could load and respond within the recommended thresholds while still moving enough to lose the complete assessment.

This is where a quick Lighthouse run can give false comfort. CLS in CrUX covers the full visit, while a standard lab test mainly observes the initial page load. Layout shifts caused later by lazy-loaded content, banners, embeds, fonts or single-page application transitions can appear in field data without showing up in the same way during a tidy lab run (Google’s CLS guidance).

That does not tell me which component caused the shift on each of these sites. I would need page-level diagnostics or first-party real-user monitoring for that.

It does tell me not to declare the problem solved because the initial viewport sat still during one automated test.

Travel was the outlier, but not for one neat reason

Travel and transport was the only sector in which all five sampled websites failed on both mobile and desktop.

That sounds like the start of a lovely simple conclusion about travel websites being bloated.

Sadly, the evidence did not arrange itself that neatly.

Trainline failed mobile on LCP, INP and CLS. Its desktop loading passed, but INP and CLS still failed.

National Express loaded quickly on both devices. Mobile failed on INP and CLS; desktop failed on CLS alone.

easyJet passed LCP on both devices. It failed mobile on INP and CLS, then desktop on CLS.

British Airways failed mobile on LCP and INP, but desktop on LCP alone. Jet2 failed both LCP and INP on both devices.

There may be shared pressures: booking journeys, personalisation, live prices, consent systems, third-party services and a fair amount of interface complexity. But this dataset does not prove one common technical cause.

What it shows is more useful. Even inside the cleanest sector-level pattern, the individual diagnosis still changes by site and device.

“Travel sites are slow” fits nicely in a slide heading. It does not tell anybody what to fix on Monday.

The URL and the website are not the same measurement

PageSpeed Insights can show field data for the exact URL submitted or for the whole origin. Those are related, but they are not interchangeable.

The URL result describes eligible experiences for that page. The origin result combines eligible experiences across the website. The CrUX API supports both levels because they answer different questions.

During collection, Tesco made the difference obvious.

The submitted homepage’s mobile result showed a 3.0-second LCP and 360-millisecond INP. The origin result showed a 2.2-second LCP and 223-millisecond INP.

Both failed overall, but the diagnosis changed. At URL level, LCP and INP missed the good thresholds. At origin level, LCP passed and INP became the remaining problem.

If I copied the red “failed” label into a report and moved on, I would miss that completely.

This is also why I have kept the aggregation source in the dataset. Nine mobile rows had to use URL-level data because origin data was not exposed. Three had no mobile data. Desktop had origin data for all 50.

That imperfection belongs in the result. Hiding it would make the comparison look cleaner and the evidence worse.

The platform did not hand me a villain

I also collected likely platform and technology fingerprints where they could be identified.

Thirteen of the sampled sites were detected using Next.js. Four passed on mobile. Eleven passed on desktop.

The same framework appeared on sites that passed both devices, sites that failed only mobile and sites that failed both. Rotork and Sky used Next.js and failed both. PizzaExpress and Paddle used it and passed both.

That does not prove Next.js is good, bad or indifferent for Core Web Vitals. It proves that a framework label is not a performance diagnosis.

The raw technical counts were not much better as shortcuts. Purplebricks passed both devices with 51 scripts detected on the submitted page. Tesco failed mobile with 25. Holland & Barrett had 66 and failed mobile but passed desktop.

Script count can be a useful clue. It does not tell you what the scripts do, when they run, how much work they create, which users receive them or whether they block a meaningful interaction.

I could manufacture a platform league table from this and give everybody a new thing to argue about on LinkedIn. My bullshit radar would be going off while I wrote it.

The sample was balanced by sector, not CMS. Technology detection was incomplete on several sites. Bot protection and redirects blocked parts of the technical crawl. An honest WordPress-versus-Next.js-versus-Shopify verdict is not hiding in this data.

That is a limitation, not a missed content opportunity.

What I would fix first

If I had one day with each failing site, I would not begin with the longest list of Lighthouse opportunities.

I would begin with the field metric that actually lost the assessment, on the device where it happened.

For the eleven mobile INP-only failures, I would inspect real interactions. Which clicks and taps are slow? Is the main thread tied up by long tasks? Are event handlers doing too much work? Does a third-party script become expensive only after consent or interaction? Google’s INP guidance focuses on reducing input delay, processing time and the delay before the next frame can be painted (optimising INP).

For the desktop CLS failures, I would reproduce the full visit on a wide viewport rather than refreshing the homepage and staring at the top for five seconds. I would look at late banners, promotional modules, font swaps, embeds, lazy-loaded sections and transitions. Then I would collect layout-shift attribution in the field so the investigation followed the movement users were actually seeing.

For the LCP failures, I would break the number into its parts: server response, resource discovery delay, resource download and element render delay. Google’s LCP guidance is useful here because it stops every slow main element being reduced to “compress the image” (optimising LCP).

And where CrUX data was missing, I would install first-party real-user monitoring before pretending an occasional lab run represented the audience.

The order matters.

Find the device. Find the metric. Find the affected experience. Then diagnose the mechanism.

This is a snapshot, not the state of the UK web

There are limits to what these 50 websites can tell us.

The sample was chosen to balance sectors, not company size, traffic or platform. Five websites per sector can reveal an interesting pattern, but it cannot establish an industry law.

CrUX represents eligible Chrome users and is not restricted to UK visitors just because the website serves the UK. It also uses a rolling 28-day period, so results can straddle releases, campaigns, infrastructure problems and consent changes.

The figures were captured on 6 August 2026 and PageSpeed displays rounded values. They will move. That is what field data does.

These limitations do not make the exercise pointless. They define the size of the conclusion I have earned.

In this sample, mobile failures were common, INP was the leading mobile breach, desktop CLS caused several fast-looking sites to fail, and one headline score regularly hid different problems underneath.

That is enough to change how I would audit them.

The score was never the diagnosis

Core Web Vitals is useful because it forces performance discussions towards what real users experience. That is a considerable improvement on treating a single clean Lighthouse run as the voice of the public.

The mistake is taking that user data and flattening it again.

Pass or fail is the start of the investigation. It is not the finding.

The useful questions come next. Which device failed? Which metric caused it? Is the number for one URL or the origin? Does the problem happen during loading, interaction or the rest of the visit? Do first-party users experience the same thing? What is the website actually trying to help them do?

Core Web Vitals is an alarm panel, not a building survey. It can tell you which zone is flashing.

Writing down only “failed” and going home is the daft bit.