⚡ Image Optimization Guide: WebP vs AVIF (No Quality Loss)

Match the format to the image

• JPEG is still a solid choice for photographs and complex images. It uses lossy compression, which lets you reduce file size by discarding some image information. Too aggressive, and you'll notice blockiness, halos, or smeared detail.
• PNG supports lossless compression and transparency. It's often a good fit for screenshots, UI graphics, and crisp edges - but it can be unnecessarily large for photographs.
• WebP supports both lossy and lossless compression and can include transparency. It's a practical option for many website images and works in current browsers.
• AVIF can produce strong compression while keeping good visual quality, especially for photographic content. It's worth testing, but encoding time, your CMS/tooling support, and your audience's browsers matter.
• SVG is great for icons, logos, and illustrations made from shapes and paths. It's not a drop-in replacement for raster photos. Also: SVGs from untrusted sources should be handled carefully because they can contain active content.

Treat format guidance as starting points, not laws. A WebP file isn't automatically smaller than a well-optimized JPEG for every image, and AVIF isn't automatically the best choice if your pipeline can't generate it reliably or you don't have a dependable fallback. Compare the real output using representative assets from your site.

For most teams, a common approach is: serve a modern format when supported, and keep a compatible fallback through your image platform or content pipeline. Just make sure the fallback is actually working - test it, don't assume your CMS "has it handled."

Resize before you compress

If an image shows at 600 pixels wide but your uploaded source is 4,000 pixels wide, the browser may download far more data than the layout needs. Compression can't fully fix a source/display mismatch.

Start by measuring the largest display size in your design. Then account for high-density screens, where the same layout might need more source pixels to stay sharp. A 600-pixel slot might sometimes justify a 1,200-pixel source - but that doesn't mean every visitor should get that same file. Responsive image delivery can send smaller versions to smaller screens.

Let dimensions follow the actual layout. A blog card may need something like 600-800 pixels wide; an article lead image may need around 1,200 pixels. Those are examples, not rules. Measure your components, test how they behave at breakpoints, and generate sizes that match those use cases.

Also keep aspect ratios consistent when the design expects them. Cropping one source into several intentional variants is often better than shrinking the same uncropped image and hoping CSS will make every composition work. This matters for product photos - if a crop removes important details, that's a quality problem even if the file is technically sharp.

Compress against a visual target

Lossy compression can make a big difference for photographs, but there's no single quality number that preserves every type of detail. Text over an image, fine textures, gradients, and skin tones can all react differently as you change settings.

A reliable process looks like this:

1. Keep an original master file outside your delivery pipeline.
2. Generate a compressed version at the exact dimensions your site needs.
3. Compare the original and optimized images at the size visitors will see.
4. Inspect important details at full size - especially text, edges, skin tones, and gradients.
5. Save the settings you used, or automate them in your image pipeline.

Tools like Squoosh are helpful for visually comparing formats and settings. TinyPNG can be convenient for straightforward compression, and ImageMagick is useful when you want command-line processing as part of a repeatable workflow.

Avoid optimizing for one file-size target if it ignores content. A compressed product image that looks slightly soft can cost you trust, and the saved bytes won't always feel worth it. Your goal is the smallest file that still does its job convincingly.

Provide responsive image candidates

Responsive image delivery provides multiple versions of the same image and enough information for the browser to choose the right one. In HTML, the srcset and sizes attributes are commonly used. See the details in MDN's responsive images guide.

The key is to create real files at multiple widths (for example: small, medium, large) and describe how wide the image is expected to be in the layout. Then the browser can select the best candidate based on the viewport and display density.

This breaks down if your candidate URLs all point to the same oversized source, or if the declared widths don't match what's actually in those files. Check the generated files and test at different viewport sizes. If the layout shows the image near full phone width, it shouldn't be served a tiny candidate that looks soft on a high-density screen.

If your CMS or image CDN generates responsive variants, confirm the configuration instead of assuming it's correct. Some systems generate many sizes by default, others serve only the original upload. The real question is whether the pipeline produces predictable, useful outputs without forcing editors into manual cleanup on every publishing task.

