A brand spends months getting the art direction right — the type, the pacing, the restraint, the single confident hero. Then the page takes four seconds to paint on a phone, the hero pops in late, the layout jumps as images load, and every impression of craft evaporates in the wait. The design was premium. The experience was not.
That gap exists because performance is treated as an engineering chore that happens after the creative work, rather than as part of the creative work itself. It is not. How fast a page becomes usable, how stable it feels as it loads, how instantly it responds to a tap — these are aesthetic properties the customer feels directly. Speed is art direction expressed through time.
01 · Perception
Speed is felt before it is measured.
Customers do not read your Lighthouse score, but they feel every part of what it measures. A slow first paint reads as a cheap site before a single word is processed. A layout that lurches as it loads feels unstable and untrustworthy. A tap that lags feels broken. These are emotional reactions, and they attach to the brand instantly.
This is why performance belongs to art direction. A luxury brand that responds sluggishly has undercut its own positioning more thoroughly than any typographic misstep could. The feeling of the site has to match the promise of the brand, and the feeling is built partly out of milliseconds.
A customer cannot tell you your LCP is slow. They will simply feel that the brand is cheaper than it claims.
02 · The budget
Set a performance budget.
A budget turns speed from a vague aspiration into a constraint the whole team designs within — exactly like a colour palette or a grid. It is a set of numbers a page is not allowed to exceed, agreed before the building starts.
- Core Web Vitals thresholds — targets for largest contentful paint, layout shift, and interaction responsiveness that every template must meet.
- A page weight ceiling — a hard cap on total transferred bytes, and a separate cap on JavaScript.
- A request budget — a limit on third-party calls, the usual hiding place for creeping slowdown.
- Device and network assumptions — measured on a mid-range phone and a real mobile connection, not a workstation.
With the numbers agreed up front, "can we add this?" stops being a matter of taste and becomes a matter of budget: what comes out to make room for what goes in.
03 · Diagnosis
Where the weight actually goes.
Ask most teams why a page is slow and they blame images. Images matter, and modern formats with correct sizing solve most of it. But the heavier, sneakier cost is almost always elsewhere: JavaScript. Render-blocking scripts, oversized bundles, and a long tail of third-party tags do more damage than any hero photograph.
The apps are the usual culprits. Every plugin that injects its own script — reviews, upsells, chat, pop-ups, analytics duplicated three times over — spends from your budget, often long after anyone remembers installing it. Fonts, loaded carelessly, block text from appearing. The path to a fast store is less about heroic optimisation and more about honest subtraction: finding the weight nobody is using and removing it.
04 · Craft
Design choices are performance choices.
Once speed is understood as a material, the creative decisions change. An autoplaying background video, a carousel of high-resolution slides, a parallax effect that runs on scroll — each is an art-direction choice with a performance price, and the price should be part of the decision, not discovered afterward.
None of this means designing timidly. It means choosing where to spend. Reserve the weight for the one moment that carries the brand and keep the rest lean, so the expensive gesture lands on a page that was fast enough to get there. Reserve space for media before it loads so nothing jumps. Load rich interaction when it becomes relevant rather than all at once. The most elegant performance work is invisible — the customer only notices that the whole thing feels considered.
05 · Discipline
Defend the budget over time.
A performance budget is easy to hit at launch and hard to hold. Every new campaign, every added app, every "quick" tag from the marketing team spends against it, and without a gate the budget quietly erodes until the site is slow again and nobody can point to when it happened.
So the budget needs enforcement, not just intention. Measure Core Web Vitals continuously, treat a regression as a bug rather than a nuisance, and put a check between "someone wants to add this" and "it ships." Part of our development practice is exactly this vigilance — periodic scans for the dead app code and abandoned scripts that accumulate on every growing store, so the theme stays as fast as the day it launched. Speed is not won once. It is defended.
Quick check
Is speed part of your design?
- You have a written performance budget, not just a vague goal.
- JavaScript and third-party requests are capped, not just image sizes.
- Rich effects are chosen against their real performance cost.
- Vitals are measured on a real phone and network, continuously.
- A regression is treated as a bug, and app bloat is scanned out regularly.
The feeling is in the milliseconds.
You cannot separate how a store looks from how it performs, because the customer never experiences one without the other. A design is only as premium as the speed that delivers it. Set the budget, spend it deliberately, defend it forever — and let the site feel as considered in motion as it does in a static mockup.