Core Web Vitals Calculator

Core Web Vitals are Google’s measurements of how a page feels to a real visitor: how quickly the main content appears, how fast the page reacts to taps and clicks, and how stable the layout is while loading. Tools such as PageSpeed Insights report them next to a 0 to 100 Lighthouse score, and the two are often confused. This calculator rates your numbers against the official thresholds and shows how the Lighthouse score is made.

The three metrics

Largest Contentful Paint (LCP) is the time until the biggest visible element, usually a hero image or a heading, has rendered. Interaction to Next Paint (INP) replaced First Input Delay in March 2024 and measures the delay between interactions such as clicks, taps and key presses and the next frame being drawn, using roughly the slowest interaction during the visit. Cumulative Layout Shift (CLS) adds up unexpected movements of visible content.

Thresholds and the 75th percentile

For each metric Google defines three bands. LCP is good up to 2.5 seconds and poor above 4. INP is good up to 200 milliseconds and poor above 500. CLS is good up to 0.1 and poor above 0.25. A page passes the Core Web Vitals assessment only when the 75th percentile of real page loads is in the good band for all three, meaning at least three quarters of visits must be good, not just the average.

Diagnostic metrics

First Contentful Paint (FCP) is when the first text or image appears, good up to 1.8 seconds, and Time to First Byte (TTFB) is how long the server takes to start responding, good up to 800 milliseconds. They are not Core Web Vitals, but a slow TTFB or FCP makes a good LCP almost impossible, so the calculator rates them on the same scale and labels them as diagnostics.

How the Lighthouse score is built

Lighthouse runs a simulated load and measures five lab metrics: FCP, Speed Index, LCP, Total Blocking Time (TBT) and CLS. Each is converted to a 0 to 100 score on a log-normal curve fixed by two reference values: the “p10” value scores 90 and the median value scores 50. The five scores are combined with weights of 10, 10, 25, 30 and 25 percent. The mobile reference values are built in, so the estimate matches a mobile run; desktop runs use different curves.

A worked example

The Sample enters LCP 2.8 s, INP 180 ms, CLS 0.08, FCP 1.6 s and TTFB 650 ms. INP and CLS are good, but LCP is in the needs-improvement band, so the assessment shows Failed. With Speed Index 3,400 ms and TBT 280 ms, the Lighthouse estimate is 87: FCP scores 94, Speed Index 90, LCP 83, TBT 81 and CLS 94. TBT carries the largest weight, so cutting JavaScript work would raise the score more than shaving the images.

Lab data and field data

Lab data comes from one controlled run and is repeatable, which makes it good for debugging. Field data comes from real visitors, through the Chrome UX Report, and is what Google uses for the assessment, so it includes the slow devices and flaky networks that a lab run does not. Use the lab to find causes and the field to confirm that a fix worked.

Improving each metric

For LCP, serve the main image in a modern format, preload it and cut server response time. For INP, break up long tasks and avoid heavy work in event handlers. For CLS, reserve space with width and height attributes on images, embeds and ads, and avoid inserting content above what the visitor is reading.

Related tools

• Page Weight Calculator turns bytes into a budget and download time.
• HAR Analyzer shows which requests delay the main content.
• Image Compressor reduces the images that usually set LCP.
• Code Minifier trims script size that adds blocking time.