Why Website Speed Matters (and How to Fix It)

Fix the largest image on your most important page, move your hosting somewhere competent, and put a CDN in front of it. Those three jobs account for most of the speed problem on most small business sites, and you can do them in a week. The rest of this article explains which measurements tell you whether it worked, and what the published research says the improvement is worth.

The three numbers that get measured

Core Web Vitals are three metrics, and each one answers a question a visitor would actually ask. Largest Contentful Paint asks when the main thing on the page appeared. Interaction to Next Paint asks whether the page responded when you tapped something. Cumulative Layout Shift asks whether the layout stayed still while you were trying to read it.

The important detail is in how they are judged. A page is assessed at the 75th percentile of real visits, separately for mobile and desktop, using data from actual Chrome users rather than a test run. That means a quarter of your visitors can have a worse experience than your reported figure, and it means your own impression of the site is close to worthless as evidence. Your laptop on office broadband is not the 75th percentile of anything.

The 2025 Web Almanac notes one change worth knowing: reporting for LCP and INP has expanded beyond Chrome to other browser engines, so cross-browser comparison is becoming possible. The thresholds themselves have not moved.

What good means, and where the bands sit

Here are the bands, including the two supporting metrics that tell you where a bad LCP comes from. Time to First Byte is your server and network; First Contentful Paint is everything the browser has to do before it can draw.

Notice that two of the three Core Web Vitals have nothing to do with how fast your server is. Layout shift is a CSS problem. Interaction delay is a JavaScript problem. Only LCP really cares about hosting, and even there the image is usually the larger share of the blame. Which is why ‘we moved to faster hosting and nothing changed’ is such a common and such an avoidable story.

How the web is actually doing

The HTTP Archive measures this across millions of sites every year, so there is a real baseline to compare yourself against rather than a vendor’s assertion. The 2025 edition, published in January 2026 from the July 2025 crawl, found 48% of mobile sites and 56% of desktop sites passing all three Core Web Vitals.

Mobile has improved steadily, from 36% in 2023 to 44% in 2024 and 48% in 2025, which the chapter attributes to a mix of better browsers, better devices and actual optimisation work. Desktop has nearly stalled, moving only from 55% to 56% in the last year. The comfortable reading is that the web is getting faster. The useful reading is that roughly half of all sites still fail on phones.

The distribution by popularity is the part that should make small business owners sit up. On mobile, 51% of the thousand most popular sites pass. That drops to 42% for the next 10,000 and 37% for the next 100,000, then climbs back to 42% and 48% for the next million and ten million. The Almanac reads this as a complexity curve: the biggest sites invest in performance, the smallest sites are simple enough to be fast by default, and the middle carries plugin-heavy complexity without the budget to tune it.

There is one more finding worth stealing. Secondary pages pass Core Web Vitals far more often than home pages: 61% against 47% on desktop and 56% against 45% on mobile. Part of that is caching, and part of it is that home pages accumulate carousels, video embeds and whatever marketing asked for last quarter. Your home page is probably your slowest page and your most important one.

What faster pages are worth

Speed arguments usually stall on the question of what it is worth, so it helps to have named figures from named companies rather than a round number from a sales deck. Google’s own published case studies collect them, and the pattern across very different businesses is consistent.

The Nuvemshop case is the most useful of those because it is recent, large and specific. The platform runs more than 180,000 online stores. Over a year, the share of its stores with healthy LCP went from 57% to 96%, and the share passing all of Core Web Vitals went from 48% to 72%. The fixes were not exotic: they removed CSS transitions from first-position sections, stopped lazy-loading images at the top of the viewport, and added explicit fetchpriority="high" to the hero image.

That write-up also cites Deloitte research commissioned by Google, covering more than 30 million sessions across 37 brands, which found a 0.1 second improvement in load speed can increase retail conversion rates by 8.4%. Treat that as a direction rather than a promise. The honest version of the claim is that for transactional sites, speed changes behaviour measurably, and the effect is largest on mobile.

