Image Optimization: Less Data Volume, Faster Load Times
Images are the single largest contributor to page weight on modern websites – and simultaneously the most powerful lever for improving your load times. We implement a complete image pipeline with modern formats, responsive delivery and intelligent lazy loading – without any visible quality loss.
85%
less data volume per image (typical, project experience)
< 2.5s
target LCP
50+
optimized projects with image pipeline
1.2s
typical LCP improvement (project experience)
Image pipeline · fixed price after a free image check
- WebP + AVIF, responsive srcset and lazy loading from one source
- A fixed price instead of a vague hourly estimate
- Free initial assessment, no obligation
- Ongoing protection via Core Web Vitals monitoring from €59 per month net
A free initial analysis comes first: we review your images at no cost and show the saving potential. A binding fixed-price offer follows — the image pipeline is part of the WordPress performance optimization from €490 net; for other systems within the full performance audit from €1,490 net. A standalone performance quick check from €349 net quantifies the image potential in advance.
Images account for an average of 42 percent (HTTP Archive, 2024) of total website weight – making them the single most important factor affecting your load times. They are also the most impactful lever: consistently optimizing images for modern formats, device-matched resolutions and deferred loading can reduce the transferred data volume per page by more than 80 percent (project experience). This not only improves Core Web Vitals – especially Largest Contentful Paint – but also reduces server costs, accelerates the mobile experience and lowers bounce rates. We implement a complete image optimization pipeline that integrates seamlessly into your build process or CMS.
How the image pipeline affects a single product image
Why Unoptimized Images Slow Down Your Website
A typical production workflow delivers images as JPEG or PNG directly from a camera or graphics application. Such a JPEG can easily weigh 2 to 5 megabytes, even though only 400 pixels wide need to be displayed on a smartphone. The browser downloads the full image and scales it down via CSS – wasting bandwidth, battery life and valuable milliseconds of load time. On mobile connections with limited bandwidth, this adds up across a page with 10 to 20 images to several megabytes of unnecessary transfer.
The direct connection to performance: Largest Contentful Paint (LCP) is determined in most cases by a hero image or product photo. When this image is delivered uncompressed, in the wrong format and at a desktop resolution, it creates a rendering bottleneck that pushes load time into the red zone even with a fast server and optimized JavaScript. Our performance analyses consistently show that image optimization alone can improve LCP by 1 to 3 seconds (project experience). That often corresponds to the difference between "poor" and "good" in Google's assessment.
Modern Image Formats: WebP and AVIF Compared
JPEG and PNG were the standard for decades but were never designed for the demands of modern web performance. WebP and AVIF are two newer image formats developed specifically for efficient web delivery, producing significantly smaller files at the same or higher perceived quality.
WebP: Broad Compatibility
WebP delivers 25 to 34 percent smaller files than JPEG at comparable quality (Google, 2024). The format supports transparency (like PNG) and animations (like GIF), is supported by over 97 percent of all browsers (Can I Use, 2024) and is therefore the solid foundation of every modern image pipeline.
AVIF: Maximum Compression
AVIF achieves up to 50 percent savings compared to JPEG (Alliance for Open Media, 2023), surpassing even WebP. Browser support stands at approximately 92 percent (Can I Use, 2024). We serve AVIF as the primary format with WebP as a reliable fallback.
Fallback Strategy
Using the HTML <picture> element with multiple <source> elements, we deliver AVIF to supporting browsers, WebP as a fallback, and JPEG/PNG for older clients. No user ever sees a broken image – the browser automatically selects the best available format.
Format compatibility is not a blocker
<picture> strategy with ordered <source> elements makes delivering modern formats fully backwards compatible. There is no need to fall back to older formats – the browser decides for itself what it can process.Responsive Images: The Right Image for Every Device
An image that looks optimal on a 27-inch monitor at 2560 pixels wide is unnecessarily large on a smartphone with a 390-pixel viewport. Without responsive images, mobile devices still load the full desktop resolution – a design flaw with significant performance consequences. The HTML attributes srcset and sizes solve this problem: they give the browser a selection of image variants at different resolutions and describe how large the image appears in the layout. The browser then autonomously selects the right variant for the current device and display resolution.
srcset: Providing Resolution Variants
We generate 4 to 6 resolution steps for each image: typically 480, 768, 1024, 1280 and 1920 pixels wide. The srcset attribute lists all variants with their width descriptor. The browser loads exactly the variant that is optimal for the current device – nothing more, nothing less.
sizes: Communicating Layout Width
The sizes attribute describes how wide the image actually appears in the layout – for example, "(max-width: 768px) 100vw, 50vw" for an image that is full-width on mobile but only half as wide on desktop. Combined with srcset, this enables pixel-perfect format selection.
Art Direction: Motif Adaption Per Viewport
The <picture> element allows you to control not just formats but also image content per viewport. A hero image can show a different crop on mobile than on desktop. The image motif is thus presented optimally on all devices without compromising responsive design.
Generation at Build Time or On-the-Fly
We integrate image variant generation either into the build process (all variants pre-generated at deployment) or as server-side on-the-fly conversion with a caching layer. For CMS-based sites with frequently changing content – such as WordPress, TYPO3 or Shopware – we typically recommend the on-the-fly approach.
How much data volume are your images wasting right now?
Send us your website URL. In the free initial analysis we measure image weight, LCP and saving potential — concrete and without obligation.
Lazy Loading: Load Images Only When They Become Visible
On initial page load, only the images in the visible area (above the fold) are actually relevant. All other images are only needed when the user scrolls down. Without lazy loading, all images on the page are loaded immediately anyway – including those at the bottom of a long product list that may never be viewed. This wastes bandwidth, strains the main thread and delays the rendering of visible content.
Native Lazy Loading and Intersection Observer
We implement lazy loading on two levels: the native HTML attribute loading="lazy" is available in modern browsers without JavaScript and defers the image download until shortly before the image scrolls into the viewport. For more precise control, we add the Intersection Observer API, which allows a configurable rootMargin – so the browser starts loading before the image reaches the viewport, preventing visible pop-in.
-
loading="lazy"on all below-the-fold images - Intersection Observer for precise preload control
-
fetchpriority="high"for the LCP image (prioritize above-the-fold) - Skeleton placeholders with aspect ratio to prevent layout shift
- Image dimensions reserved via HTML attribute or CSS
aspect-ratio
Important: the LCP image – typically the hero image or the first visible product photo – must not be set to lazy loading. It receives fetchpriority="high" instead, and if needed, a <link rel="preload"> hint in the HTML head so the browser begins the download as early as possible. Only the correct prioritization of the LCP image combined with lazy loading for all remaining images maximizes LCP improvement while minimizing total data volume.
Lossless and Lossy Compression
Compression reduces the file size of an image without – or with only minimal visible – quality loss. There are two main categories: lossless compression reduces redundant data without any information loss, making it suitable for graphics, logos and screenshots with clean edges. Lossy compression, on the other hand, also reduces actual image information, which for photos and natural subjects results in smaller files without the human eye perceiving a quality difference.
Finding the Optimal Quality Level
We test the best combination of quality level and format for each image type and platform. For WebP photos, the optimal quality range is typically 75 to 85; for AVIF, 60 to 75. Above these values, file size increases significantly without users perceiving any improvement.
Avoiding Visible Quality Loss
A structured comparison (butterfly test, SSIM measurement) ensures that compressed images are delivered without visible degradation on all devices and display resolutions – including high-resolution retina displays. We do not accept quality compromises.
Format-Specific Settings
PNG graphics are optimized with lossless compression (OxiPNG, advpng). For product photos and photography, we use WebP and AVIF with optimized quality levels. GIF animations are converted to animated WebP or CSS animations where possible, as WebP animations are significantly smaller.
Image Pipeline: Fully Automated from Source to Optimized Delivery
Manually optimizing every image is neither practical nor scalable for websites with dozens or hundreds of images – especially for CMS-based projects with regularly changing content. We implement fully automated pipelines that generate all required variants in optimized formats with every image upload or build process.
Analysis of the Current State
We record all images on the website with their current format, weight and actual display sizes in the layout. A waterfall analysis tool shows which images consume the most bandwidth, cause the LCP, and which images are above vs. below the fold.
Pipeline Design and Integration
Depending on the project stack, we decide between build-time conversion (e.g. with Sharp, ImageMagick or Vite plugins) and server-side on-the-fly conversion with a caching layer. For WordPress and TYPO3, we use established extensions configured to optimal parameters.
Generating Responsive Variants and Formats
The pipeline generates all required resolution steps in WebP and AVIF for each source image. The naming convention and file structure is designed so that the HTML markup with srcset and sizes can be generated simply and automatically.
Markup Integration and LCP Prioritization
All images receive correct srcset, sizes and loading attributes. The LCP image is equipped with fetchpriority="high" and a preload hint where needed. Dimension attributes prevent layout shifts during loading.
Validation and Monitoring
After implementation we measure the Core Web Vitals improvement (LCP, CLS) with Lighthouse and in the Chrome User Experience Report. A performance budget prevents future content from introducing new unoptimized images. We document all measurements before and after optimization.
CMS Integration: WordPress, TYPO3 and Shopware
Image optimization is not a one-time intervention but must be integrated into the editorial workflow. When an editor uploads a new image tomorrow, the pipeline must automatically generate all variants – without manual post-processing. We have extensive experience integrating complete image pipelines into the three most widely used CMS systems.
WordPress
WordPress automatically creates thumbnail sizes on image upload. We configure the required sizes precisely to match the theme layout, activate WebP conversion and supplement block editor markup with optimal srcset, sizes and loading attributes. Existing uploads are batch-reprocessed for immediate improvement.
TYPO3
TYPO3 provides a solid foundation for image optimization with its integrated image processing framework. We configure WebP conversion via ImageMagick/GraphicsMagick, set up appropriate crop variants and use the Fluid template system for optimal responsive srcset output. FAL-based media assets are processed uniformly.
Shopware
Shopware provides for performance-optimized shops a thumbnail engine that we configure to output WebP and add AVIF support. The thumbnail configuration is aligned with the actual display sizes in the storefront theme. Product images with thousands of variants are converted in a one-time batch process.
Typical Results of Image Optimization
The following figures reflect typical improvements we achieve in our projects through complete image optimization. Actual results depend on the starting condition and type of website – shops with many product images often benefit more than simple corporate websites. Our references page describes typical project scenarios in detail (project experience).
| Metric | Before Optimization | After Optimization |
|---|---|---|
| Page weight (images total) | 3.0 – 10.0 MB | 300 – 1,000 KB |
| Single image (product photo, desktop) | 800 KB – 2.5 MB | 60 – 180 KB (AVIF/WebP) |
| Single image (product photo, mobile) | 800 KB – 2.5 MB | 25 – 60 KB (AVIF 480px) |
| Largest Contentful Paint | 3.5 – 7.0 s | 0.8 – 2.2 s |
| Cumulative Layout Shift | 0.05 – 0.30 | 0.00 – 0.03 |
| Number of blocking requests | 10 – 30 | 2 – 5 (LCP preload + critical assets) |
Combine image optimization with <a href="/en/frontend-optimization/">frontend optimization</a>
Image Optimization in Practice
Anonymised project outcomes (project experience). Results depend on the starting condition and the type of website.
Scope: What Image Optimization Does Not Solve
Image optimization is a central but not the only factor in fast load times. A poorly configured server infrastructure with high TTFB values or render-blocking JavaScript can limit the impact of even perfectly optimized images. Image optimization also primarily improves transfer time; aspects like interactivity (INP) or JavaScript execution time are not directly affected. For a complete performance picture, we recommend a combined view of all optimization layers: server, frontend, images and caching strategies work together. If you want a comprehensive analysis, contact us about our technical performance analysis. In-depth practical articles cover WebP and AVIF in practice and progressive image loading with LQIP.
Frequently Asked Questions About Image Optimization
<picture> element with multiple <source> entries handles this automatically.rootMargin in the Intersection Observer API – typically 200 to 400 pixels – so the download begins before the image reaches the viewport. Additionally, skeleton placeholders with the correct aspect ratio of the image should be reserved so it does not cause a layout shift when it fades in.