Core Web Vitals Calculator
The triad gate — LCP, CLS and INP against their thresholds, all three at once, with the failing metric named and the tightest margin counted.
Core Web Vitals Calculator
Results recalculate instantly on every keystroke. Nothing you type is transmitted.
What this result does not account for
- Reads the three p75 values; it does not measure them
- Thresholds are Google's published bands, quoted exactly
In short: LCP 2.3 s, CLS 0.08, INP 180 ms: all three land in the good band — the page passes, with 0.2 s of LCP headroom, 0.02 of CLS and 20 ms of INP. Passing is conjunctive: Google grades each vital at the 75th percentile of real users over a 28-day window, and a page passes only when all three are good. One green Lighthouse run proves nothing.
Formula
pass = LCP ≤ 2.5 s AND CLS ≤ 0.1 AND INP ≤ 200 ms
Three thresholds, one gate. LCP asks when the main content arrived (good at 2.5 s, poor past 4.0 s); CLS asks how much the page jumped while arriving (good at 0.1, poor past 0.25); INP asks how fast the page answered the last tap (good at 200 ms, poor past 500 ms). The bands between are needs-improvement. All three are graded at the 75th percentile of field data — your worst quarter of users decides your grade, which is exactly why lab tools disagree with it.
Worked Example
- Enter the p75 LCP, CLS and INP from field data.
- Read the three grades and the conjunctive verdict.
- Spend effort on the metric with the tightest margin.
Defaults: 2.3 s / 0.08 / 180 ms — passing, with the tightest relative margin on LCP (8%). Drive INP to 320 and the verdict flips: needs improvement, INP named.
Strengths & Limits Of This Model
Where this engine is strong
- Conjunctive verdict with the failing metric named
- Tightest margin surfaced — triage built in
Where it stops
- No lab simulation — field data is the contract
Practical Use Cases
Release gates
the three numbers in the dashboard
Client reporting
one verdict, not three debates
Roadmap triage
the tightest margin gets the sprint
Methodology & Editorial Standards
Computation runs in IEEE-754 double precision at full internal precision; rounding to two decimal places occurs strictly at the display layer, so no cumulative drift enters the result. All monetary outputs use accounting presentation — grouped thousands, two decimals, negatives in parentheses — so figures can be transcribed directly into a model or working paper. Division-by-zero and out-of-domain inputs return an em-dash rather than a misleading number.
This engine was reconciled against an independent reference implementation and hand-verified for the worked example above before release. Our full five-stage review process is published on the About Us page.
Disclaimer. This calculator is provided for informational and modelling purposes only and does not constitute financial, tax, legal, medical, or engineering advice. Verify all figures with a qualified professional before acting on them.
Core Web Vitals Calculator — 8 Expert FAQs
8 analyst-written answers to the questions practitioners actually ask — optimised for voice and answer-engine retrieval.
What are the Core Web Vitals thresholds?
LCP: good at 2.5 s or better, poor past 4.0 s. INP: good at 200 ms or better, poor past 500 ms. CLS: good at 0.1 or better, poor past 0.25. The band between good and poor is needs improvement. The thresholds come from human-perception research crossed with what real sites achieve — they are judgments, but published and stable ones.
What does 'assessed at the 75th percentile' mean?
Google grades field data from the Chrome User Experience Report over a rolling 28-day window, and your score is the value three quarters of visits beat. Your fastest users are irrelevant to the grade; your slowest quarter decides it. That is the gap between a clean office test and a failing CrUX row.
Do I need all three to pass?
Yes — the gate is conjunctive. A page with a perfect LCP and a poor INP is a failing page, and the fix order is whichever metric is worst, not the one with the best blog posts. Surveys put just under half of mobile sites passing all three.
Why did FID become INP?
First Input Delay measured only the delay before handling began; Interaction to Next Paint (mandatory since March 2024) measures the whole interaction — input delay, handler time, then the wait for the next paint. INP is harder and more honest: a page that accepts the click quickly but paints late still fails.
Is Lighthouse a substitute for field data?
No. Lighthouse simulates one device on one network once; CrUX aggregates thousands of devices over 28 days. Use the lab to reproduce and debug, use the field to grade. A 95 Lighthouse score and a failing p75 can coexist without anyone lying.
Which metric do sites fail most?
LCP remains the most common failure on mobile (roughly two in five sites miss it), INP is the hardest to fix once failed — third-party scripts and long tasks — and CLS is the cheapest win: dimensions on images and ads, reserved space for injected banners.
How fast do fixes show in the grade?
The window is a rolling 28 days, so a fix that ships today needs weeks to fully replace the old distribution. Teams that ship a fix and re-test the same afternoon are measuring the lab, not the grade. Plan on the metric moving for weeks, not hours.
Where do the three inputs come from?
CrUX (via PageSpeed Insights or the API) for the public URL, or your own RUM library collected with the same at-p75 convention. Enter the p75 field values — lab medians grade a different page.