Type is the voice your customer hears first
A typeface sets your tone of voice before the first sentence is read. Choosing it is a strategic act, not a cosmetic one.
Read
“Can you make the site faster?” is the most common thing we get asked after a build that wasn’t ours. The honest answer is usually: the site isn’t slow because of one thing. It’s slow because of fifty decisions, each of which felt perfectly reasonable in isolation.
Speed isn’t a setting. It’s a discipline — a posture you hold from the first wireframe to the last deploy. By the time someone reaches for a caching plugin, the expensive mistakes are already baked in.
Performance is a design decision
The heaviest thing on most websites isn’t the code. It’s the choices: an autoplaying hero video, a slider nobody asked for, four web fonts in nine weights, a stock photo exported at 4,000 pixels to sit in a 600-pixel box. None of that is an engineering problem. It’s a design brief that never had a performance budget.
“
Speed isn’t a setting. It’s a posture you hold from the first wireframe to the last deploy.
We give every project a budget before we design: a ceiling on total page weight, a maximum number of fonts, a hard rule that nothing blocks the first paint. The budget isn’t a punishment. It’s the constraint that makes the design sharper — the same way a tight word count makes the writing better.
The four things that actually cost you
Where the seconds go
- Images shipped far larger than they render — usually 60% of the weight.
- Render-blocking fonts and scripts that freeze the first paint.
- Third-party tags: chat widgets, A/B tools, six analytics scripts.
- Layout shift: content that jumps as it loads, so a fast page still feels broken.
Fix those four and you’ve fixed most sites. None of them require a rewrite. All of them require someone deciding they matter before launch, not after.
Why it’s a money problem, not a vanity one
Every hundred milliseconds of delay measurably costs conversions. Google notices too — speed has been a ranking factor for years, and the Core Web Vitals it grades you on are exactly the things teams cut to hit a deadline. A slow site is a tax you pay on every visitor, forever, compounding quietly in the background.
The 95+ baseline, and how we hold it
We ship on a 95-plus Lighthouse baseline, and we hold it the boring way: a budget agreed up front, images that render at the size they’re shown, fonts subset and self-hosted, scripts loaded only when they earn their place, and an audit on every deploy that fails the build if the number drops. No heroics — just refusing to let it slip in the first place.
Steal our pre-launch checklist
- Is every image sized for its container and lazy-loaded below the fold?
- Are fonts subset, preloaded, and capped at two families?
- Does anything block the first paint that doesn’t absolutely have to?
- Have you set explicit dimensions so nothing shifts as it loads?
- Did you test on a mid-range phone on real 4G — not your office fibre?
Run that list and you’ll catch ninety percent of what makes sites feel slow. The last ten percent is engineering. The first ninety is just caring earlier than is comfortable.
Fast is a feeling
Users don’t read your Lighthouse score. They feel it — in the tap that responds instantly, the page that doesn’t lurch, the sense that the thing is well-made. Speed is the most invisible part of craft and the most felt. Your website probably isn’t slow because of a missing plugin. It’s slow because somewhere upstream, fast stopped being a requirement. Make it one again.