Every team I've worked with eventually has the same meeting: someone says the product feels slow, and the room nods, and then nobody can agree on what to fix first. That's because "slow" is rarely one problem. It's a label covering load time, response time, perceived time, and rendering time — four different systems with four different fixes.
Load time isn't response time
Load time is what happens before a person can do anything at all. Response time is what happens after they've already started — every click, every keystroke, every scroll. A page that loads in under a second can still feel sluggish if every interaction after that has a 400ms lag. Teams that only measure the first number miss the second entirely.
The fastest-feeling products aren't always the fastest products. They're the ones that tell you something is happening the instant you ask.
Perceived time is a design problem
A progress indicator that appears within 100 milliseconds changes how long a wait feels, even when the actual duration doesn't change at all. This is the cheapest lever available, and it's usually the last one teams pull, because it doesn't show up on a performance budget — it shows up in a design review.
Where to actually start
Before optimizing anything, name which kind of slow you're solving. If people are bouncing before the page is usable, that's load time. If they're waiting mid-task, that's response time. If the numbers look fine but it still feels slow, that's perception — and the fix lives in the interface, not the network tab.