Avoid Enormous Network Payloads: Cut Page Weight

What "Avoid enormous network payloads" actually flags

This check adds up the total transfer weight of everything the page pulls, HTML, CSS, JavaScript, images, fonts, and third-party requests, and warns when the sum gets fat. Lighthouse draws its line around 1,600 KB of total transfer; go past that and it flags the page and ranks your heaviest requests. Every one of those kilobytes has to cross the network, and on a mid-tier phone over mobile data that is the difference between a page that paints in a second and one that crawls.

The stakes hit Largest Contentful Paint (LCP) hardest, because a bloated payload delays the moment your main content finishes downloading, and they hit anyone on a capped data plan in the wallet. Heavy pages also cost you crawl efficiency and bounce.

A real failing example (and the fix)

The classic offender is a full-resolution image dumped straight from a camera or a stock library, served at display sizes a fraction of its real dimensions:

<!-- A 5.8 MB, 6000x4000 JPEG rendered in a 800px column -->
<img src="/uploads/DSC_04412_original.jpg" alt="Team photo">

Right-size it, convert to a modern format, and serve responsive variants so phones never download the desktop file:

<!-- ~90 KB AVIF/WebP, correctly sized per viewport -->
<img
  src="/uploads/team-1200.webp"
  srcset="/uploads/team-600.webp 600w,
          /uploads/team-1200.webp 1200w,
          /uploads/team-1800.webp 1800w"
  sizes="(max-width: 800px) 100vw, 800px"
  width="1200" height="800"
  alt="Team photo" loading="lazy">

That single change routinely strips megabytes off a page. Apply the same discipline to code: ship minified, compressed CSS/JS and drop libraries you barely use.

# Serve text assets compressed (nginx example)
gzip on;
gzip_types text/css application/javascript application/json image/svg+xml;
# Better still, enable Brotli for smaller text payloads
brotli on;
brotli_types text/css application/javascript application/json image/svg+xml;

The 30-second math on why weight matters

Bytes are not free. A 4G connection in the real world delivers maybe 1.5-4 Mbps once you account for latency and congestion, not the headline speed on the box. At a realistic ~2 Mbps effective throughput, every extra 1 MB of payload adds roughly four seconds of download time before the browser can even use it. Stack three oversized images and an unminified bundle and you have buried your content under ten-plus seconds of transfer that a right-sized page would never have spent. That is the gap between a page that feels instant and one people abandon.

Where the weight usually lives

How to detect it on your own site

1. Lighthouse: the "Avoid enormous network payloads" diagnostic lists total transfer size and the top requests by weight, so your worst offenders are named directly.
2. PageSpeed Insights: run your URL at pagespeed.web.dev for the same breakdown against real-world mobile conditions.
3. DevTools Network panel: reload with the panel open and read the summary bar at the bottom, transferred vs. resources. Sort by Size to find the heaviest files, and check "Disable cache" so you measure a cold load.
4. WebPageTest: the "Content Breakdown" pie and the byte-weighted waterfall show exactly which categories dominate your page weight, per request.

How to fix it, step by step

1. Rank requests by transfer size and fix the top of the list first; a couple of oversized images usually outweigh everything else combined.
2. Resize images to their real display dimensions, convert to AVIF or WebP, and add srcset so devices download only what they need. See image optimization.
3. Enable Brotli or gzip on all text assets, and minify CSS and JS.
4. Remove unused JavaScript and split bundles so pages load only their own code; see remove unused JavaScript.
5. Subset fonts to WOFF2 and limit weights; lazy-load below-the-fold media.
6. Audit third-party tags ruthlessly, then defer what survives so it does not compete with your content for bandwidth.

FAQ

Is 1.6 MB a penalty threshold?

No, it is the point where Lighthouse starts flagging. There is no fixed Google penalty for weight. The real cost is slower loads and worse Core Web Vitals, which is what actually moves rankings and conversions.

Transferred vs. resource size, which one counts?

Transferred size, the compressed bytes on the wire, is what the payload check measures and what users actually download. Resource size is the uncompressed total. If they diverge a lot, your compression is working; if they match, you probably have compression turned off.

Do images really matter more than JavaScript?

On most content sites, yes, by weight. Images are frequently the single largest chunk of transfer. JavaScript is usually smaller in bytes but more expensive per byte because it also blocks the main thread when it executes.

Will a CDN fix payload size?

A CDN makes each byte arrive faster and closer to the user, but it does not shrink the payload. You still have to right-size and compress the assets themselves.

How does this connect to LCP?

Your LCP element is often the very image you are over-serving. Trim its weight and LCP drops with it; the full playbook is in how to improve LCP.

What about fonts and video, are they really that heavy?

They can dwarf your images. A single custom typeface loaded in four weights across two families can run several hundred kilobytes; subset it to WOFF2 and two weights and you often reclaim most of that. An autoplaying MP4 hero is worse, easily multiple megabytes streaming before anyone reads a word. Swap it for a poster image that plays the video only on interaction and you delete the single largest line in your waterfall.