LCP measures loading, INP measures responsiveness, and CLS measures visual stability. Start with the failing mobile field metric on an important page, then reproduce the issue in DevTools before choosing a fix.
SQLite’s homepage scored 95 in a mobile Lighthouse run. In the same PageSpeed Insights report, its real-user loading metric missed the Core Web Vitals threshold. Before changing the hero image or removing scripts, check which number describes the problem your visitors are having.
Start with the mobile field result for the page you care about. LCP tells you how soon the main content appears. INP tells you how quickly the page responds to interactions. CLS tells you how much the layout moves unexpectedly. Each sends you to a different part of the page.
LCP vs. INP vs. CLS at a glance
| Metric | What the visitor experiences | Good field value | First check |
|---|---|---|---|
| LCP (Largest Contentful Paint) | The main image or text takes too long to appear | 2.5 seconds or less | Find the LCP element and check when its resource starts loading |
| INP (Interaction to Next Paint) | A tap, click, or key press takes too long to get visible feedback | 200 milliseconds or less | Record the slow action in Chrome DevTools |
| CLS (Cumulative Layout Shift) | Content moves unexpectedly while the visitor reads or uses the page | 0.1 or less | Find the shift in a trace and check what pushed the content |
Google checks the 75th percentile for each metric and reports mobile and desktop separately. PageSpeed Insights uses a rolling 28-day window for field data from the Chrome UX Report, or CrUX. In a report with sufficient data for all three metrics, each one needs to meet its good threshold for the assessment to pass. Google can assess LCP and CLS when INP has insufficient data. Google’s Web Vitals guide · How PageSpeed Insights uses CrUX
Why a green Lighthouse score can still come with a failed assessment
PageSpeed Insights puts two measurements on one screen. The field section summarizes visits from eligible Chrome users, with their actual devices, networks, and interactions. The Lighthouse section shows a simulated page load under a defined test setup. You can rerun the lab test after a change and inspect its trace to see what happened. Google’s PageSpeed Insights documentation
SQLite scored 95 and missed the mobile LCP threshold
On November 13, 2026 at 04:51 UTC, we ran the SQLite homepage through the PageSpeed Insights API with the mobile strategy. Lighthouse 13.6.0 reported a performance score of 95. The same response contained Chrome UX Report data for the exact homepage URL. These are the results from that run. Rerun the SQLite homepage in PageSpeed Insights
| Part of the report | Result | What to take from it |
|---|---|---|
| Lighthouse Performance | 95 out of 100 | The simulated mobile load earned a green overall score |
| Lighthouse LCP | 1.20 seconds | The main content appeared within the good LCP threshold in that run |
| Mobile field LCP | 2.59 seconds | The 75th percentile missed the 2.5-second good threshold |
| Mobile field INP | 68 milliseconds | Responsiveness met the good threshold |
| Mobile field CLS | 0.00 | Visual stability met the good threshold |
LCP was the metric that kept the homepage from passing. The same report showed an origin-level LCP of 2.03 seconds. If you switch to the Origin tab, you’re looking at visits across the site, and you can miss the homepage issue.
The first thing I’d check is the initial document request. The field report put the homepage’s time to first byte at 1.90 seconds at the 75th percentile, and the lab report identified a paragraph as the LCP element. Record a mobile load in DevTools and inspect the document timing and the LCP event. If the response is consistently slow, check redirects and cache behavior. If the response arrives quickly and the text still appears late, look for render-blocking resources. Field TTFB and field LCP are separate percentile measurements. Use the trace to find the delay in a single visit. Google’s LCP optimization guide
Which Core Web Vital should you fix first?
Start with a page people use to do something important. That could be a pricing page, a checkout, or a landing page that brings in most of your signups. In PageSpeed Insights, select Mobile and check whether the field data is for This URL or Origin. If you see origin data, use it to pick pages to investigate and check the affected URL groups in Search Console. Search Console’s Core Web Vitals report
If LCP is high, check when the main content appears
Record a load and find the LCP element. If it’s an image and the request starts late, check whether the browser can find it in the initial HTML and whether it’s being lazy-loaded. If the document itself takes a long time to arrive, investigate the response first. The same LCP value can come from either problem. Our walkthrough for diagnosing slow LCP
If INP is high, repeat the action a visitor takes
Try opening the menu, switching a pricing tab, or typing into a form. Record the action in the Performance panel. Check whether the browser was busy before it could handle the input, whether the handler did too much work, or whether rendering delayed the next frame. A standard Lighthouse navigation run gives you Total Blocking Time as a lab clue. To diagnose the slow tap, record the tap. Google’s INP optimization guide
If CLS is high, watch what moves during the visit
Record the page as you load it and scroll through it. Check the layout shifts in DevTools. If a banner or embed appears above content and pushes it down, reserve the space before it loads. For images and video, check whether their size or aspect ratio is set early enough for the browser to lay out the page. Google’s CLS optimization guide
If two metrics miss their thresholds, fix the issue that repeatedly gets in the way of the page’s main action. A pricing toggle that responds late and a small layout shift near the footer both deserve a look. I’d start with the toggle if it keeps buyers from comparing plans.
How to check whether the fix worked
- Save the affected URL, device type, field metric, and the trace showing the problem.
- Change one thing, then repeat the same lab test or interaction under the same conditions. Compare the metric and the trace so you can see what changed.
- Watch the same URL or URL group in field data as post-release visits enter the 28-day window. The field report will still contain some visits from before the fix.
If you’re comparing two versions of a page, keep the viewport, test setup, and interaction the same. Our website performance comparison guide
Common questions
Why do Core Web Vitals fail when my PageSpeed score is green?
The Lighthouse Performance score comes from a simulated load. The Core Web Vitals assessment uses real-user field data where it’s available. Check the mobile field panel for the metric that misses its threshold and confirm whether the report describes your exact URL or the whole origin.
Which Core Web Vital should I fix first?
Start with a metric that misses its good threshold on a page that matters to your business. Reproduce the issue so you can choose a fix tied to what users see. Check load timing for LCP, record the slow interaction for INP, or identify what moved for CLS.
What does no Core Web Vitals data mean?
CrUX may have insufficient eligible visits for a page or origin to show field results. You can still use a lab trace to diagnose a problem and, if you own the page, collect your own real-user measurements. Treat the field status as unknown until you have enough data.
Run your own public presence audit
See how your website, search footprint, AI visibility, social proof, and conversion trust look from the outside.