Why a Fast, Modern Website Matters More Than Ever

Cut the weight. That is the headline. The HTTP Archive’s 2025 Web Almanac shows 57% of mobile home pages under 1 MB passing Google’s Core Web Vitals assessment against 30% of pages 5 MB or larger, and the median mobile home page now ships 2,164 KB — of which images and JavaScript are 71%. Most speed work on most sites is weight work, not clever code.

The reason this matters more than it did five years ago is that the measurement moved from your laptop to your visitors’ devices. Google’s page experience signals use field data from real Chrome users, so a site that feels quick on office fibre can still be failing for the person on a three-year-old Android phone on a train.

What fast means when Google measures it

Three metrics, each measuring something a visitor can feel. Largest Contentful Paint asks how long until the biggest visible thing finishes rendering. Interaction to Next Paint asks how long between a tap and the screen changing, across the whole visit rather than just the first interaction. Cumulative Layout Shift asks how much the page jumped around while loading.

That last number is the one people skip. A metric counts as good when at least 75% of page views meet the threshold, and mobile and desktop are assessed separately. So your median visitor having a nice time is not the test. The test is whether your slowest quarter is still inside the limit.

How the web is actually doing

The Almanac’s 2025 performance chapter, built on Chrome UX Report field data from July 2025, is the best public view of where the web stands. Mobile has climbed steadily — 36% of sites passing all three vitals in 2023, 44% in 2024, 48% in 2025 — while desktop has nearly plateaued at 56%.

Two details in that chapter are genuinely useful for planning. First, the mobile curve is U-shaped by popularity: 51% of the thousand most popular sites pass, dropping to 37% in the next hundred thousand, then recovering to 48% among the least popular. Big sites invest in performance and tiny sites are simply lighter; the squeeze is in the middle, where complexity arrives before the performance budget does. Second, secondary pages pass more often than home pages — 56% against 45% on mobile — because caches are warm and inner templates are more consistent. If you only ever test your home page you are testing your worst case.

Weight is the lever, and the data is blunt about it

The page weight chapter makes the correlation hard to argue with. Pass rates fall with every megabyte, on both devices, without exception.

For scale, here is the distribution of page weight across the web in 2025. If your pages sit above the median you are not unusual, but you are choosing the harder path.

Home pages carry more than inner pages: a 2,710 KB median against 1,866 KB. Almost all of that difference is images, which drop from 911 KB on a median mobile home page to 354 KB on an inner one.

Your largest element is almost certainly an image

LCP is good on 74% of desktop pages and 62% of mobile pages, and poor on 13% of mobile pages against 7% on desktop. The fix is usually one element: the Almanac found an image is the LCP element on 85.3% of desktop pages and 76% of mobile pages, with text accounting for most of the rest.

So before you refactor anything, find out what your LCP element is on your three most visited templates. If it is an image — and the odds say it is — the checklist is short:

• Serve it in AVIF or WebP at the size it is actually displayed, with a srcset for narrow screens.
• Never lazy-load it. loading="lazy" on the hero image is the single most common self-inflicted LCP wound.
• Preload it, or let it be discoverable in the initial HTML rather than injected by script.
• Set width and height so the browser reserves the space.
• Check it is not sitting behind a slider, a cookie banner or a font that blocks render.

Responsiveness is a JavaScript problem

Interaction to Next Paint is the widest device gap in the data: 97% of desktop sites are good against 77% on mobile. That gap narrowed from 23 percentage points in 2024 to 20 in 2025, which is progress, but it still means roughly one mobile site in four feels sluggish when you tap it.

INP is not bandwidth. It is the main thread. An interaction is slow when the browser is busy running your JavaScript and cannot paint a frame. With a median 632 KB of JavaScript on mobile home pages, there is usually plenty to be busy with. The practical moves are unglamorous: ship less script, break long tasks into smaller ones so the browser can interleave painting, move heavy work off the main thread, and defer third-party tags until after first interaction.

Layout stability is the cheap win

Cumulative Layout Shift is the one metric where mobile beats desktop: 81% of mobile pages are good against 72% on desktop, and mobile has improved from 62% in 2021. Single-column layouts have less room to rearrange themselves. It is also the cheapest vital to fix, because almost every cause is a missing dimension.

1. Set explicit width and height on every image and video.
2. Reserve fixed space for ad slots, embeds, consent banners and anything injected by script.
3. Use font-display: swap with a metrics-matched fallback so a web font swap does not reflow the paragraph.
4. Never insert content above existing content after load — put the notification bar at the bottom or reserve its height.
5. Animate with transform and opacity rather than properties that trigger layout.

The fixes, in the order that pays

In the order that usually returns the most for the least effort on a typical business site:

Hosting, caching and the bit before your code runs

Everything above is about your code. The first few hundred milliseconds are not: they are DNS, the TLS handshake, and how long your server takes to produce the first byte. Cheap shared hosting with a cold cache and a database on the same overloaded box will cost you half a second before anything you wrote begins to matter.

You do not need to overspend here. For most content sites, page caching plus a CDN for static assets closes most of the gap, and it is far cheaper than re-architecting an application. Measure Time to First Byte from the regions your visitors are actually in, not from your own city, before you decide you have a hosting problem.

How to measure without buying a lab

1. Read your field data first: Search Console’s Core Web Vitals report, or the CrUX data in PageSpeed Insights. Mobile and desktop separately.
2. Use a lab tool — Lighthouse or WebPageTest — only to diagnose, never to grade. A lab score is a hypothesis about your field data.
3. Throttle. Mid-tier Android CPU profile and a 4G connection is a fair approximation of a real visitor.
4. Measure INP by interacting: open the menu, filter the list, submit the form. A page load with no interaction produces no INP at all.
5. Record a baseline per template before you change anything, so you can prove the improvement rather than assert it.
6. Re-measure after every third-party addition. That is where regressions come from.

If you would rather hand this over, our web development and hosting service covers performance audits, image and bundle work, caching and CDN setup, all delivered remotely wherever your business is based. Related reading: mobile-first web design, because the narrow layout is where these numbers are decided; web accessibility basics, since simpler markup helps both; and how to redesign without losing rankings if the rebuild is already scheduled.

Want to know exactly which three changes would make your site faster? Get in touch with Eudora Technology to talk about your project.