CDN vs Better Hosting: What Actually Makes Your Site Faster?

The speed problem has two layers

When a visitor loads your website, two things happen sequentially. First, your server generates the page — executing PHP, querying the database, building the HTML. This is the origin response. Second, that generated page travels across the internet from your server to the visitor's browser. This is the delivery.

Better hosting makes the origin response faster. A CDN makes the delivery faster. If your origin takes 4 seconds to generate a page, no amount of CDN optimisation makes that page load in under 4 seconds for the first uncached request. If your origin generates the page in 200 milliseconds but the server is in London and the visitor is in Sydney, the network round trip adds latency that a CDN eliminates.

Most people throwing solutions at a slow website do not diagnose which layer is the problem. They add a CDN to a site with 3-second origin TTFB and wonder why it is still slow. Or they upgrade to premium hosting when their server was already fast — the problem was geographic latency.

What a CDN actually does

A CDN is a network of servers distributed around the world. When you put your site behind a CDN, it caches copies of your content at these edge servers. When a visitor requests your page, the CDN serves the cached copy from the nearest edge server instead of sending the request all the way to your origin server.

What a CDN caches well

• Static files — images, CSS, JavaScript, fonts, videos. These do not change between visitors and cache perfectly.
• Full HTML pages — if the page is the same for every visitor (like a blog post or marketing page), the CDN can cache the entire page.
• API responses — if the response is the same for all users and does not change frequently.

What a CDN cannot cache

• Logged-in user content — dashboard pages, account settings, personalised feeds. Each user sees different content.
• Form submissions — POST requests go to your origin server.
• Checkout and payment flows — real-time inventory, pricing, and payment processing require the origin.
• Search results — query-dependent content that changes with every request.
• API calls with authentication — personalised responses cannot be cached.

For a brochure site or blog, a CDN can cache almost everything and dramatically reduce load times. For a SaaS app, ecommerce store, or membership site, most page views are dynamic and uncacheable — the CDN helps with static assets but the origin server generates every page view.

What better hosting actually does

When we say "better hosting," we mean a faster origin server. This is the machine that runs your application code, processes database queries, and generates the HTML that either gets served directly or cached by a CDN.

What faster origin hosting improves

• TTFB on every request — whether cached or not, the origin is faster when the CDN needs to fetch fresh content
• Dynamic page generation — dashboard pages, search results, checkout flows all execute on the origin
• Database query speed — better hosting usually means faster storage (NVMe SSDs vs SATA drives), more RAM for database caching, and dedicated CPU
• PHP/application processing — more CPU cores and faster clock speeds directly reduce execution time
• Concurrent request handling — more PHP workers means more simultaneous visitors can be served without queuing

The origin TTFB floor

Think of origin TTFB as the performance floor of your website. No optimisation layer above it — CDN, caching plugin, minification — can make a request faster than the origin can generate it. If your WordPress site on shared hosting takes 2.5 seconds to generate the homepage, the best case for an uncached visit is 2.5 seconds plus network latency. A CDN can serve cached copies faster, but every cache miss hits that 2.5-second floor.

On managed hosting with dedicated resources, the same WordPress site might generate the homepage in 200 milliseconds. Now even uncached requests are fast. The CDN cache is a bonus, not a necessity. And dynamic pages that can never be cached — the ones that matter most for revenue — are dramatically faster.

How to diagnose your speed problem

Test 1: Measure your origin TTFB

Bypass your CDN and measure how fast your origin server responds. If you use Cloudflare, enable Development Mode temporarily (this disables caching). If you use another CDN, access your site directly via your server's IP address.

Use your browser's developer tools (Network tab) to measure TTFB on your homepage, a product page, and a search results page. Record the numbers.

• Under 500ms origin TTFB — your hosting is fine. Speed improvements will come from CDN, caching, and frontend optimisation.
• 500ms to 1 second — borderline. Optimise your application code and database first. If still slow, consider hosting upgrade.
• Over 1 second — your hosting is the bottleneck. No CDN will fix this. Upgrade hosting.
• Over 3 seconds — your hosting is critically slow. This is likely shared hosting with CPU throttling. Migrate immediately.

Test 2: Measure cached vs uncached response times

With your CDN active, load a page twice. The first load is likely an uncached origin fetch. The second load should be served from CDN cache. Compare the response times.

• Big difference (e.g. 3s uncached, 200ms cached) — your CDN is working but your origin is slow. Hosting is the problem.
• Small difference (e.g. 300ms uncached, 200ms cached) — your origin is fast. The CDN adds a modest improvement. Your hosting is fine.
• Both slow (e.g. 3s uncached, 2.5s cached) — something is wrong with both. Possibly CDN misconfigured and not caching, or the page is dynamic and uncacheable.

Test 3: Monitor over time

One-off speed tests give you a snapshot. Uptrue's HTTP monitoring gives you the full picture — response times measured every 60 seconds, 24 hours a day. This reveals patterns that single tests miss:

• Peak-hour slowdowns caused by shared hosting throttling
• Early-morning speed improvements when server load is low
• Intermittent spikes caused by noisy neighbours or background processes
• Gradual degradation as the hosting provider adds more accounts to your server

The caching layers explained

