What Actually Makes a Website Fast

Performance advice tends to arrive as a list of micro-optimisations. In practice, the largest wins are structural decisions made long before anyone profiles anything.

The order of impact

Working from largest to smallest effect:

1. How much JavaScript you ship. This dominates. Every kilobyte of JS is parse, compile, and execute time on a device slower than yours. Frameworks that ship less, and pages that need less interactivity, win here before any tuning.

2. When it ships. Render on the server, send HTML, and let the page be readable before the JS arrives. A page that renders without JS is fast by construction.

3. What you load eagerly. Images below the fold, fonts you don't use, third-party scripts on every page. Defer, lazy-load, and delete.

4. Then, actual optimisation. Bundling, caching, compression, CDN. Real wins, but they're a fraction of the above.

Most teams start at 4. It's the easiest to measure and the least consequential.

Measure on the right device

The single most common mistake: profiling on a fast laptop over fast wifi and concluding the site is fast.

The people who experience your site as slow are on mid-range Android devices on congested mobile networks. Chrome DevTools throttling — 4x CPU slowdown, Slow 4G — is a rough approximation but far closer to reality than an unthrottled MacBook.

The metrics that matter

• LCP — how long until the main content is visible
• INP — how quickly the page responds to interaction
• CLS — how much the layout moves while loading

CLS is the most commonly neglected and the most irritating. It's almost always caused by images without dimensions or fonts without a fallback metric — both trivial to fix and both cause the page to jump under the reader's cursor.

The uncomfortable conclusion

If a site is slow, the honest diagnosis is usually "we shipped too much JavaScript." That's a structural decision, not a tuning parameter. No amount of compression fixes an architecture that sends a megabyte of script to render text.

Performance is mostly a design constraint you accept at the start, not a cleanup task at the end.