How big does a website get from unoptimized images? A real-world calculation

The problem nobody sees in the editor

In almost every web project I've worked on over the years, the same component ended up responsible for the lion's share of the page weight: the images. Not the JavaScript, not the fonts, not the CSS — the images. The tricky part is that you never notice it while maintaining content. You drag a photo straight from your camera export into the CMS editor, it looks great, you hit “Publish.” The fact that this one file weighs 4.2 MB is nowhere in view.

On a single page it barely registers. Only when you extrapolate across a whole project does the scale become visible — and that's exactly what I want to do here, with a deliberately sober worked example. According to the HTTP Archive's annual analyses, the median web page has sat in the megabyte range for years, and the single largest line item is almost always the media. The calculation below shows why.

The worked example: 1,200 pages, 3 images, 1–5 MB

Take a mid-sized website — a corporate site with a blog, a travel portal, a club or real-estate catalog: 1,200 pages, each with 3 images on average. The images come straight from a camera, phone or stock library and, unprocessed, weigh between 1 and 5 MB. That's 1,200 × 3 = 3,600 images in total. Depending on the average file size, that works out to:

The average case alone comes to roughly 10.8 GB of pure image data — and that's only what sits on the server. No CSS, no code, no backups, no thumbnails, no retina second versions. Just the original images. In practice, most CMSes generate several additional image sizes per upload (thumbnail, medium, large), so the actual storage happily doubles or triples.

What this number means per page

More interesting to the visitor than total storage is the weight of a single page. Three images at 3 MB each is 9 MB of image data alone that the browser has to load before the page is done. For comparison: Google's target for the Largest Contentful Paint is 2.5 seconds. A single 3 MB hero image blows past that on an average mobile connection all by itself.

Let's do the math: on a typical 4G connection with a realistically usable ~10 Mbit/s, transferring 9 MB takes around 7 seconds — just for the images, before connection setup, before the rest of the page. On a throttled plan or a crowded train, that quickly doubles. It's precisely within that window that a significant share of visitors bounce, and that's not a hunch but well documented for years. More on that in Optimize load time.

The traffic multiplier that's easy to overlook

Storage is a one-time cost — traffic is incurred anew on every page view. Assume a modest 100 visits per page per month and set the cache aside (first visits, changing users, mobile connections with no warmed cache):

1,200 pages × 100 visits × 9 MB ≈ 1,080,000 MB ≈ 1.08 TB of image traffic per month. With a CDN that bills for outbound traffic, that's a real line item on the invoice — and it grows linearly with your visitors. The same website with optimized images would sit at around 72 GB. The difference isn't cosmetic; it's the factor by which your infrastructure costs scale.

The counter-calculation: the same website, cleanly optimized

Now the other case — the same 3,600 images, but properly prepared before they go in: scaled to the size they're actually displayed at, exported as WebP or AVIF, and sensibly compressed. A large-format content image then realistically lands at 150–300 KB instead of several megabytes. Let's be conservative and use 200 KB:

10.8 GB becomes roughly 0.7 GB — a factor of about 15, a good 10 GB saved, at a visual quality barely any visitor could tell apart from the original. The monthly image traffic drops in the same proportion from ~1.08 TB to ~72 GB, and the 9 MB page loads its images in under half a second instead of 7. That's the whole lever — and it costs no new server hardware, just one step in the workflow.

Where the bloat comes from — from experience

Why does this happen so often? In the projects I've seen, it was almost always the same four causes, and none of them is ill will:

• Full resolution in the slot. A 6000 × 4000 pixel photo from the camera lands in a container that's 800 pixels wide on screen. The browser scales it down — but loads the full file. This is by far the most common case.
• Wrong format. Photos saved as PNG because “PNG is high quality, after all.” For photos, PNG is almost always the largest and worst choice — more on that in the format comparison.
• No modern format. JPG instead of WebP/AVIF. The format switch alone often saves 30–50% at the same visual quality.
• The retina misunderstanding. The original gets embedded unchanged “for crisp displays,” instead of deliberately serving a 2× version at the right size. How to do it properly is covered in Optimizing retina images.

What I recommend to projects

The good news: you don't need to master an image editor, and you don't need to upload anything. The routine that has the biggest effect in practice is simple:

1. Scale to the display size. If the slot needs 1200 pixels, export 1200 (or 2400 for retina) — not 6000. The resize tool is all you need.
2. Convert to the right format. Photos to WebP or AVIF via the converter.
3. Compress with judgment. Quality around 75–82 is usually the sweet spot — done in seconds with the compressor.
4. Embed it cleanly. loading="lazy" for everything below the fold, srcset/sizes for pixel-perfect delivery. The full web workflow is in the compression guide.

At JNRT Pixel, every one of these steps runs locally in your browser — the images never leave your device, and whether it's 3 files or 3,600, it costs us nothing, because your machine does the work. That's exactly why I find the worked example above so worthwhile: the effort is nothing compared to the gigabytes saved.

Sources

HTTP Archive — Web Almanac, Page Weight · web.dev — Optimize Largest Contentful Paint · web.dev — Serve images in modern formats · MDN — Lazy loading (img loading).