# Reading a Lighthouse score on a phone You care about the phone score. That is how most people experience your site, and that is how PageSpeed Insights runs by default. Here is how to read the four scores, what makes the Performance number, how it differs from field data, and what to change on your pages. Updated 2026-09-13 · Source: https://porteur.ai/guides/lighthouse-score ## Why the mobile run is the one that counts Lighthouse runs a simulated mobile test by default: a mid-range phone on throttled 4G. That is closer to your visitors than a fast laptop on Wi-Fi. PageSpeed Insights shows that mobile run first. Your Search traffic lands on mobile first for most sites. If your phone score is low, your users feel it. > Check your pages on a real phone on a normal connection. If text shifts or buttons lag there, Lighthouse will surface it too. ## What the four Lighthouse categories mean You get four scores, each from 0 to 100: Performance, Accessibility, Best Practices, and SEO. Each is an automated check, not a guarantee of success. - Performance reflects how fast the page appears and responds, using lab metrics. - Accessibility checks colour contrast, labels, and landmarks. Helpful, but it misses manual checks. - Best Practices covers security and modern web features. It catches unsafe links, mixed content, or older APIs. - SEO checks basic discoverability, like meta tags and crawlable links. It is not a ranking score. For growth, Performance on mobile is your focus. The other three should be green, but do not chase 100 if it harms speed or content quality. ## What makes the Performance score on Lighthouse Lighthouse v10 and later weights five lab metrics to form the Performance score. The weights are fixed. Scores vary between runs, so read the details too. | Metric | Weight | What it captures | Simple mobile example | | --- | --- | --- | --- | | Total Blocking Time | 30% | Main thread blocks after content starts, a proxy for interactivity lag | Large third-party script stalls taps on /pricing long enough to feel laggy | | Largest Contentful Paint | 25% | Time to render the main content element | Hero image on /guides/getting-started appears at 3.2 s | | Cumulative Layout Shift | 25% | Unexpected visual movement during the session window | Price cards jump when a webfont loads | | First Contentful Paint | 10% | First painted pixels | Skeleton header at 1.4 s | | Speed Index | 10% | How quickly content fills the viewport | Above-the-fold fills unevenly due to late CSS | Lower TBT and faster LCP usually lift your score the most. Small CLS changes can swing the score because its weight is high too. Speed Index and FCP matter, but less. > Scores are binned. Shaving 200 ms off LCP can cross a scoring threshold and jump the grade more than you expect. ## How lab data differs from field data Lighthouse is lab data. It is one simulated run with fixed device and network settings. It is good for debugging and seeing what your code does in a clean room. Field data is real user experience. The Chrome User Experience Report samples Chrome users over 28 days, and uses the 75th percentile per URL or origin. This is what Search looks at for Core Web Vitals, as of 2026. - Core Web Vitals today: Largest Contentful Paint good up to 2.5 s, poor above 4 s. - Cumulative Layout Shift good up to 0.1, poor above 0.25. - Interaction to Next Paint good up to 200 ms, poor above 500 ms. INP replaced FID in March 2024. PageSpeed Insights shows field data when there is enough traffic, then a Lighthouse run. If your field INP is poor but Lighthouse TBT is fine, users are hitting slow code that the lab run misses, like when chat loads after idle or a third-party widget blocks taps on real networks. > Fix what field data flags first. A green lab score with red field vitals means real people still suffer on your site. ## Running and reading a Lighthouse test on a phone Use PageSpeed Insights for a quick view and shareable link. It runs Lighthouse on Google’s servers and shows field data if available. Enter your URL, read mobile first, then desktop. 1. **Run PageSpeed Insights** Go to pagespeed.web.dev. Paste https://yourproduct.com/pricing. Hit Analyse. Read the Mobile tab first. 2. **Scan the field data panel** If it shows Core Web Vitals, note LCP, CLS and INP statuses. They use the 75th percentile over 28 days. 3. **Open the Lighthouse lab panel** Note the Performance score and each metric value: LCP, TBT, CLS, FCP, Speed Index. Expand View Treemap and Diagnostics. 4. **Check Opportunities and Diagnostics** These are suggestions with estimated savings. They are based on the lab run. Focus on big savings that match your field issues. 5. **Reproduce on device** Open the same page on a mid-range phone on 4G. Confirm the slow element, shifting block or input lag you saw in reports. For deeper debugging, run Lighthouse in Chrome DevTools. Open your page, press F12, go to Lighthouse, pick Mobile, and run. You can record a performance trace and block specific resources to isolate heavy scripts. Use the same URL and settings when you compare two runs. ## The Opportunities list and what to fix first Opportunities estimate how much faster the page could be if you apply a change. Treat them as pointers, not as a shopping list. Check each against your field data and your code budget. - Serve images in next-gen formats: Convert hero.jpg to AVIF or WebP. On /pricing, this can drop LCP from 3.2 s to near 2.5 s. - Preload key requests: Preload the hero image and the main font. On /, cuts LCP jank. - Reduce unused JavaScript: Split your React bundle. Do not ship the dashboard code to /features. Aim to cut main-thread work and TBT. - Eliminate render-blocking resources: Inline critical CSS for above-the-fold. Defer non-critical CSS and scripts. - Avoid large layout shifts: Reserve space for images and embeds. Use aspect-ratio in CSS. Avoid late-loading banners pushing content. A fixed page example: /guides/getting-started loads a 1200 px hero image as AVIF, preloads it, inlines 3 KB of critical CSS, defers analytics, and reserves card heights. LCP drops under 2.5 s, CLS under 0.1, and the page feels steady on a mid-range Android on 4G. > Do not chase every 0.1 s saving if it bloats your codebase. Fix the largest user-visible wins first: LCP render path, main-thread blocks, and layout shifts. ## Core Web Vitals on mobile, in plain terms Largest Contentful Paint is when the biggest content block in the viewport renders. Aim for 2.5 s or less on real users. Optimise the render path to that element. - Keep HTML light so the browser starts fast. - Preload the hero image and critical CSS. Avoid blocking scripts before LCP. - Host fonts well and use font-display: swap if you must. Do not delay LCP with a late webfont. Cumulative Layout Shift measures surprise movement. It is a sum, not a time. Keep it at or below 0.1. Always set width and height or an aspect ratio, and avoid injecting banners above existing content without space reserved. Interaction to Next Paint measures how long the page takes to respond visually to a user input. Good is up to 200 ms, poor above 500 ms. Break up long tasks, avoid heavy work on input, and delay non-essential scripts until idle. If your lab TBT is high, your field INP is likely bad too, but not always, because INP captures user input timing on real sessions. ## How to compare two Lighthouse runs honestly Scores vary. One point up or down means little. Compare like for like and look at the metric values and traces, not just the badge colour. 1. **Fix the test conditions** Use the same URL, no query params, logged-out state, and disable consent popups for the run if you can. Use Mobile each time. 2. **Hold the environment steady** In DevTools, use the same throttling profile. On PageSpeed Insights, run two or three times and average the metric values. 3. **Compare metrics, not just the score** Check LCP, TBT, CLS, FCP, Speed Index. A small drop in CLS can be more valuable than a 1-point score rise. 4. **Read the waterfall and main-thread work** Open the Performance trace. Look for long tasks over 50 ms and blocking network calls before LCP. 5. **Validate in field data** Wait for the 28-day window to move. Check your page’s field LCP, CLS and INP. If they did not move, recheck your change on real devices. > Do not compare your site’s desktop run to a rival’s mobile run, or your homepage to their blog post. Align device, page type and weight. ## Troubleshooting common mobile slowdowns - Hero image too heavy: Compress and serve AVIF or WebP, set sizes and preload. Avoid a full-screen video on first paint. - JavaScript bundle too large: Code-split routes. Remove unused libraries. Lazy-load heavy components below the fold. - Third-party scripts: Audit tags. Delay non-essential ones. Use async and defer. Load chat and heatmaps after interaction. - Fonts block rendering: Preload critical fonts. Limit variants. Use system fonts for UI. Set font-display to avoid FOIT. - Layout shifts from ads or banners: Reserve space with a fixed container. Avoid inserting above existing content after load. - Slow API before first paint: Do not wait for data to render the shell. Show skeleton UI and fetch in parallel. Cache where safe. Example fix on /pricing: Hero image preloaded, React bundle split, consent banner given a fixed height, and live chat delayed until user scroll. Lighthouse LCP drops from 3.8 s to 2.6 s, TBT comes down, and CLS drops below 0.1. The page feels fast, and buttons respond without lag. ## Questions ### What is a good Lighthouse score? Aim for green on the mobile Performance score, but judge by metrics. A phone LCP near or under 2.5 s, CLS at or under 0.1, and low TBT are strong signals. Field INP good at or under 200 ms matters more than a single lab score of 100. ### How do I run a Google Lighthouse test? Go to pagespeed.web.dev and enter your URL. Read the Mobile tab first. For debugging, open Chrome DevTools, go to Lighthouse, select Mobile, and run. Keep the URL, device and throttling the same when you compare runs. ### How do I access Google Lighthouse? You can run it in Chrome DevTools, from the Lighthouse tab. Or use PageSpeed Insights which runs Lighthouse in the cloud and adds field data when available. Both use a simulated mobile device by default. ### How do I interpret Lighthouse results? Read the metric values first, then the score. Focus on LCP, TBT and CLS. Use Opportunities as pointers. Check PageSpeed Insights’ field panel for Core Web Vitals. Fix items that map to poor field LCP, CLS or INP before chasing minor lab wins. ### Why does my Lighthouse score change between runs? It is one simulated run with network and CPU throttling. Variance is normal. Run two or three times and compare metric values, not just the score. Hold conditions steady and validate improvements in field data over the 28-day window. ### Does a high Lighthouse score improve SEO directly? There is no direct ranking bonus for a 100 badge. Good Core Web Vitals help users and are part of page experience signals. Fix speed to win conversions and reduce bounce. Do not ship less content to chase a round number. ## Read next - [Lighthouse vs PageSpeed Insights: lab and field](https://porteur.ai/compare/lighthouse-vs-pagespeed-insights): Use Lighthouse for repeatable lab checks, PageSpeed Insights for real-user field data. See why scores differ and which to trust for fixes and reporting. - [Core Web Vitals for a product site: the three numbers](https://porteur.ai/guides/core-web-vitals): The product founder’s guide to LCP, CLS and INP: what Google measures, why phones decide the pass, common causes, and how to test and fix. - [Largest Contentful Paint: what slows it and what fixes it](https://porteur.ai/guides/largest-contentful-paint): See what usually counts as LCP, what makes it slow, how to fix it in order, and how to read it in Lighthouse and field data. - [Interaction to Next Paint (INP)](https://porteur.ai/glossary/interaction-to-next-paint): INP is the delay from tap to next paint, good up to 200 ms; learn how to measure it, read field versus lab data, and fix script delays. - [Cumulative Layout Shift (CLS)](https://porteur.ai/glossary/cumulative-layout-shift): Cumulative Layout Shift is how much a page moves while loading. Keep CLS at or below 0.1. Here is how to measure, find causes, and fix them. - [Technical SEO checklist for a small site](https://porteur.ai/guides/technical-seo-checklist): Run these 20 technical SEO checks, in order. Each shows how to check it free and what fixed looks like for a site under 1,000 pages. - [WebPageTest vs PageSpeed Insights](https://porteur.ai/compare/webpagetest-vs-pagespeed-insights): Use PageSpeed Insights for the verdict from field data, and WebPageTest to see why a page is slow. Here is when to choose each and how to pair them. Want a second opinion on your slow pages? Paste your URL and the free check reads your site and rivals in about thirty seconds and shows three findings. Free check: https://porteur.ai/