Image Optimization 2026: WebP, AVIF and Responsive Delivery

The numbers speak clearly: According to HTTP Archive, the median page size for desktop websites in 2025 is around 2.4 MB, with images accounting for an average of 1.2 MB (Source: HTTP Archive, 2025). On mobile devices, the ratio is even worse, as the same desktop images are often served despite the screen displaying only a third of the pixels. This waste costs not only loading time but also real money: with capped mobile data plans, users literally pay for unnecessarily large images.

The Largest Contentful Paint (LCP) measures when the largest visible element in the viewport is fully rendered. For most websites, this element is an image -- the hero image, a product photo or a banner. Google defines an LCP under 2.5 seconds as good (Source: Google, 2024). Websites with unoptimized LCP lose an average of 7 percent of conversions per additional second of loading time (Source: Portent, 2022). This makes image optimization a direct revenue driver.

But image optimization goes far beyond simply compressing files. A holistic approach encompasses choosing the right format, providing different sizes for different devices, a thought-out loading strategy and automation of the entire process. Anyone who considers all these aspects can reduce the data volume caused by images by 80 to 95 percent -- without visible quality loss.

WebP was developed by Google and has been available since 2010. Today, 96 percent of all active browsers support the format (Source: Can I Use, 2025), including Safari from version 14. WebP offers both lossy and lossless compression and supports transparency (alpha channel) as well as animations. Compared to JPEG, WebP achieves 25 to 35 percent smaller files at the same visual quality (Source: Google Developers, 2024).

WebP's strength lies in its universal support. Unlike newer formats, WebP is available in virtually every modern browser, making it the safe default choice for image delivery. The lossy compression uses a VP8-based algorithm that works particularly efficiently with photographic content featuring many color gradients. The lossless variant is suitable for graphics, screenshots and images with text where every detail must be preserved.

An important aspect of WebP conversion is the quality setting. The default value of 75 percent quality delivers a good balance between file size and visual quality for most use cases. For hero images and product photos, we recommend a quality of 80 to 85 percent; for thumbnails and background images, 60 to 70 percent suffices. This differentiation alone saves an additional 15 to 25 percent of data volume compared to a uniform quality value.

AVIF (AV1 Image File Format) is based on the AV1 video codec and represents the current state of the art in image compression. The format was specified in 2019 and has rapidly gained browser support in recent years: 92 percent of all active browsers now support AVIF (Source: Can I Use, 2025). Chrome, Firefox, Safari from version 16 and Edge offer full support. Compared to JPEG, AVIF achieves 50 to 70 percent smaller files at the same visual quality, and compared to WebP it is still 20 to 35 percent smaller (Source: Netflix Technology Blog, 2024).

AVIF's technical advantages extend beyond pure compression ratios. The format supports HDR (High Dynamic Range), a color space of 10 and 12 bits per channel, as well as transparency and film grain synthesis. For web applications, the superior compression at low bitrates is particularly relevant: where WebP produces visible artifacts with aggressive compression, AVIF still delivers appealing results. This makes AVIF ideal for mobile delivery, where every saved kilobyte counts.

The main disadvantage of AVIF is encoding speed. Creating an AVIF file takes significantly longer than WebP or JPEG -- depending on settings, 5 to 20 times as long. For static websites and shops where images are converted once upon upload, this is not a problem. For applications that need to convert images in real-time, encoding time can become a bottleneck. Decoding in the browser, however, is fast and presents no bottleneck.

The choice between WebP and AVIF is not an either-or question. In practice, both formats should be used in parallel, with the browser selecting the optimal format via content negotiation or the HTML picture element. The delivery chain follows a clear hierarchy: AVIF as the preferred format, WebP as fallback, and JPEG as universal safety net for the remaining 4 percent of browsers without WebP support.

For photographic content -- product photos, team images, hero images -- AVIF is almost always the best choice. Its superior compression at low bitrates is particularly noticeable with large color gradients, skin tones and fine details. For graphics with sharp edges -- screenshots, diagrams, logos -- lossless WebP often delivers better results than AVIF, since the AV1 codec is primarily optimized for natural images.

Another factor is the encoding infrastructure. If images are uploaded via a CMS or shop and need to be converted in real-time, slow AVIF encoding can become problematic. In this case, we recommend creating AVIF variants asynchronously in the background and serving WebP until they are ready. For static websites built via a build process, encoding time is irrelevant since conversion happens once during the build.

