Page Size and Request Count, Explained

After reading this you can find out how much a page weighs, count how many separate files it pulls in, and tell which resources deserve the blame for a slow load.

What page weight and request count actually measure

Every web page is a set of files. The HTML document arrives first. It references other files: scripts, stylesheets, images, fonts, and sometimes embedded pages (iframes). The browser fetches each one. Page weight is the total size of all those files added together. Request count is how many separate files the browser had to ask for.

Both numbers matter, and they matter differently. A page that weighs 3 MB in 12 requests behaves differently from one that weighs 1 MB in 90 requests. The first is heavy; the second is chatty. Each request carries its own connection overhead and latency, so 90 small files can be slower than one large file even when the large file holds more bytes.

Here is the hook. Suppose two pages both weigh 2 MB. Page A is 1.8 MB of images and 0.2 MB of everything else. Page B is 1.4 MB of JavaScript and 0.6 MB of everything else. Page B will almost always feel slower, because the browser must parse and execute those scripts before the page becomes interactive. Images just decode and paint. The byte count alone hides that difference, which is why the analyzer breaks weight down by resource type.

When to run this check and when it will mislead you

Run it when a page feels slow and you want evidence before you start optimizing. It answers one question well: where do the bytes come from? If a single hero image is 1.2 MB out of a 2 MB page, you know exactly what to fix.

Run it also as a sanity check after a redesign. A new template that adds a font library and three tracking scripts can double request count without anyone noticing until Monday.

So do not treat the total as the final word for a heavily interactive application. Treat it as the weight of the initial document and its declared dependencies. For a mostly static page, that is nearly the whole story.

The arithmetic behind the totals

The math is addition, but the interpretation needs care. Total weight is the sum of each resource size:

Here W is total page weight, n is the number of resources counted (at most 30 here), and s_i is the size in bytes of resource i, taken from its HTTP Content-Length header.

To see where weight concentrates, compute each resource's share:

A useful rule: if the largest single resource is more than 40% of total weight, one file dominates the page and fixing it fixes most of the problem. If no resource exceeds 10%, weight is spread across many files, and the real lever is reducing request count rather than shrinking any one file.

To weight the cost of scripts more honestly, apply a rough execution penalty. A common working figure: JavaScript costs about 3 times as much wall-clock time per kilobyte as an image of the same size, because it must be parsed and executed, not just decoded.

Here C is an effective cost estimate, s_{\text{img}} is total image bytes and s_{\text{js}} is total script bytes. The factor 3 is a heuristic, not a physical constant, but it stops you from treating a megabyte of script as harmless just because a megabyte of images sits next to it.

Watching JavaScript reshape the real cost

The gap between raw bytes and felt cost is the one thing a table cannot show well. Move the slider below and watch the effective cost climb far faster when the extra weight is script rather than image.

Reading the results without fooling yourself

Start with the total and compare it to the median. The median web page weighs a little over 2 MB. If your page is under 1 MB you are lighter than most; if you are over 4 MB you are heavier than most and users on slow connections will feel it.

Next, sort resources by size and look at the top three. On most real pages, the top three resources account for 50% to 80% of total weight. Fix those first. Shaving 5 KB off a stylesheet while a 900 KB uncompressed image sits untouched is wasted effort.

Then look at request count separately from weight. A 1.5 MB page in 15 requests is well-built. A 1.5 MB page in 120 requests is fragmented, and consolidating files will help even though total bytes stay the same.

Common mistakes

The first mistake is trusting the total on a script-heavy page. If the site is a single-page application, most of its content loads after the initial HTML, and this check sees only the opening move.

The second mistake is reading compressed and uncompressed sizes as the same thing. The Content-Length header reports the transferred size, which is usually gzip or brotli compressed. A 900 KB text file may transfer as 180 KB. Images and fonts are already compressed, so their transferred size is close to their real size.

The third mistake is optimizing request count by inlining everything. Inlining a large script into the HTML removes one request but makes the HTML uncacheable and larger on every page. Balance matters.

Related tools

Weight tells you how much a page costs to load. It says nothing about what the page is about. If you want to check whether your text actually covers its target terms, run the copy through the Keyword Density Checker, which reports word and phrase frequencies with a stopword filter.

Related tools

Keyword Density Checker

Word and phrase frequencies of any text, with stopword filter.

Meta Tag & Open Graph Generator

Generate meta tags and preview the Google, Facebook and X cards.

Redirect Chain Checker

Follow every hop: 301s, 302s, loops and chain length.

SERP Snippet Preview

Pixel-accurate preview of your Google result on desktop and mobile.

UTM Campaign URL Builder

Build tagged campaign URLs with correct encoding.

robots.txt Tester

Test which URLs a robots.txt blocks, rule by rule.