LCP Calculator
Decompose the load — TTFB, load delay, load time and render delay, priced against the 2.5-second line.
LCP Calculator
Results recalculate instantly on every keystroke. Nothing you type is transmitted.
What this result does not account for
- Four-phase model — no waterfall or parallelism modeled
- Reads trace values; it does not capture them
In short: 600 + 400 + 900 + 300 = 2,200 ms of LCP — 2.2 s, good, with 300 ms of headroom to the 2.5 s line. The biggest slice is resource load time at 40.9%, so the bytes of the hero element are the lever; the phases before it are the origin's and the document's, and the phase after it belongs to the render queue. LCP is four waiting rooms in a row — this page prices each one.
Formula
LCP = TTFB + load delay + load time + render delay
The largest contentful paint is a relay of four phases. The server holds the first baton (TTFB); the document then has to notice the hero resource and start it (load delay — preload hints live here); the resource transfers (load time — formats and sizes live here); and finally the browser paints it (render delay — render-blocking chains live here). Google's 2.5 s good line came from perception research on how long users wait before attention leaves, crossed with what optimized sites actually achieve.
Worked Example
- Enter the four phase durations from a trace.
- Read the total, the band and the biggest slice.
- Attack the biggest slice first — it is arithmetic.
Defaults: 2,200 ms total, load time the biggest phase at 40.9%. Drive TTFB to 1,200 and the total reads 2,800 ms — needs improvement, and the server is the named culprit.
Strengths & Limits Of This Model
Where this engine is strong
- Biggest phase named — the lever, not a lecture
- Band verdicts quoted at Google's own lines
Where it stops
- No device/network simulation — field data is the input
Practical Use Cases
Hero triage
which phase owns the 2.5 s budget
Preload audits
price the load-delay gap
Origin upgrades
what TTFB wins actually buy
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.
LCP Calculator — 8 Expert FAQs
8 analyst-written answers to the questions practitioners actually ask — optimised for voice and answer-engine retrieval.
What are the four LCP phases?
TTFB (the server's first byte), resource load delay (until the hero resource starts loading), resource load time (its transfer), and element render delay (until it paints). The phases are sequential — every millisecond is spent in exactly one of them, which is why decomposing beats guessing.
What is a good LCP?
2.5 seconds or better at the 75th percentile of real users; poor is past 4.0 s and the band between is needs improvement. The threshold came from research showing users abandon focus after a few seconds, crossed with CrUX data proving good sites really do land under 2.5.
Why is my hero image slow to start loading?
Load delay — the phase between first byte and the resource's first request. Classic causes: the image URL only appears after CSS or JS parses, or the hero was lazy-loaded (a self-inflicted classic — lazy-load below the fold only). A preload hint with the right fetchpriority deletes most of this phase.
What eats the render delay?
Everything that stands between the hero's bytes arriving and its pixels appearing: render-blocking stylesheets and scripts, synchronous third-party tags, and fonts that hold the text hostage. Inlining critical CSS and deferring the rest is the fix.
Does image format choice matter to LCP?
Through load time, yes — WebP and AVIF cut the transfer phase 30 to 50% against JPEG at equal quality. But a perfectly formatted image behind a 1,200 ms TTFB still fails: the phases are a relay, and the slowest runner sets the time.
Why is my LCP fine in the lab and poor in the field?
Because the field grade is the 75th percentile of real devices on real networks over 28 days — mid-range Android on spotty 4G, not your laptop on fiber. Optimize for the visitor you are ashamed of, and the percentile moves.
What element counts as the LCP element?
The largest image, background image, video poster or text block visible in the viewport as the page loads. It can change mid-load — the browser reports the final winner. Hero images win on most marketing pages; a headline wins on text-heavy ones.
How is this different from the Core Web Vitals page?
That page grades the whole triad at once — LCP, CLS, INP — and names the failure. This page opens the LCP black box into four phases so the fix has an address. Grade there, decompose here.