The most common form of image waste is not the wrong format but the wrong size. When a 2400-pixel-wide image is displayed on a smartphone with a 400-pixel viewport width, 83 percent of the transferred pixels are never visible. The srcset attribute solves this problem by offering the browser multiple size variants of the same image and letting it choose the optimal variant.

A well-designed srcset setup typically includes four to six breakpoints: 400w for smartphones, 800w for tablets, 1200w for desktop screens and 2400w for retina displays. The sizes attribute tells the browser how wide the image actually is in the layout, so it can choose the right variant without having to parse the CSS first. For example: sizes="(max-width: 640px) 100vw, (max-width: 1024px) 50vw, 33vw" tells the browser that the image takes up the full width on smartphones, half on tablets and one-third on desktops.

The combination of picture, source and srcset enables simultaneous format and size selection. Each source element defines a format with its associated size variants, and the browser chooses both the best format and the appropriate size. This technique virtually eliminates image waste -- the actually transferred image is always as close as possible to the actually needed size.

Even perfectly compressed and responsively delivered images burden initial load time if they are all loaded simultaneously. Lazy loading defers the loading of images until they scroll into or are about to enter the browser's visible area. The native loading="lazy" attribute is supported by 96 percent of browsers (Source: Can I Use, 2025) and requires neither JavaScript nor external libraries.

Correct implementation distinguishes between above-the-fold and below-the-fold images. The LCP image and all other images in the initial viewport should not be lazy-loaded, as this would worsen Core Web Vitals. Instead, they receive loading="eager" and fetchpriority="high" so the browser loads them with priority. All images below the visible area receive loading="lazy" and decoding="async". This combination significantly reduces initial HTTP requests and transferred data volume.

A common mistake with lazy loading is missing width and height attributes. Without explicit dimensions, the browser cannot reserve space for the image, leading to layout shifts when it loads -- the Cumulative Layout Shift (CLS), one of the three Core Web Vitals. The solution is simple: every img element receives its intrinsic dimensions as width and height, combined with style="aspect-ratio: auto" or a CSS aspect-ratio container. This keeps the layout stable even before the image loads.

Choosing the right compression quality is critical to the result. Overly aggressive compression produces visible artifacts -- blocking, color distortion and detail loss. Overly conservative compression wastes bandwidth without visible quality gains. The optimal setting depends on the image type, intended use and format.

For WebP, we recommend a differentiated strategy: hero images and product photos at quality 80-85, general content images at quality 72-78 and thumbnails and preview images at quality 60-68. For AVIF, optimal values are lower since the codec produces fewer artifacts at the same quality level: hero images at quality 65-72, content images at quality 55-65 and thumbnails at quality 45-55. This differentiation saves 20 to 40 percent of data volume compared to a uniform quality value for all images.

A professional quality comparison should always be both visual and metric. The SSIM index (Structural Similarity Index) quantifies the perceived quality difference between the original and compressed image on a scale of 0 to 1. An SSIM of 0.95 or higher means the difference is practically imperceptible to the human eye. Tools like libvips and sharp can automatically calculate SSIM, allowing the optimal quality level to be determined individually for each image.

An image CDN takes over the entire image optimization as an external service: format conversion, resizing, quality optimization and delivery via a global edge network. The advantage lies in simplicity -- instead of building your own pipeline, all image URLs point to the CDN service, which performs transformations on-the-fly and caches the results.

The architecture of an image CDN follows a URL-based transformation model. Parameters like format, width, quality and crop are encoded directly in the URL. The first request triggers the transformation and stores the result in the edge cache. All subsequent requests are served directly from the cache without repeated transformation. This architecture is particularly suitable for e-commerce shops with thousands of product images needed in various sizes and formats.

For websites with self-hosted infrastructure, open-source solutions offer an alternative to commercial image CDNs. Tools like imgproxy or thumbor can be run as Docker containers and offer similar transformation capabilities. The effort for setup and operation is higher, but ongoing service costs are eliminated. We recommend self-hosted solutions for projects with predictable image volumes and commercial image CDNs for projects with highly variable or very high volumes.

