The Ultimate Guide to Web Hosting, CDN & Infrastructure for Speed: TTFB, Caching, Edge Workers & Traffic Resilience in 2026

Time to First Byte (TTFB) is the time between the browser sending a request and receiving the first byte of the response. It's the starting line for every other metric — LCP, FCP, and everything downstream can't begin until TTFB completes.

What TTFB includes:

1. 1DNS lookup (5–100ms): Translating your domain name to an IP address
2. 2TCP connection (10–100ms): Establishing the network connection
3. 3TLS negotiation (10–150ms): HTTPS handshake for secure connection
4. 4Server processing (10–2000ms+): Your server generating the response (the most variable component)

Why TTFB matters more than most realize: A 500ms TTFB means your LCP cannot possibly be under 500ms — it hasn't even started receiving content yet. If your TTFB is 800ms, achieving an LCP of 2.5s means the entire page (HTML parsing, CSS loading, image rendering) must complete in 1.7s — extremely difficult on mobile devices with 4× CPU throttling.

Google's TTFB recommendation: Google recommends TTFB under 200ms for the p75 (75th percentile) of user requests. Note: this is a "good" threshold — TTFB under 800ms is "needs improvement," and over 800ms is "poor."

The geographic TTFB problem: Physics limits the speed of light. A server in New York responding to a user in Tokyo has at least 140ms of unavoidable network latency (round-trip). Without a CDN, every user outside your server's region experiences inflated TTFB. A CDN solves this by serving cached responses from edge locations near the user.

Server processing optimization: The most variable TTFB component is server processing time. Common causes of slow server processing:

• •No page cache: Every request triggers full PHP/Python/Node execution + database queries
• •Unoptimized database queries: Missing indexes, N+1 queries, full table scans
• •Overloaded server: Shared hosting with 500+ sites on one server
• •No opcode cache: PHP recompiles code on every request without OPcache
• •External API calls: Server waiting for third-party APIs before responding

HTTP/2 and HTTP/3 impact on TTFB: HTTP/2 multiplexes multiple requests over a single connection, eliminating the overhead of establishing new connections for each resource. HTTP/3 (QUIC) reduces connection setup to a single round-trip (vs 2–3 for HTTP/2 over TLS). Ensure your hosting and CDN support HTTP/3 — most modern CDNs (Cloudflare, Fastly) do.

Hosting selection is the single biggest infrastructure decision for website speed. The difference between hosting tiers is not incremental — it's often the difference between passing and failing Core Web Vitals.

Hosting tiers compared:

Shared hosting ($5–20/month):

• •TTFB: 500–1500ms (highly variable)
• •Resources: Shared CPU, RAM, and disk with 100–500+ other sites
• •Control: None over server configuration
• •Best for: Personal blogs, hobby sites, sites where speed doesn't affect revenue
• •Avoid for: E-commerce, lead generation, any site where speed = money

Managed hosting ($25–150/month):

• •TTFB: 100–300ms (consistent)
• •Resources: Isolated containers or dedicated resources
• •Control: Platform-managed caching, CDN, and security
• •Examples: Kinsta, WP Engine, Flywheel (WordPress); Pantheon (Drupal); Platform.sh (PHP/Node)
• •Best for: Most business websites — the best balance of speed, reliability, and management overhead

Cloud VPS ($20–200/month):

• •TTFB: 50–200ms (depends on configuration)
• •Resources: Dedicated vCPU, RAM, and SSD storage
• •Control: Full root access, custom server configuration
• •Examples: DigitalOcean, Linode, Vultr, AWS EC2, Google Cloud Compute
• •Best for: Developers who can configure and maintain servers, sites needing custom software stacks

Dedicated servers ($100–500+/month):

• •TTFB: 30–100ms (maximum raw performance)
• •Resources: Entire physical server
• •Control: Complete hardware and software control
• •Best for: High-traffic sites, sites with specific compliance requirements, applications with sustained high CPU usage

Platform-specific recommendations:

