If your site takes four seconds to become usable on mobile, you are losing visitors before they ever read your copy. This is a teardown of a real website speed optimisation project: how we took a client site from a four-second first impression to under one second, which changes actually moved the needle, and how you can run the same process on your own site. It’s written for founders, product owners and marketing leads who suspect speed is costing them conversions but don’t know where the budget is best spent.
Where the four seconds went
Before touching a line of code, we measured. Guessing at performance problems wastes engineering time on fixes that don’t matter; a waterfall trace and a field-data report (real user measurements, not just a lab score) told us exactly where the four seconds went. In this case: a heavy JavaScript bundle blocking render, render-blocking web fonts loaded from a third-party origin, unoptimised hero images, and a stack of third-party scripts each adding hundreds of milliseconds before the page was interactive. The database and the server response time were not the problem. The front end was.
That diagnosis step matters more than any individual fix. Reducing page load time on a site where the server is slow looks completely different from a site where a bloated client-side bundle is the bottleneck — and if you skip the measurement, it’s easy to spend a sprint compressing images when the real cost is sitting in blocking JavaScript instead.
We also looked beyond Largest Contentful Paint. Interaction to Next Paint and Cumulative Layout Shift matter just as much to a real visitor, even if LCP is the headline number most teams fixate on. A page that paints quickly but then jank-scrolls or shifts under a user’s thumb hasn’t actually solved the problem; it’s just moved the frustration a second later. Mobile was the priority throughout, since that’s where the bulk of the traffic — and the worst devices and networks — actually were.
The changes that mattered most
Once we knew where the time was going, we worked down the list in order of leverage, largest win first.
Ship less JavaScript
Code-splitting and removing unused dependencies cut the main bundle dramatically. Less script to download, parse and execute is the highest-leverage fix on almost every slow site, because JavaScript is the most expensive byte a browser handles — it has to be downloaded, parsed, compiled and then executed on the main thread before the page responds to input. Every non-essential script we could defer, lazy-load or delete came off the site’s critical path.
Fix the fonts
Self-hosting the fonts, subsetting them to the characters actually used, and setting font-display: swap removed a render-blocking round trip to a third-party font origin. That one change alone shaved a meaningful chunk off first paint, because the browser no longer had to open a new connection, resolve DNS and complete a TLS handshake with an external domain before it could show any text at all.
Right-size the images
Modern formats, responsive srcset markup, explicit width and height attributes, and lazy-loading everything below the fold turned the single largest payload on the page into a fraction of its former size. Images are still the most common cause of a slow Largest Contentful Paint, and they’re also the easiest to get wrong: a hero image served at four times the rendered size is a self-inflicted performance problem that costs nothing to fix once you know it’s there.
Tame the third parties
We deferred analytics and chat widgets so they loaded after the page was usable, and dropped a tag manager that was pulling in scripts nobody was actually using anymore. Third-party tags are a slow, silent tax: each one is added for a good reason at the time, but they accumulate, and few teams ever go back and audit which ones are still earning their keep.
Cache aggressively
A proper edge and page cache meant most visitors were served a fully-rendered page in tens of milliseconds rather than waiting on a server render for every request. Combined with sensible cache headers for static assets, this made repeat visits and navigation between pages feel close to instant.
The result
Largest Contentful Paint dropped from just over four seconds to under one on a mid-range phone on a throttled connection — the profile that matters most, since that’s how a large share of real visitors experience the site. Bounce rate fell, pages-per-session rose, and the same traffic started converting noticeably better, without changing a word of the marketing copy. That’s the part worth underlining: nothing about the offer changed. The only variable was how quickly the page became usable, and that alone shifted the numbers.
It’s also a useful reminder that page speed isn’t a purely technical metric. It’s a proxy for how much friction you’re putting between a visitor and the thing they came to do. Every extra second of load time is a chance for someone to give up and go elsewhere.
A repeatable website speed optimisation checklist
You don’t need a full rebuild to see gains like this. A sensible order of operations for most sites is:
- Measure first. Use field data (not just a single lab test) to see what real visitors on real devices actually experience, and identify whether the bottleneck is server response time, JavaScript, images, fonts or third-party scripts. Free tools already give you most of this: a browser’s own network panel for the waterfall, and any Core Web Vitals field-data report for how real visitors experience the page.
- Cut the JavaScript bundle. Code-split, remove unused dependencies, and defer anything that isn’t needed for the first paint.
- Fix font loading. Self-host, subset, and avoid render-blocking requests to external font origins.
- Optimise images properly. Modern formats, correct sizing, and lazy-loading below the fold.
- Audit third-party scripts. Keep what earns its place; defer or remove the rest.
- Cache aggressively. An edge or page cache turns repeat visits, and often first visits too, into near-instant loads.
None of this is exotic. It’s measurement, then a handful of disciplined changes applied in the right order, based on where the evidence says the time is actually going rather than where it’s assumed to be going. Speed is rarely one big fix; it’s a dozen small ones that respect the user’s device and network — and each one compounds with the others rather than replacing them.
If you’re weighing up a broader performance pass, it’s worth reading how we think about improving your Core Web Vitals score more generally, since LCP is only one of the three metrics Google measures. And if the underlying codebase has grown unwieldy alongside the slow load times, a code audit is usually the fastest way to find out what else is quietly costing you performance and maintainability.
When it’s worth bringing in help
Some performance work is a genuine afternoon’s job: compressing images, adding font-display: swap, deferring a script. Other cases need someone who can read a waterfall trace, understand your build pipeline, and make judgement calls about what to cut without breaking functionality. If your team doesn’t have the spare capacity or the specific expertise for that, it’s the kind of focused, bounded engagement a studio can complete quickly — you can see examples of the kind of work involved in our portfolio, and how a project like this is typically scoped on our services page.
If you suspect your own site is leaving conversions on the table because of load time, book a free consultation and we’ll tell you honestly whether it’s worth fixing and roughly what’s involved.
