Mobile Speed Findings in Site AI Audit: LCP, CLS and INP

Short answer: The speed area of a Site AI Audit report is built on Google’s mobile measurements. During the check, the audit asks Google PageSpeed for your mobile score and the Core Web Vitals, then turns the numbers into findings: a low mobile score, a slow main content (LCP), a layout that jumps (CLS) and a page that reacts slowly to taps (INP). Each finding states the threshold that was crossed, why it matters to visitors and what to do first.

Why the audit measures speed on a phone

Most visitors reach a small business website from a phone, often on a mobile connection that is slower and less stable than the office network. A page that feels instant on a laptop can take five seconds on a mid-range phone, and the visitor will not wait. Google also uses mobile experience as part of how it judges a site. That is why the speed check in the audit asks for mobile results, not desktop ones.

On the home page the speed step is described as “Google PageSpeed”: mobile speed and Core Web Vitals, measured by Google. It is one of the later steps of the check, after the connection, robots.txt, the crawl and the e-mail records. The result becomes the speed score in your report, next to the SEO, security and e-mail scores. If you are new to the three vitals, the article on Core Web Vitals for small business websites gives the background in plain language.

The mobile score finding

The first speed finding is the overall mobile score from Google, a number out of 100. In the report it appears as “Mobile speed score is N / 100”. A score below 50 is reported as critical, because slow mobile pages lose most visitors before they load. A score from 50 to 89 is reported as a warning, because there is room to load faster. A score of 90 or more produces no finding.

The suggested first steps are practical: compress images, remove unused scripts and turn on caching. Do not chase 100. A score in the nineties is a good result, and the gap between 92 and 100 is rarely worth the effort. If the score changes from one check to the next without any change on your side, that is normal; the article on why your PageSpeed score changes every time you test explains the reasons.

LCP: when the main content appears

Largest Contentful Paint measures how long it takes for the biggest visible element, often the hero image or the main heading block, to appear. The audit raises a warning when it takes longer than 2.5 seconds and a critical finding when it takes longer than 4 seconds. The finding shows the measured time, for example “Main content appears after 4.1 s (LCP)”, and explains that beyond four seconds visitors perceive the site as broken.

The usual causes are a large hero image, a slow server and styles or scripts that block rendering. The audit’s advice is to optimise the largest image or block at the top of the page and to speed up the server response. In practice, check these in order:

Is the main image far larger than the space it fills? Resize it and use a modern format.
Is that image loaded lazily? The first image on the page should load immediately.
Does the server answer slowly? The audit has a separate finding for that, covered below.

The guide on improving Largest Contentful Paint goes through each fix with examples.

CLS: when the page jumps

Cumulative Layout Shift measures how much visible content moves while the page loads. You have felt it: you go to tap a button and an image above it loads, pushing the button down, so you tap the wrong thing. The audit raises a warning above 0.1 and a critical finding above 0.25, and it names the finding “Layout shifts while loading” or “Layout jumps while loading”, with the measured value.

The audit’s advice is to set width and height on images, reserve space for ads and embeds, and avoid inserting content above existing content. Those three habits fix most cases. Other common causes are web fonts that swap late and banners that appear after the page has rendered. The article on fixing Cumulative Layout Shift explains how to find the element that moves.

INP: how fast the page reacts

Interaction to Next Paint measures the delay between a tap or a click and the moment the page responds. The audit reports a warning when INP is above 500 milliseconds, with the finding “The page reacts slowly to taps”. Half a second is long enough that visitors tap twice or give up. The cause is almost always heavy JavaScript, especially third-party scripts such as chat widgets, tag managers and tracking pixels that all compete for the phone’s processor. The advice in the report is to reduce heavy JavaScript and third-party scripts. For a closer look, see the article on fixing slow interactions.

A note on data: INP and some other measures come from real-user data that Google collects, and a small site with little traffic may have no such data. In that case the report relies on the laboratory measurement and does not show findings that need field data. Missing data is not a bad sign; it only means there were too few visits to measure.

