The usual sequence is: design something beautiful, build it, discover it takes four seconds to load on a real phone, then spend a fortnight removing the beauty. It works, sort of, and everybody ends up slightly disappointed.
Give the page a budget
Before design starts we agree a performance budget: a target for largest contentful paint, a ceiling for JavaScript, a limit on font files and a rule for above-the-fold imagery. It is a constraint in exactly the way a grid or a colour palette is a constraint, and it produces better work for the same reason.
- A hero video costs roughly the entire mobile budget. If it is essential, something else must go.
- Four font weights is usually two more than the design actually needs.
- A carousel of eight full-bleed images is a decision to be slow, made quietly.
- Client-side animation libraries are cheap individually and expensive collectively.
Prototype in the browser, on a real device
A design reviewed as a static image on a fast laptop hides every performance problem it contains. We prototype key moments in the browser and open them on a mid-range Android over throttled network before anything is approved. Decisions made this way rarely need reversing.
The three things that usually matter
After dozens of builds, the same three levers account for most of the gain: shipping less JavaScript, serving correctly sized modern images, and getting text painted without waiting on a font. Everything else is refinement around those.
Beauty that loads in four seconds is not beauty. It is a rumour of beauty.
Measure continuously, not once
A Lighthouse score on launch day is a snapshot of a site nobody has touched yet. Budgets belong in CI, with a build that fails when the bundle crosses the line, plus real-user monitoring so you learn what actual visitors on actual networks experience.
Treated this way, performance stops being a periodic cleanup project and becomes something the design process simply produces.
- Performance
- Core Web Vitals
- Process