Use lazy loading selectively

Lazy loading delays images below the initial viewport until they're closer to being needed. That can reduce unnecessary initial work on long articles, galleries, and pages with many product cards.

But don't apply it blindly. The main hero image (or any image that's visible immediately when the page opens) often matters for first impressions and can affect Largest Contentful Paint. If you delay that content, the page can feel slower even if total downloads drop. In practice: lazy-load images farther down the page, keep above-the-fold content ready, and - when your stack supports it - prioritize the likely largest content image instead of treating every image the same.

Test the actual page, not just the markup. On a short screen, an image "just below the fold" may still be needed almost immediately. A gallery far down a long product page is a more straightforward lazy-loading case. Context matters.

Reserve space to prevent layout shifts

When the browser doesn't know an image's dimensions before it loads, it may render the page without reserving the right space. Once the image arrives, text and controls can move around. That's frustrating and can contribute to Cumulative Layout Shift (CLS).

Provide the image's intrinsic width and height, or otherwise make its aspect ratio clear to the browser. The layout can then reserve the correct space before the file finishes downloading. Responsive CSS can still scale the image to fit its container - the intrinsic dimensions are about reserving proportions, not locking a fixed rendered size.

This is especially important with CMS content, third-party product feeds, and ad-driven systems, where the final asset dimensions may not be known ahead of time. If you still see shifting, inspect the full layout: late-loading ads, embedded content, late-loading fonts, and injected UI elements can all be responsible. Image dimensions help, but they won't fix every source of movement.

Write alternative text for the image's purpose

Alternative text should communicate the useful information conveyed by an image in its context. For a product photo, it might identify a model or a visible feature. For a chart, it may need to summarize the main takeaway or point readers to a fuller explanation in the surrounding text.

Decorative images that don't add information can use empty alternative text so assistive technology can skip them. Don't omit meaningful alt text, and don't stuff it with keywords. "Blue running shoe, side view, with white sole" is more useful than a string of repeated product terms.

Use descriptive filenames too - something maintainable beats camera-style character soup. But filenames aren't a reason to force keywords into every asset. Add a caption when readers need context, source information, or an explanation that doesn't fit naturally into alt text.

Measure pages before and after

After changing images, retest the important pages. Google PageSpeed Insights can show diagnostics and available field data. Browser developer tools can help you verify which files were requested, their sizes, and whether the expected responsive candidate was selected.

Don't judge improvements from one "perfect" page view. Check a representative set, such as:

• A typical article with a lead image and several images below the fold.
• A product or listing page with multiple thumbnails.
• A mobile layout on a slower connection or constrained device.
• Any page where the main image is part of the initial view.

Evaluate both performance and presentation. Look for fewer unnecessary downloads, correct modern formats, images that stay sharp enough, and layout that doesn't shift. If the page is still slow, investigate other contributors - server response, CSS and JavaScript, fonts, and third-party scripts. Smaller images help, but they don't prove the whole page is fast.

For ongoing sites, automate what you can make predictable: resize uploads, generate approved formats, preserve originals, and apply sensible compression defaults. Keep a way to review exceptions. A screenshot with small text, or a product photo that needs accurate color, may need different handling than a generic thumbnail. Automation should reduce repetitive work - not remove judgment where quality and meaning matter.

A publishing checklist

Before publishing or replacing an image, ask:

• Does the pixel size match the component and expected screen sizes?
• Is the format appropriate for the image content and your delivery setup?
• Does the compression look acceptable at the size visitors will see?
• Can the browser reserve the correct aspect ratio before the file loads?
• Is lazy loading appropriate for where the image sits on the page?
• Does the alt text describe meaningful content, or is the image truly decorative?
• Have you tested the key page and the mobile layout after the change?

Keep the checklist short. If the process takes so long that editors start skipping it, it's not a good production workflow. Move the repeatable steps into your upload pipeline, and keep human review for images where quality or meaning is sensitive.