For static websites and shop systems where images are known at build time, a build pipeline is the most efficient approach. The pipeline automatically converts each source image into all required formats and sizes and generates the associated picture elements. Changes to the source image automatically trigger regeneration of all variants.

A typical pipeline consists of four steps: First, source images are analyzed -- dimensions, color profile and content determine the optimal compression setting. Then the pipeline generates size variants according to defined breakpoints. In the third step, all variants are converted to WebP and AVIF, with quality settings depending on image type. Finally, the HTML picture elements with all sources and srcsets are generated. The entire process runs automated and reproducibly.

Integration into existing build systems like Vite, webpack or Gulp is straightforward with libraries such as sharp or @squoosh/lib. For Shopware-based shops, plugins enable conversion during image upload or as batch processing. The key is that the process requires no manual intervention -- every uploaded image is automatically optimally prepared without editors or shop operators having to worry about formats and compression.

The biggest challenge of image optimization is not technology but workflow. When editors upload images via a CMS, optimization must happen transparently in the background. An upload of 5 MB camera JPEGs must not result in them being served unchanged to visitors. Instead, the system should automatically generate variants and produce the picture element.

For Shopware-based shops, there are several approaches: The thumbnails configuration generates size variants on upload but must be correctly configured for optimal results. The default breakpoints (400, 800, 1920 pixels) cover the most important device classes but should be supplemented with a retina variant (2x the desktop width). For format conversion to WebP and AVIF, server-side plugins or an upstream image service are required.

A frequently overlooked aspect is metadata stripping. Camera images contain EXIF data, ICC color profiles and thumbnail previews that together can amount to several hundred kilobytes. This data is not relevant for web display and should be removed on upload. Stripping EXIF data alone typically saves 50 to 200 KB per image for photos -- for a shop with 10,000 product images, this adds up to several gigabytes of unused data.

The Largest Contentful Paint is the Core Web Vital metric most strongly influenced by image optimization. In 72 percent of all cases, the LCP element is an image (Source: Web Almanac, 2024). Optimizing the LCP image requires a different approach than general image optimization, as delivery speed takes priority over file size.

The most important measures for a fast LCP image are: Preload via in the HTML head, so the browser loads the image as early as possible. No lazy loading for the LCP image -- it must be served with loading="eager". Inline CSS for the image container, so the browser knows the dimensions before the CSS sheet is loaded. And DNS prefetch for external image sources, to perform DNS resolution in parallel with HTML parsing.

A common mistake is serving the LCP image via JavaScript or CSS background images. Both variants delay loading because the browser can only discover the image once the JavaScript or CSS is fully parsed. The LCP image should always be a regular element or inside a element in the HTML, so the browser's preload scanner can detect and prioritize it during HTML parsing.

The effectiveness of image optimization must be continuously measured. The most important metrics are LCP as a Core Web Vital, total image data size per page, number of image requests and the proportion of modern formats in total image delivery. A professional performance monitoring setup captures these metrics automatically and alerts on regressions.

Analysis by device type is particularly insightful. Mobile users with slow connections are most affected by suboptimal image optimization. The Chrome User Experience Report (CrUX) field data shows the actual LCP distribution for different device types and connection speeds. If mobile LCP is significantly worse than desktop LCP, the cause is often missing responsive image variants.

For continuous optimization, we recommend a monthly image audit: Which pages have the most image data? Which images are served in outdated formats? Which images are missing from the srcset configuration? These questions can be answered automatically with server-side analysis and crawler tools. The result is a prioritized action plan that addresses the biggest savings potential first.

Image optimization is not a one-time project but an ongoing process that must be integrated into the content workflow. The combination of modern formats (AVIF with WebP fallback), responsive delivery (srcset/sizes), thoughtful lazy loading and automated build pipeline forms the foundation for optimal image performance. Those who consistently implement these measures can reduce image-caused data volume by 80 to 95 percent and improve LCP by 30 to 50 percent.

The investment in setting up an image optimization pipeline pays off quickly: faster loading times lead to better Core Web Vitals, which in turn improve organic search rankings. At the same time, hosting costs decrease through reduced traffic and user experience measurably improves -- especially on mobile devices, where the majority of web usage takes place today. With the right strategy and the appropriate frontend optimizations, image delivery transforms from a performance problem into a competitive advantage.