Reduce Time to First Byte (TTFB)

Time to First Byte (TTFB) measures the elapsed time from when the browser sends an HTTP request to when it receives the first byte of the response. It is a composite of four components: DNS lookup time (resolving the domain name to an IP address), TCP connection time (establishing the TCP connection to the server), TLS negotiation time (establishing the encrypted HTTPS connection), and server processing time (the time the server spends generating the response). Each component can be the dominant contributor to total TTFB depending on your infrastructure configuration.

Google's Core Web Vitals guidelines consider TTFB under 600ms as good, 600ms to 1,800ms as needing improvement, and over 1,800ms as poor. Google includes TTFB implicitly in the Largest Contentful Paint calculation—LCP cannot start until the server has responded. A high TTFB adds directly to LCP time, meaning that improving TTFB has a 1:1 impact on LCP improvement. For pages that are LCP-limited by server response time rather than by client-side rendering or resource loading, TTFB optimization delivers the highest LCP improvement per engineering hour.

Measure TTFB from multiple geographic locations to distinguish between high server processing time (consistently high TTFB from all locations) and high network latency (TTFB high only from locations far from your servers). A TTFB of 800ms from both US East and EU West likely indicates a slow server or database query. A TTFB of 200ms from US East but 600ms from EU West indicates the content is not CDN-cached and the user is making a full round-trip to the origin in a distant region. These two scenarios require completely different fixes.

TTFB breakdown by component is available in the browser's Performance API through the PerformanceNavigationTiming interface. The serverTiming attribute of the response can include custom server-side timing data that breakdown response generation time by phase: database query time, cache lookup time, template rendering time, and middleware processing. Emitting server timing headers allows your RUM tool to capture not just total TTFB but the breakdown of how server processing time was spent, dramatically accelerating root cause analysis for high TTFB.

Monitor TTFB for every page template in your application, not just the landing page. A TTFB measurement from a single page is unrepresentative—your checkout page may have high TTFB due to inventory queries while your blog posts have low TTFB from edge caching. Track TTFB as a distribution (P50, P75, P90, P95) segmented by page type, user authentication status, and geographic region. This multi-dimensional view reveals where optimization effort will have the greatest impact across your user base.

Compare TTFB across deployments to detect backend performance regressions immediately after release. A step change in TTFB—where P95 increases from 400ms to 900ms aligned precisely with a deployment timestamp—is a clear regression signal. Configure automated TTFB regression detection that alerts when post-deployment TTFB increases by more than 20% relative to the pre-deployment baseline measured over the same time window. This catches performance regressions before users file support tickets and while the responsible code change is still fresh in the deploying developer's mind.

Segment TTFB by user authentication status to understand whether your application's per-user data loading is the bottleneck. Unauthenticated page requests that hit CDN caches may have TTFB under 50ms. Authenticated requests that must hit the origin and perform user-specific database queries may have TTFB of 400ms or more. The gap between these two groups represents the cost of your authenticated request processing pipeline—database queries for user data, permission checks, session validation—and identifies the optimization opportunity for authenticated user experiences.

Use server-side performance tracking to measure TTFB from the server's perspective in addition to the client's perspective. Client-measured TTFB includes network transit time that the server cannot control. Server-measured response generation time (from when the request arrives at the server to when the response bytes are sent) is the component that application code changes can improve. Both measurements are valuable: client TTFB informs users about their actual experience; server processing time guides optimization prioritization.

Database queries are the dominant contributor to server processing time in the vast majority of web applications. A single synchronous database query executed before returning a response adds its full execution time to every user's TTFB. Profile the database queries executed during page generation and identify the slowest queries. Adding appropriate indexes to WHERE clause columns, rewriting inefficient queries, and replacing multiple sequential queries with a single JOIN or parallel queries can reduce server processing time from 500ms to under 50ms for database-bound pages.

Authentication and session validation middleware adds fixed overhead to every authenticated request. Middleware that validates a JWT token by calling a remote authentication service adds one external API round-trip to TTFB for every request. Cache session data locally (in Redis or process memory) after initial validation so subsequent requests validate tokens from the local cache rather than making remote calls. A remote authentication call adds 50 to 200ms to every request; a cached token validation adds under 1ms. This single optimization can eliminate a quarter of your TTFB for authenticated user requests.

Template rendering time contributes to TTFB for server-rendered applications. Complex templates that perform computation during rendering (sorting, filtering, formatting), access the database or ORM associations during rendering (N+1 in templates), or iterate over large datasets add rendering time to TTFB. Move computation and data aggregation into controller code that runs before rendering begins, and ensure all data needed by the template is pre-loaded before the render method is called. Server-Side Rendering (SSR) in React/Next.js has similar concerns—server components that access databases or external APIs during rendering add to TTFB.

Eliminate sequential awaits in server request handlers that could be parallelized. If your handler fetches user profile data and then fetches user preferences and then fetches recent activity as three sequential async operations, total TTFB includes the sum of all three operations' durations. Rewriting to execute all three operations in parallel with Promise.all() (Node.js) or asyncio.gather() (Python) reduces TTFB to the duration of the slowest operation, typically reducing the sequential total by 60 to 75%.

