Prepare lighter web-ready images without uploading them to a remote server.
Most optimization guides skip this step entirely. That's backwards. Without a target file size, you're compressing blindly and hoping the result is "good enough."
Real-world targets by context:
Write your target down. It becomes your pass/fail criterion for every subsequent step.
Format selection isn't about preference. It's about matching the image's content characteristics to a codec's compression strengths. Get this wrong, and no amount of compression tweaking will save you.
Decision matrix based on content type:
Use WebP when the image contains photographic content (gradients, smooth color transitions, natural textures). WebP's lossy compression handles these 25–35% more efficiently than JPEG at equivalent visual quality. It also supports transparency — so if you have a product photo on a transparent background, WebP replaces both the JPEG and the alpha-channel PNG in one file.
Use JPEG when you need maximum compatibility with older systems or email clients, or when you're already serving WebP with JPEG as a fallback. JPEG is the safe default for photographs in contexts where browser support can't be assumed.
Use PNG only for images with sharp edges, flat colors, text, or pixel-level transparency requirements — logos, icons, screenshots with UI elements, and diagrams. PNG's lossless compression is efficient for these content types but wasteful for photographs (a PNG photo can be 5–10× larger than the same image as JPEG).
Use SVG for logos, icons, and simple illustrations that can be described with vector paths. An SVG logo is typically 2–15KB regardless of display size, while a PNG equivalent at retina resolution can exceed 100KB.
Avoid GIF for anything except animation. If the image is static, GIF's 256-color limitation and inferior compression make it the worst choice in every scenario.
One format decision that saves more bytes than hours of compression tweaking: if your image has a transparent background and contains photographic elements, convert it from PNG to WebP. A 500KB 24-bit PNG with alpha often compresses to 60–90KB as WebP with no perceptible quality loss.
This is where most of the hidden file-size bloat lives. A 4000×3000 pixel image displayed in a 800×600 container forces the browser to download 12 million pixels when it only needs 480,000. That's a 25× waste.
How to determine the right dimensions:
Check your CSS. Find the container width where the image will be displayed. If your content area is 1200px wide maximum, no image in that column needs to exceed 1200px wide. For responsive layouts, check the largest breakpoint — typically desktop at 1920px, 1440px, or 1280px depending on your design.
The 2× retina rule: Multiply your maximum display width by 2 for retina displays, but rarely more. A 600px-wide product image should be uploaded at 1200px wide maximum. Uploading at 3000px "just in case" wastes bandwidth for every single visitor.
Specific dimension targets:
Resizing before compression yields better results than compressing first. A 4000px image resized to 1200px and then compressed at quality 80 will be both smaller and sharper than a 4000px image compressed to quality 40.
The lossy vs. lossless decision isn't philosophical. It's mathematical, and it depends entirely on what the image contains.
Lossy compression discards data that human vision is less likely to notice — subtle color variations in smooth gradients, fine noise in shadow areas, imperceptible details at high spatial frequencies. For photographs and complex images, this is the right choice. A JPEG or WebP at quality 75–85 removes information you genuinely cannot see, and the file size reduction is dramatic: typically 60–80% smaller than the original.
Lossless compression preserves every single pixel. It works by finding patterns in the data and encoding them more efficiently — like a zip file for images. For screenshots, UI elements, images with text, and pixel art, lossless (or near-lossless) compression is appropriate because any artifact in sharp-edged, high-contrast content becomes immediately visible.
The practical decision:
A common trap: using lossless compression on photographs and assuming you're getting "better quality." You're not. You're getting identical quality at 3–5× the file size. Lossless compression on photographs typically achieves only 10–20% size reduction because photographs have very little repeated data to exploit.
After optimization, don't just check the file size. Run through this validation:
Visual check: Open the optimized image at 100% zoom on a calibrated display. Look for banding in skies and gradients, color shifts in skin tones, ringing artifacts around sharp edges, and blurring in areas that should be crisp. If you see any of these, your compression quality is too aggressive for that specific image.
File size check: Compare against your target from Checklist Item 1. If you're over budget, resize dimensions first (Checklist Item 3), then adjust compression quality second. Never try to solve a dimension problem with more compression.
Format verification: Confirm the file extension matches the actual format. A JPEG file renamed to .webp is still a JPEG — browsers may reject it or handle it incorrectly.
Metadata check: Strip EXIF data unless it serves a specific purpose (copyright, GPS for mapping applications). EXIF data from a phone camera can add 50–200KB of invisible metadata. Most optimization tools handle this automatically, but verify.
Progressive rendering check: For JPEGs intended as hero images or LCP elements, ensure progressive encoding is enabled. Progressive JPEGs render a low-quality preview immediately and refine as the file loads, creating a better perceived performance even at the same file size as baseline JPEG.
Here's the complete optimization workflow in execution order. This sequence matters — each step builds on the previous one, and reversing the order produces worse results.
Step 1: Determine context. Where does this image appear? What's the maximum display size? This sets your dimension target.
Step 2: Choose format. Based on content type and transparency needs, select WebP, JPEG, PNG, or SVG.
Step 3: Resize to target dimensions. Downscale before compressing. Use Lanczos resampling for photographs, nearest-neighbor for pixel art.
Step 4: Apply compression. Set quality based on your file-size target and content type. Start at quality 80 for lossy formats and adjust.
Step 5: Strip metadata. Remove EXIF, IPTC, and XMP data unless specifically needed.
Step 6: Validate. Check visual quality, file size, and format correctness.
Step 7: Implement responsive delivery. If you're serving multiple sizes, generate the variant set and use srcset attributes so mobile devices don't download desktop-sized images.
For batch processing — when you're optimizing dozens or hundreds of images at once — a web image optimizer that handles resizing, format conversion, compression, and metadata stripping in a single pass saves significant time over manual processing. The key is choosing a tool that lets you control each variable independently rather than applying a blanket "optimize" preset that makes decisions for you.
Even with a solid workflow, these errors are common enough to warrant their own checklist:
1. Optimizing the master file. Always work from a copy. If you over-compress and save over the original, that data is gone. Keep untouched originals in a source folder and generate optimized versions separately.
2. Using the same quality setting for every image. A dark, low-detail nighttime photo tolerates quality 65 without visible degradation. A bright landscape with fine foliage detail needs quality 82 to avoid banding. Uniform settings either waste bandwidth on easy images or damage difficult ones.
3. Forgetting about the container. An image optimized to 50KB is irrelevant if your CSS loads a 2MB background image, or if your CMS generates unoptimized thumbnails at 3× the needed dimensions. Audit the entire image pipeline, not just individual files.
4. Ignoring mobile dimensions. If 60% of your traffic is mobile (check your analytics — it probably is), optimizing only for desktop display sizes means most of your visitors download unnecessarily large files. Responsive image delivery isn't optional.
5. Compressing already-compressed images. Running a JPEG that's already at quality 70 through another round of JPEG compression at quality 70 introduces double artifacts without meaningfully reducing file size. If you need to re-optimize, start from the original.