A perfect performance score and a site that feels slow are entirely compatible. Here is the gap between them.

Performance scores measure a synthetic load on a simulated device. A customer measures the wait between deciding to read something and being able to.

The number that matters

Time to readable content, on the median device your analytics actually reports — not the flagship phone in the room where the decision is being made. A site tested on a developer's current-generation phone over office wifi can score well and still be genuinely slow for the customer on a three-year-old handset over patchy mobile data, and that customer is not a hypothetical edge case — for many businesses, they are the median visitor, not the exception.

Why scores and experience diverge

A performance testing tool runs a fixed script under fixed conditions and produces a number that is genuinely useful for catching regressions — a score that drops ten points after a deploy tells you something real changed. What it does not tell you is how the page feels to a specific visitor on a specific network, because real visitors do not experience an average of every condition the tool tested. They experience one specific load, on one specific device, once — and a site tuned to look good in the tool's summary without being tested against realistic device and network conditions can easily satisfy the metric while failing the visitor it was supposedly optimised for.

Where the time usually goes

• Fonts that block text for hundreds of milliseconds — a visitor staring at a blank screen while a font file downloads, when the browser had a perfectly readable system font available the entire time.
• Hero images sized for a desktop retina display, served to a phone, at four or five times the resolution a phone screen can even display.
• Third-party tags, loaded synchronously, that nobody remembers adding — an analytics snippet here, a chat widget there, each contributing a blocking request that individually seems negligible and collectively adds up to a meaningful delay before anything on the page is usable.
• Client-side rendering of content that never changes, which means a visitor downloads an empty page, then downloads the code to build the page, then waits for that code to run, for content that could have been sent as finished HTML in the first response.

The gap between "loaded" and "usable"

A page can finish loading, in the sense a performance tool measures, and still not be usable — buttons present but not yet responsive because the JavaScript that wires them up has not finished running, a layout that visually settles into place a full second after the text appeared and shifted whatever the visitor was about to tap. These moments do not always show up clearly in a single summary score, because the score is measuring a specific definition of "done" that does not always match a visitor's own sense of when a page became usable. Reading the full breakdown, not just the headline number, is where these gaps actually surface.

What we do about it

Server-render anything static, ship the smallest font subset that covers the copy, and put a budget on third-party scripts that someone has to argue against to exceed. Every new script gets weighed against what it costs in load time, not approved by default because the request came from a reasonable team with a reasonable reason — reasonable requests are exactly how a fast site accumulates its way to a slow one, one small addition at a time.

Where perceived speed and measured speed disagree

Two pages can load in identical measured time and feel completely different to a visitor, because perception is shaped by what happens first, not just by how long the whole process takes. A page that shows real text immediately and then loads images progressively feels fast, even if the final byte arrives no sooner than a page that shows nothing until everything is ready. Sequencing what appears first — text before decoration, the content a visitor came for before anything ornamental — is often a bigger lever on perceived speed than shaving raw milliseconds off the total, and it is a lever most performance checklists do not explicitly account for because it is a sequencing decision, not a technical one.

Testing against reality, not convenience

We test primary flows on a throttled connection and a mid-range device profile, not because it is pleasant to work with but because it is closer to what a meaningful share of real visitors actually experience. A page that feels instant on a fast connection and takes several seconds to become usable on a throttled one is a page that has only been tested in the condition that flatters it. The uncomfortable test is the useful one, and skipping it is how a site ships fast for the people building it and slow for the people it was built for.

Speed is a business number before it is a technical one

A slower page is not just a worse experience in the abstract — it is measurably fewer people staying long enough to be convinced. The relationship between load time and drop-off is not linear and not subtle: past a fairly short threshold, each additional second of wait costs a real, visible share of visitors who simply leave before the content they came for appears. This is why performance work is worth treating as a commercial priority rather than a technical nice-to-have discussed only when something breaks — a site that takes two extra seconds to become usable is quietly taxing every single piece of marketing spend driving traffic to it, whether anyone is tracking that tax or not.

The parts that are easy to fix, and the ones that are not

Fonts and images are usually the fastest wins, because they are entirely within your control and rarely require restructuring anything — subsetting a font, compressing and correctly sizing images, and serving modern formats can meaningfully improve load time in an afternoon. Third-party scripts are harder, because removing one usually means a conversation with whichever team requested it, and client-side rendering of core content is harder still, because it can mean restructuring how a page is built rather than adjusting an asset. Knowing which category a fix falls into helps prioritise realistically — start with the afternoon fixes, and schedule the structural ones deliberately rather than treating a performance audit as one undifferentiated list.

What good actually feels like

A fast site does not feel fast because a number said so. It feels fast because text is there to read almost immediately, images do not visibly pop in after the layout has already settled, and tapping something responds without a noticeable delay. None of that requires an exceptional performance score — it requires the handful of specific things above being done correctly, consistently, on the devices and networks your actual visitors use. A site chasing a perfect score while ignoring the median visitor's real conditions is optimising for the wrong audience.

In short

A performance score is a proxy, not the goal. The goal is the wait a real visitor, on a real device, on a real connection, experiences between wanting something and getting it — measure that directly, on the conditions your actual traffic reports, and treat the synthetic score as a regression alarm, not the finish line.