Why is file size so important?
A single uncompressed DSLR shot can weigh 6–25 MB. For print that makes sense — for a website it's a disaster. According to HTTP Archive, images account for an average of 50–65% of a web page's total weight. Fail to optimize images and you give away load speed, SEO ranking, and user satisfaction.
The good news: with the right methods, image size can often be reduced by 60–90% without a normal user seeing the difference.
Method 1: choose the right format
The format choice alone can halve the file size. The rule of thumb:
- Photo → WebP (or JPG as a fallback): 25–35% smaller than JPG
- Graphic with transparency → WebP (or PNG): up to 50% smaller than PNG
- Logo / icon → SVG: scales perfectly, usually just a few kilobytes
- Animation → animated WebP or MP4: up to 10× smaller than GIF
Method 2: match resolution to display size
The biggest and simplest optimization potential often lies in the resolution. Loading a 5000 × 3333 px photo onto a blog page where it's only displayed at 800 × 533 px means: you download 39× more pixels than needed.
Scale images to the maximum display width multiplied by 2 for retina displays. An image displayed 600 px wide needs a source file at most 1200 px wide.
Method 3: lossy compression
The quality slider in compression tools (like JNRT Pixel) determines how aggressively image information is removed:
- 90–100%: hardly any difference from the original, little compression
- 75–85%: the sweet spot for web images — minimal visible loss, big saving
- 60–74%: clear saving, slight artifacts visible on some images
- Below 60%: visible quality loss, only for non-critical thumbnails
Method 4: remove metadata
Photos from cameras and smartphones contain EXIF data: GPS coordinates, camera model, capture time, copyright info, and more. This metadata can amount to several hundred kilobytes and is completely irrelevant for web display.
Many compression tools (including the Canvas API in JNRT Pixel) remove EXIF data automatically. That's also good for privacy on the side — no GPS coordinates in publicly accessible images.
Method 5: enable lazy loading
Lazy loading loads images only when they scroll into the visible area. This doesn't reduce the file size itself, but the initially loaded data volume considerably:
- HTML:
<img src="..." loading="lazy" /> - Supported by all modern browsers
- On long pages often saves 50–80% of the image data on first load
- Don't use it for the first visible image (LCP)!
Method 6: responsive images with srcset
Different devices need different image sizes. With the srcset attribute you deliver each device exactly the fitting version:
- Smartphone gets the 400 px version (~40 KB)
- Tablet gets the 800 px version (~120 KB)
- Desktop retina gets the 1600 px version (~280 KB)
- Instead of always sending everyone the 1600 px version (~280 KB)
Method 7: caching and CDN
A Content Delivery Network (CDN) stores your images on servers worldwide. A user in Munich gets the image from the Frankfurt server instead of from the US. Latency drops dramatically. Combined with aggressive caching (Cache-Control: max-age=31536000), once-loaded images are served directly from the browser cache for months — without any network request.
Combination effect: what's realistically achievable?
| Starting point | After optimization | Saving |
|---|---|---|
| DSLR photo, 18 MB, 6000 px | WebP, 1200 px, 80% | ~97% smaller |
| PNG screenshot, 2.1 MB | PNG compressed | ~45% smaller |
| Logo JPG, 340 KB | SVG (if possible) | ~85% smaller |
| Animated GIF, 4.2 MB | Animated WebP | ~80% smaller |
Conclusion
Image optimization isn't a one-off project but a habit. Every new image that goes onto a website should first be compressed, scaled to the right size, and saved in the right format. The combination of the right resolution, WebP format, and compression to 75–85% almost always delivers the best result — with JNRT Pixel it takes under a minute per image.