← Back to blog

Technical SEO · July 13, 2026 · 8 min read

TTFB Optimization: How Server Response Time Quietly Caps Your LCP

TTFB optimization is the backend lever that caps LCP. Learn caching, CDN config, and database tuning to cut server response time and hit Core Web Vitals targets.

By FluxWriter Team

TTFB optimization is the most underappreciated lever in Core Web Vitals work. Spend weeks compressing images and deferring JavaScript, and you can still watch your Largest Contentful Paint (LCP) stubbornly miss the 2.5-second threshold — because the server itself is slow to respond. This guide focuses on the backend: caching strategies, CDN configuration, and database tuning that cut Time to First Byte at the root.

Why TTFB Is the Hidden LCP Ceiling

Google's own research shows that a TTFB above 800ms makes a "good" LCP score nearly impossible to achieve. The math is simple: LCP measures when the largest element on the page is rendered. That clock starts from navigation — which means every millisecond the server takes to return its first byte is a millisecond permanently baked into your LCP.

Chrome's field data in CrUX consistently shows that pages with TTFB under 200ms achieve "good" LCP at roughly 3x the rate of pages with TTFB above 600ms. The rendering pipeline — HTML parsing, resource discovery, style calculation — cannot start until those first bytes land.

Yet most CWV guides bury TTFB in a paragraph and move on to images. The backend is messier than front-end optimizations. It requires touching infrastructure. But it's where the largest, most durable gains live.

The Three Layers That Determine TTFB

Before optimizing, it helps to separate the problem into its actual components:

Most slow TTFBs are a compounding problem across all three. A 700ms TTFB might be 80ms of DNS, 120ms of TLS, 200ms of application logic, and 300ms of database work. Fixing only one layer rarely moves the needle enough.

CDN Configuration: The Fastest Win

A Content Delivery Network cuts the network transit layer by serving responses from an edge node close to the user. But misconfigured CDNs can actually make TTFB worse by adding a cache-miss hop to origin.

Cache-Control Headers Matter More Than the CDN Plan

The CDN can only cache what you tell it to cache. A common misconfiguration: setting Cache-Control: private or no-store on pages that are actually public and identical for all logged-out users. The CDN dutifully passes every request to origin.

For a typical marketing or content page:

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

This tells browsers not to cache (useful if you need instant purges), tells CDN edge nodes to cache for 24 hours, and allows stale serving for 60 seconds while revalidating in the background. The result: logged-out visitors get sub-10ms TTFB from edge, and your origin sees a fraction of the traffic.

Vary Header Discipline

The Vary header tells CDNs to maintain separate cache entries per header value. Vary: Accept-Encoding is fine. Vary: Cookie is often catastrophic — it means the CDN creates a unique cache entry per cookie combination, effectively bypassing your cache for any user with session cookies. Audit your Vary headers. Strip anything that doesn't genuinely produce different content.

TLS Termination at Edge

If your origin handles TLS and your CDN is only proxying, you're adding a full TLS handshake round-trip on every uncached request. Terminate TLS at the CDN edge. This alone can cut 100–200ms from cold TTFB for users far from your datacenter.

Server-Side Caching: Full-Page vs. Fragment

After CDN, the next lever is what happens on your origin when a cache miss does reach it.

Full-Page Caching

For content-heavy pages with few personalized elements, full-page caching with a tool like Varnish, Redis, or a platform-native cache (Next.js's Data Cache, Laravel's response cache) can reduce origin TTFB from 400ms to under 20ms. The page is rendered once, stored, and returned as raw bytes on every subsequent hit.

The implementation challenge is cache invalidation. A common approach:

1. Tag cache entries with content IDs (e.g., post:1234, category:seo).
2. On content update, purge by tag rather than URL.
3. Use short TTLs (60–300 seconds) for pages you can't reliably tag-purge.

Fragment / Edge-Side Caching

When a page has a mix of cacheable and personalized content, full-page caching breaks. Fragment caching stores individual components — the navigation, the product listing, the sidebar — separately and assembles them on request. ESI (Edge Side Includes) moves this assembly to the CDN edge. Both approaches are more complex but allow aggressive caching of the 90% of a page that doesn't change per user.

Database Tuning: The Slowest Source of TTFB

For dynamic applications, the database is usually where time disappears. A query that returns instantly in development can take 800ms in production against a table with 10 million rows and no index on the WHERE clause column.