Where the time goes on a typical page

On a typical small business site, the time breaks down into three buckets, and most people spend their effort on the wrong one. The first bucket is server and network time, which Time to First Byte captures. The 2025 Web Almanac put 55% of desktop sites and 44% of mobile sites in the good band for TTFB, meaning under 0.8 seconds, with 17% of mobile sites in the poor band at over 1.8 seconds. If you are in that poor band, no amount of image work will save you.

The second bucket is render-blocking work: stylesheets and fonts the browser must fetch before it can paint anything. This is where the web is doing worst and improving least. Only 13% of desktop pages and 15% of mobile pages passed the render-blocking resources audit in the 2025 crawl, a figure that moved by a single percentage point in a year.

The third bucket is the hero image itself, and it is usually the single biggest item. An unsized photograph straight from a phone camera can be four megabytes. The same image resized to its display width and saved as WebP or AVIF is often under a hundred kilobytes. That one change routinely takes a second or more off LCP on a mobile connection, and it requires no developer.

The fixes, in the order they pay

Do these in order. Each one is cheaper than the one below it, and doing them out of order is how people spend money without moving the numbers.

1. Fix the hero image. Resize to the display width, convert to WebP or AVIF, set explicit width and height, and remove loading="lazy" from anything above the fold.
2. Turn on caching and a CDN. Page caching plus edge caching fixes TTFB for visitors who are not near your server, and it is usually a setting rather than a project.
3. Reserve space for everything that loads late. Images, ads, embeds, cookie banners. This is almost the entire CLS problem.
4. Cut third-party JavaScript. Audit what is loading and remove the trackers nobody reads. This is where INP lives.
5. Deal with fonts. Self-host, subset, and use font-display: swap so text is readable while the font loads.
6. Then look at hosting. By this point you will know whether your server is the bottleneck, because TTFB will tell you.

Hosting comes last on that list deliberately, which surprises people. It matters, and a genuinely slow host puts a floor under everything else, but it is rarely the biggest single number. Our guide to hosting types covers how to tell whether yours is the problem, and what the realistic tiers cost.

Measuring it without fooling yourself

There are two kinds of measurement and confusing them wastes a great deal of time. Lab tools run a single simulated page load on a fixed device and connection, which makes them reproducible and useful for debugging. Field data is what real visitors on real devices experienced, which makes it messy and the only thing that counts for ranking.

Field data lags, typically reflecting a rolling 28-day window, so do not expect a fix deployed on Tuesday to show up on Thursday. Use the lab tool to confirm the change worked technically, then wait for the field data to confirm it mattered. If you are planning larger changes, our note on redesigning without losing rankings covers how to keep performance and search visibility while the site changes underneath you.

What to do this week

Open your most important page on a phone, on mobile data, and count. If the main content takes more than two and a half seconds to appear, start with the image. Then check whether page caching is on, and whether there is a CDN in front of the site. Those three checks take fifteen minutes and will tell you which of the three buckets your problem lives in.

The 2025 Web Almanac’s CMS chapter adds one caution for WordPress sites specifically: roughly 60% use a page builder, and builders tend to produce more complex markup and heavier CSS and JavaScript. The chapter’s own conclusion is that WordPress performance variance is driven more by configuration than by core. Which is encouraging, because configuration is something you can change. If your site was built mobile-first in the first place, most of this is already done; our mobile-first design guide covers why that order matters.

Eudora Technology does this work remotely for clients in Europe, the Middle East, Asia, Africa and the Americas: field measurement first, then the specific fixes, then a second measurement a month later so you can see whether it worked. Our web development and hosting page sets out what that involves and what you get to keep.

If your site is slow on phones and you would rather not guess which of the three usual causes it is, we can measure it, fix it and show you the before-and-after. Get in touch with Eudora Technology to talk about your project.