The key takeaway: a CDN and local image optimization solve different problems — a CDN shortens the network distance a file travels, while local optimization shrinks the file itself. Sites with a lot of international traffic and large media libraries usually benefit from both; sites with mostly local visitors often get more from fixing format and size first.
Two Different Bottlenecks, Often Confused as One
"My images are slow" can mean two different things, and the fix is different depending on which one is actually true:
- The file is too big. A 2MB JPEG is a 2MB JPEG no matter how close the server is. This is a format and compression problem.
- The file has to travel too far. A perfectly optimized 80KB WebP file still takes longer to reach a visitor in Sydney if your only server is in Amsterdam. This is a network latency problem.
A CDN (Content Delivery Network) solves the second problem by caching copies of your files on servers distributed globally, so a visitor downloads from the nearest one instead of your origin server. It does nothing about the first problem — a CDN happily caches and serves an unoptimized 2MB file just as fast as it would a small one, from a networking point of view.
What Local Optimization Actually Does
"Local optimization" here means processing images on your own WordPress server: converting to modern formats (WebP, AVIF), compressing without visible quality loss, resizing to match actual display dimensions, and generating the responsive srcset variants browsers need to pick from.
This is a one-time, per-image cost. Once an image is converted and correctly sized, that work doesn't need to happen again on every request — the smaller file is simply what gets served from then on, whether that's from your own server or from behind a CDN.
Erdo Image Optimizer does exactly this: it uses your server's own GD or Imagick library to convert and compress images, with no external API or per-image fee. For the mechanics, see our guide to converting WordPress images to WebP.
Where Each Option Actually Wins
| Factor | Local optimization | CDN |
|---|---|---|
| Reduces file size | Yes — this is its main job | No — serves whatever file it's given |
| Reduces network distance | No | Yes — this is its main job |
| One-time or recurring cost | Mostly one-time processing | Usually recurring, scales with bandwidth |
| Helps a single-region audience | Yes, directly | Limited — little distance to shorten |
| Helps a global audience | Indirectly (smaller files transfer faster everywhere) | Yes, directly |
| Setup complexity | Plugin install + bulk conversion | DNS/origin configuration, cache invalidation rules |
A Worked Comparison
Consider a 1.8MB unoptimized JPEG hero image, requested by a visitor 9,000km from the origin server:
| Scenario | File size | Approx. total load time* |
|---|---|---|
| Unoptimized JPEG, no CDN | 1.8 MB | ~2.9s |
| Unoptimized JPEG, behind a CDN | 1.8 MB | ~2.1s |
| Optimized WebP (~350KB), no CDN | 350 KB | ~1.3s |
| Optimized WebP (~350KB), behind a CDN | 350 KB | ~0.6s |
*Approximate, illustrative figures based on typical latency and bandwidth assumptions for a long-distance request — actual numbers vary by host, connection, and CDN provider.
The pattern that matters: format optimization alone (row 3) beats adding a CDN to an unoptimized file (row 2). The two combined (row 4) beat either alone by a wide margin. If you can only do one first, fixing the file size gets you further than fixing the distance.
When a CDN Is Worth Adding
- Your traffic is genuinely international, not just local with occasional foreign visits.
- Your media library is large enough that origin server bandwidth or CPU is itself becoming a bottleneck under load.
- You're already serving optimized formats and sizes, and want the next increment of speed.
- You run WooCommerce or another high-traffic setup where origin server load during traffic spikes is a real risk.
When It's Not the Priority
- Your audience is concentrated in one country or region close to your hosting.
- You haven't yet converted images to modern formats — this is almost always the higher-leverage fix to do first.
- Your current hosting already includes a basic CDN or caching layer (common on managed WordPress hosts like Kinsta or WP Engine) — check before paying for a second one.
How to Check Which One Your Site Actually Needs
Rather than guessing, run a quick diagnostic:
- Open PageSpeed Insights and check the "Diagnostics" section for flagged images — if it's calling out format or sizing issues, that's a local optimization problem, not a distance problem.
- Use a tool like WebPageTest with a test location far from your server (for example, testing from Singapore if your host is in Europe). Compare the "Time to First Byte" and connection time against a test run from a location near your server. A large gap between the two points toward latency, not file size, as the bigger factor.
- Check your hosting plan's documentation — many managed WordPress hosts (Kinsta, WP Engine, Cloudways) bundle a CDN or edge caching layer by default. Paying for a second CDN on top of one you already have rarely helps.
A Few CDN Pitfalls Worth Knowing
A CDN isn't a pure upside once added — a few practical issues come up in real WordPress setups:
- Cache invalidation — replacing an image in the media library doesn't always immediately update the CDN's cached copy. Most integrations handle this automatically, but it's worth confirming, especially for time-sensitive content like pricing graphics.
- Extra DNS/connection overhead on small sites — for a page with only 2-3 images, the overhead of a new DNS lookup and TLS handshake to a CDN domain can occasionally offset the latency gain, particularly for visitors already close to the origin server.
- CORS configuration — if the CDN serves assets from a different subdomain, fonts and some JavaScript-loaded images can hit CORS errors unless headers are configured correctly.
None of these are reasons to avoid a CDN outright — they're configuration details worth checking rather than assuming a CDN is a strictly free win.
Using Both Together
For sites that do need both, the order matters: optimize first, then cache. Erdo Image Optimizer includes optional BunnyCDN integration for exactly this reason — images are converted to WebP/AVIF and correctly sized locally, then the already-optimized files are what gets pushed to and served from the CDN edge, rather than caching the original oversized uploads.
Wrapping Up
Treating "CDN" and "image optimization" as interchangeable fixes for the same problem is a common mistake — they address different layers of the same overall load time. If your site's images are still raw JPEGs and PNGs, converting and resizing them will typically move the needle more than adding a CDN in front of them. If you've already handled format and size and your traffic is genuinely global, a CDN is the logical next step. For most WordPress sites, the correct order is optimize first, then decide if the remaining latency justifies a CDN's ongoing cost.