To test mobile page speed, enter your URL in PageSpeed Insights and read the real-user data at the top first, then the Lighthouse lab results below it. Real-user data tells you whether visitors on phones have a fast experience; lab data helps you find out why they do not. A page passes Core Web Vitals on mobile when, for at least 75% of visits, the largest content appears within 2.5 seconds, interactions respond within 200 milliseconds, and the layout shift score stays at 0.1 or below.
Field data and lab data are different things
Most confusion about speed scores comes from mixing these up.
Field data is collected from real Chrome users who visited your page, over the previous 28 days, through the Chrome User Experience Report. It reflects real phones, real networks and real behaviour. It only exists for pages and sites with enough traffic.
Lab data comes from a single simulated test, usually Lighthouse loading the page on an emulated mid-range phone with a throttled network. It is repeatable and detailed, so it is the right tool for debugging. Its score (0–100) is not what Google uses for ranking, and it changes from run to run.
When the two disagree, trust field data for “is it good?” and lab data for “what should I fix?”.
Core Web Vitals thresholds on mobile
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| Largest Contentful Paint (LCP) | When the main content appears | ≤ 2.5 s | 2.5–4 s | > 4 s |
| Interaction to Next Paint (INP) | How quickly the page responds to taps and clicks | ≤ 200 ms | 200–500 ms | > 500 ms |
| Cumulative Layout Shift (CLS) | How much the layout jumps while loading | ≤ 0.1 | 0.1–0.25 | > 0.25 |
Each is assessed at the 75th percentile of visits, separately for mobile and desktop. Mobile numbers are almost always worse, because phones have slower processors and less reliable networks. The thresholds are defined by Google on web.dev.
The best free tools for a mobile speed test
| Tool | Data type | Use it for |
|---|---|---|
| PageSpeed Insights | Field (if available) + lab | The first check on any public URL |
| Search Console, Core Web Vitals report | Field | Finding groups of slow pages across a site |
| Lighthouse in Chrome DevTools | Lab | Testing pages behind a login or on localhost; detailed diagnostics |
| DevTools Performance panel | Lab, plus live metrics for your own interactions | Finding the exact script or element causing a delay |
| WebPageTest | Lab on real devices and locations | Filmstrips, waterfalls and tests from other countries |
How to run Lighthouse step by step is covered in the Lighthouse mobile audit guide.
How to run a useful mobile speed test
- Test the right page. Use your most visited landing pages, not only the home page.
- Check field data first in PageSpeed Insights. If it says “No data”, look at the origin-level data or Search Console.
- Run the lab test three times and look at the median. Single runs vary.
- Throttle when testing locally. In DevTools, set CPU throttling to 4x and a Fast 4G or Slow 4G network before recording a Performance trace. Your laptop is much faster than most phones.
- Look at the page while it loads. Speed problems are often visible: a hero image that pops in late, a cookie banner that pushes content down. A mobile view helps here. DevTools device mode or a mobile view extension such as Mobile View Extension lets you watch the phone-sized page load with a mobile user agent, which matters if your server sends phones different assets.
Fixes that usually move the numbers
For a slow LCP
- Serve the hero image in a modern format at mobile size, with
srcsetandsizes. - Do not lazy-load the hero image; add
fetchpriority="high"to it. - Reduce server response time with caching or a CDN.
- Remove render-blocking CSS and JavaScript from the
<head>, or load it later.
For a slow INP
- Split long JavaScript tasks; anything over 50 ms blocks taps.
- Defer or remove third-party scripts (chat widgets, tag managers, A/B tests) that run on every page.
- Avoid heavy work in click and input handlers; show feedback first, then do the work.
For a high CLS
- Set
widthandheight(oraspect-ratio) on images, videos and embeds. - Reserve space for ads and banners.
- Load web fonts with
font-display: swapand choose a fallback with similar metrics.
How much does mobile speed matter?
Google uses Core Web Vitals as part of its page experience signals, but relevance and content quality matter more for ranking. The stronger reason to care is what visitors do: on a phone, a slow or jumpy page loses people before they read anything. Treat Core Web Vitals as a quality floor, not a score to chase.
For the rest of a pre-launch check, see the mobile website testing checklist, and for broader mobile fixes, how to make a website mobile friendly.
Frequently asked questions
What is a good mobile page speed score?
The Lighthouse score is a lab estimate. What matters more is passing Core Web Vitals in field data: LCP under 2.5 s, INP under 200 ms and CLS under 0.1 for at least 75% of visits.
Why is my mobile score much lower than desktop?
Lab tests for mobile simulate a slower processor and network. Heavy JavaScript and large images hurt far more on that profile.
Can I test mobile speed on localhost?
Yes, with Lighthouse or the Performance panel in Chrome DevTools. PageSpeed Insights only tests public URLs.