Users do not experience your page as a single load time; they experience a sequence — blank screen, first content, something they can read, something they can click. "Slow" is really a story about how long each of those steps takes, and which one your particular page gets wrong. Optimising the wrong step is wasted effort, so the first job is knowing which step hurts.
The good news is that the industry has converged on a small set of metrics that map well onto how a page actually feels, and browsers hand them to you for free. Learn those and you can stop guessing.
The three vitals worth your attention
Largest Contentful Paint measures how long until the main content — usually the biggest image or heading — appears. It is the closest single number to "when does this page feel loaded". A slow LCP almost always traces back to a heavy image, a slow server response, or render-blocking resources at the top of the page.
Interaction to Next Paint captures responsiveness: when the user taps or types, how long until the page visibly reacts. And Cumulative Layout Shift measures visual stability — how much the page jumps around as it loads, the infuriating effect where you go to tap a button and an ad pushes it away. Together these three describe loading, responsiveness and stability.
The usual culprits
Images are the number one weight on most pages: unsized, uncompressed, and far larger than the space they display in. Serving appropriately sized, modern-format images and giving them explicit dimensions fixes both slow LCP and layout shift at once. It is the highest-return change on the majority of sites.
JavaScript is the second: large bundles that must download, parse and execute before the page becomes interactive block the main thread and wreck responsiveness. Shipping less script, splitting it so only what a page needs loads, and deferring non-essential work are the levers. A third culprit — a slow server or database query — sits underneath everything, because nothing renders until the first bytes arrive.
Measure real users, not just your laptop
Your development machine on fast office internet is the best case, not the typical case. Lab tools that simulate a mid-range phone on a slower connection give a truer picture, and field data collected from actual visitors tells you what your real audience experiences across their real devices.
The workflow that works: measure to find the worst step, fix the biggest single cause of it, measure again. Chasing a perfect score on a synthetic test matters far less than moving the metric your real users feel. Performance is iterative, and a few targeted fixes usually recover most of the lost time.