Heavy Page Weight, What Megabytes of Website Cost Your Visitors

Heavy total page weight. That is the flag when a page transfers more than about 2,000KB before it is done, and it is one of the most common performance findings we see on real sites, behind only the raw counts of CSS and JavaScript files. The number comes straight from the page itself, every file the browser had to download counted, and the report tells you exactly how heavy it is.

The finding makes no grand claims. Weight alone does not decide whether a site is fast, and it earns no points of its own one way or the other. What it does is put a number on how much a visit has to download, and that number sets the fastest the page can possibly answer, no matter how quick the connection underneath.

What counts as heavy

The check adds up the transfer size of everything the page loads, HTML, CSS, scripts, images, fonts, third-party embeds, and compares the total against a fixed budget. Over 2,000KB the page gets flagged as heavy. Over 4,000KB the finding escalates to high severity, because the download alone can eat several seconds before the page even starts to render.

Our own numbers show how common this is. Across the sites we have tested, around two in three pages come in over the 2,000KB line, and the middle result is roughly 3,600KB. Heavy is the norm, not the exception, which is exactly why the flag shows up so often in reports.

Where weight sits in the score

Here is the part most write-ups skip. Page weight is not a line item in the performance score. The score follows the Core Web Vitals, the Largest Contentful Paint and Cumulative Layout Shift measured in a real browser, with Total Blocking Time standing in as the lab proxy for Interaction to Next Paint, because true responsiveness only shows in field data. Weight reaches the score only through those metrics, because a heavy page tends to push LCP and blocking time up.

That is why the flag can fire on a page that scores perfectly. This site is the proof. Enterramon.com transfers about 3,358KB across 44 requests, so the finding appears on our own report, yet the page scores 100 on performance because the largest content paints at 728 milliseconds. The megabytes are real, the lab numbers are clean, and both statements are true at once. Weight is what every visit has to move across the wire, not a verdict on the lab score.

The bar moved, not the bandwidth

Look at what changed first. Twenty years ago a heavy page was a disaster because the connection could not carry it. A megabyte took minutes on dial-up, and every kilobyte of page weight was real money on a metered line. That argument is mostly gone. Broadband, fibre, and mobile data have made raw transfer size a smaller problem than it used to be, and a 3,600KB page is simply not the hardship it was in 2005.

What replaced the old problem is expectation. People do not compare your page to the web of a decade ago, they compare it to the fastest thing they opened this morning, and they expect a page to be usable almost the instant they tap it. A page that takes two seconds to paint feels slow next to one that answers in half a second, and on mobile the tolerance is shorter still. The connection got fast, the bar got faster, and weight is what decides whether a page can clear it.

Weight still matters most where connections stay thin. A 3,600KB page over fibre is a blink, over a patchy 3G or 4G signal it is ten seconds of staring at a spinner, and in many regions that thin connection is the daily reality. So the importance comes down to this. The old reason to care, the cost of the bytes, has faded for most visitors, and the new reason, the expectation of near-instant load, has taken its place, with the same megabytes sitting behind both.

Where the weight comes from

Rarely the page’s own HTML. Almost always images, scripts, and third-party code. Our own homepage breakdown is typical. Of the 3,358KB it ships, about 1,460KB is JavaScript across 22 files, roughly 610KB is images across 13 files, and the rest is fonts and other assets. Around 1,370KB of the same total comes from third-party hosts, analytics, chat, and embeds, which are themselves JavaScript and images, not a separate pile on top. The single heaviest thing on our homepage is a 968KB icon font, one file doing more damage than all the images combined.

Big sites make the same mistake at a bigger scale. One real report in our records shows a page transferring about 5,931KB across 83 requests, with 3,666KB of that being 44 images alone, and roughly 2,412KB of the total arriving from third-party hosts. The pattern is consistent. The heaviest contributors are almost always fonts, images, and third-party JavaScript, and that is where the fix should start, never with the site’s own markup.

Trimming the biggest contributors first

Start by looking at the breakdown, not at random. In a browser, the network panel in the developer tools sorts every request by size, which instantly shows the ten files that make up most of the weight. The report’s own findings point the same way, because the oversized asset and image format checks name the specific files involved.

Images come first. They are usually the single biggest block, and modern formats shrink them dramatically. WebP typically cuts 25 to 30 percent off the same image at the same quality, and AVIF goes further, often around 50 percent over the original JPEG. Every modern browser supports both, so the question is never whether visitors can view them, it is whether your pipeline can produce them. If the site already serves WebP somewhere, the CMS or build step has proven it can, which makes converting the rest pure upside. Resize at the source too, because serving a 2,000 pixel image into a 400 pixel slot wastes most of the bytes.

Then third-party scripts. Tag managers, chat widgets, analytics, video embeds, each one is a separate download plus the JavaScript to run it. Load them lazily so they wait for real engagement, or remove the ones that do not earn their bytes. One real report we looked at had a quarter of its requests coming from third parties, and every removal is a permanent cut. Lazy loading has one catch worth naming. Analytics and consent platforms have to run on the first view to count it and to show a cookie banner before any other script touches the page, so defer those two past user interaction and you lose your initial pageview count and break your consent flow. Load the lazy ones lazily, never the ones the law or your measurement depends on.

Fonts and duplicate libraries are the sneaky ones. A single icon font can weigh close to a megabyte, and loading jQuery twice, once from the site and once from a CDN, doubles that script’s cost for zero benefit. Our own report caught both of those on this site, a 968KB font file and a duplicated jQuery. Subset the font to the glyphs actually used, self-host it in woff2, and load one copy of every library.

Setting a budget and proving it

The fix ends with a number, not a feeling. Set a page-weight budget for the site, something like 1.5MB for a content page and a little more for a shop, and re-test against it after every change so the weight cannot creep back up silently. The report gives you the total on every run, which makes the budget easy to enforce.

Then run another Enterramon test. If the total drops under 2,000KB the flag clears on its own, and the Core Web Vitals checks next to it usually improve at the same time, because cutting the biggest downloads is also cutting the work the browser had to do before the page became usable. The score follows the visitor experience, and the visitor experience follows the time to first paint, which is what the megabytes really buy you.