Core Web Vitals Scanner

How this check works

Scanaris does not make up performance numbers: it asks PageSpeed Insights, Google's service that runs Lighthouse, to measure your page in mobile mode and reads the result. From it, it takes the 0 to 100 score and three metrics: LCP (Largest Contentful Paint, how long the largest visible element takes to paint), CLS (Cumulative Layout Shift, how much the page "jumps" while loading) and TBT (Total Blocking Time, how long JavaScript blocks the main thread). The score is stored in an informational finding that costs nothing and feeds the performance pillar's grade. It only opens findings with a severity when a metric falls into the range Google calls "poor": LCP above 4 seconds (medium), CLS above 0.25 (low) or TBT above 600 milliseconds (low). If Lighthouse returns no score (page not measurable, tool error), there is no finding.

Why it matters

Performance is user experience and it is SEO. Google has used Core Web Vitals as a ranking signal since 2021, and it measures those of your real users in Chrome, not just lab ones. But the most direct effect is on the business: every extra second of load time on mobile reduces conversions measurably, and an LCP of 5 seconds means a good share of your visitors see a blank screen long enough to leave. The metrics are measured on mobile because that is where most sites perform worst and where Google indexes first.

How to fix it

High LCP

• The hero image is usually the LCP element. Serve it as WebP or AVIF, at the displayed size rather than the original, with fetchpriority="high" and without loading="lazy". In Nuxt and Next.js, the image components (NuxtImg, next/image) do this for you.
• Server response time adds to everything else. Page caching, a CDN in front and, on WordPress, a properly configured cache plugin.
• Render-blocking CSS and JavaScript: inline the critical CSS and load the rest afterwards; third-party scripts with defer or async.
• Web fonts: font-display: swap, preload the main font and, if you can, self-host them instead of loading from Google Fonts.

High CLS

Almost always images without width and height, ads or embeds that pop in, and fonts that change size on load. Declare the dimensions of every image and iframe, reserve space for dynamic blocks with min-height, and never insert content above what the user is already reading.

High TBT

Too much JavaScript running at startup. Split the bundle by route, load heavy components only when needed, delay analytics and chat scripts until after interaction, and review library weight: outdated libraries and a full copy of jQuery for one menu are the typical cases.

Check it is fixed

npx lighthouse https://yourdomain.com --only-categories=performance --preset=perf --form-factor=mobile --screenEmulation.mobile --view

Or paste the URL into PageSpeed Insights, which besides the lab measurement shows real-user data from the last 28 days. Target: LCP under 2.5 s, CLS under 0.1 and TBT under 200 ms. Measure several times: lab results vary a little between runs.

Frequently asked questions

My site loads fast on my computer. Why does it score badly?

Because the measurement simulates a mid-range phone on a slow 4G connection, which is what a large share of your visitors use. Your laptop on fibre is not the representative case.

Does a 100 performance score help SEO more than a 90?

Not noticeably. Google distinguishes "good", "needs improvement" and "poor" per metric; once you are in "good", the rest is user experience, not ranking. Focus on getting out of the red, not on chasing 100.

Does this check measure all my pages?

Only the scanned URL. If your product page or your blog have different problems, scan them separately. The other checks in this pillar, such as accessibility, also work on the specific page.