Running a site
Mobile speed and Core Web Vitals, explained
Speed is not one number. Here are the three measures Google publishes, what usually makes a business site slow on a phone, and what a good score does and does not buy you.
Many visitors to a business website arrive on a phone, often on mobile data and often on a device that is not new. A site that feels quick on the developer’s laptop can feel slow there. This note explains the measures Google publishes for that experience, what usually causes slowness, and how far speed should drive your decisions.
The three measures
Google’s web.dev team publishes three Core Web Vitals, each with a target for a “good” result:
| Measure | What it describes | Good result |
|---|---|---|
| Largest Contentful Paint (LCP) | How quickly the main content appears | Within 2.5 seconds of the page starting to load |
| Interaction to Next Paint (INP) | How quickly the page responds when you tap or type | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | How much the page jumps around while it loads | 0.1 or less |
A page passes only if all three are good at the 75th percentile of real visits, measured separately for mobile and desktop. In plain terms, three out of four visits should be at least that good, not just the best visit you happened to test. web.dev describes INP as the successor to an older measure called First Input Delay (FID), so guides that still lead with FID are out of date.
Field data and lab data
Field data comes from real visitors’ browsers. It is the only data that shows what your customers experience, because it varies with their phone, their connection and what they do on the page. It appears in PageSpeed Insights and in the Core Web Vitals report in Search Console, but only when enough people have visited. A new or small site may have none yet.
Lab data comes from a controlled test, such as Lighthouse. It is good for catching a mistake while the site is being built. It cannot measure INP at all, because a simulated load has no real taps, so it estimates responsiveness another way. Treat a lab score as a warning light, not as a verdict.
What usually makes a business site slow
This part is experience and judgement, not a published rule, so test your own site and do not assume.
- Large images. A photograph straight from a camera, shown in a small space, is the most common cause; images that load fast covers sizes, formats and layout.
- Many fonts or heavy font files.
- Third-party scripts, such as chat widgets, trackers, embedded videos and maps. Each one is a small site you do not control, loaded into yours.
- Large amounts of JavaScript, especially for effects that a visitor does not need to enquire.
- Content that loads late and pushes the page around, which is what CLS measures.
Fixing the page that jumps
web.dev’s guidance on layout shift is practical. Put width and height on every image and video so the browser can reserve the space. Reserve room for adverts, embeds and anything that is injected after the page loads. Web fonts can shift text when they arrive; using a close fallback font and loading the important font early reduces it.
My business site feels slow: where to start
Find which of these you are seeing, then ask about the likely cause. Each row is a pattern from experience, so confirm it on your own site before paying for a fix.
| What you notice on a phone | Likely cause | What to ask or check |
|---|---|---|
| The page stays blank, then everything appears at once | Large images or a heavy script blocking the first view | How many kilobytes is the biggest image on this page, and is the first screen waiting for a script? |
| Text appears, then jumps down when a picture arrives | Images without width and height, or an embed without reserved space | Does every image and video have its size set in the page? |
| The page shows but ignores taps for a moment | Too much JavaScript for the phone to run | Which scripts run on this page, and does the page need each of them to read it and enquire? |
| Slow only the first time, fast afterwards | Files not cached, or a slow host far from your visitors | Where is the site hosted, and are static files cached? |
| Fast on Wi-Fi, slow on mobile data | Total page weight is too high | What is the total download size of the home page, and what is the target? |
| Slow only on pages with a map or video | Third-party embeds | Can the map be a link until the visitor asks for it? |
A developer can usually find the cause in under an hour by recording a load in a browser’s developer tools on a throttled connection. If a quote for “speed optimisation” does not name what will be measured before and after, ask for that first.
Is the site mobile-friendly? Tools that no longer exist
Older guides send you to Google’s Mobile-Friendly Test or the Mobile Usability report in Search Console. Google retired both in December 2023, according to industry reporting at the time, and named Lighthouse (built into Chrome’s developer tools) as one of the better resources now available. PageSpeed Insights also runs Lighthouse. If a guide or a seller still offers a “mobile-friendly test score” from the old tool, it is out of date. The reliable check is still the human one: open the site on a real phone, tap every button, fill in the form and read the smallest text without zooming.
What speed does for search
Google says Core Web Vitals are used by its ranking systems, but also that good results do not guarantee a top position, and that there is more to page experience than the scores. It advises against chasing a perfect score only for search reasons. A fast site mainly helps the people using it: they can read, tap and enquire without waiting.
A ten-minute check
- Open your website on your own phone using mobile data, not Wi-Fi. Time how long until you can read the main heading and tap the phone or WhatsApp button.
- Scroll while the page is still loading. Does the text jump?
- Paste the address into PageSpeed Insights and read the field data first, if it exists, then the lab results.
- Once Search Console is connected, open its Core Web Vitals report after a few weeks of visits.
What to ask a developer
- How big are the images on the home page, and are they sized for a phone?
- Which third-party scripts will the site load, and why is each needed?
- Which phone and connection will you test on before launch?
- How will we measure speed after launch, and who looks at the result?
A developer who answers these plainly is thinking about your visitors.