Full-page caching serves entire HTML responses from cache, reducing server processing time to near zero for cached pages. For pages that are identical for all users (marketing pages, blog posts, product pages with common content), a full-page cache with a 60-second TTL eliminates 99%+ of origin requests during normal operation. Implement full-page caching at the CDN layer for publicly accessible pages, and at the application layer (Redis, Varnish) for pages that require authentication but are identical for all users of the same role.

Fragment caching caches portions of a page independently, enabling caching for pages that have both cacheable and non-cacheable sections. A product page that is mostly static content but includes dynamic inventory availability can cache the static content section with a long TTL while refreshing only the inventory section on each request. Fragment caching reduces database query load even when full-page caching is not feasible, cutting TTFB for the database-heavy sections of the page.

Output caching for API responses stores the serialized response body in a cache and serves it directly without re-executing the business logic, database queries, or serialization. Even for responses that cannot be cached for long periods, a 5 to 30-second cache TTL can dramatically reduce origin database load during traffic spikes. A product detail API that accepts 1,000 requests per second with a 10-second cache TTL only executes the underlying database query 6 times per minute (once per TTL expiry) instead of 1,000 times per second.

Stale-while-revalidate (SWR) cache semantics serve a potentially stale cached response while asynchronously refreshing it in the background. From the user's perspective, TTFB is always the cache lookup time (under 5ms), even when the cache is being refreshed. The Cache-Control header supports SWR with the stale-while-revalidate directive: Cache-Control: max-age=60, stale-while-revalidate=600 serves the cached response for up to 10 minutes (600 seconds) while the cache is being refreshed, after the 1-minute (60-second) fresh window expires. This effectively eliminates TTFB variability at the cost of brief data staleness.

DNS resolution time adds 20 to 200ms to the first connection to any new domain. DNS lookup results are cached by browsers and operating systems, so this cost is paid only once per domain per user session, not on every request. However, users who have never visited your site, users who clear their DNS cache, and users connecting from networks with slow DNS resolvers experience full DNS lookup latency on every page load. Use a fast, globally distributed DNS provider, set appropriately short TTLs (5 minutes is standard) that balance update latency with lookup frequency, and implement DNS prefetching for domains your page will connect to.

TLS 1.3 reduces the TLS handshake from 2 round-trips (TLS 1.2) to 1 round-trip, cutting TLS negotiation time approximately in half. TLS 1.3 also supports 0-RTT session resumption for returning users, allowing resumed connections to send application data with the first packet, eliminating TLS handshake latency entirely for users with valid session tickets. Enable TLS 1.3 on all servers and CDN configurations, and ensure TLS session tickets are configured to allow 0-RTT resumption while maintaining appropriate security policies.

HTTP/2 and HTTP/3 improve connection efficiency for users making multiple requests. HTTP/2's multiplexing allows multiple requests over a single TCP connection, eliminating the 6-connection parallelism limit of HTTP/1.1 and the head-of-line blocking that affects separate connections. HTTP/3 over QUIC eliminates TCP's connection establishment overhead and is resilient to packet loss, which is particularly impactful on mobile networks. Enable HTTP/2 on your origin servers and CDN endpoints, and monitor browser support metrics before prioritizing HTTP/3 migration.

Geographic proximity between users and servers reduces network round-trip time, which directly affects TTFB for uncached requests. For origin requests that cannot be served from CDN cache, locate application servers in regions near your highest-traffic user locations. Multi-region deployments with traffic routing based on user geography can reduce network round-trip time from 150ms (cross-continental) to under 20ms (same region). Evaluate the user geography distribution from your RUM data to prioritize which regions would benefit most from regional deployment.

HTTP response streaming allows the server to begin sending response bytes before the entire response body has been generated. For server-rendered HTML pages, streaming the HTML document head immediately (while the body is still being generated) allows the browser to begin loading CSS, fonts, and critical JavaScript before the server finishes processing database queries for the page body. React 18's renderToPipeableStream and Next.js 13+ App Router's streaming architecture implement this pattern, potentially improving time-to-first-content by 200 to 500ms for database-heavy pages.

Early hints (HTTP 103 status code) allow servers to send preliminary response headers before the final response is ready. A 103 Early Hints response containing Link headers for preloading critical resources allows the browser to begin fetching those resources while the server continues processing the full response. The server then sends the actual 200 response when ready. This overlaps resource loading with server processing time, reducing perceived page load times even when server processing is unavoidable. Supported by nginx, Cloudflare, and Fastly with major browser support since 2022.

Defer non-critical data loading to after the initial response. For pages that display above-the-fold content alongside a data-heavy section below the fold, serve the above-the-fold content immediately and load the below-the-fold data separately via an API call after the page is rendered. This pattern—sometimes called progressive loading or deferred hydration—reduces TTFB for the initial page response by eliminating database queries for data that users will not see immediately. React's Suspense boundaries with streaming SSR implement this pattern declaratively.

Database read replicas with geographic distribution reduce database query time for the portion of origin requests that hit the database. Routing read queries to a replica in the same region as the application server eliminates cross-region database latency that can add 50 to 200ms per query. Monitor replication lag to ensure replica data is fresh enough for your consistency requirements, and implement fallback logic to route to the primary when replica lag exceeds acceptable thresholds or when reading data that was recently written.