Image weight is still the single biggest lever most sites have over page load time, but “optimize your images” gets treated as a one-time task rather than something hosting-side infrastructure actively affects on an ongoing basis. This piece tests what actually changes when image optimization is handled at the hosting/server layer — via built-in CDN transforms, automatic WebP/AVIF conversion, and server-side compression — versus doing it manually before upload.
Three Ways Hosts Handle Image Optimization
| Approach | Example | What It Does |
|---|---|---|
| Automatic format conversion | Cloudflare Polish, Bunny CDN Optimizer | Serves WebP/AVIF to supporting browsers automatically, keeps originals as fallback |
| Built-in image CDN | WP Engine's Smart Image CDN, Kinsta's Kinsta CDN | Resizes and compresses on the fly based on requesting device, cached at the edge |
| Server-side plugin compression | ShortPixel, Imagify running on shared/VPS hosting | Compresses at upload time on the origin server itself, no edge layer involved |
Test Setup
We used a consistent set of 20 test images (a mix of product photos, screenshots, and hero banners, 200KB-2.4MB originals) uploaded to WordPress installs on three hosting configurations: a host with an automatic image CDN enabled, a host with only Cloudflare's free-tier Polish enabled, and a baseline host with no image optimization layer active, images served as originally uploaded JPG/PNG.
Results: File Size Reduction
| Configuration | Avg. File Size Reduction | Format Served |
|---|---|---|
| Built-in image CDN (resize + modern format) | ~78% | AVIF/WebP, device-appropriate dimensions |
| Cloudflare Polish (format conversion only, no resize) | ~45% | WebP |
| No optimization layer | 0% (baseline) | Original JPG/PNG at full upload dimensions |
The gap between “format conversion only” and “full image CDN” comes almost entirely from dimension resizing. A hero image uploaded at 3000px wide but displayed at 800px wastes the majority of its bytes regardless of compression format — an image CDN that serves device-appropriate dimensions closes that gap; a host that only recompresses the original file at full size does not.
Results: Time to First Contentful Paint
On a page with 8 above-the-fold images (a typical product or portfolio grid), the built-in image CDN configuration finished First Contentful Paint about 0.9-1.3 seconds faster than the unoptimized baseline on a throttled mobile connection profile. The Cloudflare Polish-only configuration landed roughly in the middle, faster than baseline but behind the full image CDN, consistent with its smaller average file size reduction.
What This Means for Choosing a Host
- If your site is image-heavy (e-commerce, photography, portfolios), a host with a built-in resizing image CDN is worth paying more for — it consistently outperformed compression-only approaches in our tests, and it works automatically without a plugin to configure or keep updated.
- If your host doesn't offer one, Cloudflare's free tier Polish feature is a reasonable middle ground and costs nothing extra.
- A plugin like ShortPixel or Imagify running server-side is still worth using for the resizing piece specifically — set it to resize on upload to your actual maximum display width, not just recompress at full resolution — since neither Cloudflare Polish nor most CDN-less hosts resize dimensions automatically.
FAQ
Does automatic WebP/AVIF conversion ever break anything?
Rarely, but watch for older email clients or embedded contexts (some PDF generators, older browser versions) that don't support AVIF — a good image CDN serves a JPG/PNG fallback automatically via the Accept header, but it's worth spot-checking if you syndicate content elsewhere.
Is server-side image optimization better than a plugin?
Server/CDN-side optimization has the advantage of not adding processing load to your WordPress install and typically caches the optimized version at the edge, closer to visitors. A plugin can offer more granular control (specific quality settings per image) but adds a dependency to keep updated.
Do these gains apply to already-optimized images?
Less so — if you're already uploading properly sized, pre-compressed WebP images, a hosting-side layer has less to improve. The biggest gains come from sites uploading originals straight from a camera or design tool without any prior optimization.
Verdict
Hosting-side image optimization isn't marketing fluff — the resizing component specifically produced the largest, most consistent gains in our tests, more than format conversion alone. If you're evaluating hosts for an image-heavy site, ask specifically whether their image CDN resizes to display dimensions, not just whether it “optimizes images,” since that distinction is where most of the real performance difference lives. It's one of several host-side compression levers worth testing directly — alongside our Brotli vs Gzip compression tests for text assets — before committing to a plan.
