Skip to content
NAFRUSoftware x Development
← Blog home

3 min read

The three measurements that make a site feel slow

Slow is three separate complaints: late to appear, unresponsive to touch, and jumping around while it settles. Each has its own measure and its own cause.

Furkan ÇolakDeveloper

The white dial of a 1970s mechanical stopwatch, its sweep hand and small subdial visible.
"Ca 1970 mechanical stopwatch by Herwins Switzerland" by R. Henrik Nilsson, CC BY 4.0, via Wikimedia Commons. Cropped to 3:2.

“The site is slow” does not describe one thing. Sometimes the page takes a long time to appear, sometimes it appears but does not respond to a tap, sometimes the content jumps around as it settles. Three different problems, and three separate measurements.

Three measures, three complaints

The three measurements Google groups as Core Web Vitals map onto those three complaints.

LCP measures when the largest piece of content on the page appears. The threshold for good is 2.5 seconds. That element is usually a cover image or a heading block, which is the moment a visitor calls the page open.

INP measures how long after an interaction the screen updates. The good threshold is 200 milliseconds. Tapping a menu and the menu opening falls under this one.

CLS measures how much content shifts while the page settles. The good threshold is 0.1. The paragraph you started reading sliding down when an ad loads is what this number counts.

Google runs this assessment on the 75th percentile of page loads, segmented across mobile and desktop. So it is not an average: it measures the worst experience that three quarters of visitors stay within.

What the average hides

That percentile matters, because averages hide slowness reliably.

If half your visitors arrive on a fast connection and a quarter on a weak mobile network, the average can look fine. The 75th percentile shows the boundary of that weak quarter, and that is where the complaints come from.

The practical consequence: a test run on your own machine over the office connection is not a measurement. Measurement comes from field data collected from real visitors.

The usual cause behind each

Each of the three has a familiar cause, and they are much the same on most sites.

LCP is usually broken by the cover image: uncompressed, larger than the screen needs, left to lazy loading. Nothing in the first viewport should be lazily loaded; a delay there lands straight on the number.

INP is usually broken by a busy main thread. Analytics, chat and marketing scripts running while the page opens queue up ahead of the user’s tap. Cutting the number of scripts changes the experience as much as the number.

CLS is usually broken by content whose size was never declared. Images without width and height, fonts loading later, notification bars inserted after the fact. All three stop shifting once space is reserved for them in advance.

Which order to work in

Trying to fix all three at once tends to scatter the effort. The order usually goes like this.

CLS first, because it is the cheapest and the most visible. Giving images dimensions and fixing font loading is a few hours’ work on most sites.

LCP next, because it generates the most complaints. Producing the cover image at the right size and prioritising its load can put the number under the threshold on its own.

INP last, because it is the hardest. The work there is usually not a code change but a decision: which third-party script gets to stay on the site.

Not mistaking the measure for the goal

One warning at the end. These three numbers are indicators of the experience, not the experience.

A site can clear all three thresholds and still be hard to use. The text is unreadable, the buttons are hard to find, the form does not say what went wrong. The measurements see none of that.

So the three numbers shorten the list of things to fix. They do not complete it.

Recommended articles

( 00-09 ) CONTACT

Let's talk about what you are building and how NAFRU can help.

Let's start the conversation.