Web Image Optimization Checklist: A Complete Guide

Photographs: Start with WebP, fall back to JPG. Use quality 75–80 for standard images, quality 70 for thumbnails, quality 85–90 for hero images or galleries. Test your specific images to find the threshold where you can't see visible degradation.

Graphics, logos, icons: Use PNG if transparency is required; otherwise consider WebP. WebP at quality 90+ often outperforms PNG for graphics while keeping file size competitive. Avoid JPG for anything with text or sharp edges.

Screenshots and UI mockups: PNG or WebP quality 85+. These images have hard edges where JPG artifacts are most visible. The extra quality is worth the minor file size increase.

Never ship a 4000×3000 image for a 400×300 display. That's wasteful bandwidth. Resize images to the maximum width they'll ever be displayed at, then let the browser scale down for smaller screens.

Use responsive images: create 3–4 versions at different widths (e.g., 400px, 800px, 1200px) and use `<picture>` or `srcset` attributes to let the browser download the version that fits its viewport. This alone cuts bandwidth by 30–50%.

Quick math: a 4000×3000 photo at quality 75 is 280 KB. Resized to 1200×900 for web, it's 30 KB. That's a 90% savings. Resizing is the single highest-impact optimization you can do.

Don't load images the user hasn't scrolled to yet. Add `loading="lazy"` to `<img>` tags, and the browser defers loading until the image approaches the viewport. This speeds up initial page load and saves bandwidth for images users never see.

For critical above-the-fold images (hero, product, main content), keep loading eager or omit the attribute. For images further down the page, lazy loading is free performance. Most modern browsers support it natively.

If you need older browser support, use a JavaScript lazy-loading library like `lqip` or `intersection-observer`. The performance gain is substantial enough to justify the extra library weight.

Tell the browser which image version to use based on the device's screen width and pixel density. Example: `<img src="image-sm.jpg" srcset="image-sm.jpg 400w, image-md.jpg 800w, image-lg.jpg 1200w" />`. Mobile devices download the small version, desktops the large one.

For high-DPI screens (Retina, modern phones), use pixel-density descriptors: `image.jpg 1x, image-2x.jpg 2x`. The browser downloads the higher resolution for sharp displays and the standard version for older phones.

Using responsive images correctly can cut mobile bandwidth by 60% compared to a one-size-fits-all approach. It's not optional for modern web performance.

Largest Contentful Paint (LCP): Images are often the LCP element. Compress them aggressively (quality 75–80), preload critical images with `<link rel="preload">`, and serve via CDN. Aim for LCP < 2.5s.

Cumulative Layout Shift (CLS): Always specify image dimensions (`width` and `height` attributes, or CSS aspect-ratio). Without dimensions, browsers don't reserve space, and when images load, they push content around, tanking your CLS score.

Interaction to Next Paint (INP): Less directly related to images, but responsive images reduce page load time, which indirectly improves INP. Slower pages = slower interactions.

Serve images from a CDN (Cloudflare, Imgix, Fastly) instead of your origin server. CDNs cache images at edge locations closer to users, reducing latency and bandwidth costs. Many CDNs also optimize on-the-fly: resize, reformat, and re-compress based on the requesting device.

Set long cache headers on images: `Cache-Control: public, max-age=31536000` (one year). Since images rarely change, aggressive caching is safe and dramatically improves repeat-visit speed.

Use cache-busting for image updates: include a version number in the filename (e.g., `hero-v2.jpg`). The CDN treats it as a new image, so users get the update immediately even with long cache headers.

Use build-time optimization: tools like Squoosh, ImageMagick, or Sharp automatically convert and resize during your build process. Next.js Image component and Astro Image do this for you.

Monitor performance: track actual image file sizes and load times using Google Analytics and Core Web Vitals reports. Set targets (e.g., avg image size < 150 KB, LCP < 2.5s) and optimize toward them.

Consider a service like img-toolbox for batch processing: upload a folder of photos, download optimized versions for web in minutes. Use it for bulk projects or testing different compression settings.