A faster page in an afternoon
Before rewriting anything, try these fixes. How we take a slow marketing or product page and make it noticeably faster in a few hours.
When a client tells us their site is slow, the first instinct in the room is often a big one. Move to a new framework. Add a caching layer. Rebuild the front end.
Usually none of that is needed, at least not yet. Most slow pages are slow for a handful of ordinary reasons, and a focused afternoon fixes the worst of them.
Measure before you touch anything
We start by loading the page on a mid-range phone over a throttled connection, the way plenty of real visitors see it. Then we write down three numbers:
- How long until the main content appears.
- How long until the page responds to a tap.
- How much the layout jumps around while it loads.
Those numbers are the before picture. Without them, it’s hard to tell a real improvement from a feeling.
Images first
On most pages we look at, images are the biggest problem by a wide margin. A single hero photo exported straight from a camera can outweigh the rest of the page put together.
The fixes are dull and effective:
- Serve modern formats like AVIF or WebP, with a fallback.
- Provide a few sizes and let the browser pick the right one.
- Set width and height so the layout doesn’t jump.
- Lazy-load anything below the first screen, and never the hero.
On a recent landing page this alone took the page from 4.1 MB to under 600 KB.
Fewer scripts
Next we count the third-party scripts. Chat widgets, two analytics tools, a heatmap from a trial that ended last year, a font loader, a cookie banner loading its own copy of a library the site already has.
Each one was added for a reason. Few of them still earn their place. We list them with the client, remove what nobody uses, and defer the rest until after the page has loaded.
Fonts that don’t block
Custom fonts are part of a brand, and we keep them. But they shouldn’t hold the page hostage. We self-host them, subset them to the characters actually used, preload the one or two weights the first screen needs, and let text show in a fallback while they load.
Let the server help
Finally, a few server settings that are often missing:
- Compression switched on for text files.
- Long cache headers on files with a hash in the name.
- A CDN in front of static assets, if the audience is spread out.
None of these takes long. Together they make repeat visits feel close to instant.
Then measure again
At the end of the afternoon we run the same test on the same phone and write down the same three numbers. Usually the main content shows up in half the time or better.
Speed is a design decision as much as a technical one. Every image and script on a page is a choice.
Some pages do need deeper work after that. But now the decision gets made with real numbers, and the quick wins are already live.