• •WordPress: Kinsta, WP Engine, or Cloudways (DigitalOcean/Vultr backend). Avoid EIG-owned hosts (Bluehost, HostGator).
• •WooCommerce: Kinsta or Cloudways — WooCommerce needs more resources than standard WordPress due to database-heavy operations.
• •Magento: Dedicated or cloud VPS with at least 4GB RAM, SSD storage, and Redis for object caching.
• •Static/Jamstack: Vercel, Netlify, or Cloudflare Pages — these serve static files from CDN edge, delivering near-zero TTFB.

How to test before committing:

1. 1Most managed hosts offer 30-day money-back guarantees
2. 2Set up a staging clone of your site on the new host
3. 3Test TTFB from multiple global locations using WebPageTest or KeyCDN's free tool
4. 4Run load tests to see how TTFB degrades under traffic (not just idle performance)
5. 5Compare TTFB at different times of day (shared hosts slow down during peak hours)

Caching is the most effective performance optimization in all of web development. A properly configured caching stack eliminates redundant work at every level of the request chain, turning seconds of processing into milliseconds of cache lookups.

Layer 1: Browser cache (client-side) The browser stores static assets (CSS, JS, images, fonts) locally after the first visit. Subsequent page views load these assets from disk instead of the network.

• •Configure via `Cache-Control` response headers
• •Static assets (versioned filenames): `Cache-Control: public, max-age=31536000, immutable` (1 year)
• •HTML pages: `Cache-Control: public, max-age=0, must-revalidate` (always check for updates)
• •Use content hashing in filenames (`style.a1b2c3.css`) so new versions get new URLs

Layer 2: CDN edge cache The CDN stores copies of your content at edge locations worldwide. Users get served from the nearest edge, typically in 10–50ms.

• •Configure via `Cache-Control` and `CDN-Cache-Control` headers
• •Static assets: Cache for 30+ days at the edge
• •HTML pages: Cache for 1–60 minutes with `stale-while-revalidate` for instant responses during revalidation
• •Use `Surrogate-Control` (Fastly) or `CDN-Cache-Control` (Cloudflare) for CDN-specific TTLs separate from browser TTLs

Layer 3: Page cache (full-page HTML cache) The page cache stores pre-built HTML pages on the server, bypassing application code and database queries entirely.

• •WordPress: WP Super Cache, W3 Total Cache, or managed hosting built-in cache
• •PHP: Varnish or Nginx FastCGI cache in front of the application server
• •Impact: Reduces server processing from 200–2000ms to 5–20ms per request
• •Invalidation: Purge cache on content updates (most CMS plugins handle this automatically)

Layer 4: Object cache (database query cache) The object cache stores database query results in memory (RAM) for instant retrieval without re-querying the database.

• •Engines: Redis (recommended) or Memcached
• •Use case: Dynamic pages that can't be fully page-cached (logged-in users, cart pages, search results)
• •Impact: Reduces database query time from 50–500ms to 0.1–1ms per query
• •WordPress: Redis Object Cache plugin + Redis server on same host

Layer 5: Opcode cache (PHP compilation cache) OPcache stores compiled PHP bytecode in memory, eliminating the need to parse and compile PHP files on every request.

• •Built into PHP 7+ (just needs enabling in `php.ini`)
• •Settings: `opcache.memory_consumption=256`, `opcache.max_accelerated_files=20000`
• •Impact: 20–40% reduction in PHP processing time
• •Note: Only applies to PHP-based applications (WordPress, Magento, Drupal, Laravel)

The compound effect: A request that would take 2000ms without caching (DNS + TLS + server processing + database queries) can be served in under 50ms with a properly configured stack: CDN edge hit (30ms) serving a pre-built HTML page that references browser-cached assets.

The three major CDN providers each excel in different areas. Choosing the right one depends on your technical requirements, budget, and existing infrastructure.

Cloudflare:

• •Network: 300+ Points of Presence (PoPs) in 100+ countries — the largest anycast network
• •Pricing: Generous free tier (sufficient for most small–medium sites). Pro: $20/mo. Business: $200/mo. Enterprise: custom
• •Strengths: Built-in WAF, DDoS protection, DNS, Workers (edge compute), automatic HTTPS, Argo Smart Routing (optimized route selection)
• •Cache control: Page Rules (limited on free), Cache Rules (more flexible), Transform Rules for URL normalization
• •Edge compute: Cloudflare Workers (JavaScript/WASM at edge, 0ms cold start, free tier: 100K requests/day)
• •Best for: Most websites — the combination of free tier, built-in security, and Workers makes it the default recommendation
• •Limitations: Less granular cache control than Fastly, page rules limited on lower tiers

