What is perceived performance?

How fast an application feels, which depends on responsiveness and sequencing rather than total load time. An interface that responds instantly and fills in detail progressively feels faster than one that finishes sooner but shows nothing until it does.

How fast does an interface need to respond to feel instant?

Visible feedback within about 100 milliseconds of a tap or click reads as immediate. Beyond roughly a second, attention drifts; beyond ten, users assume something has broken and start retrying.

Are Core Web Vitals relevant to applications, not just websites?

Yes for any surface a search engine reaches, and the underlying qualities — responsiveness, stability, time to meaningful content — matter behind sign-in too, where they simply stop being measured for you.

What usually makes an application slow?

In practice: unnecessary JavaScript, unindexed or repeated database queries, unpaginated lists, oversized images and chatty sequential API calls. Rendering is rarely the first culprit, though it is often the first thing optimised.

Are loading spinners bad?

A spinner says something is happening but not what or for how long. Skeletons that match the real layout are better because they also reserve the space, which prevents the content jump that makes an interface feel unstable.

Application performance

App performance: what makes an application feel fast?

Perceived speed is not the same as measured speed. An application feels fast when every action is acknowledged immediately, the layout never moves under the user, and slow work happens where nobody is waiting on it.

John M GranskouAugust 22, 202611 min read

Two applications can post identical numbers on a synthetic test and feel completely different in use. The one that acknowledges every action immediately, holds its layout still and fills in detail progressively will be described as fast. The other will be described as sluggish, and no amount of arguing with the benchmark will change that.

The sequence users actually experience

Tap → feedback → content → detail

Nothing in this path should ever look stalled — that, more than total duration, is what registers as slow.

Where speed is actually decided

Optimisation effort is often spent on the layer that is easiest to see rather than the one causing the delay. The stack below is roughly in order of how often it is the real problem in business applications.

Where application speed is decided

Payload and data access account for most real-world application slowness.

Symptom	Frequent cause	Fix
Slow first load	Large JavaScript bundle, unoptimised images	Code splitting, server rendering, modern image formats and correct sizing
Slow list or table	Unpaginated query, missing index, N+1 access	Pagination, indexes, batched queries, virtualised rendering
Interface stutters on interaction	Excess work on the main thread, oversized re-renders	Narrow the update, defer non-critical work
Feels slow despite good metrics	No feedback on action, layout shifting as data lands	Optimistic updates, reserved space, matched skeletons
Fast in the office, slow for users	Measured on one fast device and network	Field measurement across real devices and connections

Common causes and the fix that usually applies

Buy perception where the work is genuinely slow

Some operations cannot be made quick — a payment authorising, a report compiling, a third-party call completing. Those are the moments to spend design effort: acknowledge the action, show honest progress, let the user continue elsewhere, and confirm when it finishes rather than holding them still.

This is also where installable delivery earns its keep: cached shells and offline tolerance remove whole categories of waiting, as described in how installable progressive web apps work.

Keep it fast after launch

Performance regresses quietly — one library, one unoptimised image, one query that grew with the data. Continuous field measurement, and a budget that fails a release when it is exceeded, is the only thing that holds the line. That belongs in the ongoing work described in maintaining an app after launch, and in how we build under application and PWA development.

Users do not experience averages. They experience the slowest thing they did today.

Frequently asked questions

What is perceived performance?: How fast an application feels, which depends on responsiveness and sequencing rather than total load time. An interface that responds instantly and fills in detail progressively feels faster than one that finishes sooner but shows nothing until it does.
How fast does an interface need to respond to feel instant?: Visible feedback within about 100 milliseconds of a tap or click reads as immediate. Beyond roughly a second, attention drifts; beyond ten, users assume something has broken and start retrying.
Are Core Web Vitals relevant to applications, not just websites?: Yes for any surface a search engine reaches, and the underlying qualities — responsiveness, stability, time to meaningful content — matter behind sign-in too, where they simply stop being measured for you.
What usually makes an application slow?: In practice: unnecessary JavaScript, unindexed or repeated database queries, unpaginated lists, oversized images and chatty sequential API calls. Rendering is rarely the first culprit, though it is often the first thing optimised.
Are loading spinners bad?: A spinner says something is happening but not what or for how long. Skeletons that match the real layout are better because they also reserve the space, which prevents the content jump that makes an interface feel unstable.