In short
- The threshold moved in March 2026. Main content display must come in under 2.5 seconds, and that bar has not moved. What moves is the 75th percentile of your real visitors: more mobile, or more modest devices, is enough to turn a site from green to amber without a line of code changing.
- The most commonly failed point is display on mobile. Around 38% of mobile pages miss the threshold on that measurement, against 23% on interaction response time, measured at 200 milliseconds.
- Fewer than half of sites pass all three thresholds. So this is not a marginal requirement: it is where a competitive gap opens at equivalent content.
- Do not measure on your own machine. The assessment runs on your real visitors’ data, mostly mobile, not on a test launched from a desk connection.
One conversation keeps coming back since the spring: “our performance has degraded, we do not understand, we have not deployed anything”. In most cases that is accurate. The site did not slow down, and the bar did not move either: the audience being measured changed.
What actually moves, and what it implies
Three measurements govern the assessment: the display time of the main content, the response time to interactions, and the visual stability of the page while it loads.
| Measurement | What it describes | “Good” threshold in 2026 |
|---|---|---|
| Main content display | The moment the most visible element of the page is shown | Under 2.5 seconds, threshold unchanged |
| Interaction responsiveness | The delay between a click and the page’s visible response | Under 200 milliseconds |
| Visual stability | Layout shifts while the page loads | Under 0.1 |
The effect is mechanical, but it does not come from a change of rule. Your score is the 75th percentile of real visits over the last 28 days. Bring in a campaign that carries more mobile traffic, or a season when customers buy from a more modest phone, and that percentile rises without the site having slowed down for anyone. Worth saying in the meeting before anyone starts looking for someone to blame.
The mistake that costs the most Optimising what a test launched from a desktop measures. The assessment that counts is based on your real visitors’ data, on their devices and their connections. A site can show an excellent lab score and fail in the field, because half its traffic comes from a mid-range phone on mobile data.
Responsiveness, the badly handled subject
It is not the most commonly failed measurement, it is the least understood one. It does not measure loading speed but how long the page takes to respond to a click. A page that displays in one second and freezes for two on the first click fails, even though the visitor finds it “fast” when it opens.
The cause is almost always the same: too much code runs at load. Marketing tags, live chat, A/B tests, recommendations, the consent banner, session recording tools. Each looks light and they all run at the same moment, on the single thread that also has to answer the click.
This matches an observation we make in almost every audit: the degradation does not come from the theme or the hosting, but from the accumulation of tools nobody ever removed. The first gain is often an inventory, not an optimisation.
The method, before calling a developer
- Look at field data, not a test. The user experience report, available in Search Console, gives what your visitors actually live through over twenty-eight days. That is the source that decides, and it is free. A single test, on the other hand, proves nothing: on our own site, four consecutive runs with nothing changed returned 100, 97, 99 and 97.
- Separate mobile from desktop. Blended averages almost always hide a struggling mobile and a comfortable desktop. On a shop, mobile is the subject.
- Inventory what loads. List the third-party scripts on a product page and ask, for each, who uses it and for what decision. A third of them, generally, no longer serve anyone.
- Handle images before code. Modern format, declared dimensions and lazy loading solve most of display and visual stability, without touching the theme.
Ten-minute self-check: open your best-selling product page on a phone, on mobile data, and count out loud until the main image appears. Then tap the add-to-basket button and count until something moves. Those two numbers are worth every report.
The options, and what they are worth
| Option | What you get | Who it suits |
|---|---|---|
| Remove useless third-party scripts | The best effort-to-result ratio, on responsiveness above all. No cost, immediate effect, and nothing breaks if the inventory is done seriously | Everyone, and it is where you start |
| Handle images | Solves most of display and stability. Done without touching the theme | Shops with visual catalogues, so nearly all of them |
| Add caching and a delivery network | Improves display, does nothing for responsiveness. Often sold as the solution when it only addresses one metric in three | International traffic, lightly personalised pages |
| Rebuild the theme | Can solve everything, costs months, and does not survive if script accumulation resumes afterwards | When the platform really is at fault, which is rarer than claimed |
Tooling
Two distinct needs: measuring continuously on real visitor data, and applying the repetitive optimisations without spending your days on them.
On PrestaShop we deploy the modules published by Datafirefly Limited, our agency’s sister company: Core Web Vitals to track the three measurements on real traffic rather than a one-off test, and the Speed Pack for image and loading optimisations. One-off purchase · 12 months of updates.
Method beats tooling, and it is particularly true here: no module decides on your behalf to remove the session recording tool nobody consults any more. That is a decision, and it is often the biggest win of the engagement.
What this says more broadly
Speed is treated as a technical subject, steered by a score, and that is what makes it ineffective. A score does not tell you what a visitor feels, nor what they abandon.
The useful question is not “what is our score”, but “how long does a customer wait before she can add to basket, on her phone, on the train”. Framed that way, it belongs to marketing as much as to engineering, and it joins the work on journey friction we carry out within our UX and CRO practice.
Sources
The verifiable claims in this article link to their primary source, opened on 10 August 2026. We do not cite a source we have not read.
- web.dev, Largest Contentful Paint (LCP). Consulter
- web.dev, Web Vitals. Consulter
- web.dev, How the Core Web Vitals metrics thresholds were defined. Consulter
- Chrome for Developers, Chrome UX Report release notes. Consulter
- Google Search Central, Understanding Core Web Vitals and Google search results. Consulter
- Google Search Console Help, Core Web Vitals report. Consulter
- HTTP Archive, Web Almanac 2025, Performance chapter. Consulter
FAQ
Has the threshold changed recently?
No. Main content display is still assessed at 2.5 seconds, responsiveness at 200 milliseconds and visual stability at 0.1. Those values have not moved and no Google release note announces a tightening. An unexplained degradation almost always comes from a shift in your traffic mix, not from a change of rule.
Which one is hardest to hold?
Main content display on mobile: around 38% of pages miss the threshold, against 23% on responsiveness. Responsiveness remains the worst handled, because it is solved neither by caching nor by a delivery network, but by reducing what runs at load.
Does a score of 100 in a test guarantee compliance?
No. The test simulates a visit; the assessment that counts is based on your real visitors over twenty-eight days. An excellent lab score coexists very comfortably with a field failure, usually because of mobile.
Is it really a ranking factor?
It is one signal among others, weighing mostly at comparable content and authority. In other words it breaks ties more than it ranks. But its effect on conversion depends on no search engine at all.
Can Dotsland help?
Yes. Reading field data split by mobile and desktop, inventorying third-party scripts with a decision on what can go, handling images, and tracking over time. It is part of our UX and CRO practice. Let’s talk, or start with the two counts in the self-check.