Why speed is a feature
Most teams treat performance as a cleanup task. Something to get to once the product works. That's backwards. Speed is the product — it's how the product feels.
A page that paints in 100ms feels like the product just works. A page that takes 3 seconds feels broken, even if it's functionally identical. Your users don't have a "performance tab" in their head. They have "this app is great" vs "this app is frustrating" and speed is most of the delta.
What "fast" actually means
Not just the TTFB. A fast site:
- Renders the first meaningful paint in under ~100ms on a warm cache.
- Has interactions that respond within 100ms.
- Has animations that land at 60fps (or 120fps on high-refresh screens).
- Feels lighter than it has any right to.
The hidden costs
Most of what makes a site slow isn't a single bottleneck — it's accumulated decisions that individually look reasonable:
- A framework that ships 300KB of JS to render a blog post.
- Fonts that block paint for 2 seconds.
- A single SQL query that does N+1 for every card on the page.
- Third-party scripts that add 6 network waterfalls before the app boots.
Any one of these is fixable in an afternoon. Together, they become the culture of the codebase — "oh, we're just slow." Breaking that is the first craft skill.
How to start
Pick one page on your app. Open DevTools. Record a load. Write down the top three things that are slower than they need to be. Fix one. Repeat next week.
That's the whole methodology. Obsession, applied on a cadence.