Fastly:

• •Network: 70+ PoPs (fewer but strategically placed in high-traffic regions)
• •Pricing: Pay-as-you-go (minimum ~$50/mo for meaningful usage). No free tier.
• •Strengths: Instant cache purge (<150ms globally), VCL configuration language (extremely granular cache control), real-time analytics, edge-side includes
• •Cache control: VCL (Varnish Configuration Language) provides the most precise cache control of any CDN — per-object TTLs, conditional caching, response header manipulation
• •Edge compute: Fastly Compute (Wasm-based, supports Rust/JS/Go, sub-millisecond cold starts)
• •Best for: E-commerce sites needing instant cache purge (price changes, inventory updates), media sites with complex caching requirements, sites needing precise per-URL cache control
• •Limitations: Smaller network, higher cost, steeper learning curve (VCL)

AWS CloudFront:

• •Network: 400+ PoPs (largest physical network, includes edge locations + regional edge caches)
• •Pricing: Pay-as-you-go based on data transfer and requests. Free tier: 1TB/month + 10M requests for first year.
• •Strengths: Deep AWS integration (S3, EC2, ALB origin), Lambda@Edge for edge compute, Regional Edge Caches (additional cache tier), Origin Access Control for secure S3 access
• •Cache control: Cache policies and origin request policies. TTLs configurable per behavior (URL path pattern).
• •Edge compute: Lambda@Edge (Node.js/Python at edge, but cold starts are 50–200ms) and CloudFront Functions (JavaScript, <1ms, for lightweight transformations)
• •Best for: Applications already running on AWS, sites using S3 for storage, organizations with AWS enterprise agreements
• •Limitations: Complex configuration (AWS console), no built-in WAF (requires AWS WAF separately), higher learning curve

Decision framework:

• •Starting a new project or don't have strong preferences → Cloudflare (free tier, easiest setup)
• •E-commerce with frequent price/inventory changes → Fastly (instant purge)
• •Already invested in AWS infrastructure → CloudFront (native integration)
• •Need edge compute for personalization/A/B testing → Cloudflare Workers (best developer experience) or Fastly Compute (best performance)

A CDN is only as effective as its cache hit rate. If your CDN runs at 20% hit rate, 80% of requests still reach your origin server — you're paying for a CDN but barely using it. The goal is 85–95% cache hit rate.

What is cache hit rate? Cache hit rate = (requests served from CDN edge) / (total requests) × 100. A "cache hit" means the CDN served the response without contacting your origin. A "cache miss" means the CDN forwarded the request to your origin.

Why most CDNs underperform: The top 5 cache-busting culprits we see on client sites:

1. Query strings that vary per request: URLs like `style.css?v=1709112345` where the version changes frequently, or analytics parameters like `?utm_source=google&utm_campaign=spring` — each unique URL is a separate cache entry.

• •Fix: Strip marketing query parameters at the CDN edge (Cloudflare Cache Rules, Fastly VCL). Normalize version parameters.