Modern websites often have multiple caching layers, and understanding them helps you diagnose where slowness originates.

Layer 1: Browser cache

The visitor's browser stores static files locally. On repeat visits, these files load instantly from the hard drive. This helps returning visitors but does nothing for first-time visitors — the most important audience for conversion.

Layer 2: CDN edge cache

The CDN stores copies of your content at edge servers worldwide. Visitors get content from the nearest edge server. Cache hit = fast (10 to 50ms). Cache miss = request goes to origin. The CDN cache has a TTL — when it expires, the next request fetches fresh content from origin.

Layer 3: Application cache (e.g. WP Rocket, Redis)

Caching plugins like WP Rocket generate static HTML versions of your pages and store them on the server. When a request arrives, the server returns the pre-built HTML without executing PHP or querying the database. This dramatically reduces origin TTFB. Redis or Memcached caches database query results in memory, avoiding repeated disk access.

Layer 4: Server-level cache (Varnish, Nginx FastCGI)

Some hosting providers run a server-level cache that intercepts requests before they reach PHP. Varnish and Nginx FastCGI cache store generated pages in server memory and serve them without any application processing. This is the fastest server-side cache — response times under 50ms.

Layer 5: Origin server (no cache)

When all caches miss — the visitor is new, the CDN cache expired, the application cache was purged — the request hits your origin server. PHP executes. The database is queried. HTML is generated from scratch. This is the slowest path and the one most affected by your hosting quality.

A CDN improves Layer 2. Better hosting improves Layer 5. Application caching (Layer 3) bridges the gap. For the best performance, optimise all layers — but start with the one that is actually your bottleneck.

Real scenarios: CDN vs hosting

Scenario 1: Blog with global audience

A content site with articles that rarely change and visitors from every continent. Origin TTFB is 400ms — fast enough. But visitors in Asia and South America experience 2+ second load times due to network distance from the UK server.

Solution: CDN. The origin is fast. The problem is distance. A CDN caches the HTML at edge servers and serves it from nearby locations. Cloudflare free tier would reduce load times for international visitors from 2 seconds to under 200ms.

Scenario 2: WooCommerce store on shared hosting

An ecommerce site with 200 products. Origin TTFB is 3.2 seconds on product pages. Cart and checkout pages take 4+ seconds. A CDN is in place but most page views are dynamic (logged-in users, cart contents, real-time stock).

Solution: Better hosting. The CDN cannot cache dynamic ecommerce pages. The origin is the bottleneck. Moving from shared hosting to a VPS or managed WordPress host would drop origin TTFB from 3.2 seconds to under 500ms — a 6x improvement for every page load.

Scenario 3: SaaS application

A web application where every page is personalised and authenticated. Nothing can be CDN-cached except static assets (CSS, JS, images). Origin TTFB is 1.8 seconds due to complex database queries.

Solution: Better hosting + database optimisation. A CDN adds nothing for the core user experience. The origin needs faster storage, more memory for database caching, and possibly a dedicated database server. Once origin TTFB is under 500ms, a CDN can handle static assets to reduce bandwidth on the origin.

Scenario 4: Marketing site with fast hosting

A 10-page marketing site on managed hosting. Origin TTFB is 180ms. All pages are static HTML with no server-side processing. Load time is already under 1 second for UK visitors.

Solution: CDN for protection, not speed. The site is already fast. Adding a CDN like Cloudflare adds DDoS protection, SSL termination at the edge, and slightly faster delivery for international visitors. The performance improvement is minimal but the security improvement is significant.

The monitoring approach

Whether you add a CDN, upgrade hosting, or both — monitoring tells you if it actually worked. Too many site owners make infrastructure changes based on assumptions and never verify the impact.

Before any change

Set up Uptrue HTTP monitoring and collect at least 7 days of response time data. This is your baseline. Record average response time, peak response time, and the pattern of spikes.

After adding a CDN

Response times should drop for cached content. If they do not, the CDN may be misconfigured or your pages may not be cacheable. Check the CDN headers (CF-Cache-Status for Cloudflare) to verify caching is working.

After upgrading hosting

Origin TTFB should drop significantly. If response times are similar after migration, the bottleneck may be in your application code or database rather than the server hardware. Monitoring data helps narrow down the issue.

Ongoing

Performance changes over time. Your hosting provider adds more accounts to the server. Your CDN cache configuration expires and is not renewed. Your site grows and database queries slow down. Continuous monitoring catches degradation before it becomes a problem.

The answer: usually both, but in the right order

For most business websites, the answer is: fix hosting first, then add a CDN. A fast origin server with a CDN on top gives you the best of both worlds — fast generation and fast delivery. But the order matters because you cannot CDN your way out of slow hosting.

Start by measuring your origin TTFB. If it is over 1 second, hosting is your priority. Get that under 500 milliseconds with a hosting upgrade and application optimisation. Then add a CDN to extend that fast performance to visitors worldwide.

If your origin TTFB is already fast and you are just starting out, add Cloudflare free tier for the CDN, SSL, and DDoS benefits. It costs nothing and adds a useful layer of protection and performance.

Either way, monitor. Without response time data, you are making infrastructure decisions based on gut feeling. With data, you know exactly what is slow, why, and whether your changes fixed it.

Frequently asked questions