Reading a Lighthouse score on a phone

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.

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.

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.

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.

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.

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. 1

   Run PageSpeed Insights

   Go to pagespeed.web.dev. Paste https://yourproduct.com/pricing. Hit Analyse. Read the Mobile tab first.

2. 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. 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. 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. 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.

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 /, <link rel="preload" as="image" href="/hero.avif"> 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.

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.

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. 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. 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. 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. 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. 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.

• 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.