Web image optimization reference
Last reviewed 2026-09-17. Every competitor figure links to the vendor's own page.
Most image weight on the web comes from serving pictures larger than they are displayed. Resizing to the actual rendered dimensions usually saves more than any format change. After that, modern formats, responsive sources and correct lazy loading deliver the remaining gains.
Optimizations by impact
| Optimization | Typical saving | Effort |
|---|---|---|
| Resize to rendered dimensions | Often 70-95% | Low |
| Convert to WebP or AVIF | 25-50% | Low |
| Tune quality to 80-85 | 20-40% | Low |
| Responsive srcset | Large on mobile | Medium |
| Lazy load below the fold | Faster initial load | Low |
| Strip unnecessary metadata | A few KB | Low |
| CDN with on-the-fly resizing | Compounding | Medium to high |
Serve at the size you display
Take the widest the image is ever rendered in CSS pixels, then double it for high-density screens. An image displayed at most 600 pixels wide needs a 1200 pixel source, not the 4000 pixel original.
Because file size scales with area rather than width, halving the dimensions cuts roughly three quarters of the bytes. This is why resizing outperforms every format-level tweak.
Format selection
| Content | Serve as | Fallback |
|---|---|---|
| Photograph, solid background | WebP lossy, quality 80-85 | JPEG |
| Cutout needing transparency | WebP lossy with alpha | PNG |
| Screenshot or flat UI graphic | WebP lossless | PNG |
| Logo or icon | SVG | PNG at 2x |
| Animation | MP4 or WebM video | Animated WebP |
Animated GIF is the single worst common choice. A short MP4 is routinely an order of magnitude smaller at better quality.
A delivery checklist
- Resize to maximum rendered size, doubled for high-density displays
- Export WebP at quality 80 to 85, keeping a lossless master
- Set explicit width and height attributes to prevent layout shift
- Lazy load below-the-fold images only; never the hero
- Use srcset where one image serves very different viewports
- Verify against a real measurement rather than assuming the change helped
Frequently asked questions
What is the biggest cause of slow-loading images?
Serving an image far larger than it is displayed. A 4000 pixel wide photo rendered in a 400 pixel column wastes roughly 99 percent of its data. Resizing to the rendered size typically beats every other optimization combined.
Which image format should I use on the web?
WebP is the practical default, supported by all current major browsers and typically 25 to 35 percent smaller than JPEG or PNG at equivalent quality. AVIF is smaller still but slower to encode. Keep JPEG or PNG as a fallback only if you must support very old clients.
How does image optimization affect Core Web Vitals?
The largest element on most pages is an image, so images usually determine Largest Contentful Paint directly. Images without width and height attributes also cause layout shift, which harms Cumulative Layout Shift.
Should I lazy load all images?
No. Lazy loading images above the fold delays your LCP element, making the page measurably worse. Lazy load below-the-fold images only, and let the hero image load eagerly.
What is srcset and do I need it?
srcset offers the browser several sizes of the same image and lets it pick based on viewport and pixel density. It matters when the same image serves both phones and desktops, because one file cannot be right for both without waste.
Do transparent PNGs slow pages down?
They can, since PNG is lossless and photographic content compresses poorly. Where transparency is needed, lossy WebP preserves the alpha channel at a fraction of the size. Keep the PNG as your master and serve WebP.