What the Core Web Vitals Budget Calculator does
This calculator turns the published Core Web Vitals thresholds - LCP 2.5 seconds, INP 200 milliseconds and CLS 0.1, each judged at the 75th percentile of real page loads - into a working budget, checks your measured p75 values against it, and shows which part of the page load has to get faster.
The LCP target is split into its four subparts using the proportions web.dev recommends, so a vague "make LCP faster" becomes a concrete number of milliseconds per phase. Everything is arithmetic in your browser; nothing you type is sent anywhere.
How to use it
- Pick the device segment. Google reports mobile and desktop separately, and mobile is usually the harder budget.
- Keep the default targets (the published good thresholds) or set stricter ones to leave a safety margin - for example LCP 2,000 ms.
- Enter your measured 75th-percentile LCP, INP and CLS and say whether they come from real users (CrUX, your RUM tool) or from a single lab run.
- Optionally open the LCP subparts section and enter the four phase timings from DevTools or the LCP Element Analyzer.
- Read the verdict, the headroom for each metric and the phase table: the phase with the largest positive "over" figure is where the time has to come from.
Reading the results
A metric is good when its p75 is at or below the good threshold, and poor when it is above the poor threshold (LCP 4 s, INP 500 ms, CLS 0.25). In between it needs improvement. A page passes the Core Web Vitals assessment only when all three are good.
Headroom is the target minus the measured value. Negative headroom is the amount you must remove, at the 75th percentile - improving the median is not enough if the slowest quarter of visits stays slow.
The LCP phase budget uses web.dev's guidance: roughly 40% TTFB, under 10% resource load delay, about 40% resource load duration and under 10% element render delay. A phase far over its share is the most promising place to work.
The INP split into input delay, processing and presentation is a convention, not a published standard. Use it to agree a working budget with your team, then adjust it.
Worked example: a mobile shop with a slow hero image
A retailer's mobile field data shows LCP 3,400 ms, INP 170 ms and CLS 0.06 at p75. INP and CLS are good; LCP is 900 ms over the 2,500 ms threshold and below the 4,000 ms poor line, so it needs improvement and the page does not pass.
With a 2,500 ms target the phase budgets are 1,000 ms TTFB (40%), 250 ms load delay (10%), 1,000 ms load duration (40%) and 250 ms render delay (10%). The measured subparts are 1,100, 900, 1,000 and 400 ms, which add up to the 3,400 ms LCP.
Load delay is 650 ms over budget - by far the largest gap. The browser is finding the hero image late, typically because it is lazy-loaded, set by script or referenced only in CSS. Fixing discovery alone would bring LCP to about 2,750 ms; trimming 150 ms of render-blocking CSS and 100 ms of server time closes the rest.
Formulas and scoring rules
- Rating
good if p75 <= good; poor if p75 > poor; otherwise needs improvementLCP 2,500 / 4,000 ms; INP 200 / 500 ms; CLS 0.1 / 0.25.- Headroom
headroom = target - measured_p75Negative means over target. Shown in ms (CLS to three decimals).- LCP phase budget
phase_budget = LCP_target x share (0.40, 0.10, 0.40, 0.10)Shares follow web.dev's Optimize LCP guidance; displayed to the nearest ms.- INP phase budget
phase_budget = INP_target x split (default 0.30, 0.40, 0.30)The split is an A2Z convention and must add up to 100%.- 75th percentile (nearest rank)
p75 = the value at rank ceil(0.75 x n) of n sorted samplesHow to compute p75 yourself from raw RUM samples.
Field data, lab data and why the difference decides the verdict
The assessment uses field data: what real visitors experienced, collected by Chrome (the Chrome UX Report) or by your own real-user monitoring. Lab tools such as Lighthouse run one load on one simulated device. They are excellent for debugging and useless as a verdict, because the 75th percentile of your audience may be on slower phones and networks than the test assumed.
INP in particular cannot be measured in a lab run with no user: it needs real interactions. Total Blocking Time is a lab proxy that correlates with INP but is not the same number. Choose "lab" in the evidence box when that is what you have, and the page will say what the numbers can and cannot tell you.
Limitations: what the result does not prove
- It checks numbers you provide; it does not measure your site. Use CrUX, PageSpeed Insights field data or your own RUM for p75 values.
- Subparts measured on one load, or p75 values of each subpart, rarely add up exactly to the p75 LCP. The phase comparison is indicative, not an exact decomposition.
- Thresholds are Google's current published values, checked on the review date shown on the page. If Google changes them, the file is updated; the page never fetches them live.
- Passing Core Web Vitals is one small signal among many. It does not guarantee rankings or conversions.
Privacy: where your data goes
Everything you paste, type or drop is processed in this browser tab. It is not uploaded, logged, stored or sent to analytics. Session recording and tag-manager scripts are switched off on this page.
Standards and sources
- web.dev - Web Vitals and thresholds - checked 19 Sep 2026
- web.dev - Optimize Largest Contentful Paint - checked 19 Sep 2026
- web.dev - Interaction to Next Paint - checked 19 Sep 2026
- web.dev - Cumulative Layout Shift - checked 19 Sep 2026
- web.dev - Defining the Core Web Vitals metrics thresholds
Frequently asked questions
What are the current Core Web Vitals thresholds?
Largest Contentful Paint is good at 2.5 seconds or less and poor above 4 seconds; Interaction to Next Paint is good at 200 ms or less and poor above 500 ms; Cumulative Layout Shift is good at 0.1 or less and poor above 0.25. Each is judged at the 75th percentile of page loads.
Why is the 75th percentile used instead of the average?
An average hides the slow visits that frustrate people. Requiring three in four page loads to be good means most visitors - including many on mid-range phones - get a good experience, while a few extreme outliers cannot fail the page on their own.
Do I need to pass on both mobile and desktop?
They are assessed separately, so a page can pass on desktop and fail on mobile. Budget each segment on its own; mobile usually needs the tighter LCP and INP plan because of slower CPUs and networks.
How should I split my LCP budget between phases?
web.dev suggests about 40% for TTFB, under 10% for resource load delay, about 40% for resource load duration and under 10% for element render delay. Time spent in the two delay phases, when nothing useful is downloading, is the easiest to remove.
Can a Lighthouse score tell me whether I pass Core Web Vitals?
No. Lighthouse is a lab test of one simulated load and does not measure INP. The pass or fail verdict comes from field data at the 75th percentile, which you can see in PageSpeed Insights or CrUX when your site has enough traffic.
Is a stricter target than the threshold worth setting?
Usually yes. Field p75 values move with traffic mix, releases and third-party scripts, so a page sitting at exactly 2.5 s will slip over it. A target around 2.0 s for LCP gives a margin that absorbs normal variation.
Last reviewed by the A2Z.Tools team against the sources listed above.