Identify the Slow Queries First

Do not guess. Use your database's query logging:

• PostgreSQL: pg_stat_statements extension + log_min_duration_statement = 100 (logs any query over 100ms)
• MySQL: slow_query_log = ON with long_query_time = 0.1
• MongoDB: db.setProfilingLevel(1, { slowms: 100 })

Run these in production for 24 hours. The top 5 slow queries are usually responsible for 80% of database-related TTFB problems.

Indexing: The Highest-Leverage Fix

Missing indexes are the most common database performance problem and the easiest to fix without changing application code. If a query filters on status and created_at, a composite index on (status, created_at) can take a 600ms full table scan to a 2ms index lookup.

One concrete example: an e-commerce site filtering orders by user_id and status with 4 million rows. Without an index:

• Query: SELECT * FROM orders WHERE user_id = 1234 AND status = 'pending'
• Execution: 680ms (sequential scan)
• With composite index on (user_id, status): 1.8ms

That 678ms difference shows up directly in TTFB.

Connection Pooling

Database connections are expensive to establish. Applications that open a fresh connection per request pay 20–50ms per request just on connection overhead, plus risk exhausting the database's connection limit under load. Use a connection pool — PgBouncer for PostgreSQL, HikariCP for JVM apps, or whatever your framework provides — and keep connections warm.

Application-Level TTFB Gains

Between the CDN and the database sits your application code. A few high-impact areas:

Defer Work That Doesn't Block the Response

If your response handler is running analytics processing, sending emails, or triggering webhooks synchronously, it's adding that latency to TTFB. Move anything that isn't required to generate the response into a background job or message queue.

Reduce Render-Blocking Computation

Server-side rendering frameworks can accumulate expensive operations during render: multiple sequential API calls, deeply nested component trees that trigger repeated data fetches. Profile your render path with APM tooling (Datadog, New Relic, or open-source alternatives like OpenTelemetry). Sequential awaits that could be Promise.all() calls are a common finding.

HTTP/2 and HTTP/3

If your origin or CDN is still serving HTTP/1.1, upgrade. HTTP/2 multiplexing reduces the connection overhead for concurrent requests. HTTP/3's QUIC protocol eliminates TCP head-of-line blocking, which matters most for users on lossy mobile networks where packet loss would otherwise stall a TCP connection.

Measuring TTFB Correctly

Field data (real users) and lab data (synthetic tests) can show very different TTFB numbers. Use both.

• Lab: WebPageTest's "Time to First Byte" metric, or Lighthouse's server response time audit. Test from multiple geographic locations.
• Field: CrUX Dashboard or the web-vitals JavaScript library's onTTFB() callback to capture real user TTFB distributions and send them to your analytics platform.

Segment field data by geography, device type, and connection type. A 150ms TTFB for US desktop users can mask a 900ms TTFB for Southeast Asia mobile users — exactly the scenario where CDN edge placement and TLS termination make the biggest difference.

FAQ

What is a "good" TTFB target?

Google's guidance is under 800ms for field data, but that's a lagging indicator. For a realistic shot at "good" LCP, aim for TTFB under 200ms for cached responses and under 500ms for uncached, dynamic pages. Sub-200ms cached TTFB is achievable for most content sites with a properly configured CDN.

Does TTFB affect SEO directly?

TTFB is not a direct ranking signal, but it's the upstream bottleneck for LCP — which is. A slow TTFB makes a good LCP score structurally impossible to achieve, which places a ceiling on your Core Web Vitals performance and, by extension, the CWV ranking factor. The path to good LCP almost always runs through TTFB.

How do I know if my TTFB problem is network, server, or database?

WebPageTest's waterfall view breaks this down. The TTFB bar is divided into "Waiting" (time before first byte) and "Receiving" (download time). Within the waiting period, the connection view shows DNS, TCP, and TLS separately. Whatever remains after subtracting those is server processing time — split between application code and database queries. APM tooling adds the database granularity that WebPageTest can't provide.

TTFB optimization rarely has a single fix. The highest-impact approach is systematic: measure with real field data, separate network from server from database, fix the largest contributor first, then re-measure. CDN caching and proper cache headers typically provide the fastest wins; database indexing provides the largest wins on dynamic pages.

If you're writing technical content around site performance and want readers to retain the nuance rather than gloss over it, tools like FluxWriter can help structure drafts that stay technically grounded without padding.

← All posts