Why speed is a design decision, not a developer task

When a website feels slow, the usual reaction is to hand it to a developer and ask them to “optimise it”. Sometimes that helps. More often, the developer finds that the real problem was decided weeks earlier, in a design file, by someone who never thought of themselves as making a performance decision.

A full-screen autoplay video in the hero. Four web fonts in six weights. A carousel of uncompressed photography. A layout that only works once three tracking scripts have loaded. None of these are code problems. They are design choices with a cost, and the cost is paid by every visitor on every visit.

Speed is part of the experience

People do not experience “performance” as a number. They experience a page that appears quickly or a page that makes them wait, a button that responds or a button that jumps away as an image loads above it. Google measures the same things through Core Web Vitals:

• Largest Contentful Paint: how quickly the main content appears. Aim for under 2.5 seconds.
• Interaction to Next Paint: how quickly the page responds when someone taps or clicks. Aim for under 200 milliseconds.
• Cumulative Layout Shift: how much the page jumps around while it loads. Aim for under 0.1.

Every one of those is shaped by design: what sits in the first screen, how heavy it is, and whether space is reserved for things before they arrive.

Give every page a budget

Before we design a page we agree on a budget, the same way you would for money. A typical marketing page might allow around 1 MB in total, no more than two font families, and nothing above the fold that depends on a third-party script.

A budget turns vague advice (“keep it light”) into a design constraint the whole team can see. When someone wants a background video, the conversation becomes “what do we remove to make room for it?” rather than “we’ll optimise it later”.

Design the first screen first

The first screen carries most of the weight. We design it with a few rules:

1. The headline is real text, not part of an image, so it can appear immediately.
2. The hero image is sized for the screen it is shown on, served in a modern format such as WebP or AVIF, and preloaded.
3. Anything decorative can arrive a moment later without moving the content around it.

If the first screen is fast, the whole site feels fast. If it is slow, nothing further down the page will rescue the impression.

Images and fonts, the usual suspects

Images are almost always the heaviest part of a page. We export them at the size they are displayed, use responsive srcset so phones never download desktop images, and lazy-load everything below the first screen.

Fonts are the second culprit. Each weight is a separate download, so we choose a small type palette on purpose, subset fonts where we can and use font-display: swap so text is never invisible while a font loads.

Motion without the weight

We love motion; this website is full of it. But animation should be built from transforms and opacity, which the browser can run smoothly, rather than from properties that force the whole page to be recalculated. Long image sequences are preloaded progressively and only while they are on screen. And everything respects the “reduce motion” setting people choose on their devices.

Measure, then measure again

Lab tools such as Lighthouse are useful while building, but the numbers that count come from real visitors on real phones. After launch we watch field data in Search Console and fix what real people experience, not what a test machine reports.

Fast websites are not the result of a heroic optimisation sprint at the end of a project. They are the result of dozens of small decisions made well from the very first sketch, and that is exactly where we start.