Why Do Fast Websites Still Feel Slow?

Why Do Fast Websites Still Feel Slow?

Because loading fast and responding fast are different problems. A page can paint in under a second and still feel sluggish if every tap takes 400 milliseconds to show anything, or if the layout moves under your thumb. Speed is what a score measures. Feel is what a person measures, and they disagree often.

We see this on almost every site we inherit that already scored well. The team did the work, the number went green, and the client still says it feels heavy. They are not wrong and the number is not lying. They are describing something else.

Here is what that something else is, with the thresholds that actually govern it.

What Is Perceived Performance?

It is how fast a system feels rather than how fast it is. The two come apart because people do not experience a page as a timeline of network events. They experience it as a sequence of their own actions and whether each one produced a result quickly enough to feel connected to what they did.

That framing changes what you optimise. Shaving 200 milliseconds off a background request nobody is waiting for buys you nothing. Shaving 200 milliseconds off the gap between a click and a visible change buys you the whole impression.

The useful mental model is a conversation. A page that answers immediately feels attentive even when the full answer takes a while. A page that goes quiet feels broken even when it is working hard.

How Fast Does a Response Need to Be to Feel Instant?

Faster than most teams assume, and the numbers have been stable for a very long time. Jakob Nielsen published three response time limits in 1993, excerpted from his book Usability Engineering, and they are still the clearest guide we have to how this feels from the inside.

The first is 0.1 seconds. At that speed users perceive the system as reacting instantaneously, and Nielsen notes that no special feedback is necessary except to display the result. The second is 1 second, where the user notices the delay but their flow of thought stays uninterrupted, and no special feedback is needed in between.

The third is 10 seconds, which is roughly the limit for keeping attention on the task. Past that, Nielsen says users will want to do other things while waiting, so they should be given feedback about when the system expects to be done. That last clause is why a progress bar with an estimate beats a spinner.

Why Does a Good Score Still Feel Bad?

Because a load score describes one moment and a session is made of hundreds. Loading metrics measure the arrival of the page. Nothing in that number covers what happens when someone opens the menu, filters a table, or types into a search box, which is where most of the session actually happens.

There is also a measurement gap. Lab scores run on a clean machine with no extensions, no background tabs, and a fast connection. Real interactions happen on a laptop with 40 tabs open and a phone that has been awake for three days.

So a site can be genuinely fast to load and genuinely slow to use. The fix is not to distrust the score. It is to stop treating one number as a description of the whole experience.

What Does INP Actually Measure?

Responsiveness across the whole visit. Google's web.dev documentation describes Interaction to Next Paint as assessing overall responsiveness by observing the latency of all click, tap, and keyboard interactions throughout a page's lifecycle. It replaced First Input Delay, which only looked at the first interaction.

The thresholds are specific. At the 75th percentile, 200 milliseconds or less is good, 201 to 500 milliseconds needs improvement, and above 500 milliseconds is poor. Notice how far 200 milliseconds sits from Nielsen's 0.1 second instant threshold. A page can pass INP comfortably and still not feel instantaneous.

The three phases are where the fix lives. Input delay is the time before your handlers start. Processing duration is your handlers running. Presentation delay is the time after they finish until the next frame renders. Teams usually optimise the middle one and find the problem was the first or the last. Our guide to interaction to next paint goes through each.

Why Does Movement Feel Worse Than Waiting?

Because a shift breaks the thing a person had already decided to do. Waiting is annoying but predictable. Reaching for a button that moves is a small failure, and it lands as the site's fault rather than the network's.

That is what Cumulative Layout Shift is for. Web.dev defines it as a measure of the largest burst of layout shift scores for every unexpected layout shift during the page's lifecycle. The thresholds at the 75th percentile are 0.1 or less for good, 0.1 to 0.25 for needs improvement, and above 0.25 for poor.

The word doing the work in that definition is unexpected. Web.dev explains that shifts occurring within 500 milliseconds of a user interaction such as a click or tap get a hadRecentInput flag and can be excluded. A panel that opens because you pressed something is not a defect. A panel that opens because an ad loaded is. Our piece on cumulative layout shift covers the usual culprits.

Do Loading Animations Help or Hurt?

They help when they carry information and hurt when they are decoration. A skeleton that matches the shape of the content that is coming reduces the sense of waiting, because the eye can start parsing the layout before the data arrives. A spinner in the middle of an empty box tells you only that something is happening somewhere.

There is a failure mode worth naming. An animation with a fixed minimum duration makes fast responses slower on purpose, and people notice. If your skeleton always shows for 400 milliseconds, you have set a floor under your own responsiveness for the sake of visual consistency.

Our default is to show nothing for the first 100 milliseconds or so, because most responses arrive inside that window and a flash of loading state is worse than no loading state. Beyond that, show structure rather than motion. We covered the design side in our notes on loading and empty states.

What Else Makes a Site Feel Heavy?

Three things that no score catches. Scroll that does not track your finger, usually because something expensive runs on every scroll event. Navigation that blanks the screen before painting the new page, which reads as a stall even when it is fast. And inputs that lag behind typing, which is the most viscerally annoying of the three.

All three share a cause: the main thread is busy when the user needs it. That is also why they cluster on mid-range Android phones and older laptops, and why they are invisible to a team testing on new hardware.

The other quiet offender is font loading. Text that appears, then reflows into a different face, reads as instability even when the layout score is fine, because the reader has already started the sentence.

How Do You Test for Feel Rather Than Score?

Use the site on a bad device on a bad connection and do a real task. Not a page load. An actual job: find a case study, filter a list, submit a form. Throttle the CPU in DevTools to something like a four times slowdown and repeat it. Most feel problems announce themselves within 30 seconds of that.

Then watch someone else do it without instructions. You know where everything is, so you do not wait in the places a stranger waits. The hesitation you see is the data, and it rarely lands where the metrics pointed.

Finally, collect field data for interactions, not just loads. Real percentiles from real visitors are the only way to know whether your 200 milliseconds is everyone's 200 milliseconds or an average hiding a bad tail.

What Would We Change First?

Make every interaction acknowledge itself within about 100 milliseconds, even if the work takes longer. Disable the button, show the state change, move the focus. An immediate acknowledgement buys you seconds of patience, and it costs almost nothing to implement.

Then remove whatever is blocking the main thread during the first few seconds, because that is when people form their opinion and also when most sites are busiest doing things nobody asked for. Third-party scripts are usually the whole answer and nobody wants to hear it.

If your site scores well and still feels slow, we are happy to take a look with you. Working out which of these is actually causing it is a normal week for us at phoenix.studio, and it is usually two changes rather than twenty.