Performance is a design decision
On a lot of projects, performance is a phase near the end. Design and build happen, then someone runs a report, and the last week is spent clawing back the seconds the previous ten weeks spent.
It rarely works, because most of the weight was decided in the design, not the code. A full-bleed hero video. Six web font weights. A carousel of un-cropped photography. By the time engineering sees it, the budget is already gone.
Design the budget first
We set targets before the first layout: a ceiling for the largest content paint, a limit on layout shift, a cap on how much JavaScript runs before the page is usable. Then every design decision is checked against it.
That hero video becomes a poster frame with the video lazy-loaded on interaction. Six font weights become two, or a single variable file. The carousel becomes a grid, because a grid doesn’t need a library.
A gorgeous page that arrives in six seconds is not a gorgeous page. It’s a rumour of one.
What actually moves the needle
In order: images, fonts, third-party scripts, then your own JavaScript. Get the hero image right — correct format, correct size, high fetch priority, no layout shift — and you’ve fixed most of the felt slowness. Self-host and subset the fonts. Question every embed. Only then optimise your own code.
Motion has a budget too
Smooth scrolling, pinned sections and scroll-linked animation are wonderful and they cost frames. We profile them on a mid-range phone with the CPU throttled, not on the machine we built them on. If a section can’t hold sixty frames a second there, it gets simpler.
None of this makes the work less ambitious. It makes the ambition survive contact with a real device on a real network — which is the only place it counts.