There's a common pattern on product teams: designers work on what things look like, engineers work on how fast they run, and never the two shall meet except in a PR review where someone adds "might be worth checking performance" as a comment that nobody acts on.
This is a mistake. Not an organisational mistake — a design mistake. Performance is part of the user experience. A slow interface communicates something to users at a level they feel before they can articulate. It says: we didn't finish this. We didn't care enough. This isn't ready.
What Performance Communicates
Speed shapes perception before rational evaluation kicks in. When a page loads in under a second, users trust it more — not because they've assessed the content yet, but because the speed signals that someone cared. When a page takes four seconds to load, you've started the relationship with a negative impression you'll spend the rest of the session trying to overcome.
Performance isn't a feature. It's the baseline condition under which all your other design work either lands or doesn't.
This matters most at the top of the funnel. A landing page with a 90+ PageSpeed score converts better than the same page at 50 — even when nothing visual has changed. The user never consciously thinks "this page loaded quickly, I'll trust this company more." They just feel less friction, and friction is the enemy of conversion.
Where Design Decisions Become Performance Decisions
Performance isn't exclusively an engineering problem because most performance issues originate in design decisions:
- Full-width hero videos — a visual direction that typically costs 3–6 seconds on mobile.
- Unoptimised image choices — showing a beautiful 4MB photograph when a well-compressed 80KB WebP would look identical at the rendered size.
- Animation-heavy landing pages — loading a 200KB JS animation library to make a headline scroll in.
- Webfont stacks with 8 weights — because the brand guidelines say to use all of them, even though only 2 appear on the page.
- Third-party embeds — adding a chatbot, a cookie banner, a retargeting pixel, and a heatmap tool without auditing the combined weight.
None of these decisions are made by engineers. They're made by designers and marketers, often without knowing the performance cost. Knowing the cost doesn't mean you never make the choice — it means you make it consciously.
How We Design for Speed at RYC
We treat a 90+ PageSpeed score as a non-negotiable output alongside visual quality. This means the performance conversation happens in design, not after build:
- Every hero image is budgeted — max file size before design is approved.
- Font loading strategy is specified in the design handoff, not left to the developer.
- Animations are prototyped against performance cost before they're committed to.
- Third-party scripts get an audit before the project ships, not as an afterthought.
The result is websites that score well on Core Web Vitals without sacrificing visual quality. The two aren't in conflict — the perception that they are comes from separating design decisions from their performance consequences.
Fast is beautiful. Not in spite of the constraints — because of them.