CDN, Caching, and Hosting Checklist
Your hosting and CDN determine your speed floor. No amount of front-end optimization compensates for a slow server response. Time to First Byte is the starting line for every other performance metric, and a server hundreds of milliseconds away silently caps your Core Web Vitals. This checklist covers TTFB, cache-control headers, browser and CDN caching, cache hit rates, and the hosting choices that keep Googlebot crawling fast. Start with what is a cdn cache and how it serves your pages from the edge.
Infrastructure Sets the Speed Floor
Time to First Byte is the moment between a request and the first byte of the response. LCP and everything downstream cannot begin until TTFB completes. It is a diagnostic metric rather than a direct ranking factor, but a high TTFB makes every other performance fix harder.
A server in New York responding to a user in Tokyo carries at least 140ms of unavoidable network latency. A CDN solves this by serving cached responses from edge locations near the user, typically in 10-50ms. Layered caching then removes work at every level: browser, CDN edge, page cache, object cache, and opcode cache.
The most common failure is not missing infrastructure but misconfiguration. CDNs frequently run at 15-30% cache hit rates because of query strings, Set-Cookie headers, and Vary header abuse. Wrong Cache-Control headers serve stale content, and overzealous bot management throttles legitimate Googlebot. Get the headers right and the infrastructure pays for itself. This page is part of the complete technical SEO checklist.
Sources
- The median web page transfers over 2.4 MB across the wire, HTTP Archive page weight report.
- Sites that meet Core Web Vitals are 24% less likely for users to abandon, Google News Initiative CWV training.
Caching Layer Stack
The 15 CDN and Hosting Checks
Audit infrastructure, caching, and crawler access across your stack.
| # | Check | Who Does It | Tool | Difficulty |
|---|---|---|---|---|
| 1 | Test TTFB from multiple global locations | You | WebPageTest | Easy |
| 2 | Identify the layer owning the delay | Developer | DevTools | Hard |
| 3 | Upgrade hosting tier if on shared hosting | You | Hosting | Medium |
| 4 | Match hosting location or use a CDN | You | Hosting | Medium |
| 5 | Deploy a CDN for global edge delivery | Developer | Cloudflare / Fastly | Hard |
| 6 | Configure Cache-Control headers correctly | Developer | Server / CDN | Hard |
| 7 | Enable stale-while-revalidate for fresh content | Developer | Server / CDN | Medium |
| 8 | Set long browser caching for static assets | Developer | Server | Easy |
| 9 | Use content hashing in file names | Developer | Build | Medium |
| 10 | Audit CDN cache hit rate | Developer | CDN analytics | Medium |
| 11 | Check HIT versus MISS via response headers | Developer | curl | Easy |
| 12 | Verify Googlebot is not throttled | Developer | Logs / WAF | Hard |
| 13 | Serve from one hostname to avoid duplicates | Developer | Server | Medium |
| 14 | Enable HTTP/2 and HTTP/3 | Developer | CDN / server | Easy |
| 15 | Set up cache invalidation on publishing | Developer | CI / CDN | Medium |
Deep Dive: Every Check Explained
What each infrastructure audit reveals and how to fix it.
1 Test TTFB From Multiple Global Locations
Measure Time to First Byte from several locations around the world using WebPageTest or similar. If TTFB is over 300ms everywhere, hosting or CDN configuration is the bottleneck. If it is only slow far from your server region, you have a geographic latency problem that a CDN solves.
2 Identify the Layer Owning the Delay
Slow TTFB can come from hosting, CDN, caching, redirects, DNS, database queries, or platform logic. Use Chrome DevTools and the request waterfall to see where the wait happens. Compare templates: if only one template is slow, the problem is application logic; if most pages are slow, the infrastructure is at fault.
3 Upgrade Hosting Tier if on Shared Hosting
Shared hosting packs hundreds of sites on one server, and one noisy neighbor slows everyone. Moving to managed or cloud hosting commonly cuts TTFB by 60-80%. Match your hosting tier to your traffic and processing needs before layering on caching.
4 Match Hosting Location or Use a CDN
A server in New York answering a user in Tokyo carries at least 140ms of unavoidable latency per round trip. Host near your audience, or better, put a CDN in front so every user hits an edge location close to them. Do not rely on one origin region for a global audience.
5 Deploy a CDN for Global Edge Delivery
A CDN serves cached content from edge locations worldwide in 10-50ms, absorbs traffic spikes, and keeps Googlebot happy during crawl surges. Choose a provider with strong caching, HTTP/3, and cache purge. The free tier of most CDNs is enough for the majority of sites.
6 Configure Cache-Control Headers Correctly
The Cache-Control header drives all caching behavior. Use public for cacheable content, max-age for browser TTL in seconds, s-maxage for the CDN TTL, and stale-while-revalidate for background refresh. A misconfigured header is the most common reason content goes stale or never caches.
7 Enable Stale-While-Revalidate for Fresh Content
Stale-while-revalidate serves the expired cached version instantly while fetching a fresh one in the background. The next request gets the update. This keeps near-zero TTFB for editorial and ecommerce pages while propagating changes within minutes.
8 Set Long Browser Caching for Static Assets
Images, CSS, and JavaScript should be served with a long max-age, typically one year with the immutable directive for versioned files. Repeat visits then load them from the user's disk with zero network requests. HTML pages should use no-cache with must-revalidate so updates show immediately.
9 Use Content Hashing in File Names
Versioned filenames like style.a1b2c3.css make each new release a new URL, so the long browser cache never serves stale assets. Without hashing, you either cache too long and ship old code, or cache too short and lose the benefit.
10 Audit CDN Cache Hit Rate
Check your CDN analytics and target a hit rate above 80%. Most CDNs run at 15-30% because of misconfiguration. The top culprits are query strings creating infinite cache variations, Set-Cookie headers preventing caching, and Vary header abuse. Fix these and hit rates climb.
11 Check HIT Versus MISS via Response Headers
Run curl -I on a URL and inspect x-cache, cf-cache-status, or x-vercel-cache for HIT or MISS, plus the age header to confirm the resource is genuinely served from cache. A high age value confirms caching works; repeated MISS reveals configuration problems.
12 Verify Googlebot Is Not Throttled
Bot management and WAF rules can accidentally throttle legitimate Googlebot traffic. Check logs for Googlebot 429 or 403 responses and verify Google's published IP ranges are allowlisted. A CDN should protect you from bad bots, not block the crawler that ranks you.
13 Serve From One Hostname to Avoid Duplicates
If your CDN serves assets on cdn.example.com while the page lives on example.com, and both are crawlable, you can create duplicate content. Serve everything from one hostname, or set HTTP Link canonical headers. Keep static asset URLs stable with no redirects.
14 Enable HTTP/2 and HTTP/3
HTTP/2 multiplexes requests over one connection, removing per-request connection overhead. HTTP/3 with QUIC cuts connection setup to a single round trip and delivers roughly 5-15% faster connection establishment and TTFB. Most modern CDNs support both automatically.
15 Set Up Cache Invalidation on Publishing
For time-sensitive content, integrate publishing with CDN cache purge so new pages appear immediately. For evergreen content, natural TTL expiry is fine. Without invalidation, editors publish changes that users and crawlers cannot see for hours or days.
Cache-Control Cheat Sheet
The headers that control every caching layer.
| Content type | Recommended header | Why |
|---|---|---|
| Versioned static assets | public, max-age=31536000, immutable | One year, never refetch |
| HTML pages | public, max-age=0, must-revalidate | Always check for updates |
| Product pages | public, max-age=300, s-maxage=3600 | Fresh prices, cached at edge |
| Dynamic / personal content | private, no-store | Never shared across users |
| CDN-specific TTL | s-maxage or CDN-Cache-Control | Edge TTL separate from browser |
Common Infrastructure Mistakes
The configuration errors that quietly cap your speed and rankings.
Shared hosting for a growing site
Hundreds of sites on one server means noisy neighbors and slow TTFB. Managed hosting cuts response time dramatically.
Low CDN cache hit rates
Query strings and Vary abuse push hit rates to 15-30%. Target 80%+ by fixing the cache key.
Throttling Googlebot in the WAF
Aggressive bot management blocks legitimate crawlers. Allowlist Google's IP ranges and verify in logs.
Serving assets on a second hostname
cdn.example.com and example.com both crawlable creates duplicate content. Serve from one hostname.
No stale-while-revalidate
Every cache miss waits on the origin. Stale-while-revalidate serves instantly while refreshing in the background.
Never purging cache on publish
Content changes stay invisible to users and crawlers until TTL expires. Invalidate on publish for time-sensitive pages.
CDN, Caching, and Hosting Tools
Measure, diagnose, and deliver fast responses globally.
WebPageTest
Tests TTFB from multiple global locations and shows the request waterfall for any template.
FreeChrome DevTools
Network tab and waterfall reveal which layer owns the delay: DNS, TLS, server, or cache.
FreeCloudflare
CDN with edge caching, HTTP/3, WAF, and cache purge on a generous free tier.
Free tierFastly / CloudFront
Enterprise edge caching with granular per-object TTL control and instant purge.
Paidcurl
Inspect cache-control, x-cache, and age headers for HIT versus MISS verification.
FreeLighthouse / PSI
Field and lab Core Web Vitals including LCP, which TTFB feeds directly.
FreeRelated Checklists
Keep exploring the technical SEO series. Every checklist follows the same structure.
Core Web Vitals and Performance
Why TTFB and cache hit rates set the floor for LCP, INP, and CLS.
Security
HTTPS, TLS, and header hardening that hosting and CDN layers must provide.
Image SEO
How CDNs serve optimized images and cut image payload at the edge.
Crawl Budget and Log Analysis
How server response time and crawl rate limit interact in your logs.
Redirects and Status Codes
Edge-level redirects and cache behavior on redirected URLs.
Full Technical SEO Audit
Run the complete audit to catch hosting and caching issues in one pass.
Need Hosting Help?
Get professional CDN and hosting performance audits from Clienvora. Our expert team finds TTFB bottlenecks and caching misconfigurations before they cap your rankings.
Free consultation. Get a personalized technical SEO audit for your website today. Or download the full checklist PDF.
CDN and Hosting Frequently Asked Questions
Direct answers on TTFB, caching, and infrastructure.
A CDN cache is a copy of your static files stored on servers at edge locations around the world. When a user requests a cached asset, the nearest edge server answers in 10-50ms instead of the origin's hundreds of milliseconds. This is the core of how CDN caching speeds up your site.
Yes, usually positively. It reduces TTFB, improves Core Web Vitals, and absorbs traffic spikes. Misconfiguration can serve stale content or throttle Googlebot, so configure caching and allowlist the crawler.
Browsers store static resources locally using Cache-Control headers, so repeat visits load from disk with zero network requests. Versioned assets use a long max-age with immutable.
TTFB is diagnostic, not a direct ranking factor, but it feeds LCP. If it exceeds 300ms from global locations, hosting or CDN is the bottleneck. A CDN serves edges in 10-50ms.
Target above 80%. Most CDNs run at 15-30% due to query strings, Set-Cookie headers, and Vary abuse. Fix the cache key and verify with x-cache or cf-cache-status headers.
Rarely. It happens when assets are served from a second hostname without canonicalization. Serve from one hostname or set Link canonical headers.
HTTP/3 with QUIC cuts connection setup to one round trip. For edge-cached sites it delivers about 5-15% faster connection establishment and TTFB, roughly 20-100ms.