Half the mobile web still misses Core Web Vitals, and loading is the reason
What the 2025 Web Almanac shows: 48% of mobile sites pass Core Web Vitals, loading is the weakest measure, and image choices matter.
Most conversations about website speed are about opinions. The HTTP Archive’s Web Almanac gives us a rare thing: public measurements of millions of real sites. We read the 2025 Performance chapter and the 2024 CMS chapter to answer one question: where do sites actually fall short?
Our reading is that, on mobile, the problem is mostly loading, and that a lot of it is fixable with decisions about images.
Why speed matters at all was put precisely by the economist Herbert Simon in 1971, long before the web:1
Hence a wealth of information creates a poverty of attention …
A slow page spends the scarcest thing a visitor brings.
How many sites pass Core Web Vitals?
According to the 2025 Web Almanac, 48% of mobile sites had good Core Web Vitals in July 2025, up from 44% in 2024. On desktop, 56% passed, up from 55%.2 The Almanac itself describes the desktop change as marginal.2
48%
of mobile sites pass all three measures
+4 pts
on mobile since 2024 (from 44%)
56%
of desktop sites pass (55% in 2024)
That means about half of mobile sites still fail at least one of the three measures. (For what each measure means, see our explainer.)
Which measure do most sites fail?
The chapter reports the share of sites with a good result for each measure. On mobile, 62% had a good Largest Contentful Paint, 77% a good Interaction to Next Paint and 81% a good Cumulative Layout Shift. On desktop the figures were 74%, 97% and 72% (Figures 7.7, 7.13, 7.17 and 7.18).2
Share of sites with a good result, July 2025
MobileDesktop
On mobile, loading is the lowest of the three. That is the pattern worth noticing, because LCP is often set by a single image.
Two other things stand out. Responsiveness is nearly solved on desktop (97%) but still behind on mobile (77%). And layout stability is better on mobile than on desktop (81% against 72%), the one place where desktop trails.
The image decision
The Almanac checked how pages treat their largest image. It found that fetchpriority="high", an instruction that tells the browser to fetch an important image early, appeared on 17% of mobile pages with an LCP image, up from 15% in 2024. About 16–17% of pages lazy-loaded their LCP image, and the chapter warns this can hurt because it “delays the main content users are waiting to see.”2
web.dev gives the same advice from the other direction: do not lazy-load the likely LCP image, and use fetchpriority="high" on it.3
We want to be careful here. These figures show how common the practices are. They do not, on their own, show that fixing them would move a particular site from failing to passing. They do show that a simple, documented fix is used by a small minority.
Does the platform decide the result?
The 2024 CMS chapter gives mobile pass rates by platform, as a share of sites (Figure 12.7).4
Mobile sites with good Core Web Vitals, by platform
20232024
The 2024 chapter also gives a global figure of 51% for all origins as of June 2024.4
Platform choice does show up, and several moved a long way in a year. But three cautions apply. These are 2024 figures, so they pre-date the 2025 data above. They describe averages across very different sites, not what you will get. And WordPress, at about 36% of mobile sites in that crawl,4 hosts a huge range of setups, from carefully tuned to neglected. A low average for a platform used by so many people says little about any one site.
What we conclude
Francis Bacon’s advice on reading books applies just as well to reading data:5
“Read not to contradict and confute; nor to believe and take for granted; nor to find talk and discourse; but to weigh and consider.”
Weighed that way, the evidence supports three conclusions. We state them as our reading, not as findings of the Almanac.
- Start with loading on mobile. It is the lowest of the three measures, and most of what controls it is visible: the main image, the fonts and what blocks the first render.
- Treat the platform as one input. Averages differ by platform, but a site’s own choices of images, scripts and plugins decide its result.
- Measure before you change. Use field data where you have it, lab data to diagnose, and change one thing at a time.
What this data cannot tell you
Figures travel faster than their caveats. Abū Hurayrah (may Allah be pleased with him) narrated that the Messenger of Allah (peace and blessings of Allah be upon him) said:6
«كَفَى بِالْمَرْءِ كَذِبًا أَنْ يُحَدِّثَ بِكُلِّ مَا سَمِعَ»
رواه الإمام مسلم رحمه الله في مقدمة «صحيحه»، باب النهي عن الحديث بكل ما سمع، رقم ٥
“It is enough of a lie for a person to relate everything he hears.”
So, before passing these numbers on, note what they leave out:
- The Almanac measures home pages and uses Chrome data, so it excludes other browsers and may not match your audience.
- A site “passing” on three measures says nothing about whether the content is useful or the site is easy to use.
- Percentages are shares of sites, not of visits.
- We have not tested these platforms ourselves. We report what the Almanac measured.
References
Footnotes
-
Herbert A. Simon. “Designing Organizations for an Information-Rich World”, in Martin Greenberger (ed.), Computers, Communications, and the Public Interest (Baltimore: The Johns Hopkins Press, 1971); the chapter begins on p. 38, and the sentence quoted begins on p. 40 and continues on p. 41. ↩
-
HTTP Archive. Web Almanac 2025: Performance. Data from July 2025; read 25 October 2026. ↩ ↩2 ↩3 ↩4
-
web.dev. Optimize Largest Contentful Paint. Last updated 31 March 2025; read 25 October 2026. ↩
-
HTTP Archive. Web Almanac 2024: CMS. Published 11 November 2024; data as of June 2024. ↩ ↩2 ↩3
-
Francis Bacon. “Of Studies”, in The Essays or Counsels, Civil and Moral (London, 1625). Read in Project Gutenberg eBook no. 575. ↩
-
Muslim ibn al-Ḥajjāj (d. 261 AH). Ṣaḥīḥ Muslim, ed. Muḥammad Fuʾād ʿAbd al-Bāqī, al-Muqaddima, bāb al-nahy ʿan al-ḥadīth bi-kull mā samiʿa, ḥadīth no. 5, vol. 1, p. 10 (printed page number). ↩