Image Compression Guide
A practical workflow that optimizes dimensions, format, quality, and responsive delivery—instead of merely lowering a quality slider. Learn why decisions differ for editorial photos, product imagery, and UI screenshots, and how to review the result before publishing.
Written and reviewed by yuuLast reviewed:
1. Set pixel dimensions before compression quality
Serving a 4000-pixel camera original in a 400-pixel card transfers detail the layout cannot display. Before making the quality slider aggressive, resize near the real display width plus an appropriate high-density candidate. This can produce a large reduction while preserving visible quality.
A useful pattern is one candidate near the CSS display width and another near twice that width for high-density screens. Do not always send the largest one: use srcset and sizes so the browser can select an appropriate resource.
- Article body: measure the content column and avoid serving originals far beyond it.
- Product zoom: separate listing and zoom assets; do not preload the zoom original in every card.
- Hero art: when composition fails across breakpoints, create alternate crops rather than only scaling.
2. Match the format to the image
Photos with continuous tones generally suit lossy JPEG or WebP. Logos, diagrams, and interface screenshots with hard edges and text should be compared as PNG and WebP. If the source is vector artwork, keeping it as SVG may be better than rasterizing it.
JPEG cannot preserve transparency. When converting a transparent PNG, verify the chosen background. WebP can handle photographic and transparent content, but compatibility across the publishing and editing workflow still belongs in the decision.
- JPEG: photographs, no alpha channel, and broad compatibility for distribution.
- WebP: a candidate for both photos and transparency; compare actual files against JPEG or PNG.
- PNG: transparency, fine lines, text, and screenshots where lossy artifacts are unacceptable.
- SVG: logos and simple vector art; sanitize untrusted SVG rather than publishing it directly.
3. Lower quality gradually and compare at real size
A quality number does not mean the same thing across formats or encoders. Start relatively high, lower it in steps, and compare both bytes and appearance. Review at 100% zoom and at the size visitors will see in the actual page.
Faces, hair, fine text, product labels, gradients, and shadows reveal artifacts quickly. Inspect critical regions for smearing, blocking, ringing, and banding instead of judging the image only as a full-page thumbnail.
- Photos: inspect skin, hair, foliage, fabrics, and dark gradients.
- Products: preserve logos, model numbers, texture, and color needed for a purchase decision.
- UI: verify small text, one-pixel lines, and icon boundaries.
- Compare at identical dimensions, scale, and background color.
4. Derive byte targets from a page budget
A rule such as “every blog image must be under 300 KB” ignores dimensions, quantity, and placement. Separate above-the-fold imagery, below-the-fold editorial images, and zoom-only product assets. Prioritize from total page weight and the effect on Largest Contentful Paint.
Smaller is better at equivalent quality, but saving a few kilobytes is not worth making product information or text unreadable. Record original and output size, reduction, dimensions, and format so the team does not repeatedly recompress an already lossy asset for marginal gains.
5. Verify delivery after export
A smaller file helps less when markup always chooses the largest candidate. Reserve layout space with width and height, configure srcset and sizes, and lazy-load offscreen assets when appropriate. Do not indiscriminately lazy-load the LCP image, which can delay the main visual.
Export can remove EXIF and other metadata. That may remove unwanted location data, but the production original should remain available when capture details or color management matter. Do not make the optimized derivative the only master copy.
Pre-publish checklist
- Pixel dimensions match display
- Formats compared for the content
- Critical regions reviewed at real size
- Transparency conversion checked
- Before/after bytes recorded
- Width and height declared
- srcset and sizes verified
- Original asset retained
Related tools
Primary references
- web.dev — Serve responsive imagesGoogle's technical guidance on responsive candidates and their effect on LCP.
- web.dev — Responsive imagesImplementation guidance covering srcset, art direction, format choice, and compression.