Image file size for web performance: dimensions, formats and quality settings

Ask a room of web developers what makes pages slow and you will hear about JavaScript frameworks and server response times. Then look at the network tab of a real content page: on most pages, images are the largest assets transferred, and the single biggest image — usually the hero — is frequently the element the browser is waiting for before it can call the page loaded. That is why image weight is the highest-leverage performance topic for most sites, and why this guide starts with bytes rather than settings. It ends with a verification routine, and uses the image compressor and WebP converter on this site, both of which show you the byte comparison before you download anything.

Image weight and LCP, in plain terms

Largest Contentful Paint (LCP) is the Core Web Vital that times how long the largest element in the viewport — very often an image — takes to render. Every extra kilobyte of that image is time on the wire, and the wire is the constraint: a fast fibre connection forgives a 900 KB hero image, while a mid-range phone on a congested mobile network does not. LCP also feeds into search ranking, but the ranking argument is the weaker one; the stronger one is that visitors abandon slow pages, and the hero image is usually most of the slowness a content page can actually remove. The practical conclusion is not "compress everything to dust". It is: give the largest image on each page a deliberate size budget, because that image is often several times heavier than it needs to be.

Step one: fix the dimensions, not the quality slider

Compression settings get the attention, but dimensions do the heavy lifting. An image's pixel count grows with the square of its width: a 4000-pixel-wide photo carries roughly twenty-five times the pixels of the same photo at 800 pixels wide, and at the same quality setting the file grows by a similar order. If the page displays that photo at 800 CSS pixels wide, the other twenty-four twenty-fifths were downloaded for nothing. So the order of operations is fixed: first resize the image to the largest size it will actually be displayed at — twice that for retina screens, if your audience's devices justify it — and only then reach for the quality slider. In the compressor on this site, the maximum-width setting does exactly this, and it never enlarges: a small original stays small, which is honest behaviour, because upscaling adds bytes without adding detail.

Step two: pick the format for the content

• JPEG — the default for photographs. Universal support, no transparency. If a photo must work everywhere with zero thought, it is a JPEG.
• WebP — the modern default for your own site. At comparable visual quality, WebP files are typically about 25–35% smaller than JPEG in published comparisons, it supports transparency, and every current browser decodes it. For most sites it is now the best first choice for both photos and graphics.
• AVIF — often smaller again than WebP at the same quality, especially on photographs with smooth gradients, but it encodes slowly and tooling support is still uneven. The converter on this site covers JPEG, PNG and WebP, so treat AVIF as a build-pipeline decision rather than a quick conversion.
• PNG — lossless, and the right answer for screenshots, interface captures, diagrams and logos with hard edges and text, where lossy formats smear exactly the details that matter. For photographs it is usually several times larger than an equivalent JPEG or WebP — the classic silent page-weight bug.
• SVG — for logos and icons that are genuinely vector: resolution-free and often only a few kilobytes. Never "convert" a photo to SVG; that embeds the raster file and adds overhead.

Step three: quality settings that hold up

For photographs, a JPEG or WebP quality setting in the 75–85 range is the working sweet spot: artefacts at these settings are hard to spot at normal viewing distance, and the file is a fraction of a quality-100 export. Quality 85–90 is a reasonable premium for hero images and product photos that visitors will zoom into. Above 90 the bytes climb steeply for improvements most viewers cannot see, and quality 100 is almost never justified on the web. Where do artefacts show first? In smooth gradients, where skies band into visible steps; around high-contrast edges, where text and logos grow fuzzy halos; and in dark, busy textures. That is why the check in the next section looks at exactly those places. One more rule: compress from the original. Re-compressing an already-compressed JPEG spends a second generation of artefacts to buy a much smaller saving.

Step four: verify like a sceptic

1. Compare bytes and pixels together. The compressor shows the before/after byte count next to a preview; a 70% saving that looks identical is a win, a 15% saving that bands the sky is not.
2. View at 100%. Artefacts hide at fit-to-screen sizes. Zoom into the busiest area — foliage, fabric, hair — and into any text or logo inside the image, and look at the edges of letters.
3. Check the gradient. Skies, walls and studio backdrops are the canary: if they stay smooth, the setting is safe for the whole image.
4. Test the page, not just the file. Load the updated page on a throttled connection profile and watch the hero arrive. Performance is what the visitor experiences, not what the exporter reported.

Mistakes that keep pages heavy

• Uploading camera originals. A 6000-pixel phone photo dropped into a 900-pixel slot is the single most common cause of multi-megabyte pages.
• PNG photographs. Lossless is a property, not a virtue, when the content is a photo and the bill is several times the bytes.
• Optimising the thumbnails, ignoring the hero. The largest image sets the LCP; twenty small wins elsewhere do not move it.
• Chasing the last 5%. Crushing quality to win a few extra kilobytes trades visible quality for invisible savings. Settle at the sweet spot and spend the effort on the next page.