Launch in Days, Not Weeks
Professional one-page website. Only a few slots left this month
Images account for roughly half of total page weight on the average B2B website, according to HTTP Archive’s ongoing tracking of page composition across the web. That hero banner, those team photos, the case study screenshots — they’re the single biggest factor in your page load time. Modern image optimisation can cut that weight dramatically without visible quality loss, and most of it is achievable without a redesign.
The format you serve an image in matters more than almost any other single decision.
AVIF is the most efficient format broadly available in 2026. At equivalent visual quality, AVIF files typically run well below the size of a comparable JPEG, often by 50% or more. Browser support is now strong across Chrome, Edge, Firefox, and Safari, making it a safe default for most B2B sites rather than an experimental choice.
WebP remains the sensible fallback for the small remaining slice of older browsers or edge cases where AVIF isn’t supported. WebP is smaller than JPEG at similar quality, just not quite as efficient as AVIF.
JPEG XL is technically capable but browser support remains inconsistent enough in 2026 that it’s not yet a safe primary choice for production sites — worth watching, not worth betting on today.
JPEG and PNG should be treated as last-resort fallbacks only. PNG still has a legitimate place for images requiring true transparency or exact-pixel graphics like logos, but for photographic content it’s rarely the right choice.
The practical setup: serve AVIF first, WebP as fallback, and let the browser choose automatically using the <picture> element or your CDN’s content negotiation.
Serving one image size to every device wastes bandwidth on mobile and under-serves quality on large desktop displays. Responsive images fix both problems.
The srcset attribute lets you offer multiple resolutions of the same image, and sizes tells the browser how much space the image will occupy at different viewport widths, so it can pick the right file rather than downloading the largest version every time.
Art direction goes a step further: serving a genuinely different crop or composition at different breakpoints, not just a resized version of the same image. A wide hero banner on desktop might need a tighter, more vertical crop on mobile to keep the subject visible, and the <picture> element with media conditions handles this cleanly.
A common failure on B2B sites: a 3,000px-wide image displayed at 400px width in the markup. That’s transferring several times more data than the page actually needs, for zero visible benefit.
Not every image on a page needs to load immediately. The loading strategy should match visual priority.
Native lazy loading (loading="lazy") defers images below the fold until the user scrolls near them, which is now supported natively across all major browsers and requires no JavaScript library.
Above-fold prioritisation works the other way: your hero image, the one contributing to LCP, should never be lazy-loaded. Loading it eagerly, and ideally with a preload hint, ensures it’s fetched as early as possible rather than competing with everything else on the page.
fetchpriority lets you explicitly tell the browser which images matter most, useful when you have multiple above-fold images and want to make sure the true LCP candidate wins the race for bandwidth.
The rule of thumb: eager-load and prioritise what’s visible on first paint, lazy-load everything else.
Where and how images are served matters as much as the files themselves.
Modern image CDNs, including Cloudflare Images, can perform on-the-fly transforms — resizing, format conversion, quality adjustment — at request time, cached at edge locations close to the visitor. This means you can upload one high-quality source image and let the CDN generate every size and format variant automatically, rather than manually exporting a dozen versions.
Caching strategy matters too. Images should carry long cache lifetimes with proper cache-busting on update (via filename hashing or versioned URLs), so repeat visitors aren’t re-downloading unchanged assets.
For UK and European B2B audiences specifically, edge locations close to your actual visitors reduce round-trip time on every image request, which compounds across a page with multiple images.
Manually optimising every image before upload doesn’t scale, and it’s the kind of process that quietly breaks down the moment someone forgets a step. The better approach is automation at build or upload time.
Build-time optimisation converts and compresses images automatically as part of your deployment pipeline, so every image shipped to production has already passed through format conversion and sizing, with zero manual intervention required.
CMS integration extends this to content editors: when someone uploads a new case study image or team photo through a CMS, the system should automatically generate optimised variants rather than relying on the editor to export the right format and size by hand.
Automated format conversion at the infrastructure level means you never have to revisit this decision per image. Set the pipeline up once, and every future image benefits.
This is precisely the kind of “set and forget” reliability we build into every site through Fernside CMS and our managed hosting: content goes in, optimised images come out, with no manual compression step for anyone to forget.
Image weight is usually the single biggest lever for Core Web Vitals, particularly LCP, but it works alongside the other performance fundamentals: minimal JavaScript, fast server response, and clean CSS delivery. Fixing images without addressing render-blocking scripts or slow server response will still leave performance on the table.
Want to check how much weight your current images are adding to your load time? Get a performance audit and we’ll show you exactly where the biggest wins are.