The other speed findings in the same area

The speed area includes findings that are not Google metrics but affect the same experience:

Page weight: a warning when the home page is heavier than about 3 MB.
Slow server: a warning when the server takes longer than 1.5 seconds to respond.
No compression: a warning when text files are sent without gzip or Brotli.
Slow pages: a notice listing pages that took over 2 seconds to load during the crawl.
Old HTTP version: a notice when the server still uses HTTP/1.1 instead of HTTP/2 or HTTP/3.

These are often the cheapest wins, because they sit at the host or server level and one change helps every page.

Which speed finding to fix first

Start with the cause that sits furthest back in the chain. A slow server delays everything, so if you see that finding, fix it before polishing images. Next come compression and page weight, which shrink every download. After that, deal with the largest image for LCP, then layout shifts, and last the script work for INP, which usually takes the most effort. Fix one group, run the check again and compare. Because the report ranks findings by impact, the order in the report is a reasonable guide, but critical speed findings should always come before notices.

What the audit cannot tell you about speed

The audit measures your site from the outside, so it can say that the main content appears after 4.1 seconds, but it cannot open your admin area and tell you which plugin is the heaviest. To find the exact element behind a slow LCP or a layout shift, you still need the developer tools in your browser, or your developer. Think of the report as the signpost: it tells you where the problem is and how large it is, and the guides on this blog and the “how to fix” lines tell you which direction to walk.

Another limit is variation. Mobile speed measurements move between runs, because networks, servers and Google’s test machines all vary. Do not react to a change of two or three points. React to the findings, which cross fixed thresholds, and to a clear improvement after a change that you made on purpose.

A routine for fixing speed findings

When the report shows several speed findings, a short routine keeps the work under control:

Write down the starting numbers. Note the mobile score, the LCP time and the page weight from the first report.
Make one kind of change at a time. Turn on compression, then check; resize the hero image, then check. Mixing five changes makes it impossible to see what helped.
Use a re-check for confirmation. A paid plan includes re-checks, so each round ends with a measured result instead of a guess.
Stop when the critical findings are gone. A warning that remains is a task for later, not an emergency.

This approach also protects you from a common trap: spending a weekend on a tiny script optimisation while the server answers in two seconds.

A worked example

A garden centre has a WordPress site with a slider on the home page. The audit report shows a mobile score of 41, a critical LCP finding of 5.2 seconds and a warning for page weight at 4.6 MB. The slider loads five full-size photographs of about 800 KB each. The owner replaces the slider with a single compressed banner image, sets its width and height and removes a heavy gallery plugin from the home page. She runs a new check: the home page now weighs 1.4 MB, the LCP finding is gone and the mobile score is 78, which is a warning rather than a critical finding. The rest of the work, such as caching, can wait for the next round.

To see these numbers for your own website, check your website with Site AI Audit. The check needs a free account and takes about one to two minutes. The plans unlock the full report and give you checks to run again after each fix.

The bottom line

The speed area of a Site AI Audit report turns Google’s mobile measurements into a short list of findings with thresholds and fixes. Begin with the server and compression, then the main image, layout shifts and scripts, and run the check again to confirm that each fix worked.

FAQ

Does the audit measure speed on mobile or on desktop?

On mobile. The audit uses Google PageSpeed for the mobile score and the Core Web Vitals, because most visitors use phones.

What score counts as good?

A mobile score of 90 or more produces no finding. A score below 90 is a warning and below 50 is critical.

Why does my score differ from another speed test?

Different tools use different locations, devices and network speeds, and results vary between runs. Compare the same tool over time instead of comparing different tools.

What if my site has no Core Web Vitals data?

Small sites with little traffic may have no real-user data. The report then relies on the laboratory measurement.

Will fixing these findings improve my Google rankings?

Speed is one signal among many, and it matters most for visitors. Faster pages keep more people on your site, which is the main benefit.