lintpage
~/tools/core-web-vitals-checker

Core Web Vitals Checker

Catch the page-level issues that wreck your Core Web Vitals — slow TTFB, lazy-loaded hero images, render-blocking scripts, and layout shift — before they cost you rankings.

§ what this tool checks

Rules applied to every scan.

Core Web Vitals are a confirmed Google ranking factor, but the field scores you see in Search Console are downstream of fixable, page-level mistakes. This tool measures your server's time to first byte and inspects the HTML for the patterns that wreck LCP and CLS — lazy-loaded hero images, render-blocking scripts, and images without dimensions — so you can fix the causes instead of guessing at the symptoms.

Time to First Byte (TTFB) measured live
Above-the-fold (LCP) images that are lazy-loaded
Render-blocking scripts and stylesheets in the <head>
Images missing width/height that cause layout shift (CLS)
Below-the-fold images missing loading="lazy"
Excessive external scripts slowing the page
§ faq

Questions, answered.

What are Core Web Vitals?
Core Web Vitals are three user-experience metrics Google uses as ranking signals: Largest Contentful Paint (LCP) measures loading speed, Cumulative Layout Shift (CLS) measures visual stability, and Interaction to Next Paint (INP) measures responsiveness. Google considers a page "good" when LCP is under 2.5s, CLS is under 0.1, and INP is under 200ms.
Why does this tool show lab signals instead of a field score?
Google's official Core Web Vitals scores come from real-user (field) data collected over 28 days in the Chrome UX Report — they can't be measured in a single request. What this tool does is inspect the page-level causes of poor vitals: a lazy-loaded hero image, render-blocking scripts, missing image dimensions, and a slow TTFB. Fix these and your field scores follow.
How does TTFB relate to Core Web Vitals?
Time to First Byte is how long your server takes to start responding. It is not a Core Web Vital itself, but it is the foundation of LCP — every millisecond of slow server response is a millisecond your largest element cannot start painting. web.dev considers TTFB good at 800ms or under. A slow TTFB caps how fast your LCP can ever be, no matter how optimized the front end is.
What is the most common Core Web Vitals mistake?
Lazy-loading the hero image. Developers add loading="lazy" to every image for performance, but the largest above-the-fold image is almost always the LCP element — deferring it directly delays LCP. The fix is to never lazy-load above-the-fold images and to add fetchpriority="high" to the LCP image instead. Missing width/height attributes (causing layout shift) is a close second.
§ run the full audit

Stop guessing. Scan everything in one click.

60 automated checks across meta tags, robots.txt, Open Graph, sitemaps, headings, AI visibility, and more — free, no signup.

run a full scan →