Why Image Compression Matters for Web Performance
Images directly impact three of Google's Core Web Vitals metrics:
- Largest Contentful Paint (LCP): The hero image or banner is often the LCP element. If it takes 4 seconds to load a 2MB JPEG, your LCP fails the 2.5-second threshold. Compressing that image to 200KB can bring LCP under 1 second on a fast connection.
- Cumulative Layout Shift (CLS): Images without explicit width and height attributes cause layout shifts as they load. Proper image handling (with dimensions specified) eliminates this.
- Interaction to Next Paint (INP): Heavy images can block the main thread during decoding, delaying user interactions. Smaller, properly formatted images decode faster.
Beyond Core Web Vitals, every 100KB you save on an image translates to real cost savings for users on metered connections and faster load times on cellular networks. The median mobile page loads over 2MB of images. Cutting that in half improves the experience for everyone.
Format Selection Guide
Choosing the right format is the highest-impact compression decision you can make. The format determines the compression algorithm, which has a larger effect than any quality slider.
Format Recommendations by Content Type
| Content Type | Best Format | Fallback | Why |
|---|---|---|---|
| Photographs | AVIF | WebP, then JPEG | AVIF excels at complex photographic content with 50% savings over JPEG |
| UI screenshots | WebP lossless | PNG | Sharp text and flat colors compress well losslessly; WebP lossless is 25-30% smaller than PNG |
| Logos / icons | SVG | WebP lossless or PNG | Vector graphics should remain vector; raster fallback should be lossless |
| Illustrations with transparency | WebP or AVIF | PNG | Both support alpha; lossy with alpha is dramatically smaller than PNG |
| Animations | Animated WebP | GIF | Animated WebP is 40-90% smaller than GIF with better color depth |
| Hero / banner images | AVIF | WebP, then JPEG | LCP-critical; maximum compression matters most here |
Quality Settings Sweet Spots
Every format has a quality range where you get the best balance of compression and visual fidelity. Going below these thresholds introduces visible artifacts; going above wastes bytes with no perceptible improvement.
JPEG Quality Settings
- Photography: Quality 75-85. Below 70, blocking artifacts become visible on detailed areas. Above 85, file size increases rapidly with no visible improvement.
- E-commerce product images: Quality 82-88. Slightly higher than general photography because buyers scrutinize product details.
- Thumbnails: Quality 60-70. Small display sizes hide compression artifacts.
WebP Quality Settings
- Photography: Quality 75-82. WebP's quality scale produces cleaner results than JPEG at the same number, so you can use slightly lower values.
- Graphics/screenshots: Use lossless mode (quality 100). WebP lossless is smaller than PNG for almost all inputs.
- Thumbnails: Quality 60-70.
AVIF Quality Settings
- Photography: Quality 50-65 (on a 0-100 scale). AVIF's scale is not comparable to JPEG's; AVIF quality 60 often looks as good as JPEG quality 85.
- Note: AVIF encoding at high quality settings is slow. Use speed presets (effort/speed setting) to balance encode time vs compression ratio.
Responsive Images Strategy
Serving a single 2400px-wide image to both desktop and mobile is one of the most common performance mistakes. A phone with a 400px-wide viewport does not need a 2400px image, even on a 3x retina display (1200px would suffice).
Use the HTML srcset and sizes attributes to serve appropriately sized images:
- Generate 3-5 width variants: Common breakpoints are 400w, 800w, 1200w, 1600w, and 2000w
- Set the sizes attribute: Tell the browser how wide the image will actually display so it can choose the correct variant
- Combine with format selection: Use
<picture>with<source>elements to serve AVIF, WebP, and JPEG variants at each size
A properly configured responsive image setup can reduce total image bytes by 50-70% compared to a single full-size source, on top of the format-based compression savings.
Lazy Loading
Images below the viewport fold should be lazy-loaded so they do not compete with above-the-fold content for bandwidth:
- Use
loading="lazy"on all images except the LCP image and critical above-the-fold content - Never lazy-load the LCP image. This delays the most important metric. The LCP image should load eagerly with
fetchpriority="high" - Set explicit width and height on all images (lazy or not) to prevent layout shifts
Common Mistakes to Avoid
- Serving JPEG at quality 100: There is no visual difference between JPEG quality 95 and 100, but the file size can be 2-3x larger. Quality 100 disables chroma subsampling, which inflates size for no perceptible benefit.
- Using PNG for photographs: PNG is lossless, which makes it excellent for graphics but terribly inefficient for photographs. A 1MB PNG photo typically compresses to 100-200KB as a JPEG or WebP with no visible difference.
- Ignoring EXIF metadata: Camera EXIF data (including GPS coordinates, camera model, and settings) can add 50-200KB per image and is rarely needed for web delivery. Strip metadata before publishing unless you specifically need it.
- Resizing in CSS instead of the source: If you display an image at 400x300 but serve a 4000x3000 source, the browser downloads 10x more data than necessary and then downscales it. Resize at the source.
A Practical Compression Workflow
Here is a step-by-step workflow that balances quality and performance:
- Step 1: Start with the highest-quality source available (original photo, export from design tool at maximum quality)
- Step 2: Resize to the maximum display dimensions you need (not larger)
- Step 3: Export to AVIF (quality 55-65) as your primary format
- Step 4: Export to WebP (quality 75-82) as your fallback
- Step 5: Export to JPEG (quality 80-85) as your legacy fallback
- Step 6: Compare all three outputs visually to verify quality is acceptable
- Step 7: Serve using
<picture>with AVIF, WebP, and JPEG sources
How FastEdit Helps
FastEdit is built specifically for this workflow. You can load any image and instantly compare different formats and quality settings side-by-side. The fit-to-size feature lets you set a target file size (e.g., "under 100KB") and the tool finds the optimal quality setting to hit that target.
For batch processing, FastEdit can compress an entire folder of images in one pass, applying consistent settings across all files. Since everything runs locally via WebAssembly, there are no upload wait times and no file size limits imposed by a server.
Key features for web optimization:
- Side-by-side comparison: See AVIF vs WebP vs JPEG at the same quality target
- Fit-to-size: Target a specific file size and let the tool optimize quality automatically
- Batch processing: Compress hundreds of images with consistent settings
- EXIF stripping: Remove metadata to save additional bytes
- Resize: Scale images to target dimensions before compression