Web Performance Is a Feature

Performance is often treated as a nice-to-have, something to fix "later". After a series of experiments on the Wavelength music web app, I've seen first-hand how much speed directly impacts user behavior.

When we first launched, our homepage took over four seconds to become interactive on mid-range mobile devices. Our engagement metrics were underwhelming, so I proposed treating performance as a product feature with its own goals and dashboards.

We started by collecting real-user metrics (Core Web Vitals) instead of relying only on lab tests on fast laptops. Then we tackled the biggest wins: code-splitting large routes, server-side rendering critical pages, lazy-loading images, and caching API responses at the edge.

The results were striking: cutting Largest Contentful Paint from 4.1 s to 1.6 s increased session starts by 34%. Even more interesting, users on slower networks saw the biggest gains, showing that performance work is also accessibility work.

I've since adopted a simple framework for performance:

1. Measure real users, not just your own machine
2. Set performance budgets and enforce them in CI
3. Fix the biggest bottleneck first, then measure again
4. Make performance visible to the whole team with dashboards
5. Treat regressions like bugs, not nice-to-haves

The most valuable lesson I've learned is that fast software feels better, and users notice even when they can't explain why.