How to Improve TTFB with Server-Side Caching

Time to First Byte (TTFB) is the time between a browser requesting your page and receiving the first byte of the response. A slow TTFB — anything above 800ms — is a hard ceiling on your FCP and LCP. No amount of front-end optimization can overcome a 2-second server response.

Caching is the most effective tool for improving TTFB.

Why Caching Matters for TTFB

Without caching, every request to a dynamic page triggers the full application stack: incoming request → routing → database queries → template rendering → response. For a complex page, this can take 500ms–3000ms.

With full-page caching, the server stores the rendered HTML and serves it immediately on subsequent requests. TTFB drops to under 100ms.

Types of Caching

Full-Page (Page) Cache

The entire rendered HTML of a page is stored and served directly, bypassing the application stack. This is the highest-impact cache for most sites.

WordPress: WP Rocket, W3 Total Cache, LiteSpeed Cache (best option for LiteSpeed servers), Cloudflare’s APO.

Laravel: Route caching (php artisan route:cache) + response caching packages.

Next.js / Astro: Static generation (SSG) pre-renders pages at build time — effectively a permanent full-page cache.

Limitation: Full-page cache can’t be used for pages with user-specific content (shopping cart, user dashboard). Use partial caching or cache with varying keys.

Object Cache (Database Query Cache)

Caches the results of database queries in memory (Redis or Memcached). Instead of querying the database on every request, the application reads from in-memory storage.

// Without cache: hits the database every time
$products = DB::select('SELECT * FROM products WHERE category = ?', [$category]);

// With Redis cache: database hit only on cache miss
$products = Cache::remember("products:$category", 3600, function () use ($category) {
    return DB::select('SELECT * FROM products WHERE category = ?', [$category]);
});

Object caching reduces TTFB for dynamic pages that can’t use full-page caching.

Edge / CDN Cache

CDN providers like Cloudflare, Fastly, and AWS CloudFront cache pages at edge nodes globally. When a user in Sydney requests your page, they get it from a Sydney edge node rather than your US-based origin server — reducing latency from 200ms to 20ms.

Cloudflare offers:

• Page Rules to cache HTML responses
• Cache Rules for fine-grained control
• APO (Automatic Platform Optimization) for WordPress — one click to edge-cache the entire site

Cache-Control headers tell CDNs and browsers how long to cache responses:

Cache-Control: public, max-age=3600, s-maxage=86400, stale-while-revalidate=86400

s-maxage sets the CDN TTL. stale-while-revalidate serves the cached version while updating it in the background.

Fragment / Partial Caching

For pages with mixed content (some static, some dynamic), cache the static parts. In template engines:

// Cache the product list for 1 hour, but always render the cart dynamically
@cache('product-list', 3600)
    @foreach($products as $product) ... @endforeach
@endcache

Platform-Specific Quick Wins

WordPress: Install LiteSpeed Cache or WP Rocket. Enable full-page caching and CDN integration. Enable Redis object caching if your host supports it.

Shopify: TTFB is largely controlled by Shopify — switch to a Shopify-optimized theme and minimize app scripts.

Next.js/Vercel: Use static generation (getStaticProps in Pages Router, or React Server Components in App Router) with proper cache headers. Vercel’s edge network handles distribution.

Custom Node.js/Express: Add a Redis-backed caching layer for expensive routes. Use etag and Last-Modified headers for browser caching.

What Good TTFB Looks Like

For static/cached pages: 10–50ms (served from CDN edge) For dynamic pages with object caching: 100–300ms For uncached dynamic pages: 300–800ms (acceptable)

Anything above 800ms is a problem worth investigating. Run a test on debugutils.dev — your waterfall report breaks down exactly where TTFB time is going.