Image compression is the single highest-impact performance optimization most websites can make. Unoptimized images account for over 50% of total page weight on the average site, and a single 3MB hero image can push your Largest Contentful Paint (LCP) past Google's "poor" threshold of 4 seconds. This guide covers the formats, quality settings, and tooling you need to compress images for the web in 2026.
Why Image Compression Matters
Images are typically the largest assets on a web page. On a typical blog post, images account for 60-80% of the total bytes downloaded. On an e-commerce product page, they can hit 90%. This matters for three reasons:
- Performance: Mobile users on 4G connections wait 2-5 seconds for every additional megabyte. A 3MB page takes 6 seconds; a 500KB page takes 1 second.
- Core Web Vitals: Google's Largest Contentful Paint (LCP) metric directly correlates with image weight. Faster LCP = better search rankings.
- Bandwidth costs: CDNs charge per GB transferred. A 70% image size reduction is a 70% bandwidth cost reduction for image-heavy traffic.
Image Formats for 2026
The format landscape has shifted significantly. JPEG and PNG are no longer the right defaults for new projects.
| Format | Best For | Compression | Browser Support (2026) |
|---|---|---|---|
| AVIF | Photographs, hero images | Best (50% smaller than JPEG) | 95%+ (Chrome, Firefox, Safari, Edge) |
| WebP | Photographs, transparent images | Good (25-35% smaller than JPEG) | 98%+ (all modern browsers) |
| JPEG | Fallback for older browsers | Baseline | 100% |
| PNG | Logos, icons, screenshots with text | Lossless only | 100% |
| GIF | Simple animations (use MP4/WebM instead) | Poor for photos | 100% |
| SVG | Vector graphics, logos, icons | Excellent (text-based, scales infinitely) | 100% |
The modern stack: serve AVIF with WebP and JPEG fallbacks using the <picture> element:
<picture>
<source srcset="hero.avif" type="image/avif" />
<source srcset="hero.webp" type="image/webp" />
<img src="hero.jpg" alt="Hero image" width="1200" height="630" fetchpriority="high" />
</picture>
Lossless vs Lossy Compression
Lossless compression preserves every pixel of the original image exactly. PNG and lossless WebP use this approach. File sizes are larger because no visual information is discarded. Use lossless when:
- The image contains text (artifacts are obvious around character edges)
- The image is a logo or icon with sharp edges
- The image will be edited further (lossy-then-edit amplifies artifacts)
- You're archiving original-quality images
Lossy compression discards visual information that the human eye is unlikely to notice — high-frequency detail in flat areas, subtle color variations, fine texture. JPEG, lossy WebP, and AVIF use this approach. File sizes are 5-10x smaller than lossless for visually equivalent quality. Use lossy for:
- Photographs (the dominant use case)
- Hero images and background photos
- Product photos on e-commerce sites
- Any image where small artifacts are acceptable in exchange for size reduction
Quality Settings — What Number to Pick
Quality is a 1-100 number that controls how aggressively lossy compression discards data. Lower = smaller file, more visible artifacts. Higher = larger file, less visible artifacts.
| Format | Quality Range | Sweet Spot | Notes |
|---|---|---|---|
| JPEG | 1-100 | 75-80 | Below 70, artifacts in gradients and skin |
| WebP | 1-100 | 75-85 | 5-10 points higher than JPEG for equivalent quality |
| AVIF | 1-100 | 50-65 | AVIF needs lower numbers due to better codec |
| PNG | N/A (lossless) | — | Use PNG-8 for <256 colors, PNG-24 for full color |
Always test compression on a representative sample of your actual images. Generic stock photos compress differently than screenshots, which compress differently than product photos with white backgrounds.
Responsive Images — srcset and sizes
Don't serve the same image file to a 1920px desktop and a 375px phone. Generate multiple sizes and use srcset to let the browser pick the right one:
<img
src="hero-1200.jpg"
srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1200.jpg 1200w, hero-2000.jpg 2000w"
sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
alt="Hero image"
/>
The browser calculates which source to fetch based on the viewport width and the sizes attribute. A 375px phone fetches hero-400.jpg (40KB); a 1920px desktop fetches hero-2000.jpg (200KB). Total bandwidth savings: 80% on mobile compared to serving the 2000px version to everyone.
Image Compression and Core Web Vitals
Core Web Vitals is Google's set of performance metrics that directly influence search rankings. Three metrics, all affected by image weight:
- LCP (Largest Contentful Paint): When the largest visible element renders. Usually a hero image. Compressing the LCP image from 2MB to 200KB can improve LCP by 2-4 seconds on mobile.
- CLS (Cumulative Layout Shift): Layout stability. Images without width/height attributes cause reflows when they load. Always set explicit dimensions on images.
- INP (Interaction to Next Paint): Indirectly affected — heavy images block the main thread during decoding. Smaller images decode faster.
For LCP optimization specifically:
- Preload the LCP image:
<link rel="preload" as="image" href="hero.avif" /> - Add
fetchpriority="high"to the LCP image element - Avoid lazy-loading the LCP image (lazy-loading delays it)
- Use AVIF or WebP for the smallest possible file
- Serve the right resolution via srcset — don't make mobile phones download a 2000px image
Compression Tools — Online and CLI
For one-off compression without installing software, use our Image Compressor — it runs in your browser, supports JPEG/PNG/WebP, and lets you adjust quality interactively while seeing the size and visual difference in real time.
For batch processing in a build pipeline:
- Sharp (Node.js): The de facto image processing library. Used by Next.js Image Optimization. Fast, supports all formats.
- Squoosh CLI: Google's reference implementation. AVIF, WebP, MozJPEG, OxiPNG.
- ImageMagick: The classic CLI. Available everywhere.
- cwebp / avifenc: Official Google/WebP and AVIF encoders. Maximum control, minimal UX.
Common Image Compression Mistakes
- Using PNG for photographs. PNG's lossless compression produces 5-10x larger files than JPEG for photographic content.
- Not setting width/height attributes. Without dimensions, the browser doesn't reserve space for the image, causing layout shift (poor CLS).
- Serving the same image to all devices. A 2000px hero image is wasted on a 375px phone. Use srcset.
- Lazy-loading above-the-fold images. Lazy-loading the LCP image delays it. Only lazy-load below the fold.
- Forgetting to compress images in CI. Developers add uncompressed images to the repo. Add a pre-commit hook.
- Using GIF for video. Animated GIFs are 10-50x larger than equivalent MP4/WebM. Use video elements.
Summary — Practical Recommendations
- Serve AVIF with WebP fallback for all photographic content.
- Use PNG only for images requiring transparency or with sharp edges (logos, icons, screenshots).
- Quality 75-80 for JPEG, 75-85 for WebP, 50-65 for AVIF.
- Always set explicit width and height attributes to prevent layout shift.
- Use srcset to serve the right resolution to each device.
- Preload and
fetchpriority="high"the LCP image. - Lazy-load below-the-fold images, never the LCP.
- Compress images in CI to prevent uncompressed images from shipping.
Tools for compressing and transforming images:
- Image Compressor — browser-based JPEG/PNG/WebP compression
- Image Resizer — resize to specific dimensions for srcset
- Image Cropper — crop to aspect ratio
- Convert to JPG — convert from PNG/WebP/AVIF
- Background Remover — for product photos that need transparent backgrounds