What actually makes a site fast
Most performance work goes into the wrong layer. The wins are usually in what you send, not how you send it.
Performance conversations tend to start at the end — caching, compression, a faster host — when the largest wins are almost always further up, in decisions about what the page contains at all.
The order that matters
Send less. Every kilobyte you do not ship is one you never have to optimise.
Send it sooner. Server-rendered HTML beats an empty page waiting on JavaScript.
Send it once. Cache aggressively and invalidate deliberately.
Then tune. Compression, formats, hosting.
The usual culprits
A hero image exported at full resolution. Three font families with six weights between them. An analytics stack loading before the content. A component library imported whole to use one button.
None of these are exotic problems, and none are fixed by a faster server.
Images are still the biggest lever
Serve modern formats, size them for the space they occupy, and always set explicit dimensions so the browser can reserve the space before the file arrives. An unsized image is a layout shift, and layout shift is the one metric users feel as sloppiness rather than slowness.
Measure what a person experiences
A lab score on a fast laptop tells you very little. Field data from real visitors on real phones and real networks is the number worth moving.