Speed is usually treated as an engineering problem, fixed at the end. The design is approved, the site is built, and then someone runs a performance test and starts removing things.
By then it is late. The heavy hero video is in the brand guidelines. The third font weight is in every heading. The animation library is in every component. Making the site fast now means arguing with decisions made weeks ago by people who are no longer in the room.
We prefer to make speed a design decision, made at the same table as colour and type.
A budget before the first screen
Before design starts, we agree a performance budget with the client. It is short and written in plain terms:
PERFORMANCE BUDGET · first visit, mid-range phone, mobile network
First screen readable text before anything decorative
Interaction taps respond at once; scrolling never freezes
Layout nothing jumps once it has appeared
Images sized for the screen they are shown on
Fonts a small, fixed set; text visible while they load
Heavy media never on the critical path of the first screenThe budget is not a target to report against at the end. It is a constraint the designer works inside, the same way they work inside a grid.
A designer who knows the first screen must render from text and CSS alone designs a different, usually better, first screen.
What we measure
We focus on what a visitor experiences, not on a single score.
First paint of real content. How soon does the visitor see the headline, rather than a spinner or a blank page? This is mostly decided by how much the browser must download before it can draw anything: stylesheets, fonts and scripts in the head of the page.
Interaction. When someone taps the menu or a button, does the page respond immediately? Long JavaScript tasks are the usual reason it doesn't, and they often come from code that was never needed on that page.
Layout stability. Does text jump when a font loads, or the page shift when an image appears? Every jump is a small loss of trust, and occasionally a mis-tap on the wrong button.
Images. Are they in a modern format, at the size they are displayed, and loaded only when they are about to be seen?
We test on a mid-range phone with a throttled connection, because that is where problems show. A site that feels fine on a developer's laptop on office Wi-Fi tells you very little.
And we test more than once. The same checks run before launch and again whenever a significant change lands, on a small set of representative pages. Performance rarely collapses in one release; it erodes one reasonable-looking addition at a time.
The trade-offs we make
A fast site is not a plain site. It is a site where every heavy element has earned its place and been placed carefully.
Fonts. We use few families, and variable fonts where possible, so one file covers every weight. Fonts are self-hosted, and only the headline face is preloaded. Fallback fonts get adjusted metrics, so text occupies the same space before and after the web font arrives and nothing reflows.
Animation. Motion is built with CSS and small, targeted scripts. Larger animation libraries load only on the pages that use them, after the content is visible. Every animation respects the visitor's reduced-motion setting.
Images. Each image gets the formats and sizes it needs and nothing more. Below the first screen, images load lazily. Decorative artwork is often better drawn in code as SVG, which stays sharp at every size and weighs a fraction of a photograph.
Third-party scripts. Chat widgets, embedded maps and tracking scripts are often the heaviest code on a small business site, and the client never chose them for speed. We load them only when they are needed, for example when someone opens the chat or scrolls to the map, and we question every one before it is added.
3D and video. These are the most expensive things on any page, so the first screen never depends on them.
Example: a 3D hero that never slows the headline
Our own website has a 3D figure in the hero: an android that turns his head to follow the cursor. On a large screen the scene uses two model files, his body (4.6 MB) and his head (4.9 MB); a phone uses one combined model of about 8 MB. Loaded naively, that would make the whole first screen wait.
Here is how the page is built instead:
- The headline renders first, from HTML, CSS and a single preloaded font. Nothing in the hero waits for the 3D scene.
- The figure arrives as a still first: a WebP of the same framing, about 22 KB, so every visitor sees him at once.
- The models load with low priority, after the page. Large screens with WebGL request the desktop files. Phones that pass a capability check (WebGL 2, enough memory, no data saver) request the phone model and switch to the live scene at the first touch. Other phones keep the still and a set of small head images, about 136 KB in all, that turn towards the finger.
- Only the pages that show him load him. Every other page fetches nothing, until the visitor points at a link to the home or contact page.
- If WebGL fails, the scene falls back to the still. The visitor sees the figure either way.
large screen + WebGL headline › still › 3D scene (low priority)
capable phone headline › still › phone 3D scene (first touch)
other phones, data saver headline › still › head images
WebGL unavailable headline › stillThe result is a hero that feels rich on a capable device, and a first screen that never waits for it.
Fast for the people who need it most
Performance is an accessibility issue as much as a technical one. The visitors who suffer most from a slow site are the ones on older phones, prepaid data and weak signal.
For a tyre workshop, that can be a customer at the roadside trying to book help. For a driving school, a learner studying on a bus between lessons. These are the people our clients' sites exist for, and the budget is written with them in mind.
Designing for them first doesn't make the site worse for anyone else. A site that is fast on a three-year-old phone feels instant on a new one.
What this means for your project
Write the performance budget before the first screen is designed, and test on the phone your customers actually use. Rich visuals can stay, as long as they load after the content, only on devices that can carry them, and never at the expense of the first screen.
