Core Web Vitals Test

What it does

• Runs a real Google Lighthouse audit on any public URL and returns all four category scores: performance, accessibility, best practices, and SEO.
• Reports the lab Core Web Vitals and their supporting metrics (Largest Contentful Paint, Cumulative Layout Shift, Total Blocking Time, First Contentful Paint, Speed Index, Time to Interactive, and Time to First Byte), each rated good, needs improvement, or poor against Google's published thresholds.
• Pulls real-user field data from the Chrome User Experience Report when your page has enough Chrome traffic to qualify, including Interaction to Next Paint, which no lab test can measure.
• Gives a straight pass or fail verdict on Core Web Vitals, gated on LCP and CLS: the two ranked vitals a lab run can measure honestly. FCP is diagnostic and TBT is only a stand-in for INP, so neither one decides the pass.
• Blends the four Lighthouse categories into one 0-100 score, weighted performance 55%, SEO 20%, accessibility 15%, and best practices 10%, then turns it into a letter grade (A at 90+, B at 80+, C at 70+, D at 50+, F below 50).
• Sorts the performance opportunities by estimated milliseconds and bytes saved, so the fix at the top of the list is the one worth doing first.
• Counts every failing audit and diagnostic across all four categories, not just performance, because a fast page that fails accessibility is not a clean bill of health.
• Tests on a throttled mobile profile by default to match Google's mobile-first index, with desktop available as a separate run.

How it works

1. Paste any public URL. We normalize it first (add the scheme, strip the noise, follow the redirect) so the report describes the page that actually loads.
2. We send the page to Google PageSpeed Insights first. It is free, it runs the same Lighthouse engine, and it is the only backend that returns real-user CrUX field data alongside the lab run.
3. If PageSpeed Insights is unreachable or out of quota, we fall back to a hosted Lighthouse runner. That backend is lab-only, so the report says plainly that no field data is available instead of passing lab timings off as real-user numbers. If Chrome could not load the page at all, we stop there: a second Chrome will not load it either.
4. Chrome loads your page, records the lab timings, and scores the accessibility, best-practices, and SEO audits alongside performance.
5. We normalize both backends into one report shape, rate every metric against Google's thresholds, blend the categories into a single score and grade, and rank the opportunities by estimated savings.
6. You see the scores, the vitals, the pass or fail verdict, and the top opportunities right away. Add an email to unlock the full itemized opportunity, failing-audit, and diagnostic lists plus the real-user field data.

Why use a core web vitals test?

Core Web Vitals are the part of page experience Google actually publishes numbers for. Google says outright that Core Web Vitals are used by its ranking systems, while also being clear that there is no single page-experience signal and that a perfect score does not guarantee a top position. The honest reading is the useful one: relevance still wins, but when several pages answer a query equally well, the one that loads fast and does not jump around under the reader's thumb has an edge. That edge is measurable, and unlike most SEO advice it comes with published pass marks. Largest Contentful Paint should land at 2.5 seconds or less, Cumulative Layout Shift at 0.1 or less, and Interaction to Next Paint at 200 milliseconds or less, all assessed at the 75th percentile of real page loads and split between mobile and desktop.

The reason to run a Core Web Vitals test rather than guess is that the three vitals fail for completely different reasons and reward completely different fixes. A slow LCP is usually a server, discovery, or image-weight problem. A bad CLS is a layout problem: an image with no dimensions, an ad slot with no reserved height, a font swap that reflows a paragraph. A poor INP is a JavaScript problem, main-thread work blocking the browser from painting the next frame. Reading one blended "speed score" tells you none of that. A proper Lighthouse report does, which is why our checker surfaces each metric with its own rating instead of hiding them behind a single number. The blended score exists to give you a headline and a grade to track over time, not to replace the diagnosis underneath it.

The other thing worth understanding before you optimize anything is lab versus field. A Lighthouse run is a lab test: one simulated load, on a throttled connection, from one location, with no real user in it. That is what makes it repeatable and what makes it useful for debugging. Field data from the Chrome User Experience Report is what Google's ranking systems consume, aggregated from real Chrome visitors whose devices, networks, and behaviour you do not control. Lab data is the diagnosis and field data is the verdict, and they will disagree. A page can score 95 in the lab and still fail its vitals in the field because half its audience is on a mid-range Android phone on a bad connection. Field data also has an eligibility bar: a page or origin needs to be publicly discoverable and get enough visitors to form a statistically significant sample, so new and low-traffic pages come back lab-only. That is not a bug in the tool, it is a real limit of the dataset, and pretending otherwise is how people end up optimizing for a number nobody is measuring them on. Use the lab run to find and fix the cause, then watch the field data to confirm the fix reached actual users.

Best practices

• Test mobile first. Google's index is mobile-first and mobile is where throttled CPU and slow networks expose problems that never show up on your laptop.
• Run the same URL two or three times before you believe a number. Lighthouse scores move between runs for reasons that have nothing to do with your code (A/B tests, traffic routing, browser extensions, antivirus), so treat performance as a distribution rather than a single reading.
• Diagnose in the lab, confirm in the field. If the two disagree, the field data is the one Google's ranking systems see, and the lab run is your best tool for working out why.
• Break a slow LCP into its four phases before touching anything: Time to First Byte, resource load delay, resource load duration, and element render delay. Google's own budget guidance puts roughly 40% on TTFB and 40% on resource load duration, with under 10% each for the two delay phases, which tells you immediately whether you have a server problem or an image problem.
• Make the LCP image discoverable and prioritized: put it in the initial HTML rather than injecting it with JavaScript, add a preload when it is only referenced from CSS, set fetchpriority="high", and never mark an above-the-fold image loading="lazy".
• Kill CLS by reserving space in advance. Set width and height (or an aspect-ratio) on every image, give ad slots and embeds a min-height, preload critical fonts and use a well-matched fallback so the swap does not reflow text, and animate transform instead of top, left, or box-shadow.
• Use Total Blocking Time as your INP proxy. A lab run has no user in it, so it cannot measure INP at all. TBT measures the main-thread blocking that causes bad INP, and our report rates it good at 200 ms or less and poor beyond 600 ms.
• When TBT is high, attack the three phases of an interaction: input delay (long tasks blocking the handler from starting), processing duration (work inside the handler), and presentation delay (the browser painting the result). Yielding to the main thread and shrinking the DOM address different phases, so measure before you pick.
• Do not chase a perfect Lighthouse score. The performance score is a weighted blend of TBT at 30%, LCP at 25%, CLS at 25%, FCP at 10%, and Speed Index at 10%, and Lighthouse treats 90 and above as good. Getting from 92 to 100 is usually worth less than fixing one failing accessibility audit.
• Read all four categories, not just performance. Our blended grade weights SEO at 20%, accessibility at 15%, and best practices at 10% precisely because a fast page with broken headings, missing alt text, or a blocked robots directive is still a page that underperforms in search.
• On WordPress, start with the plugin and theme layer before micro-optimizing images: render-blocking plugin CSS and JavaScript in the head is the usual reason a WordPress site's LCP and TBT are both bad, and the fastest win is often removing a plugin rather than caching around it.
• Change one thing at a time and re-test. Shipping five fixes in one deploy and watching the score move tells you the bundle worked, not which fix did, which makes the next regression much harder to find.