Image Sizes for Websites: The Numbers We Check Before Launch
Last week I checked the logo on warasat.com.pk and it came back at 334,564 bytes. It renders about 320 pixels wide on the site, which means the browser was downloading a 2,560-pixel-wide PNG to display something smaller than a postage stamp. On the median 3G connection that is roughly half a second of load time spent on the one element that carries no photograph at all. This article settles image sizes for websites with the same numbers we check before any launch, most of them measured on our own builds this morning.
The web is mostly images, so the web is mostly slow
The numbers behind that claim come from the HTTP Archive’s Web Almanac 2024 page-weight chapter (data crawled in October 2024, almanac.httparchive.org). The median desktop page weighs 2,652 KB, and 1,054 KB of that is images. JavaScript, the component everyone loves to blame, sits at 613 KB on the same median homepage. On mobile the median page weighs 2,311 KB and carries 900 KB of images.
Two more facts from the same chapter are worth sitting with. Image bytes per page went up between 2022 and 2024 at the median and above, which means this problem is growing, not shrinking. And on inner pages, JavaScript has overtaken images as the biggest component, so the answer to “what is making my page heavy” genuinely depends on which page you are looking at. A blog post’s heaviest asset can be a script; a homepage’s heaviest asset is almost always a picture somebody uploaded at full camera resolution.
Formats first, in plain words
There are really three decisions to make about an image, and the format is the cheapest one. Google’s own guidance for developers is blunt about it: AVIF and WebP have superior compression and quality characteristics compared to their older JPEG and PNG counterparts (Chrome for Developers, Lighthouse audit doc). The Learn Performance guide on web.dev adds the practical version: pick formats that compress better, size them for the layout, and know that WebP works in all modern browsers.
What that means on a real site is less dramatic than the forums make it sound. We do not hand-convert anything anymore. On truckaxic.com the JPEG sources stay in the repo exactly as they were uploaded, and Next.js serves a properly sized variant to every device through its built-in image component. The format work happens on the server, per request, and nobody on the team touches it by hand. If your stack does not have an optimizer, a WebP export at quality 75 from any free tool gets you most of the win.
Image sizes for websites: the three numbers that decide
Three numbers decide everything we ship. First, the layout width: an image only ever needs to be as wide as its container, times two for retina screens. Second, quality: 80 for photography, 60 for background images nobody studies closely. Third, position: whatever sits below the first screen gets loading="lazy", and only the hero is allowed to load eagerly.
On truckaxic.com the raw hero file is 320,743 bytes (1600x1920). Through the Next.js optimizer at width 1080 and quality 90, the browser receives 147,688 bytes, 54 percent less for the same picture. A background image called dispatch-ops.jpg starts at 136,350 bytes and ships at 47,468 bytes at width 1080 and quality 60, a 65 percent cut. Neither number required cleverness; the optimizer just refuses to send phone screens a file sized for a billboard.
There is a trap in that pipeline worth naming. Optimizer URLs follow the viewport they were generated for, so if the page builder requests a lazy image at desktop width (3840 pixels on one of our pages), a phone that never resizes it still downloads the heavy variant. We check the generated URLs against the real rendered width, not the trust that the tool is doing the right thing. Trust the pipeline after you have verified it once with curl.
The size checklist we run before launch
This is the whole list, and it fits in one table. It is deliberately boring; the point is that none of it is optional.
| Check | Standard | Why it survives |
|---|---|---|
Every <img> carries width and height | Yes, always | Stops layout shift while loading |
| Below-fold images lazy | Yes | Saves bytes the visitor may never need |
| Hero image | Sized to viewport, eager | The one image worth its bytes |
| Logo | Sized to rendered width | Usually the worst offender, and invisible |
| Format | WebP or AVIF for photos | Smaller at the same quality |
| Page budget | Under 1 MB, one page | Forces the conversation early |
Two of these deserve the shame they earn. The logo rule exists because of the 334 KB file at the top of this article; a resized copy at 640 pixels came to 55,537 bytes, an 83 percent cut, and we made it with a one-line ffmpeg resize on this machine, no paid tool involved. The width-and-height rule is not about speed so much as about sanity: warasat.com.pk’s homepage has 21 image tags today, 20 of them carrying explicit dimensions, so nothing on the page jumps while the images stream in. The one tag without dimensions is the logo. That correlation is not an accident; the file everyone forgot to size is also the file nobody dimensioned.
What this morning’s check found
We ran the list on all three live client sites today. warasat.com.pk: 20 of 21 images are lazy, resized through an 800-pixel cache path, and each hero image lands between 110,981 and 137,504 bytes. The logo is the one failure, and the fix is a resize command we already have the output for. truckaxic.com: eight images, all of them through the optimizer, every one under 150 KB at phone width. mtufaildiagnosticcenter.com: zero img tags on the homepage, which reads as an almost-empty diagnostic site until you remember it is mostly text and booking information, exactly what a visitor on 3G wants.
The dashboard shows what good looks like from the other side. The median desktop homepage on the wider web carries 1,054 KB of images (Web Almanac 2024). Every homepage we manage carries fewer image bytes than that today, and the gap is not talent; it is the checklist running before launch instead of after a complaint.
What to do this afternoon
Pick the page you care about most and run one command against it, the same one we used this morning:
curl -s https://your-site.com/ | grep -o 'src="[^"]*"' | grep -iE '\.(png|jpe?g|webp|avif)' | head -20Then run curl -sI https://your-site.com/the-biggest-image.jpg and read the Content-Length. If your largest image is above 200 KB, resize it to twice its rendered width and re-upload. If that sentence felt too easy, it is; the whole exercise took us ten minutes on a site we did not build.
If you would rather hand the checklist to someone who runs it every week, that is what our web development service is for. We wrote a companion piece on website speed on mobile data that covers what page weight does to a visitor on a slow connection, and another on contact form fields for the part of the page where a lost byte matters less than a lost enquiry. You can also book a free consultation and we will run the checklist on your site and send you the numbers.
FAQ
What image size should I use for a website hero image?
Size it to the widest viewport you actually support, usually 1920 pixels for desktop, and export at quality 75 to 85. On our builds that lands a hero between 100 and 150 KB; the raw file is often two to three times that. Serve a smaller variant to phones through an optimizer or a srcset, because a 3840-pixel hero on a 390-pixel-wide screen is 80 percent wasted bytes.
What is the difference between image dimensions and image file size?
Dimensions are pixels: width by height, what you set when you resize. File size is bytes: what the visitor downloads, decided by format and quality after the dimensions are fixed. A 1920x1080 photo can weigh 180 KB as a quality-75 JPEG or 900 KB as a PNG, same pixels. Resize first for dimensions, then choose format and quality for bytes. Both matter; they are two different dials.
Should I use WebP or AVIF on my website?
WebP, for now, unless you have a specific reason for AVIF. WebP works in all modern browsers, so a site that serves it needs no fallback chain and no risk of a broken image for an older device. AVIF compresses better at the high end but arrives with fallback complexity. If your framework has a built-in image optimizer, let it negotiate formats per request; that is what we do on Next.js builds and it has not cost us a browser support complaint yet.
How do I check what images are slowing down my website?
Open the browser dev tools, go to the Network tab, filter by Img, sort by size, and reload the page. The top rows are your answers; anything above 200 KB deserves a resize. If you prefer a command line, curl -sI https://your-site.com/your-image.jpg prints the Content-Length of any single file. Run it on the largest image from step one and compare it against its rendered width on the page.
Do I need to compress images that are already JPEG?
Usually yes. JPEG is a format, not a guarantee of size; a straight-from-camera JPEG is often 10 times the bytes its rendered width needs. Re-encoding at quality 80 to 85 and the right pixel width typically cuts 40 to 70 percent of the bytes with no visible change. On our truck hero, one pass through the framework’s optimizer cut the file by 54 percent, and nobody has ever asked which photo we removed.