CDN Basics for Small Sites: What They Are and Why You Need One

The Problem CDNs Solve

Imagine your web server is in Frankfurt. A visitor from Sydney loads your site. Every file — HTML, CSS, JavaScript, images — travels ~17,000km from Frankfurt to Sydney. Even on a fast 1Gbps connection, physics adds 170ms of latency. In reality, with TLS handshakes, TCP slow start, and routing inefficiencies, that page load might be 2-3 seconds.

A CDN (Content Delivery Network) places copies of your static files on servers around the world. That same visitor from Sydney loads your files from a CDN edge node in Sydney or Singapore — maybe 50km away instead of 17,000km. Page load drops to 300-500ms.

For small sites with international audiences, this difference is significant.

What a CDN Actually Does

A CDN is a geographically distributed network of proxy servers that cache and serve your content. Here's the flow:

1. First request (cache miss): CDN fetches content from your origin server, serves it to the user, stores a copy at the edge node 2. Subsequent requests (cache hit): CDN serves the cached copy from the edge node — no origin server involvement 3. Dynamic content: CDN passes through to your origin server (or doesn't cache if configured not to)

What Gets Cached

CDNs excel at static content — files that don't change between requests:

• HTML pages (if cacheable)
• CSS and JavaScript
• Images (JPEG, PNG, WebP, SVG)
• Fonts
• Videos (for streaming-focused CDNs)

Dynamic content — API responses, personalised pages, authenticated user data — typically can't be cached or require short cache windows.

What CDNs Don't Fix

• Slow origin servers (CDN can't speed up uncacheable requests)
• Poorly written JavaScript that blocks rendering
• Large uncacheable API responses
• Database-driven pages with no caching strategy

A CDN makes your fast content faster. It doesn't fix a slow application.

CDN Architecture Basics

Edge Nodes vs Origin

• Origin server: Your actual web server — the source of truth
• Edge nodes (or PoPs — Points of Presence): The CDN's distributed servers around the world
• Cache: The stored copy of your content at edge nodes

Cache Headers

CDNs decide what to cache and for how long based on HTTP headers from your origin:

Cache-Control: public, max-age=86400

This tells the CDN: cache this for 86,400 seconds (1 day). Without explicit cache headers, CDNs use their own defaults — often conservative (shorter cache) to avoid serving stale content.

Cache Invalidation

When you update a file, you need to clear the cached copy. Methods:

• Purge specific URLs — remove one file from all edge nodes
• Purge by tag/path — remove all files matching a pattern (CloudFlare Cache Tags, Fastly Surrogate Keys)
• Cache versioning — change the URL for updated files (e.g., style.v2.css instead of style.css)

Setting Up a CDN: The Practical Options

Option 1: CloudFlare (Free Tier)

CloudFlare is the easiest entry point for small sites. DNS-level integration, no code changes required.

Setup:

1. Create a CloudFlare account 2. Add your domain — CloudFlare scans your current DNS records 3. Change your nameservers to CloudFlare's (provided during setup) 4. In CloudFlare dashboard, enable caching for your origin

CloudFlare's free tier includes:

• 200+ edge locations globally
• DDoS protection
• Basic optimisation (auto-minification, image compression)
• SSL/TLS encryption
• HTTP/3 support

What you give up on free tier:

• No image optimisation (Polish feature)
• No Argo Smart Routing (faster routing)
• Rate limiting requires paid plan
• Fewer analytics

Option 2: CloudFront (AWS)

CloudFront integrates tightly with AWS but works with any origin server.

Setup:

1. Create a CloudFront distribution 2. Set your origin server (domain or S3 bucket) 3. Configure cache behaviours (which paths to cache, TTLs) 4. Update your DNS to point to the CloudFront distribution domain

CloudFront pricing is based on data transfer and requests. For small sites, the free tier (1TB/month egress) is often sufficient.

Pros:

• Tight AWS integration
• Sophisticated cache policies
• Lambda@Edge for edge computing

Cons:

• More complex configuration than CloudFlare
• Pricier than CloudFlare for high-traffic sites
• AWS console complexity

Option 3: BunnyCDN

BunnyCDN is simpler and often cheaper than CloudFlare for media-heavy sites.

Setup:

1. Create a pull zone for your domain 2. Configure your origin server address 3. Update DNS CNAME to point to the BunnyCDN zone 4. Enable SSL (BunnyCDne provides free certificates)

Pricing: $0.01/GB for bandwidth in Europe/North America (~$10/month for 1TB).

DNS-Level vs Full Proxy CDN

There are two ways to integrate a CDN:

DNS-Level (CNAME only)

• You point a subdomain (e.g., cdn.yoursite.com) to the CDN
• Only that subdomain's traffic goes through the CDN
• Your main domain still hits your origin directly
• Use when: You want CDN for specific static assets only

Full Proxy (CloudFlare "orange cloud")

• All traffic to your domain routes through the CDN
• CloudFlare handles DNS, DDoS protection, SSL termination, caching
• Your origin IP is hidden from the public internet
• Use when: You want full CDN benefits including DDoS protection

For small sites, full proxy is usually the right choice. DNS-level is useful when you need the CDN for specific assets but want to keep your main domain separate for SEO or technical reasons.

CDN Caching for WordPress

WordPress is notoriously cache-unfriendly out of the box — dynamic pages, personalised content, and frequent database queries. Here's how to make it work with a CDN:

1. Use a Caching Plugin

Plugins like WP Super Cache, W3 Total Cache, or LiteSpeed Cache generate static HTML files that CDN can cache effectively.

2. Configure Cache Headers

Add to your .htaccess or server config:

    # Cache static assets for 1 week
    
        Header set Cache-Control "public, max-age=604800"
    
    
    # Cache HTML for 15 minutes (short because WordPress is dynamic)
    
        Header set Cache-Control "public, max-age=900"
    

3. Exclude Pages from Cache

Pages that shouldn't be cached (cart, checkout, account, logged-in users):

• Configure your caching plugin to exclude these
• Or set Cache-Control: no-store for authenticated requests in your application

4. Image Optimisation

Compress images before upload:

# Install squoosh CLI
npm install -g @squoosh/cli
# Compress an image
squoosh-cli --webp auto --output-dir ./compressed ./image.jpg

Smaller images = faster loads, lower CDN bandwidth costs.

Measuring CDN Effectiveness

Cache Hit Rate

Your CDN dashboard shows the ratio of cache hits (served from edge) to misses (fetched from origin). Higher is better:

• 90%+ cache hit rate: Excellent
• 70-90%: Good, room for optimisation
• <70%: Investigate — your caching configuration may need tuning

Time to First Byte (TTFB)

Measure TTFB with and without CDN:

# With CDN
curl -o /dev/null -s -w "Time: %{time_starttransfer}s\n" https://cdn.yoursite.com/page.html
# Without CDN (direct to origin)
curl -o /dev/null -s -w "Time: %{time_starttransfer}s\n" https://yoursite.com/page.html

A good CDN should reduce TTFB by 50-80% for cached content.

Real User Monitoring

CloudFlare Analytics, BunnyCDN stats, or third-party tools (SpeedCurve, New Relic) show real-world performance improvements.

Common CDN Mistakes

1. Cache Everything Including Dynamic Content

Setting Cache-Control: public, max-age=86400 on an authenticated dashboard page means users see each other's data. Know what you're caching.

2. Not Purging After Updates

Updating a CSS file but users see the old version because it's still cached. Implement cache purging as part of your deployment process.

3. Ignoring Origin Performance

CDN only helps with cached content. If your origin is slow, uncacheable requests will still be slow. Optimise your origin server independently.

4. Setting Cache TTLs Too Long

Long cache = fast delivery, but stale content risk. Balance cache duration against how often your content changes.

When You Don't Need a CDN

• Site serves a single geographic region (if your server is in that region)
• Very low traffic (CDN setup overhead isn't worth it)
• Entirely dynamic, personalised content (little to nothing to cache)
• Strict data residency requirements (can't send data to third-party edge nodes)

Bottom Line

For most small sites with any international traffic, a CDN is worth the minimal setup cost. CloudFlare's free tier is sufficient for the majority of cases — it takes 10 minutes to set up and provides meaningful performance improvement.

The key insight: CDN makes your static content fast regardless of where your origin server is. Combine it with a good caching strategy, and you'll serve pages in 300ms globally instead of 2-3 seconds.