Speed and mobile:what to measure and where it stops paying off

The three values in plain language

LCP, largest contentful paint. How long it takes before the largest block of text or the largest image is on screen. That is the moment a visitor thinks: the page is here. Not the moment everything is finished. The usual culprits are an enormous header image that has not been resized, a slow server and a cookie banner that holds everything up behind it.

CLS, cumulative layout shift. How much the page jumps around under your finger while it loads. You want to click a link and at the last moment an advert or a banner slides in between, so that you hit something else. That is CLS. The cause is almost always the same: images or iframes without a stated height and width. A second cause is something that gets slotted into the page later.

INP, interaction to next paint. How long it takes before the page visibly reacts after you click or tap something. A menu that only opens after a second, a button that seems to do nothing. INP replaced the older metric FID in March 2024 and it measures more strictly, because it looks at the whole reaction instead of at the first delay. The cause is usually too much JavaScript running at the same time.

The thresholds

Between good and poor lies a middle zone that Google labels as needs improvement. Two things about this table.

First: the measurement happens at the 75th percentile. Three out of four visitors have to sit under the threshold. Your own feeling on a fast laptop with fibre therefore says nothing. The visitor who counts is the one with a three year old phone on a mediocre connection.

Second: these thresholds are not set in stone. Google has changed the set before and can do so again. Check the current values at the source before you put them in a specification or a contract.

Lab data and field data: this is where almost everyone gets stuck

This is the distinction that makes most discussions about page speed unnecessary.

Lab data is a measurement in a controlled environment. One device, one simulated connection, one moment. Lighthouse and the lab part of PageSpeed Insights do this. Advantage: repeatable and it says exactly what is wrong. Drawback: it is not your audience.

Field data comes from real Chrome users who visited your site, collected over a period of 28 days. This is called the Chrome User Experience Report. The Core Web Vitals report in Search Console shows these figures. Advantage: it is reality and it is what counts towards your position. Drawback: it lags behind and you only see the effect of an improvement weeks later.

Two consequences you have to know. A small site often has too few visitors for field data. Search Console then reports that there is not enough data. That is not an error and not a problem, it is a consequence of your visitor numbers. You then work with lab data and with common sense.

And INP cannot be measured decently in the lab, because there is nobody clicking. Lighthouse gives total blocking time instead, as an approximation. Anyone who presents you with an INP figure from a lab test is measuring something other than what they say.

Running Lighthouse locally, free of charge

You need no paid tooling for this and no account.

1. Open the page in Chrome.
2. Right click and then Inspect. The shortcut is F12 on Windows and Cmd+Option+I on Mac.
3. Choose the Lighthouse tab. If it is not there, click the double arrow next to the tabs.
4. Set the device to Mobile and tick Performance.
5. Click Analyse page load.

Three practical rules. Run the test in an incognito window, otherwise you measure your own browser extensions as well. Run it three times and take the middle outcome, because the score fluctuates between two identical measurements. And do not test the homepage alone. The pages where your visitors come in are more important and that is rarely the homepage.

If you want field data and lab data side by side, use PageSpeed Insights on the web. At the top sits the field data if it is there, below it the lab measurement. Do not confuse the two blocks, because they sit under each other and measure something different.

Mobile: viewport and zoom

Google indexes mobile first. What is not in the mobile version of your page does not count. A site that hides half of the text on mobile hides that half from Google as well.

One line of HTML is compulsory in the <head> of every page:

<meta name="viewport" content="width=device-width, initial-scale=1">

Without that line a phone shows your page as a zoomed out desktop version and the visitor has to zoom in to read anything.

What you do not add to it: user-scalable=no or maximum-scale=1. Those two block zooming. That is a problem for everyone who does not see sharply and it is an accessibility fault. Some browsers ignore the setting by now. Do not count on that and simply leave them out.

Three more things that come back on mobile:

• Text too small. Under 16 pixels, reading on a phone becomes awkward. On input fields it has an additional consequence: iOS zooms in automatically when the font size sits under 16 pixels, which throws the visitor out of the layout.
• Tap targets too close together. Two links under each other with a few pixels in between cannot be separated with a finger.
• Horizontal scrolling. A table or an image wider than the screen pushes the whole page out of true. Lighthouse reports this under the heading that the content is not sized correctly.

Where it stops paying off

Now the honest part. Speed is a ranking signal of limited weight. It works above all as a referee between pages that are equal in substance. A slower page with a better answer beats a fast page with a poor answer.

From five seconds to two seconds is a noticeable difference, for the visitor and for the measurement. From 1.4 seconds to 1.2 seconds it is not. How much a tenth of a second exactly yields in revenue is not reliably known for your site. What is certain is where the threshold lies: 2.5 seconds for LCP and not zero. If you sit under it, this subject is finished and your next day of work goes better into content.

Anyone who nevertheless keeps chasing a Lighthouse score of 100 usually pays for it with something else. A chat widget that has to go, tracking that has to go, a font that has to go. Sometimes that is the right trade-off. Often it is optimising a score instead of a site.

Where the gain for an SMB does sit, in this order:

1. Images. Files that are too large are the most common cause of a poor LCP. Resize to the display size, save as WebP and let images below the fold load only when they are needed.
2. Scripts you do not use. A chat window, three tracking pixels, a tag manager with forgotten rules and a slider plugin from 2019. Every script costs INP.
3. The cookie banner. It is often responsible for both the worst LCP and the worst CLS, because it loads on top of the page and pushes the rest down.
4. Caching and compression at your host. Usually a switch in the control panel of your hosting.
5. Fixed dimensions on images and iframes. Two attributes, width and height, solve the majority of CLS problems.

What you can do yourself and what you cannot

To do yourself, without a developer:

• Run Lighthouse in Chrome and open the Core Web Vitals report in Search Console.
• Resize images before you upload them. This is the cheapest gain in this whole chapter.
• Switch off plugins and scripts that nobody uses any more.
• Check the viewport line and take out user-scalable=no if it is there.
• Switch on caching and compression at your host.

What you need help with:

• A slow server response. If the first byte already comes late, it is down to your hosting or to the build of the site. That is not a setting.
• CSS and JavaScript that block the painting of the page. Rearranging that requires knowledge of the theme.
• A site that is built entirely in JavaScript. There, speed and findability are one and the same build question and you do not solve that with a plugin.
• A theme that is heavy by design. At a certain point replacing is cheaper than repairing.

Our working order: measure first, then work through the five points above, then measure again. If you stay above the thresholds after that, it is a conversation about hosting or about the theme and no longer about settings.

Would you rather not do this yourself: SEMANU carries out the full SEO and GEO audit for 1,450 euro, report and working session included. What it covers is on the guide page.