If your pages feel sluggish, Time to First Byte (TTFB) is often where to look first. TTFB measures how long the browser waits before the server sends anything back. That wait sits at the front of the loading chain: before rendering, before subresource discovery, before Largest Contentful Paint (LCP) can even begin. LCP tracks when the largest visible element on a page finishes rendering, and it can't start until that first byte arrives. A slow TTFB delays every metric that follows. This guide covers what TTFB measures, how to test it, what causes it to spike, and which fixes move the needle.
TTFB is the elapsed time from the moment a browser initiates a navigation to the moment the server sends its first byte back. That single number is actually several phases stacked in sequence:
Which phase is slow determines which fix applies, so measuring before optimizing matters.
Google evaluates TTFB at the 75th percentile per origin in Chrome User Experience Report (CrUX) data, using these thresholds:
If you're in the "needs improvement" or "poor" range, users are waiting for your server before the page has done any work at all.
TTFB isn't a Core Web Vital, but it sets the clock for the ones that are. Google measures page experience through three Core Web Vitals: Largest Contentful Paint (LCP), which tracks how long it takes for the main content to appear on screen; Interaction to Next Paint (INP), which measures how quickly the page responds when a user clicks or taps; and Cumulative Layout Shift (CLS), which captures how much the page jumps around while it's still loading.
None of those things can happen until the browser receives that first byte from the server. If the server takes 2 seconds to respond, the browser spends 2 seconds doing nothing, and every other metric starts its clock 2 seconds late.
The field data shows the gap clearly: sites with poor LCP have a 75th-percentile TTFB of 2,270ms, while sites with good LCP have a median TTFB around 600ms. Faster server response doesn't guarantee good scores across the board, but a slow one makes them nearly impossible.
Reduce latency and handle data in real time.
Two types of data are useful here. Field data reflects real user conditions (varying networks, devices, and locations) and shows what your actual audience experiences. Lab data runs under controlled conditions you define, which makes it repeatable and useful for debugging. The most reliable picture comes from using both.
PageSpeed Insights shows both in one report. Chrome DevTools breaks down per-request timing in the Network tab, including a dedicated TTFB row. WebPageTest lets you test from specific regions, which helps identify content delivery network (CDN) coverage gaps. For real-user monitoring in production, the Navigation Timing API and Google's web-vitals library both expose TTFB from actual sessions.
One thing to know: TTFB includes redirects in most definitions, so field data may show higher numbers than synthetic tools for the same page.
TTFB is a sum of phases, so the cause determines the fix. The four most common culprits are:
Each of these maps directly to a fix in the next section.
Get Redis up and running in minutes, then scale as you grow.
Once you've identified which phase is slow, the fix becomes clearer. The highest-impact changes tend to address the phases with the most headroom.
In-memory caching sits across several of these: it reduces server processing time, cuts database round trips, and can serve cached responses without touching the origin at all.
Memory-caching is a primary server response time optimization. When database or session lookups sit on your critical path, serving that data from RAM instead of disk can cut the server-processing phase from hundreds of milliseconds to single digits.
Redis is built for exactly this. Redis is a real-time data platform built for sub-millisecond data access, and capabilities like the cache-aside pattern can help keep the data layer from dominating TTFB. Common use cases include query caching (storing frequently requested results in memory), session storage (avoiding a database round trip on every authenticated request), and API response caching (serving repeated responses without regenerating them). Redis 8 introduced hash-field expiration for advanced session-management scenarios, letting you set time-to-live values on individual fields within a hash rather than expiring the entire key.
Use Redis to power real-time data, retrieval, and caching at scale.
With those fixes in mind, it's worth zooming back out to the bigger picture. In 2025, 55% of desktop sites and 44% of mobile sites have good TTFB, which means more than half of all mobile sites still fall short. The share of sites achieving good TTFB increased by 1% on desktop and by 2% on mobile since 2024, but the gap between mobile and desktop remains at 11 percentage points.
Getting your TTFB under 800ms across real-user traffic puts you ahead of the majority of mobile sites, where progress has been slow.
TTFB affects every performance metric that follows. A slow server response delays First Contentful Paint (FCP), delays LCP, and delays when the browser can start working with the page.
One of the biggest levers for reducing the server-processing component of TTFB is data retrieval speed. Redis is a real-time data platform that keeps frequently accessed data in memory, reducing the disk I/O that slows server response times. Cache-aside patterns, session stores, and API response caching can help keep your data layer within its latency budget rather than consuming it on every request.
Redis combines caching, session management, and data retrieval in a single platform, so you don't need to stitch together multiple tools to keep server response times low. Try Redis free to see how it handles your caching workload, or talk to our team about reducing server response times across your infrastructure.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。