How we cut a site’s load time to under one second
Speed isn’t a vanity metric — it moves rankings and revenue. Here’s the exact performance work we run on every build, in the order that matters most.
Most slow websites aren't slow for mysterious reasons. They're slow because of a handful of predictable problems stacked on top of each other — and they get fixed in a predictable order. When a client comes to us with a three-second load time, we rarely need exotic tricks. We need discipline.
This is the same checklist we run on every performance engagement, roughly in priority order. Each step is cheap relative to its impact, and most sites feel dramatically faster after the first three.
Measure before you touch anything
You can't improve what you don't measure, and you definitely can't prove improvement without a baseline. We start every engagement with field data, not just lab scores.
- Lab — Lighthouse and WebPageTest for a controlled, repeatable snapshot.
- Field — real-user metrics (CrUX / RUM) for what people actually experience.
- Budget — a hard ceiling per route, so regressions get caught in CI, not in production.
A lab score of 100 means nothing if your real users are on mid-range phones and flaky networks. Optimize for the field.
Kill render-blocking resources
The single biggest win on most sites is getting CSS and JavaScript out of the critical path. The browser can't paint until it has finished parsing render-blocking resources — so the fewer there are, the sooner something appears.
// defer everything that isn't critical
const load = () => import('./analytics.js');
if ('requestIdleCallback' in window)
requestIdleCallback(load);
else setTimeout(load, 2000);Inline the small amount of CSS needed for the first viewport, then load the rest asynchronously. Defer non-critical scripts. The goal is a first paint that doesn't wait on anything it doesn't absolutely need.
Treat images as a budget
Images are usually the heaviest thing on a page, and the easiest to get wrong. Three rules cover ninety percent of cases:
- Serve modern formats — AVIF or WebP — with a fallback.
- Size images to their rendered dimensions; never ship a 3000px hero into a 600px slot.
- Lazy-load anything below the fold, and reserve space to avoid layout shift.
Cache at the edge
Once the page is lean, the next question is how quickly bytes reach the user. A CDN with sensible cache headers turns a 600ms origin trip into a 30ms edge hit. For dynamic content, stale-while-revalidate gives you instant responses while refreshing in the background.
Performance is a feature. We budget for it the same way we budget for any other part of the build.
The result
On the project that prompted this article, the homepage went from a 3.1s to a 0.9s largest contentful paint, and organic conversions rose measurably within the month. None of it was magic — just the checklist above, applied in order.
If your site feels sluggish and you're not sure where to start, get in touch — a short audit usually surfaces the two or three changes that matter most.