--- title: Lighthouse says 100, users say slow? Check with the Core Web Vitals Checker description: Your laptop's Lighthouse run scores 100, yet phone users say the page is slow or jumps around. To check Core Web Vitals properly, test the same page with the mobile profile, not just desktop, and read LCP and CLS against Google's thresholds. Here's how with the free Core Web Vitals Checker, a real page that scored 100 on desktop and 65 on mobile, and what to fix first. canonical: https://watchfor.io/blog/how-to-check-core-web-vitals --- # Lighthouse says 100, users say slow? Check with the Core Web Vitals Checker 2026-10-04 · WatchFor Team · Guides · guides, core-web-vitals, performance Your laptop's Lighthouse run scores 100, yet phone users say the page is slow or jumps around. To check Core Web Vitals properly, test the same page with the mobile profile, not just desktop, and read LCP and CLS against Google's thresholds. Here's how with the free Core Web Vitals Checker, a real page that scored 100 on desktop and 65 on mobile, and what to fix first. To check Core Web Vitals, run a Lighthouse audit on the page with the **mobile** profile as well as desktop, and compare Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS) with Google's thresholds: LCP is good at 2.5 seconds or less, CLS at 0.1 or less. A desktop run on a fast machine often scores near 100 while the same page on a throttled phone profile fails, and the phone result is closer to what most visitors get. The free [Core Web Vitals Checker](/core-web-vitals-checker) runs a full Google Lighthouse audit in a real browser on a WatchFor probe, with a desktop or mobile profile, and shows the scores, the vitals, a loading filmstrip and the top fixes. No signup. ## What this tool answers *How fast does this page load and how stable is it, for the device I pick, measured the way PageSpeed Insights measures it?* Reach for it when users complain about speed that your own tests don't show, after a redesign, when Search Console flags poor URLs, or before and after a performance fix. It runs from a clean browser on a server, so your extensions, cache and fast laptop don't flatter the result. ## A real example ### Checking Core Web Vitals when desktop says 100 and mobile users complain The classic report: "Lighthouse gives us 100, but people on phones say the page jumps around while it loads." We ran the [Core Web Vitals Checker](/core-web-vitals-checker) on `www.mozilla.org` twice from Vilnius, once per device preset. Desktop first: ![Core Web Vitals Checker, desktop preset, www.mozilla.org: Performance 100, Accessibility 100, SEO 100, Best Practices 96, LCP 687 ms and CLS 0.001, both green](/blog/how-to-check-core-web-vitals-desktop.webp) **Performance 100**, LCP 687 ms, CLS 0.001. If that's all you test, the page is perfect. Then the same URL with **Mobile (throttled)**: ![Core Web Vitals Checker, mobile throttled preset, www.mozilla.org: Performance 65 in amber, Accessibility 100, SEO 100, Best Practices 96; LCP 2.95 s in amber, CLS 0.948 in red, INP not measured; FCP 2.26 s, Speed Index 2.73 s, Total Blocking Time 175 ms, Time to Interactive 3.64 s](/blog/how-to-check-core-web-vitals-mobile.webp) **Performance 65.** LCP rose to 2.95 seconds (needs improvement), and CLS jumped to **0.948**, almost ten times the 0.25 line where "poor" begins. The complaint is real, and it's mostly about layout shift, not raw speed: Total Blocking Time is a healthy 175 ms. The filmstrip and the fixes list explain the rest: ![The mobile run's loading filmstrip: blank frames at 0.4, 0.8 and 1.1 seconds, content from 1.5 seconds; and the top opportunities: eliminate render-blocking resources (about 1.06 s), avoid multiple page redirects (about 837 ms), reduce initial server response time (about 588 ms), defer offscreen images (about 340 ms) and serve images in next-gen formats (about 170 ms)](/blog/how-to-check-core-web-vitals-opportunities.webp) The screen stays white for over a second, then the content appears. The full Lighthouse report (the **Full Lighthouse JSON** link under the results) has the details. Nearly all of the shift, 0.933 of 0.948, is the whole page wrapper moving down once, and Lighthouse lists the header logo image as the likely cause ("unsized image element"). The logo tag does carry `width` and `height`, so the thing to check is whether CSS overrides the space those attributes reserve. The redirect item is `www.mozilla.org/` → `www.mozilla.org/en-US/`, which costs a phone about 837 ms before the real page even starts. **The answer:** both reports were true. Desktop is excellent; on a throttled phone the page fails CLS badly and is borderline on LCP. The fixes, in order: stop the layout shift (reserve the header's height so nothing moves when the logo loads), link straight to the final URL to skip the redirect, then work on render-blocking CSS and JavaScript. ## How to read the results | What you see | What it means | | --- | --- | | **Performance (0–100)** | Lighthouse's weighted score of the lab metrics. Green from 90, amber 50–89, red below 50. | | **Accessibility, SEO, Best Practices** | Lighthouse's other category scores, same colours. | | **LCP** | When the largest element in the first screen finished rendering. Good ≤ 2.5 s, poor > 4 s. | | **CLS** | How much visible content moved during load. Good ≤ 0.1, poor > 0.25. | | **INP** | Interaction to Next Paint needs real users clicking, so a lab run leaves it empty. Total Blocking Time is the lab stand-in. | | **FCP, Speed Index, TBT, TTI** | Supporting lab timings: first content, how fast the screen fills, main-thread blocking, and when the page becomes reliably interactive. | | **Coloured dots** | Each metric against its published threshold: green good, amber needs improvement, red poor. | | **Loading filmstrip** | Frames at fixed intervals, so you can see what a visitor sees at 0.4 s, 0.8 s and so on. | | **Top opportunities** | Lighthouse's fixes with estimated savings. Savings overlap, so they don't add up. | | **Final screenshot / Full Lighthouse JSON** | The finished page, and the complete report with every audit, including which elements shifted. | | **Footer** | Lighthouse version (12.8.2 in our runs), preset and how long the audit took. | ## More ways to use it - **Before and after a fix.** Run the same preset before and after reserving image sizes or removing a render-blocking script, and compare. - **After a redesign or new theme.** New hero images, web fonts and consent banners are common sources of LCP and CLS regressions. - **Template checks.** Test a product page, an article and the home page; they rarely share the same problems. - **Vendor and competitor pages.** See how a landing page builder or a competitor's site performs on a phone profile. ## Tips and gotchas - **Always test mobile.** The mobile preset applies CPU and network throttling; the desktop preset doesn't. A desktop 100 says little about phones. - **Lab is not field.** Google's ranking signal uses field data from real Chrome users (the Chrome UX Report, 75th percentile over 28 days). A lab run is the tool for finding *why*; Search Console shows *how many* users are affected. [Synthetic vs real-user monitoring](/blog/synthetic-vs-real-user-monitoring) explains the split. - **Scores vary between runs.** Network and server timing change; compare metrics over several runs before calling a regression. - **Only a few audits an hour.** Each audit runs a full browser, so the free checker has a much tighter per-IP limit than the other tools. Plan your before and after runs. - **Redirects count.** Testing `example.com` when visitors land on `www.example.com/en/` adds the redirect time to every metric. - **Fix CLS with reserved space.** Give images and embeds `width` and `height` (or `aspect-ratio`), reserve space for banners and ads, and use `font-display: optional` or size-matched fallbacks for web fonts. [CLS explained](/blog/cls-explained) and [LCP explained](/blog/lcp-explained) go deeper. ## Check it from the command line too Lighthouse has a CLI that runs the same audit locally with Chrome or another Chromium browser: ```bash npx lighthouse https://www.mozilla.org/ --only-categories=performance \ --form-factor=mobile --output=json --output-path=mobile.json --quiet npx lighthouse https://www.mozilla.org/ --only-categories=performance \ --preset=desktop --output=json --output-path=desktop.json --quiet jq -r '[.categories.performance.score, .audits["largest-contentful-paint"].displayValue, .audits["cumulative-layout-shift"].displayValue] | @tsv' mobile.json desktop.json ``` ```text 0.7 2.5 s 0.935 0.99 0.8 s 0.001 ``` Same pattern from our own machine a few minutes later: 70 and CLS 0.935 on mobile, 99 and CLS 0.001 on desktop. The exact numbers differ from the probe's because the network and CPU differ; the mobile CLS problem shows up both times. To find the shifting elements in the report: ```bash jq -r '.audits["layout-shifts"].details.items[] | "\(.score) \(.node.selector)"' mobile.json ``` ```text 0.9343863912515188 body#home > div#outer-wrapper 0.0001659430767801573 main > div.m24-t-dark > section.m24-c-flag > button.m24-c-flag-button ``` The page wrapper again, as in the checker's report. ## Keep watching it A redesign, a new script or a consent banner can undo good vitals without anyone noticing. A [Core Web Vitals monitor](/core-web-vitals-monitoring) repeats this Lighthouse audit on a schedule, keeps a 7-day trend of every metric, and opens an incident when LCP or CLS falls into Google's *poor* band (both rules are on by default), with optional rules for the performance or SEO score. The device is fixed per monitor, so add one for mobile and one for desktop. ## FAQ **How do I check my Core Web Vitals?** Run a Lighthouse audit with the mobile profile (the free checker, Chrome DevTools or PageSpeed Insights) for lab results, and look at Search Console's Core Web Vitals report for field data from real visitors. **Why is my mobile PageSpeed score lower than desktop?** The mobile profile simulates a mid-range phone on a slow connection, with CPU throttling. Heavy JavaScript, large images, redirects and unsized elements cost far more there, as the 100 vs 65 example shows. **What is a good CLS score?** 0.1 or less is good, 0.1 to 0.25 needs improvement, and above 0.25 is poor. The most common causes are images and embeds without reserved size, late banners, and web fonts that swap in with different metrics. --- Canonical page: https://watchfor.io/blog/how-to-check-core-web-vitals · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt