Why your site feels slow even though the score is green

Short answer: a green score usually measures how fast the page appeared. What people feel is the moment they tap something and nothing happens — and that is a different number, on a different part of the timeline.

Two different clocks

Loading has an end. Interactivity does not: it is a property the page has, or briefly does not have, every time the main thread is busy.

A marketing page that paints in 0.9 seconds and then spends 1.4 seconds hydrating a component tree scores well and feels broken, because the 1.4 seconds land exactly when a visitor has read the headline and reached for the button.

The test that matches what people feel

Forget the lab for a moment and do this on a real phone, on real mobile data:

1. Open the page.
2. The instant the headline is readable, tap the main button.
3. Count how long until something changes.

If that gap is noticeable, no score is going to argue you out of it.

Where the time actually goes

On most content sites, in this order:

• A framework runtime, loaded to render text that never changes.
• Hydration, which walks the whole tree to attach behaviour to markup the server already produced.
• Third-party tags — analytics, chat widgets, consent banners — which arrive last and run first.
• Fonts that block text, or swap it and move the layout under a reader's eye.

None of those are wrong in themselves. They are wrong for a page that is a layout, some text, a few images and a call to action.

What actually fixes it

• Ship less JavaScript. Not "smaller" — less. A page with none cannot have a slow one.
• Let the HTML be the page. If the words exist in the document, the browser can paint them without executing anything, and an answer engine can read them too.
• Defer what is not needed to read. Chat widgets and analytics can wait for interaction.
• Self-host fonts and set font-display: swap with a fallback whose metrics are close, so the swap does not shove the page around.
• Give images width and height. Layout shift is felt as slowness even when nothing is slow.

The number worth quoting

A typical page DragGo publishes is around 56 KB with an LCP near 0.8 seconds, and ships zero JavaScript unless the page needs some. That is not a boast about a framework; it is what happens when the output is HTML and CSS and the runtime is the browser.

The point is not the number. The point is that the page responds the moment it looks ready — which is the only definition of fast a visitor has ever used.