Core Web Vitals checker

The tool loads the page once in Lighthouse, the open-source lab tool inside Chrome, on a simulated mid-range phone over a throttled 4G connection. It reads four timings and one weight: Largest Contentful Paint (when the biggest element in the viewport appears), Cumulative Layout Shift (how much the page moves after it appears), Total Blocking Time (how long the main thread is busy with JavaScript between the first paint and the page becoming usable), First Contentful Paint (the first text or image), and the total bytes the page loads. It also returns Lighthouse's performance score out of 100, its three other scores, the changes it estimates would save the most time, and the audits that fail.

Each figure is judged against the thresholds web.dev publishes: LCP good up to 2.5 s and poor above 4 s, CLS good up to 0.1 and poor above 0.25, FCP good up to 1.8 s and poor above 3 s, and TBT good up to 200 ms in the lab. Interaction to Next Paint, the third Core Web Vital, cannot be measured without a user, so the lab stands in TBT for it.

Google ranks on field data: the 75th percentile of real Chrome visitors' loads over 28 days, per URL, at the Good thresholds. That data lives in Search Console's Core Web Vitals report and in PageSpeed Insights, and a page with too few visits has none. A lab run is the thing you can get for any page, now, on a phone you do not own, and it tells you what to change: the field data says whether the page passes, the lab run says why it does not.

The thresholds are not academic. A page whose largest element paints at 3.7 s on a phone is one a visitor on a train sees as blank, and a page that shifts as it loads is one where the first tap lands on the wrong thing. The ranking signal is smaller than relevance, and the visitor's patience is not.

• LCP is the figure to fix first. On yourproduct.com/pricing, an LCP of 3.9 s with a hero image as the largest element means the image is lazy-loaded, unsized, or discovered late; the savings table will usually name it.
• CLS above 0.1 means something moves: an image or embed without width and height, a cookie banner pushing content, a web font swapping. The fix is to reserve the space before the thing arrives.
• TBT above 200 ms means JavaScript is running before the page can respond. The savings table names the unused scripts; a third-party tag is often the largest.
• Page weight above 1.5 MB on a text page is a sign of unoptimised images or a bundle that ships everything.
• What would save the most time is Lighthouse's own estimate, in seconds, of each change. Take the top one.
• Audits that fail on accessibility, best practices and SEO are the same run read for other faults: a missing main landmark, a low-contrast button, links without descriptive text.

1. 1

   Measure the pages that sell

   The home page, the pricing page, one guide, one docs page. Each template has its own faults; the home page rarely stands for the rest.

2. 2

   Fix the largest element first

   Give the hero image explicit dimensions, fetchpriority="high" and no lazy loading; serve it in AVIF or WebP at the size the viewport needs; put it in the HTML rather than a CSS background or a script.

3. 3

   Reserve space for what arrives later

   Width and height on every image and iframe, a minimum height for banners and ad slots, a fallback font whose metrics match the web font.

4. 4

   Take the biggest saving from the table

   Unused JavaScript is usually a tag manager's contents, a chat widget or an analytics script loaded before it is needed. Load them after the page is interactive, or on the visitor's first action.

5. 5

   Run it again, then wait for the field data

   A second run confirms the change in the lab. The Core Web Vitals report in Search Console needs 28 days of real visits to agree.

One run, one simulated device, one place, once. The score is a lab figure and is not a ranking factor; the field data is. A page behind a login, a bot check or a cookie wall cannot be loaded. A run takes twenty to forty seconds. The tool is limited to five runs an hour from one address and two hundred a day in all, because each run is paid for on your behalf; when the day's budget is spent, it says so and the free check on the home page still works.

Each run is a Lighthouse run that costs a few cents at a provider, so the tool runs for a signed-in account only: a free account, no card, five paid checks a day and forty a month across the paid tools, counted per account. The same input asked twice in a day is answered from memory and is not counted. The free check on the home page is not counted either. A day's budget for the tool as a whole is capped as well, so a busy day ends with a plain message rather than a bill.