Calculator
Core Web Vitals budget calculator
Largest Contentful Paint is the sum of four phases and Interaction to Next Paint of three. Enter what you measured for each phase and see where the budget goes.
Budget
Calculate your Core Web Vitals budget
Adjust the four phases of LCP and the three phases of INP to see where the budget is being spent, then change one phase at a time to see what moves the total.
Estimated LCP
Largest Contentful Paint
Good
Good up to 2,500 ms · poor above 4,000 ms (the two marks)
Estimated INP
Interaction to Next Paint
Good
Good up to 200 ms · poor above 500 ms (the two marks)
Use the estimate to choose what to profile next, then check the change with lab traces and 75th-percentile field data. It is a planning aid, not a CrUX score or a performance guarantee.
Worked example
Worked example: a slow WooCommerce product page
This illustrative Core Web Vitals budget shows how the calculator turns a slow WooCommerce product page into smaller timing problems. LCP is the sum of time to first byte, resource load delay, resource load duration, and element render delay. The calculator rates LCP Good at 2,500 ms or less, Needs improvement up to 4,000 ms, and Poor above.
LCP breakdown
| Phase | Before | After |
|---|---|---|
| Time to first byte | 1,200 ms | 500 ms |
| Resource load delay | 650 ms | 100 ms |
| Resource load duration | 1,450 ms | 800 ms |
| Element render delay | 350 ms | 350 ms |
| Total | 3,650 ms, Needs improvement | 1,750 ms, Good |
Read the rows as a budget rather than one opaque LCP number. Here, a page cache cuts time to first byte by 700 ms. Making the product image load with priority instead of lazily cuts resource load delay by 550 ms. A correctly sized, modern-format image cuts resource load duration by 650 ms. Element render delay stays at 350 ms, so it is not part of this modeled gain.
Start with the large phases where you have a clear cause and a meaningful reduction, then measure again. For the two image phases, use the WordPress LCP image article. web.dev's LCP optimization guidance (opens in a new tab) gives a well-optimized-page guideline of roughly 40% time to first byte, under 10% resource load delay, roughly 40% resource load duration, and under 10% element render delay. These proportions are guidelines, not fixed targets.
INP budget example
INP is input delay + processing duration + presentation delay. The calculator rates it Good at 200 ms or less, Needs improvement up to 500 ms, and Poor above.
| Phase | Before | After |
|---|---|---|
| Input delay | 90 ms | 40 ms |
| Processing duration | 260 ms | 110 ms |
| Presentation delay | 70 ms | 40 ms |
| Total | 420 ms, Needs improvement | 190 ms, Good |
Processing duration is the first target because 260 ms is the largest phase. Splitting the long click handler brings processing to 110 ms and the total to 270 ms, still Needs improvement. Reducing input delay to 40 ms and presentation delay to 40 ms then gives 190 ms, rated Good.
Use real measurements
Use the Chrome DevTools Performance panel (opens in a new tab) to inspect local LCP and interaction phase breakdowns. PageSpeed Insights can provide field data where available, so you can compare a controlled trace with what real visitors see.
The calculator models a budget. Field data from real visitors decides the Core Web Vitals result.
How LCP and INP phases add up
- LCP = time to first byte + resource load delay + resource load duration + element render delay.
- INP = input delay + processing duration + presentation delay.
Chrome DevTools shows both breakdowns in the Performance panel, so the numbers can come straight from a trace. Time to first byte is often the first phase worth measuring: how to reduce WordPress TTFB walks through finding where it goes.
Get help with a slow LCP or INP phase
Tell me which phase is spending the budget and on which pages, and I will say what I would look at first.