Google publishes three numbers that describe how a page feels to use, and between them they cover almost everything a visitor notices. A page is in good shape when the main content appears within 2.5 seconds, taps and clicks respond within 200 milliseconds, and nothing jumps around while it loads.
They are worth knowing by name because they turn "the site feels slow" into something you can measure and fix.
LCP: when does the page look ready
Largest Contentful Paint measures how long it takes for the biggest thing above the fold, usually a heading image or a hero block, to finish rendering. It is the closest single number to "the page has arrived."
Good is 2.5 seconds or less. Between 2.5 and 4 seconds needs work. Beyond 4 seconds, visitors are leaving before they see anything.
Three things usually cause a bad LCP. The server takes too long to send the first byte. Scripts and stylesheets in the head block rendering until they have downloaded. Or the hero image is enormous and served in a format from a decade ago.
INP: does the page answer when you touch it
Interaction to Next Paint measures the delay between a visitor interacting with the page and the page visibly responding. It replaced First Input Delay in 2024 because it looks at interactions throughout the visit rather than only the first one.
Good is 200 milliseconds or less. This is the number that captures the specific frustration of tapping a menu and watching nothing happen for half a second, which reads as broken rather than slow.
A bad INP is nearly always JavaScript. The browser runs your scripts on the same thread it uses to respond to input, so while a heavy script is running, the page cannot answer anybody. Fixing it means doing less work on that thread, or doing it later.
CLS: does the page stay still
Cumulative Layout Shift measures how much content moves around after it first appears. Everyone has met this one: you go to tap a link, an image finishes loading above it, the page shoves everything down, and you tap an advertisement instead.
Good is 0.1 or less. The usual causes are images and embeds without width and height set, fonts that swap and change the height of a paragraph, and banners injected at the top of the page after everything else has drawn.
Most of it is preventable by reserving space. Set dimensions on media, give injected elements a fixed slot, and the browser stops having to rearrange the page around late arrivals.
Lab numbers and real numbers are different things
Run a page through a performance tool and you get a lab score: one load, one simulated device, one network profile. It is a useful diagnostic and it is not what your visitors experienced.
Field data is what actual people on actual devices measured, which is what search engines use when these numbers affect anything. The two disagree regularly, usually because your visitors are on slower connections and older phones than the machine you tested from.
Use lab tools to find causes, since they will point at the specific script or image responsible. Use field data to decide whether you have a problem at all. Chasing a lab score on a page that is already fine for real users is a way to spend a week and change nothing.
The one that markup cannot fix
There is a fourth number underneath LCP: Time to First Byte, the time from requesting the page to the first byte of the response arriving. It is not one of the three, but it sets the floor for all of them.
It matters to know which side of the line it sits on. Render-blocking scripts, oversized images and layout shift live in your markup and you can fix them this afternoon. TTFB is mostly your hosting: how quickly the origin server responds, how far it is from your visitor, whether a cache or CDN is in front of it. No amount of tidying the HTML moves it.
We hit exactly this on these pages. The markup-side work was worth doing and made a visible difference, and the remaining time was the origin's response time, which is a hosting decision rather than a code one. Being honest about that distinction saves you from optimising the wrong layer for a week.
What actually moved the needle here
The single highest-value change on most sites, including this one, is not loading scripts in a way that blocks rendering.
By default a script tag in the head stops the browser from building the page until that file has downloaded and run. Every one of them adds its download time to how long the visitor stares at nothing. Adding defer tells the browser to keep going and run the script once the page structure is ready, which for anything that only needs to work after the page exists is almost always correct.
On these pages that meant deferring the jQuery and framework bundles that the exported template had loading in the head. Same functionality, same scripts, and the browser is no longer waiting on them before drawing anything. You can confirm it in the source of this page.
The second thing worth doing is auditing what you load at all. Exported and templated sites routinely ship libraries for features the page does not use, and a script you delete is faster than any script you optimise.
A sensible order to work in
Fix the foundations before chasing a score, which is the same order we work in for technical SEO, and for the same reason: the later work does not hold if the base is wrong.
- Check field data first, to find out whether you have a real problem and on which pages.
- Deal with render-blocking scripts and stylesheets in the head.
- Size and compress the hero image, and serve it in a modern format.
- Set explicit dimensions on every image and embed.
- Remove scripts nothing on the page uses.
- Only then look at whether hosting is your ceiling.
Working in that order means the cheap fixes happen first, and you find out whether you need to spend money on infrastructure after you have already made the page faster for free.
None of this is exotic, and all of it compounds with everything else on the page. A fast site gives your content a chance to work, which is the entire point of building the site properly in the first place. If you want us to look at where your pages are actually losing time, send us the URL.