2. Set-Cookie response headers: Responses that include `Set-Cookie` headers are typically not cached by CDNs (to prevent one user's session cookie from being served to another user).

• •Fix: Ensure static asset responses (CSS, JS, images) never include `Set-Cookie` headers. Review your application's cookie behavior.

3. Vary header misconfiguration: `Vary: *` tells the CDN to never cache. `Vary: Accept-Encoding, Cookie, User-Agent` creates separate cache entries for every combination — effectively no caching.

• •Fix: Use only `Vary: Accept-Encoding` for most resources. Remove unnecessary Vary values.

4. Short cache TTLs: A 60-second TTL means the CDN re-fetches from origin every minute. For content that changes daily, this wastes 1,439 origin requests per day per edge location.

• •Fix: Use longer TTLs with `stale-while-revalidate`. For content updating hourly: `Cache-Control: public, max-age=3600, stale-while-revalidate=86400`

5. No origin shielding: Without shielding, a cache miss at ANY edge location goes directly to your origin. With 300 PoPs, a single page update can trigger 300 origin requests simultaneously.

• •Fix: Enable origin shielding (Cloudflare: Argo Tiered Caching; Fastly: Shielding; CloudFront: Regional Edge Caches). This routes edge misses through a single "shield" POP, reducing origin load by 90%+.

Monitoring cache hit rates:

• •Cloudflare: Analytics → Caching → check "Cached" vs "Uncached" ratio
• •Fastly: Real-time analytics dashboard shows hit ratio per service
• •CloudFront: CloudWatch metrics → CacheHitRate
• •Target: 85%+ for static assets, 60%+ for HTML pages with stale-while-revalidate

Modern CDNs aren't just content delivery networks — they're security platforms. CDN-level security stops attacks at the edge before they reach your origin, improving both security and performance (malicious traffic consumes server resources that should serve real users).

Layer 1: DDoS Protection Distributed Denial of Service attacks flood your server with traffic to cause downtime. CDN-level DDoS protection absorbs attack traffic across the global network.

• •Volumetric attacks (bandwidth flooding): CDN absorbs at network edge — your origin never sees the traffic
• •Application-layer attacks (HTTP floods): CDN rate-limits suspicious request patterns before forwarding
• •Always-on vs on-demand: Cloudflare and Fastly provide always-on DDoS protection. AWS requires enabling AWS Shield Standard (free) or Shield Advanced ($3K/mo)
• •Most CDNs handle DDoS with zero configuration — it's built into the network architecture

Layer 2: Web Application Firewall (WAF) WAF rules inspect HTTP requests and block malicious patterns before they reach your application.

• •OWASP Top 10 protection: SQL injection, cross-site scripting (XSS), CSRF, path traversal
• •Managed rulesets: Pre-built rules updated by the CDN vendor's security team (Cloudflare Managed Ruleset, Fastly WAF, AWS Managed Rules)
• •Custom rules: Block specific patterns, IP ranges, or request characteristics unique to your application
• •Rate limiting: Prevent brute-force login attempts, API abuse, and scraping (e.g., block IPs exceeding 100 requests/minute to /login)

Layer 3: Bot Management Distinguish legitimate bots (Googlebot, Bingbot) from malicious bots (scrapers, credential stuffers, spam bots).

• •Known good bots: Allow search engine crawlers, monitoring tools, and partner integrations
• •Suspicious bots: Challenge with CAPTCHA or JavaScript challenges
• •Malicious bots: Block outright (credential stuffing, content scraping, DDoS bots)
• •Cloudflare Bot Management and Fastly Bot Detection use machine learning to classify bot behavior in real-time

Layer 4: Additional security headers CDN edge workers can inject security headers without modifying your application:

• •`Strict-Transport-Security: max-age=31536000; includeSubDomains; preload` (enforce HTTPS)
• •`Content-Security-Policy` (prevent XSS and code injection)
• •`X-Content-Type-Options: nosniff` (prevent MIME type sniffing)
• •`X-Frame-Options: DENY` (prevent clickjacking)
• •`Permissions-Policy` (control browser feature access)

Performance impact of CDN security: CDN-level security actually improves performance because:

• •Blocked bot traffic frees server resources for real users
• •DDoS mitigation prevents server overload during attacks
• •Reduced malicious traffic means lower bandwidth costs
• •Edge processing of security rules is faster than application-level security checks

Edge workers (Cloudflare Workers, Fastly Compute, Lambda@Edge, Deno Deploy) run server-side code at CDN edge locations worldwide — executing in under 1ms with zero cold starts (on modern platforms). They bridge the gap between static CDN caching and dynamic server-side processing.

When edge workers add significant value:

A/B testing without origin round-trips: Traditional A/B testing tools (Optimizely, VWO) run client-side JavaScript that causes layout shifts and delays. Edge workers can select the variant server-side and serve the appropriate HTML directly — zero client-side overhead, zero CLS.

Geographic personalization: Serve different content based on the user's country, region, or city without routing to origin. Edge workers have access to geolocation data from the CDN network. Examples: currency selection, language, regional pricing, compliance messages.

URL redirects and rewrites: Handle redirect maps (301/302) at the edge instead of the origin. For sites with thousands of redirects (post-migration), this eliminates origin round-trips for redirect resolution. Edge redirects resolve in <1ms vs 100–500ms for origin-based redirects.

Header manipulation: Add, modify, or remove HTTP headers at the edge: security headers, cache control headers, CORS headers, custom response headers. No application code changes needed.

Authentication at the edge: Validate JWT tokens, API keys, or session cookies at the edge before forwarding to origin. Invalid requests are rejected without consuming origin resources.

HTML transformation: Modify HTML responses at the edge: inject scripts, modify meta tags, insert banners. Cloudflare's HTMLRewriter API provides streaming HTML transformation without buffering the entire response.

When edge workers are overkill:

• •Static sites: If your content is fully cacheable and doesn't need personalization, a standard CDN cache is sufficient
• •Low-traffic sites: If your origin handles current traffic without issues, edge compute complexity isn't justified
• •Simple blogs/portfolios: CDN caching + proper cache headers is all you need
• •When the origin is already fast: If your origin responds in <50ms, edge workers don't add meaningful speed benefit

Platform comparison:

• •Cloudflare Workers: Best developer experience, 0ms cold starts, free tier (100K requests/day), V8 isolates
• •Fastly Compute: Best performance (Wasm-based), supports Rust/JS/Go, sub-millisecond execution
• •Lambda@Edge: AWS-native, Node.js/Python, but 50–200ms cold starts (use CloudFront Functions for lightweight tasks)
• •Deno Deploy: TypeScript-first, globally distributed, good for API-heavy edge workloads

WordPress hosting migration is the most common infrastructure upgrade we perform. Moving from shared hosting to managed hosting typically reduces TTFB by 60–80% — a single change that often makes the difference between passing and failing Core Web Vitals.

Pre-migration checklist:

1. Audit current environment:

• •Record current TTFB from 5+ global locations (WebPageTest)
• •Document PHP version, MySQL version, and installed extensions
• •List all active plugins and their versions
• •Note any server-level configurations (custom .htaccess rules, cron jobs, email routing)
• •Verify SSL certificate type (Let's Encrypt vs commercial) and expiry

2. Choose and prepare the new host:

• •Select a host appropriate for your traffic level (see Choosing Hosting section above)
• •Ensure PHP 8.1+ support, Redis availability, HTTP/2 or HTTP/3 support
• •Set up staging environment on new host for testing

3. Clone your WordPress site:

• •Use a migration plugin (UpdraftPlus, All-in-One WP Migration, Duplicator) or manual export
• •Clone both files (wp-content, plugins, themes, uploads) and database
• •Verify database character set matches (utf8mb4)

4. Test on new server:

• •Modify your local `hosts` file to point your domain to the new server's IP
• •Test every critical page: homepage, product pages, blog, checkout, forms
• •Verify email sending works (SMTP configuration)
• •Verify cron jobs execute (wp-cron or server-level cron)
• •Verify SSL works correctly (no mixed content warnings)
• •Run Lighthouse on the staging site to confirm TTFB improvement

5. DNS switch (zero-downtime):

• •Lower DNS TTL to 300 seconds (5 minutes) at least 48 hours before the switch
• •Perform a final database sync immediately before switching DNS
• •Update DNS A record to point to the new server
• •Monitor propagation with tools like whatsmydns.net
• •Keep the old server running for 48+ hours (some DNS resolvers cache beyond TTL)

6. Post-migration optimization:

• •Enable page caching on the new host (managed hosts usually handle this automatically)
• •Configure Redis object caching if available
• •Verify OPcache is enabled and properly configured
• •Set up CDN integration (Cloudflare or host-provided CDN)
• •Test TTFB from multiple locations to confirm improvement
• •Monitor for 1–2 weeks for any issues

Traffic spikes kill unprepared infrastructure. Black Friday, product launches, viral social media moments, TV appearances, and seasonal peaks can increase traffic 10×–100× within minutes. Preparation is the difference between capturing revenue and serving error pages.

The preparation timeline:

4 weeks before (if planned event):

• •Load test at 2–10× expected peak: Use k6, Locust, or Artillery to simulate concurrent users. Test the full user journey (browse → product → cart → checkout), not just page views.
• •Identify the bottleneck: Is it the application server (CPU-bound), database (query-bound), CDN (cache miss rate), or external service (payment gateway rate limits)?
• •Fix identified bottlenecks: Add database indexes, optimize slow queries, increase server resources, configure auto-scaling.

1 week before:

• •Warm CDN cache: Crawl your entire site programmatically to populate CDN edge caches. Use a tool like Screaming Frog or a custom script that hits every product and category URL.
• •Extend cache TTLs: Increase TTLs for static assets and HTML pages during the event. Product prices won't change during a flash sale — cache aggressively.
• •Enable stale-while-revalidate: Serve cached content while the origin generates fresh content. Users get instant responses even during cache revalidation.
• •Pre-scale infrastructure: Don't wait for auto-scaling triggers during the event. Add application servers, increase database resources, and upgrade CDN tier BEFORE the spike.

Day of:

• •Monitor in real-time: Dashboard showing error rates, response times, CDN cache hit rates, checkout completion rates, and server resource utilization.
• •War room: Have engineers available to respond to issues immediately. Pre-define escalation procedures.
• •Disable non-essential features: If the origin is struggling, disable recommendation engines, chat widgets, and personalization to reduce server load.

Graceful degradation plan: When all else fails, degrade gracefully rather than crash completely:

• •Queue system: Implement a virtual waiting room (Cloudflare Waiting Room, Queue-it) that holds users in a queue during extreme spikes
• •Static fallback: Serve cached/static versions of product pages if the application server is overwhelmed
• •Feature toggling: Disable resource-heavy features (search autocomplete, real-time inventory, personalization) via feature flags
• •Rate limiting: Limit requests per IP to prevent individual users from consuming disproportionate resources

Post-spike analysis:

• •Review error rates, response times, and revenue throughout the spike
• •Identify moments where infrastructure struggled and why
• •Document what worked and what didn't for the next event
• •Correlate speed degradation with revenue impact to justify future infrastructure investment

Infrastructure optimization is not a one-time project — it requires ongoing monitoring to prevent gradual degradation, catch regressions after deploys, and justify continued investment.

Essential monitoring layers:

1. Uptime monitoring:

• •Monitor from multiple global locations (not just one)
• •Check every 1–5 minutes for production sites
• •Alert on downtime within 1 minute via PagerDuty, Opsgenie, or Slack
• •Tools: Pingdom, UptimeRobot, Better Uptime, StatusCake

2. TTFB monitoring:

• •Track TTFB trends over time from multiple locations
• •Set alerts for TTFB exceeding 300ms (warning) and 600ms (critical)
• •Compare TTFB across different page types (homepage, product, checkout)
• •Tools: Grafana + Prometheus, Datadog, New Relic, or CDN analytics

3. CDN performance monitoring:

• •Track cache hit rate daily (alert if drops below 80%)
• •Monitor bandwidth usage and cost
• •Review top cache-miss URLs weekly (these are optimization opportunities)
• •Check edge response times by region

4. Error rate monitoring:

• •Track 5xx error rates (server errors) — alert above 0.1%
• •Track 4xx error rates (client errors) — review weekly for broken links/redirects
• •Monitor slow response rates (requests taking >3 seconds)
• •Separate error tracking by page type and geography

5. Database performance monitoring:

• •Track slow query log (queries taking >100ms)
• •Monitor connection pool utilization
• •Alert on database CPU/memory approaching limits
• •Track cache hit rates for Redis/Memcached object cache

6. CrUX (Chrome User Experience Report):

• •The CrUX Dashboard shows real-user infrastructure performance
• •TTFB in CrUX reflects actual user experience, including DNS, network, and server processing
• •Track mobile vs desktop TTFB separately
• •Set up BigQuery exports for granular analysis

Correlating infrastructure changes with business metrics:

• •When you upgrade hosting, document the TTFB change AND the conversion rate change
• •When CDN cache hit rate improves, correlate with page load time improvement
• •When a traffic spike succeeds without downtime, calculate the revenue protected
• •Present infrastructure investment as revenue protection and growth enablement, not cost