Core Web Vitals Checker
Check your Core Web Vitals free — LCP, INP and CLS from real Chrome users plus a Lighthouse performance score and top fixes, powered by Google's API.
About the Core Web Vitals Checker
This free Core Web Vitals checker runs any public URL through Google's own PageSpeed Insights API and reports the three metrics Google uses as ranking signals: Largest Contentful Paint (loading), Interaction to Next Paint (responsiveness) and Cumulative Layout Shift (visual stability). Each metric is colour-coded against Google's official thresholds — for example, LCP is Good under 2.5 seconds and Poor above 4 seconds.
When your page has enough Chrome traffic, the cards show field data from the Chrome User Experience Report (CrUX) — the 75th-percentile experience of real visitors over the last 28 days, which is exactly the data Google's ranking systems use. Pages without CrUX coverage fall back to Lighthouse lab estimates for LCP and CLS; INP exists only in field data because it requires real user interactions.
Core Web Vitals are part of Google's page experience signals: they rarely make a bad page outrank a great one, but among comparable results, the faster, stabler page wins — and the conversion-rate impact of speed is even better documented than the ranking impact. Run the check for mobile first (most traffic and the stricter test), then use the top opportunities list to prioritise fixes. Each test takes 20–40 seconds because Lighthouse loads your page live on Google's servers.
How to Use the Core Web Vitals Checker
- 1Enter the full URL of a public page (localhost and login-protected pages can't be tested).
- 2Choose mobile or desktop — mobile is what Google primarily indexes.
- 3Click Check Core Web Vitals and wait 20–40 seconds while Lighthouse runs.
- 4Read the LCP, INP and CLS cards and work through the top opportunities list.
Frequently Asked Questions
What is a good LCP score?
Under 2.5 seconds is Good, 2.5–4 seconds Needs Improvement, and over 4 seconds Poor — measured at the 75th percentile of real visits. LCP marks when the largest visible element (usually a hero image or heading) finishes rendering. The most common fixes are compressing and preloading the hero image, faster server response (TTFB), and removing render-blocking CSS and JavaScript.
What is INP and why does it replace FID?
Interaction to Next Paint measures how quickly the page visibly responds when users click, tap or type — Good is 200 ms or less, Poor is over 500 ms. It replaced First Input Delay in March 2024 because FID only measured the first interaction's queuing delay, letting janky pages score well. INP considers all interactions across the visit, so it reflects real responsiveness. It only exists as field data, since it needs real users interacting.
Why does my page show no field data?
Field data comes from the Chrome User Experience Report, which only publishes metrics for pages and origins with enough Chrome traffic to be statistically meaningful. Newer or low-traffic pages simply aren't in the dataset. In that case this tool shows Lighthouse lab estimates for LCP and CLS — useful for debugging, though your real users' experience may differ with their devices and networks.
Do Core Web Vitals really affect Google rankings?
Yes, as one signal among many. Google confirms page experience — with Core Web Vitals at its heart — is used in ranking, most visibly as a tiebreaker between pages of similar relevance. Content relevance still dominates. The stronger business case is user behaviour: faster, stabler pages measurably reduce bounce and increase conversions, which is worth more than the ranking nudge.
What is a good CLS score and what causes layout shift?
CLS of 0.1 or less is Good; above 0.25 is Poor. Layout shift happens when content moves after initial render: images without width/height attributes, late-loading ads and embeds, web fonts swapping in at a different size, or banners injected at the top of the page. The fix is always to reserve the space in advance — explicit dimensions, min-height on ad slots, and font-display strategies.
Why do mobile and desktop scores differ so much?
The mobile test simulates a mid-range phone on a slow 4G connection, while desktop assumes far more CPU and bandwidth — so mobile scores are always harsher. Since Google indexes and ranks the mobile version of your site, treat the mobile result as the one that counts and the desktop score as a bonus.