Website speed on mobile. Three Google thresholds, and why you don’t need a 100

Someone is waiting for a tram, searches Google for a service and opens your site. For a moment the screen stays blank. Then a big photo pops in and pushes down the button their thumb was about to tap. That is what poor website speed on mobile looks like in practice, and nobody in that moment is looking at a score.

Google describes this with three numbers it calls Core Web Vitals. Each has an official threshold, published on web.dev. Below we explain what the numbers mean, where they come from and when you can stop improving.

Three numbers Google uses for website speed on mobile

LCP is the time until the largest element on the first screen appears. It can be the main photo, a video frame or a large block of text. Good is 2.5 seconds or less. Over 4 seconds, Google calls it poor.

INP is how quickly the page reacts to a tap, a click or a key press during the whole visit. Scrolling does not count. Good is 200 milliseconds or less, poor is over 500.

CLS is how much things jump around while the page loads. It is the button that slides away from under your finger. Good is 0.1 or less, poor is over 0.25.

Google does not judge a single visit. It looks at the 75th percentile. Put simply, a page meets a threshold if at least three visits out of four are within it. Phones and computers are counted separately.

Google’s test and real visits

When you enter your address at pagespeed.web.dev, you get two different things on one page.

The first is data from real Chrome users over the last 28 days. It shows how your site behaves for people, on their phones and their connections. The Core Web Vitals assessment passes when all three numbers are good. With little traffic this part is simply missing, because Google has nothing to calculate it from. That is not a fault in your site.

The second is a lab test. Google loads the page on a simulated mid-range phone on a mobile network, and that is where the score from 0 to 100 comes from. The test usually starts with an empty browser cache, and it does not scroll or tap the way a person does, so it misses part of what real visitors go through.

When the two disagree, the real-user data matters more. Google says so plainly on web.dev. The lab test is useful for finding causes.

A score of 90 is the green zone, and that is enough

In the lab test Google treats 90 and above as good, 50 to 89 as needing improvement and anything below 50 as poor. The green zone is enough. Chasing 100 usually means cutting photos, animations or features that help your customers, and a customer on a phone rarely feels the difference between green and a perfect score.

Run the same test twice and you can get different numbers even if nothing on the site changed. Google describes this in its own PageSpeed documentation. So treat the score as a measurement on a given day, not a promise, and write it down with the date.

Speed will not win you a search position on its own either. Google writes that it always tries to show the most relevant content, even when the page experience is weaker, and that good Core Web Vitals do not guarantee a top ranking. Where there are many equally useful pages, good speed can help.

What usually slows a website down on a phone

The causes are nearly always the same, and they can be described without jargon.

• The main photo at full size. Uploaded straight from a camera, while the phone shows it in a small frame anyway. Sometimes it is also set to load only after everything else.
• A background video on the first screen. It looks great on an office computer, and on a phone over a mobile connection it is often the heaviest thing on the page.
• Images and pop-ups with no space reserved for them. The page lays out the text, then an image or a banner arrives and everything moves down. That hurts CLS.
• Fonts that swap after loading. Text first shows in a fallback font, then in the real one, which is wider or narrower, and the lines jump.
• Outside scripts. Chat, maps, counters, ad pixels. The phone has to download and run each one, and while it is busy it reacts more slowly to taps.
• A slow server. If the server takes long to answer, everything else starts later, and getting LCP under the threshold becomes hard.

Most of this can be fixed without rebuilding the site. First you need to know which of these applies to you.

How to check your own site

The simplest way is pagespeed.web.dev, on the mobile tab. If you use Search Console, it has a separate Core Web Vitals report.

Our free website scan runs the same Google PageSpeed test and shows the phone and computer results side by side, plus real-user data when Google has it. It also checks SEO, SSL, security headers and a few other things.

If you are wondering whether a faster site would matter for sales, work it out in the page speed calculator. You enter every number yourself, including your own assumption about what one second is worth. We do not fill in market averages.

Check the mobile result and write it down with the date. If it is green, leave speed alone and spend the time on what your site says.