If there’s one thing we’ve learned from working across so many digital platforms, it’s that images quietly make or break performance. Businesses invest heavily in great visual content but the moment those assets hit a CMS, all the technical nuance behind size, compression, and formats tends to disappear. Teams upload whatever they have, usually large JPGs or PNGs, and the website has to deal with the consequences.
For years, that meant slow mobile load times, inflated hosting costs, and a constant uphill battle with SEO. And as Google has doubled down on Core Web Vitals, the pressure has only increased.
So the question becomes simple: how do you optimise images for delivery?
Google's ranking signals have become increasingly performance-driven. Metrics like Largest Contentful Paint (LCP), which measures how quickly the biggest visible element on a page loads, usually a hero image, sit right at the heart of how pages are evaluated. A slow-loading image doesn't just frustrate visitors; it directly suppresses your search rankings.
Many businesses have found their positions slipping purely because their media wasn't being delivered efficiently. Even though Google now expects next-gen image formats, most non-technical teams simply don't have the tools or time to produce them.
A traditional CDN (Content Delivery Network) serves static files from servers close to the visitor. An image CDN goes further - it doesn't just deliver images, it transforms them in real time based on the requesting device, browser, and layout context.
Where a standard CDN asks "where is this visitor?", an image CDN asks "what does this visitor actually need?" The result is an image that's the right format, the right size, and the right quality for that specific request - served from a location close to them.
This distinction matters because storing dozens of pre-generated variants for every image is impractical at scale. An image CDN solves that by generating and caching variants dynamically, meaning you maintain one source file and let the delivery layer handle everything else.
Most websites still serve images as JPGs or PNGs. Both formats are decades old and carry significant overhead compared to modern alternatives.
WebP, developed by Google, typically delivers 25–35% smaller file sizes than JPEG at equivalent visual quality. It supports transparency (like PNG) and animation, and is now supported by all major browsers.
AVIF goes further still - offering even better compression than WebP, particularly for photographs and high-detail images. Browser support has caught up significantly, making it a viable first-choice format for most audiences in 2026, with WebP as a reliable fallback.
Serving the right format to the right browser used to require manual intervention or complex build pipelines. With a properly implemented image CDN, format negotiation happens automatically via the Accept request header: the browser declares what it supports, and the delivery layer responds accordingly.
Google has an excellent guide on improving image delivery using next-gen formats.
Format and compression only go so far if the browser is loading images the visitor hasn't even scrolled to yet. Lazy loading defers the loading of off-screen images until they're about to enter the viewport, reducing initial page weight and improving time-to-interactive.
The browser-native loading="lazy" attribute handles this for most use cases with no JavaScript required. The important caveat is that your above-the-fold images should never be lazy loaded - particularly your hero image, which is almost always your LCP element. Lazy loading the LCP image is one of the most common causes of a poor LCP score we see.
For your hero image specifically, consider adding <link rel="preload"> in the document head - it tells the browser to fetch it as a priority before it even begins rendering the page.
We built a system that fixes this entire problem without changing anyone’s workflow.
Instead of relying on plugins or manual resizing, we developed a custom image CDN that automatically transforms and optimises images the moment they’re requested, not when they’re uploaded, and not in bulk. Think of it as “just-in-time” image generation. Your team uploads a standard image. Our system interprets what the visitor’s device, browser, and layout need, produces the ideal version on the fly, and makes sure future visitors get it instantly. The system is completely CMS-agnostic, which means it works just as well with WordPress, headless platforms, bespoke systems, or anything else you throw at it.
The best part is how much inefficiency this removes. Because we only store the original source image and generate everything else dynamically, we’ve been able to reduce storage requirements by up to 80% across client sites. Once an optimised version of an image has been created, it’s delivered from a high-performance cache network, which has cut bandwidth costs by as much as 90%. As that cache builds up, we see hit rates as high as 90%, which means most visitors load images almost instantly.
The performance difference is noticeable. Cached images currently average around 43 ms to reach the user, fast enough that most people never even perceive the load. Even when an image is requested for the first time, the real-time optimisation only adds around 400 ms, still far faster than traditional image processing workflows that rely on pre-generated assets.
For clients who depend on high-quality imagery, and won't compromise on it, this has resolved what used to feel like an unavoidable trade-off. We've had clients with the highest expectations of their visuals benefit from the full pipeline without anyone in their organisations able to tell the difference in image quality.
You can see this in practice with Oliver's Travels, where the system now supports galleries of 40+ property photographs without compromising load times.
Your website becomes faster, lighter, and far more SEO-friendly without your content team needing to understand image formats, compression settings, or device breakpoints. Upload a JPG, and the system automatically delivers it in modern formats like WebP where supported. Upload a large hero banner, and it’s instantly resized and optimised for mobile. Every transformation strengthens Core Web Vitals because images are always served properly sized, properly compressed, and in formats Google actually favours.
We intentionally designed the system to be hands-off for editors and invisible to visitors but powerful enough to make a measurable difference to search rankings, user engagement, and operational costs. It’s the kind of upgrade that doesn’t require retraining or rethinking how teams work, yet it strengthens the technical foundation of every page.
High-quality visuals shouldn’t compromise performance. With a smarter delivery pipeline, they don’t have to; and if your business is ready to modernise how images are delivered, we’d be glad to walk you through what’s possible.
Mobile users are disproportionately affected by poor image delivery. Images that are sized for a desktop screen but served unchanged to a phone force the browser to download far more data than it needs, then scale it down - wasting bandwidth and slowing the page.
Google moved to mobile-first indexing in 2024, meaning it now crawls and evaluates your site primarily as a mobile visitor would. If your images are dragging down mobile load times, that's the version of your site Google is judging. Properly optimised image delivery: right size, right format, right compression for the requesting device, can have a dramatic effect on mobile performance scores and, by extension, your search rankings.
Largest Contentful Paint (LCP) is a Core Web Vitals metric that measures how long it takes for the largest visible element on a page to load, most commonly a hero image or large banner.
Google considers a good LCP to be under 2.5 seconds. The most effective ways to improve it are serving your hero image in a modern format like WebP or AVIF, ensuring it's correctly sized for the viewport rather than scaled down in CSS, avoiding lazy loading on above-the-fold images, and using a <link rel="preload"> tag so the browser prioritises fetching it early.
An image CDN handles most of these automatically, since it serves the right format and dimensions for each device without any manual intervention.
The quickest way is to run your URL through Google PageSpeed Insights, which is free and gives you a breakdown of exactly what's affecting your performance score. Look for specific recommendations like "Serve images in next-gen formats", "Properly size images", or "Defer offscreen images"
These are direct signals that image delivery is a problem. Google Search Console also surfaces Core Web Vitals data across your whole site, so you can see whether LCP issues are widespread rather than limited to one page. If you're seeing scores below 50 on mobile, images are almost always a contributing factor.
Compression is one part of optimisation. It reduces file size by discarding data, either losslessly (no quality change) or lossily (some quality reduction in exchange for smaller files).
Image optimisation is the broader practice that includes compression but also covers format selection (serving WebP or AVIF instead of JPEG), responsive sizing (delivering the right dimensions for each device), lazy loading, caching strategy, and delivery method. You can compress an image heavily and still have a poorly optimised image if it's the wrong format, served at the wrong size, or delivered from a slow origin server. True optimisation addresses the whole pipeline, not just the file size.
You shouldn't have to. Manually converting images before upload is time-consuming, error-prone, and puts an unreasonable burden on content teams who are focused on the work itself rather than file formats.
A well-implemented image CDN handles format conversion automatically, detecting what the requesting browser supports and serving WebP or AVIF accordingly, with a JPEG fallback for older browsers. Your team uploads images as they normally would, and the delivery layer takes care of everything else. If you find yourself or your team manually exporting to WebP, that's a sign your image pipeline needs attention.
When an image CDN generates an optimised version of an image, the right format, size, and compression for a specific device and browser, it stores that version in a cache. Every subsequent visitor with a similar request gets the cached version delivered almost instantly, without triggering the transformation process again.
This is why cache hit rate is such an important metric: a 90% hit rate means 9 out of 10 image requests are served from cache with no processing overhead at all. For high-traffic sites, this translates directly into lower bandwidth costs, faster load times, and a reduced load on your origin server. The cache builds over time, so performance tends to improve as traffic grows.
For the vast majority of use cases, the answer is no. And this is the question we hear most often from clients who invest heavily in photography and brand imagery. Modern formats like WebP and AVIF achieve smaller file sizes through more efficient compression algorithms, not by discarding visible detail.
When configured correctly, the optimised image is visually indistinguishable from the original. The caveat is that aggressive lossy compression, pushing file sizes down too far, can introduce artefacts, which is why the compression level needs to be tuned carefully. Our pipeline is configured to prioritise visual fidelity, and we've had clients with the highest expectations of their imagery run the full pipeline without anyone in their organisation able to spot a difference.
.webp)