Your store takes eight seconds to render the homepage. The reflex is instant: "we need a CDN." You flip Cloudflare into proxy mode, wait for the miracle — and checkout still responds in five seconds. The diagnosis was not wrong, just in the wrong order.
A CDN speeds delivery of whatever can be cached at the edge. It does not fix a SQL query scanning the entire orders table, or a 4 MB hero image served uncompressed. The real question is not "CDN or no CDN?" It is: where is time lost — at the origin, on the network, or both?
Read the waterfall before buying a network layer
Open browser dev tools or run a test on WebPageTest. Two numbers guide the next move:
- TTFB (Time To First Byte) — time before the origin responds. High everywhere? Origin issue (PHP, database, disk, CPU saturation).
- Asset download time — long on JS/CSS/images but TTFB low? Network, file size, or missing static cache.
| Symptom | Likely cause | Priority action |
|---|---|---|
| TTFB > 800 ms in Europe | Slow DB, PHP, saturated disk | SQL profiling, page cache, disk upgrade |
| Low TTFB, heavy images | Unoptimized assets | WebP/AVIF, lazy-load, resize |
| Fast in France, slow in US | Geographic latency | CDN or closer origin |
| Unstable LCP on mobile | Above-the-fold not prioritized | Critical CSS, preload, image CDN |
A CDN does not compress application debt. It sometimes moves it out of sight.
Optimize the origin: levers that actually hold
Before any network layer, check what you control on the server.
Images and media. Often 50–70% of a WordPress or e-commerce page weight. Modern formats, viewport-sized dimensions, lazy-loading below the fold: immediate gains without a CDN contract.
HTTP and application cache. A reverse proxy (Nginx, Varnish) or page cache plugin avoids recalculating the same PHP page on every visit. Check Cache-Control headers, purge after deploy, and behavior for logged-in users.
Database. Enable the slow query log for one hour of real traffic. A missing index on a WooCommerce table or WordPress meta_query costs more than a Business CDN plan.
PHP and concurrency. On an overloaded shared host, TTFB spikes even behind a CDN: dynamic pages bypass edge cache. A right-sized VPS or properly tuned PHP-FPM may be enough.
What a CDN delivers — and what it does not cover
A CDN replicates your assets (and sometimes HTML) on points of presence near visitors. Concrete benefits:
- Lower latency for JS, CSS, fonts, images
- TLS termination and HTTP/2 or HTTP/3 at the edge
- DDoS protection and rate limiting (depending on plan)
- Less bandwidth to the origin
However, a CDN does not replace:
- Database writes (cart, forms, POST APIs)
- Misconfigured application cache (pages marked
no-cacheeverywhere) - An undersized origin saturating CPU
- Consistent purge rules after deploy
For mostly static sites (blog, brochure, Jamstack), a CDN can be step two after a clean origin. For transactional apps, it is almost always the reverse.
Scenarios A vs B: two battle orders
Scenario A — WordPress blog, France audience, TTFB 200 ms, heavy images. Start with ShortPixel or Imagify, page cache, then a free or host-included CDN. The CDN only helps once page weight is under control.
Scenario B — SaaS API in Europe, clients in US and Asia, origin already tuned. TTFB from Asia stays prohibitive despite indexed tables: then CDN with selective API cache or an extra origin region makes sense.
Scenario C — Black Friday spike, origin fine at normal load. Plan CDN and cache before the spike, not on the day. Test purge and cart behavior under partial cache.
The peak: a CDN is an amplifier, not a fix
CDN sales pages show green curves. They quietly omit Cache-Control: private pages, session cookies that bust cache, and admin requests that will never hit the edge.
Decide and move forward without blind spots
- Measure TTFB and waterfall from two regions without a CDN.
- Fix the origin: images, cache, SQL — until TTFB is stable under 400 ms in your main market.
- Retest: if network latency still dominates, shortlist CDNs (generalist or specialist).
- Document purge rules, cart/session behavior, and real origin (some proxies hide the IP).
Compare CDN and hosting offers in our directory and compare tool. To dig into the network layer choice, read Cloudflare or specialist CDN.
Frequently asked questions
How do I tell whether the problem is the origin or the network?
Measure TTFB from several regions without a CDN. If it stays high even near the server, the origin or database is at fault. If TTFB is low but total load time is long, network or static assets dominate.
Can a CDN hide a misconfigured origin?
Yes, temporarily, for static files. Dynamic pages, APIs, and writes still hit the origin. Without application caching, gains vanish when the CDN cannot serve the response.
Which origin optimizations offer the best effort-to-gain ratio?
Image compression, HTTP cache, SQL indexes, and trimming WordPress plugins. Profiling (slow query log, waterfall) sets the priority.
When does a CDN become the right first step?
When the origin is healthy, traffic is mostly static or geographically spread, and network latency dominates the waterfall.
Before adding a network layer, ask one simple question: if I disable the CDN tomorrow, does my site still hold up? If the answer is no, you have not finished the origin work yet.