Free tool

Performance budget calculator

Turn a Largest Contentful Paint target into concrete byte budgets per resource type — modeled on TCP slow start, not naive bandwidth math — and export a ready-to-use Lighthouse budget.json.

Your situation

One PageSpeed run grounds the inputs in your reality: your real users' p75 LCP for context, and your measured TTFB prefilled — field p75 when CrUX has it, lab when it doesn't. Measured on mobile (desktop when the Cable profile is selected). ~15–30 s. Or skip it and use the tool instantly.

Lighthouse/PSI mobile throttling (1.6 Mbps, 150 ms RTT)

Time to first byte of the HTML — measure it in DevTools or your audit report. Google's “good” bar is ≤ 800 ms.

Advanced assumptions

Main-thread time to layout, paint and decode after bytes arrive (mid-range mobile).

HTML → CSS → LCP image is 3. The HTML request itself is already paid for by your TTFB; every hop after it costs one full round trip.

247 KBtotal critical-path budget
1350 msleft for network transfer
12max sequential request hops
Suggested split — the total is the hard number; re-cut the shares for your page (text-LCP pages need far less image budget).
Resource typeShareBudget
HTML document 8% 19 KB
Render-blocking CSS 12% 29 KB
Render-critical JavaScript 25% 61 KB
LCP image 45% 111 KB
Web fonts 10% 24 KB
Download Lighthouse budget.json How is this computed?

Drop budget.json next to your Lighthouse CI config (budgets setting) and CI fails when a build busts the budget.

Watch this URL's real-user data — the day-28 verdict, emailed

A budget is a promise about the field. We fetch your CrUX p75s now as the baseline, email the verdict when the 28-day window has turned over, and alert you if any vital crosses out of “good”. If your site is below CrUX's traffic threshold, we say so honestly — and tell you the moment Chrome starts publishing data.

Double opt-in: we email a confirmation link first. Baseline card · day-28 verdict · threshold alerts — your own numbers, on the instrument's clock. Stop any time with one click.

The model (and why naive bandwidth math lies to you)

Dividing “1.6 Mbps × time” into bytes overestimates small budgets badly, because TCP doesn't start at line rate. A new connection starts with an initial congestion window of 10 segments ≈ 14.6 KB (RFC 6928) and doubles it every round trip until it saturates the link. On a 150 ms-RTT mobile connection that means the first ~450 ms move only ~100 KB — no matter how fat the pipe is.

This calculator therefore computes:

  1. Time budget

    LCP target − TTFB − render allowance − ((sequential requests − 1) × RTT). Every hop after the HTML in a discovery chain (HTML → CSS → font) burns a full round trip before its first byte — the HTML's own round trip is already inside your TTFB.

  2. Bytes from time

    TCP slow start from 10 segments, doubling per RTT, capped at the bandwidth-delay product, line-rate after that.

  3. A suggested split

    Weighted toward the LCP image because on most commercial pages the LCP element is an image. The total is the contract; the split is a starting point.

Deliberate simplifications

One connection (HTTP/2/3 multiplexing shares it anyway), no packet loss, no BBR, render allowance as a flat constant instead of a CPU simulation. These all make the budget slightly optimistic — treat it as an upper bound, which is exactly what a budget should be.

And if you prefill from your page: the field p75 gap you see is closed by the whole path — TTFB, redirects, the discovery chain, render on real devices — not by bytes alone. The byte budget is the piece this calculator disciplines. Treat it as necessary, not sufficient.

Sources

Want the budget enforced against your real page?

A PageSpeedAudit report measures where your actual bytes go, which ones block your LCP, and the exact code changes that bring you under budget.

Get your audit