Web Page Size Calculator
What a page weighs — every class of bytes on the ledger, judged against the HTTP Archive medians the web actually ships.
Web Page Size Calculator
Results recalculate instantly on every keystroke. Nothing you type is transmitted.
What this result does not account for
- Five classes — video and analytics streams excluded
- Uncompressed bytes; wire sizes differ by class
In short: The median page, part for part — 18 KB of HTML, 78 KB of CSS, 613 KB of JavaScript, 1,054 KB of images and 131 KB of fonts — weighs 1,894 KB: 71.4% of the 2,652 KB desktop median and roughly 82% of the 2,311 KB mobile one. The heaviest class is images at 55.6% of the page, and that is the ledger's whole argument: weight is a budget, and something always holds the largest share.
Formula
weight = Σ class bytes · share = class ÷ total
Page weight is a five-line ledger — HTML, CSS, JavaScript, images, fonts — and every optimization argument starts by asking which line holds the largest share. The medians are the HTTP Archive's October 2024 crawl: 2,652 KB desktop, 2,311 KB mobile, with the desktop composition quoted in the defaults of this very page. Weigh yours against the web that actually ships, not against a fantasy of the lean old days.
Worked Example
- Enter each class's bytes in KB, uncompressed.
- Read the total and its share of the medians.
- Act on the heaviest class, not on vibes.
Defaults are the desktop median page part for part: 1,894 KB total, images 55.6%. Drive images to 3,000 KB and the total jumps to 3,840 KB — heavier than the 75th-percentile desktop page, on one class alone.
Strengths & Limits Of This Model
Where this engine is strong
- Medians cited from the crawl, not folklore
- Heaviest class named — the actionable output
Where it stops
- No request-count or waterfall modeling
Practical Use Cases
Budget gates
a KB ceiling per template in CI
Before/after audits
price a refactor in bytes
Third-party trials
what the tag manager really costs
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.
Web Page Size Calculator — 8 Expert FAQs
8 analyst-written answers to the questions practitioners actually ask — optimised for voice and answer-engine retrieval.
What is the average web page size in 2025?
By the HTTP Archive's October 2024 crawl: 2,652 KB for the median desktop page and 2,311 KB for mobile. The 75th percentile sits above 4 MB on desktop. Both medians keep climbing — up about 15% in two years — which is why 'about average' is a low bar to defend.
What makes up a typical page's weight?
Images dominate: 1,054 KB of the median desktop page. Then JavaScript at 613 KB, fonts at 131 KB, CSS at 78 KB and HTML at just 18 KB. The composition matters more than the total — image bytes compress no further on the wire, while text classes shrink 70 to 80% under gzip or brotli.
Is page weight the same as load time?
No — weight is one input. Connection overhead, server think time and render-blocking chains decide how the bytes translate to seconds. A 900 KB page on a slow origin can lose to a 2 MB page from a warm CDN. Weight is the ledger; the Core Web Vitals pages on this site time the experience.
Do gzip and brotli shrink all of it?
Only the text classes. HTML, CSS, JS and fonts (usually) compress 70 to 80% on the wire; JPEG, WebP and AVIF images are already compressed and arrive essentially at their ledger size. That is why this page reads uncompressed bytes — the classes behave differently on the wire and the note card keeps the distinction honest.
What is a good page weight budget?
Whatever your audience's worst connection forgives. A common gate is the median itself — ship under 2,652 KB desktop / 2,311 KB mobile — with a hard ceiling per template. The number matters less than having one: un-budgeted pages find their way to the 90th percentile, and the p90 web weighs 8 MB.
Which class should I optimize first?
The heaviest one — that is arithmetic, not philosophy. On the median page that is images: format downgrades (JPEG to WebP/AVIF), honest dimensions, and lazy-loading below the fold. On JS-heavy pages the script line is the target and the win doubles as an INP fix.
Why count fonts as their own class?
Because they are the class teams forget. A full family set — regular, italic, bold, black, each in latin-plus-latin-ext — crosses a megabyte before a single image loads. Two families at two weights, subset, is the discipline the median's 131 KB implies.
How do I keep a page light over time?
Put the ledger in CI: measure per template, fail the build on a budget breach, and make every third-party script buy its slot with a measured value. Weight regresses silently because each individual addition is small; the ledger is how a page stays under the median after a hundred reasonable decisions.