Latency reads as indifference

Performance gets filed under engineering. It's a design problem, and treating it as engineering cleanup is exactly why so many genuinely beautiful sites still manage to feel cheap.

Someone forms an impression before your first paragraph renders. If the page hesitates, that impression is already set, and no amount of typography is walking it back.

Slow reads as careless

Here's the part that gets missed. People rarely think "this site is slow." They think the brand is careless, or the company's tiny, or something's broken and they should try again later. The judgment lands on you. Never on the network.

Latency reads as indifference. Three seconds to become usable says something about how much you care, and it says it to every single person who shows up, before one pixel of your actual work is visible.

The ornament is the payload

When a site drags, what's actually doing it? Almost never the content. It's the ornament.

An uncompressed hero image. Six font weights loaded for a design that uses two. An entire animation library imported to do one fade. Analytics, a chat widget, a heatmap tool, a consent banner, each one added by a reasonable person for a reasonable reason on a different Tuesday.

None of them were design decisions, which is the whole problem. They accumulated. Nobody weighed the cost against what came back, because nobody was watching the total.

Show the layout before the data

Real speed matters. But perception is where design has direct leverage, and it's chronically underused.

Content that renders progressively feels faster than content that appears all at once after a wait. A skeleton matching the final layout feels faster than a spinner, because nothing jumps when the data lands. An interaction that responds instantly and reconciles afterward feels faster than one politely waiting for a server to confirm what it already knew.

Layout shift is the worst offender by some distance. A page that finishes loading by rearranging itself feels broken even when it was quick, because now you have to go find the sentence you were halfway through.

Budgets, not vibes

"Keep it fast" isn't a constraint anyone can act on. A number is.

Pick a page weight and a time-to-interactive you won't cross, then treat them like any other design constraint. Anything new that wants on the page fits the budget or displaces something that's already there. The discipline isn't in the optimisation, it's in the refusal.

Most sites don't need to get faster. They need to stop getting slower, one entirely reasonable addition at a time. Different problem, different fix.

Test on the phone in their pocket

Test on a mid-range phone on a normal connection, not on the machine you built the thing on. Your laptop on office wifi is the least representative device your site will ever run on, and it's the one you stare at all day.

The gap between how a site feels to the person who made it and how it feels to everyone else is where most performance problems are hiding.