Website speed: what Google actually measures and how to fix it

“The site is slow” cannot be fixed because it says nothing. Slowness is three different things, each with its own cause and cure: when content appears, when it responds to touch, and whether it jumps under your finger.

The three metrics

• LCP — when the largest visible element appears (usually an image or heading). Target: under 2.5 seconds.
• INP — how long the site takes to respond when the visitor taps. Target: under 200 milliseconds.
• CLS — how much the layout shifts while loading. Target: under 0.1, and zero is achievable.

Images: the biggest cause and the easiest fix

On most sites that get measured, images alone explain the bulk of the slowness. The cure is three steps, no more:

1. 01Export at the size they are actually displayed. A 4000-pixel-wide image shown at 800 wastes nine tenths of its weight.
2. 02Use a modern format (WebP or AVIF): 30–50% smaller with no visible difference.
3. 03Set width and height in the markup. This alone prevents layout shift, because the browser reserves the space before the image arrives.

Fonts

A custom font loads after painting begins, so text appears late or jumps when it arrives. Use font-display: swap so text shows immediately in a fallback, and pick a fallback with similar metrics so the swap goes unnoticed. Load only the weights you actually use: each weight is another file.

What only the server can fix

If the server itself is slow to send the first byte, every browser-side optimisation is built on a late foundation. Watch time to first byte: if it consistently exceeds half a second, the problem is your hosting or your database queries, not your images.

Finally: do not optimise without measuring. Change one thing, measure again, keep the number. Optimising without measurement is expensive guesswork.