# Core Web Vitals checker

One Lighthouse run on a simulated phone over a slow connection: the largest paint, the layout shifts, the blocked main thread, the page's weight, and the three changes that would save the most time, each judged against the thresholds Google publishes.

Updated 2026-09-14 · Source: https://porteur.ai/tools/core-web-vitals-checker

## What it measures

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.

## Why a lab run is worth having

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.

> Scores move between runs. A difference of five points is noise; a metric crossing a threshold is not.

## How to read the result

- **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.

## What to do with it

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. **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. **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. **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. **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.

## Limits

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.

## Questions

### Is this the same as PageSpeed Insights?

The lab half of it. PageSpeed Insights also shows field data from real Chrome visitors when a page has enough traffic; this tool runs Lighthouse only, so it can measure any public page, including ones with no traffic yet.

### What is a good Lighthouse performance score?

Lighthouse colours 90 and above green, 50 to 89 orange, under 50 red. The score is a weighted sum of the metrics and moves between runs; the metrics against their thresholds are the figures to act on.

### Why does my page score well here and fail in Search Console?

The lab loads the page from one place on one simulated phone; Search Console reads the slowest quarter of real visits, on real devices and connections, over 28 days. A page that is fast on the lab's device can still be slow for a visitor on an old phone in a distant country.

### Does this measure Interaction to Next Paint?

No lab tool can: INP needs a real visitor to tap and type. Total Blocking Time is the lab's stand-in; a page with a high TBT usually has a poor INP in the field.

### Why does the score change when I run it twice?

Network and server timing vary, and the simulation runs once. Treat a difference of a few points as noise and look at whether a metric crossed a threshold.

## Read next

- [Core Web Vitals for a product site: the three numbers](https://porteur.ai/guides/core-web-vitals): The product founder’s guide to LCP, CLS and INP: what Google measures, why phones decide the pass, common causes, and how to test and fix.
- [Largest Contentful Paint: what slows it and what fixes it](https://porteur.ai/guides/largest-contentful-paint): See what usually counts as LCP, what makes it slow, how to fix it in order, and how to read it in Lighthouse and field data.
- [How to fix cumulative layout shift, cause by cause](https://porteur.ai/guides/how-to-fix-cumulative-layout-shift): See how CLS is measured, find the shifting elements, fix each common cause, and check field data after 28 days to confirm it worked.
- [Total Blocking Time: the lab number that stands in for INP](https://porteur.ai/guides/total-blocking-time): What Total Blocking Time measures in Lighthouse, why it weighs 30 percent, how it relates to INP, and the fixes that cut it fast.
- [How to read PageSpeed Insights: field data first, then the score](https://porteur.ai/guides/how-to-read-pagespeed-insights): Start with field data, not the score. Learn what Google uses, why scores vary, and how to turn a PageSpeed Insights run into a clear order of fixes.
- [The Core Web Vitals report in Search Console, page group by page group](https://porteur.ai/guides/search-console-core-web-vitals-report): Understand where the Core Web Vitals data comes from, how page groups work, what to fix by template, and how to move groups to Good.
- [Interaction to Next Paint (INP)](https://porteur.ai/glossary/interaction-to-next-paint): INP is the delay from tap to next paint, good up to 200 ms; learn how to measure it, read field versus lab data, and fix script delays.
- [Time to first byte: the delay every other metric inherits](https://porteur.ai/guides/time-to-first-byte): TTFB sets the pace for every other speed metric. See what it includes, how to test it in field and lab, the causes on product sites, and the fixes.

One page here; the free check measures the home page on a phone as part of reading the whole site, the searches around it and the rivals on them. Free check: https://porteur.ai/