WordPress Hosting CDN Performance Impact: Measured Results
The promise is simple: add a CDN, cut your load times. But the actual WordPress hosting CDN performance impact varies more than most guides admit. I ran the same WordPress test site through four hosting environments, toggled the CDN on and off in each, and recorded every request in WebPageTest. What follows is the data, not the marketing copy.
How I Measured (Before Trusting Any Number)
Before citing a single millisecond, here is the exact test setup:
- Test site: WordPress 6.5.3, Twenty Twenty-Four theme, WooCommerce 8.9.1 installed but shop page disabled. Total page weight without CDN: 1.84 MB, 48 requests.
- Test tool: WebPageTest (Dulles, VA node for U.S. origin servers; Sydney, AU node for geographic distance tests). Three runs per configuration, median taken.
- Metrics captured: Time to First Byte (TTFB), Largest Contentful Paint (LCP), total transfer size, and request count.
- CDN toggle method: Each host's native CDN was enabled and disabled through its own dashboard. No third-party CDN layered on top. Cloudflare's free plan was tested separately as a standalone variable.
- Caching state: Full-page cache always warm before measuring. I wanted to isolate CDN edge delivery, not cold-cache behavior.
- Plugin versions: WP Rocket 3.16.3 (page cache only, CDN module disabled), Cloudflare plugin 4.12.2 when applicable.
All tests ran during the same two-hour window on a Tuesday morning to reduce CDN load variance.
The Baseline Problem: Origin TTFB Without a CDN
TTFB is the clearest signal of raw server responsiveness. Without a CDN, every visitor's browser connects directly to the origin server. If that server is in Dallas and the visitor is in Melbourne, physics applies.
Here are the baseline TTFB readings from the Dulles node (same-continent, favorable conditions) and the Sydney node (cross-Pacific, worst-case for U.S.-hosted sites):
| Host | Origin Location | TTFB – Dulles (ms) | TTFB – Sydney (ms) |
|---|---|---|---|
| Host A (shared) | Dallas, TX | 310 | 1,420 |
| Host B (managed WP) | Iowa, US | 185 | 1,380 |
| Host C (managed WP) | Frankfurt, DE | 290 | 1,510 |
| Host D (VPS, Nginx) | New York, NY | 155 | 1,390 |
The Sydney numbers are the story. Even the fastest origin server (Host D at 155 ms locally) produced 1,390 ms TTFB from Australia. That is before a single byte of HTML has been parsed. LCP on those Sydney tests ranged from 4.1 s to 5.8 s — firmly in the "Poor" range under Core Web Vitals thresholds (LCP > 4.0 s).
CDN On: What the Numbers Changed
I enabled each host's native CDN and re-ran the same Dulles and Sydney tests. For Host D (VPS), I pointed the domain through Cloudflare's free plan since there was no native CDN option.
| Host | CDN Provider | TTFB – Dulles (ms) | TTFB – Sydney (ms) | LCP – Sydney (s) | Transfer Size Change |
|---|---|---|---|---|---|
| Host A (shared) | Proprietary edge | 280 | 390 | 2.6 | −18% |
| Host B (managed WP) | Cloudflare Enterprise | 160 | 195 | 1.9 | −22% |
| Host C (managed WP) | Proprietary + BunnyCDN | 240 | 310 | 2.2 | −20% |
| Host D (VPS, Nginx) | Cloudflare Free | 145 | 210 | 2.0 | −19% |
The before → after headline: Sydney TTFB dropped from an average of 1,425 ms (no CDN) to an average of 276 ms (CDN on). That is an 81% reduction in time to first byte from a geographically distant node. LCP moved from the "Poor" band into "Needs Improvement" or "Good" on every host.
Notice that Host A's CDN produced the smallest TTFB improvement at the Sydney node. Its proprietary edge network has fewer points of presence than Cloudflare's 300-plus PoP infrastructure. More PoPs generally means a shorter physical path to any given visitor — and that shows up directly in TTFB.
Same-Region Impact: CDN Still Matters, Less Dramatically
A common misconception is that CDN only helps international visitors. The Dulles results tell a different story. Even for same-continent traffic, turning the CDN on reduced TTFB on three of four hosts. The mechanism is different here: CDN edge nodes cache static assets (images, CSS, JS) and serve them from infrastructure optimized for high-throughput delivery, reducing the load the origin server handles per request.
The exception was Host D with Cloudflare Free. TTFB at Dulles dropped from 155 ms to 145 ms — statistically negligible. The origin server was already fast and geographically close to the test node. The CDN's value for that configuration is almost entirely geographic distribution, not raw speed improvement at close range.
Transfer size reduction (18–22% across all hosts) came from CDN-level image compression and Brotli encoding being applied at the edge. This matters for LCP because the LCP element on my test page was a 340 KB hero image. After CDN processing, that image was served at 278 KB — a 62 KB saving that trimmed approximately 0.3 s off LCP on a 10 Mbps simulated connection.
Where CDN Alone Is Not Enough
CDN improves delivery of cached content. It does not fix slow PHP execution or an uncached dynamic page. I tested this directly by disabling WP Rocket's page cache while keeping the CDN active.
With page cache off, CDN on:
- Host B TTFB at Dulles: 680 ms (up from 160 ms with page cache warm)
- Host D TTFB at Dulles: 590 ms (up from 145 ms)
The CDN has nothing to cache if the origin is generating a fresh PHP response for every request. TTFB spikes back toward the uncached origin baseline. This is why CDN and full-page caching are complementary, not interchangeable. If you are choosing between enabling one or the other, enable the page cache first.
The same logic applies to WooCommerce cart and checkout pages, which must bypass cache. CDN cannot rescue a slow WooCommerce checkout because that page is intentionally excluded from caching. Server-side performance — PHP version, object cache, database query optimization — governs those pages entirely.
Recommended CDN Configuration Settings
Based on the test results, here are the settings I applied to get the numbers in the table above. These are not defaults; each required a deliberate change.
| Setting | Recommended Value | Why It Matters |
|---|---|---|
| Static asset cache TTL | 1 year (31,536,000 s) | Maximizes edge cache hit rate for versioned assets |
| HTML cache TTL | 4 hours (logged-out users only) | Balances freshness vs. edge delivery for content pages |
| Image compression | Lossless at CDN edge | Reduces transfer size without quality loss for hero images |
| Brotli encoding | Enabled | Smaller than gzip for text assets; supported by all modern browsers |
| HTTP/2 push | Disabled | Causes duplicate requests in most WordPress setups; net negative |
| Minification at edge | Disabled if WP Rocket handles it | Double-minification breaks scripts; pick one layer |
| Cache bypass rules | wp-admin/*, wp-login.php, /cart/, /checkout/, /my-account/ | Prevents stale authenticated or transactional pages |
The HTTP/2 push row is worth a note. Several managed WordPress hosts enable it by default in their CDN settings. In my tests, it added between 2 and 6 duplicate requests per page load because WordPress already enqueues assets with explicit dependency resolution. Disabling push reduced request count from 48 to 44 on Host B and shaved 0.2 s off LCP.
Do This First: The Sequenced Checklist
If you are setting up CDN on a WordPress site for the first time, order matters. Running these steps out of sequence produces confusing results and sometimes breaks caching entirely.
1. Establish your baseline. Run three WebPageTest runs from a node geographically distant from your server before touching anything. Record TTFB, LCP, and transfer size. You need this to know whether any change helped.
2. Enable full-page caching before CDN. WP Rocket, W3 Total Cache, or your host's built-in page cache should be warm and confirmed working (check response headers for X-Cache: HIT) before you activate the CDN. A CDN serving uncached PHP responses is delivering your slowest possible page.
3. Configure cache bypass rules. Add exclusions for /wp-admin/, /wp-login.php, /cart/, /checkout/, and /my-account/ before enabling the CDN. If you are using WooCommerce, also exclude any URL containing ?add-to-cart=.
4. Enable the CDN and set a long static asset TTL. Start with 1 year for CSS, JS, fonts, and images. These assets are fingerprinted by WordPress and WP Rocket on every change, so cache busting is automatic.
5. Disable HTTP/2 push if it is on by default. Check your CDN dashboard. If there is a "push" or "early hints" toggle, turn it off and retest.
6. Re-run your WebPageTest baseline. Same node, same number of runs. Compare TTFB and LCP. If TTFB from the distant node did not drop by at least 40%, check whether the CDN is actually serving your HTML or only static assets.
7. Verify with real-user data. After 72 hours of traffic, check Google Search Console's Core Web Vitals report or CrUX data in PageSpeed Insights. Lab data (WebPageTest) and field data (CrUX) sometimes diverge, particularly for LCP, because real users have varying connection speeds and device capabilities.
What the Data Confirms
The WordPress hosting CDN performance impact is real and measurable, but it is not uniform. The clearest gains appear when the distance between server and visitor is large — the Sydney tests showed an 81% TTFB reduction. Closer to the origin server, the impact is smaller and depends heavily on how well the CDN's edge network is built.
The number of PoPs in a CDN's network correlates with consistent performance across regions. Cloudflare's infrastructure (used natively by Host B and optionally by Host D) produced the lowest and most consistent TTFB across both test nodes. Proprietary CDNs with smaller networks showed higher variance.
Page caching remains the prerequisite. CDN amplifies the speed of a fast, cached response. It cannot compensate for slow PHP execution or a missing cache layer. Get the cache working first, then let this guide on migrasi dari shared hosting ke VPS pemula help you understand the infrastructure layer, or ensure you have the right software SEO terbaik 2024 to monitor your performance improvements.