Making a Slow Website Fast: What Actually Helps

Most advice about page speed ends with a plugin recommendation. Install the plugin, tick the boxes, watch the score go up. Sometimes that works. More often it papers over one specific bottleneck while leaving the thing that is actually costing you visitors untouched.

The useful version of this job is duller. You find out what is slow, for whom, on what connection, and then you fix the three or four items responsible for most of the delay.

Score chasing versus field data

The number PageSpeed Insights gives you at the top of the page is a lab simulation. It runs your page once, on a modelled mid-range Android device, on a throttled connection. It is a diagnostic tool. It is not a measurement of what your visitors experience.

Underneath that score, on sites with enough traffic, sits the section that matters: real user data from the Chrome User Experience Report. That is drawn from actual visits over the preceding 28 days. If the two disagree, believe the field data.

Three metrics carry the weight, and Google assesses them at the 75th percentile of real visits — meaning three quarters of your visits need to clear the bar, not the average visit.

• Largest Contentful Paint — how long until the biggest thing above the fold has rendered. Under 2.5 seconds counts as good.
• Interaction to Next Paint — how long the page takes to visibly respond after someone taps or clicks. Under 200 milliseconds counts as good. This replaced First Input Delay in 2024.
• Cumulative Layout Shift — how much the page jumps around while loading. Under 0.1 counts as good.

The Core Web Vitals report in Search Console groups your URLs by template, which is the fastest way to spot that every blog post is failing while every service page passes.

Images, which are nearly always the culprit

On a typical brochure or ecommerce site, images account for the bulk of the bytes and most of the delay before something appears. Four things fix most of it.

Serve them at the size they are displayed. A 4000-pixel-wide photograph rendered into a 600-pixel column is wasting most of what it downloads. Resize at source, then use srcset and sizes so the browser can pick an appropriate variant per device.

Use a modern format. WebP is broadly supported and typically much smaller than the equivalent JPEG at comparable quality. AVIF is smaller again where support allows.

Set explicit width and height attributes. This is the single cheapest fix for layout shift. The browser reserves the correct box before the file arrives, so nothing below it jumps down the page.

Be careful which images you lazy-load. Lazy loading below-the-fold images is good. Lazy loading the hero image is actively harmful, because it delays the very element that defines your Largest Contentful Paint. Mark the hero with fetchpriority="high" instead and leave it eager.

Fonts, and the pause before your text appears

Custom web fonts create a specific problem: the browser has text ready to paint but no font to paint it with, so it waits.

Set font-display: swap so the browser draws fallback text immediately and swaps the custom face in when it arrives. Self-host the files rather than pulling them from a third-party domain, which removes an extra DNS lookup and connection. Preload only the one or two faces used above the fold. Then delete the weights nobody uses — a family loaded at six weights and two styles is twelve files, and most sites genuinely use three.

Everything that blocks the first paint

CSS in the document head blocks rendering by design. That is usually correct behaviour, but it means a bloated stylesheet delays everything. Scripts are worse: a synchronous script in the head stops the parser dead. Add defer to anything that does not need to run before the page draws.

Third-party tags deserve their own audit. Open your tag manager and list what is actually firing. Most sites accumulate a chat widget, two analytics tools, a heatmap recorder, a review badge, three advertising pixels and a survey tool that was installed for one campaign in 2023. Each one is a connection to another domain and, frequently, a chunk of JavaScript running on the main thread while your visitor is trying to tap a button. That main-thread contention is what wrecks Interaction to Next Paint.

Removing tags nobody reads is free, reversible and usually the largest single win available. It is also the recommendation people resist most, because someone once asked for that tool.

Caching, and what it does not solve

Setting long cache lifetimes on static assets — stylesheets, scripts, images, fonts — with fingerprinted filenames means returning visitors download almost nothing. This is worth doing and takes an afternoon.

What it does not fix is the first visit, which is the one that matters for a stranger arriving from a search result. It also does nothing for a slow server response. If your time to first byte is poor before anything has even been sent, the problem sits below the front end, in your hosting or your database queries, and no amount of front-end tuning will rescue it.

An order of operations

If you have a limited budget and want the most return from it, work through this list in order and re-measure after each step.

1. Pull the field data. Establish which templates are failing and on which metric.
2. Fix the hero image on those templates — correct dimensions, modern format, eager loading, high priority.
3. Add width and height attributes site-wide.
4. Audit and cut third-party tags.
5. Defer non-critical scripts.
6. Sort out fonts.
7. Set cache headers.
8. Only then consider a caching plugin, a content delivery network, or a hosting change.

Most teams do that list backwards, starting with the plugin, and then wonder why the score moved by four points.

The honest limits

Speed work has a ceiling. A page that loads in 1.2 seconds instead of 1.9 is unlikely to change your enquiry volume. A page that loads in 8 seconds instead of 2 absolutely will, because a meaningful share of people leave before it finishes. The gains are front-loaded, and past a certain point you are optimising something your visitors cannot perceive.

Speed is also not a substitute for the page being any good. A fast page that fails to explain what you do, and gives no obvious reason to get in touch, is just a quicker disappointment.

If you want a view on where the time is actually going on your site, that is a website development question, and the measurement side of it sits with web analytics.