Image hosting and optimisation: why images belong on a CDN
Images are most of a page's weight and most of the bandwidth bill. How they should be sized, formatted, delivered and cached, and why on a CDN.
The short answer
On a business website, images are more than half of every page’s bytes, most of the bandwidth bill, and the main reason the largest element on the page arrives late. Getting them right is the biggest single improvement available for speed and cost, and it is mechanical: size each image for the space it fills, serve a modern format, compress sensibly, load images below the fold only when needed, and deliver everything from a CDN with long cache lifetimes. A build step or an image CDN does all of this automatically from one original. Nobody should be resizing images by hand.
What right looks like
| Aspect | Wrong | Right |
|---|---|---|
| Size | The camera original, shrunk by the browser | Generated at the sizes the layout needs; the browser picks the closest |
| Format | JPEG or PNG for everything | Modern formats where supported, with fallback, chosen per browser |
| Compression | None, or a slider someone once set | Consistent, quality-tuned, automatic |
| Loading | Every image loaded immediately | Above the fold eager with priority; below the fold lazy |
| Layout | Images that push content around as they load | Width and height known in advance; no layout shift |
| Delivery | From the origin server, every time | From the CDN edge, cached for a long time, with versioned URLs |
| Video | Uploaded to hosting and served like an image | On a dedicated video service, embedded |
How it is done on a modern site
- One original per image, high quality, stored with the content or in a media library.
- A build step or image service generates the sizes and formats needed, once, and caches the results.
- The page markup describes which sizes exist and how wide the image will display, so the browser chooses well.
- Dimensions are set so space is reserved before the image arrives.
- Loading priority is set: the hero image first, the footer logos when they scroll into view.
- The CDN serves the generated files with long cache lifetimes; a changed image gets a new address, so caches never serve stale versions.
Video is different
Video files are large in a way images are not, and serving them from web hosting is expensive and slow. Host video on a dedicated service that handles encoding, adaptive quality and delivery, and embed it. Load the embed only when the visitor interacts, so a page with a video does not pay the video’s cost for visitors who never press play.
What this means for you
Images decide most of a page’s speed and most of its bandwidth cost, and the fix is a process, not a person: one original, automatic sizes and formats, dimensions reserved, priority set, CDN delivery with long caching, video elsewhere. Ask whether that process exists on your site. If it does not, it is the highest-return technical change available, and it never needs to be done again once it is in place.
Frequently asked questions
Our photographer sends huge files. Do we have to resize them ourselves?
No. Upload the original; the build step or the image service generates the sizes and formats each page needs and serves the right one to each device. Hand-resizing is error-prone and stops being done the day the person who did it leaves.
Which image format should we use?
Let the tooling decide per browser: modern formats such as AVIF and WebP for browsers that support them, with a fallback for the rest. You provide one good original; the pipeline serves the best format each visitor can display.
Why does the same image cost us bandwidth every month?
Because it is served to every visitor, on every visit, in whatever size it was uploaded. A properly sized, compressed image cached at the edge is served in a fraction of the bytes, and repeat visitors get it from their browser cache. The monthly cost of one oversized hero image across thousands of visits is real and avoidable.
Sources
- HTTP Archive Web Almanac 2025: Performance (accessed 2026-09-14)
- web.dev: Image performance (accessed 2026-09-11)