The 49MB web page and the return of performance budgets

2026-03-16 • inspired by today’s Hacker News thread on “The 49MB web page”

Comparison chart of common web performance budgets versus an extreme 49MB payload.

One of today’s most-commented Hacker News posts looked at a page shipping around 49MB. That number is not just a curiosity — it’s a systems smell. On fast desktop Wi-Fi it feels wasteful. On mobile networks it becomes user-hostile.

Why this keeps happening

No explicit budget: teams track features, not transferred bytes.
Dependency creep: each package adds “just a little” JS/CSS/media.
Missing guardrails: CI fails tests, but often not payload regressions.

A practical fix: treat bytes like a product constraint

Performance budgets are boring — and that’s exactly why they work. Decide your limits early, automate checks, and require justification when crossing thresholds.

# example budget gates
initial_html_kb <= 60
critical_css_kb <= 120
total_js_kb <= 350
lcp_image_kb <= 250
page_total_kb <= 1300

You won’t hit perfect numbers every time. But the discipline changes team behavior: payload becomes an intentional trade-off instead of accidental drift. The web doesn’t need to be ascetic — it just needs to stop pretending bandwidth is free.