Before a single pixel appears, before the slightest image downloads, before the browser even knows what the page will look like, it waits for one thing: the first byte of the server's response. The time elapsed until that moment has a name, TTFB (Time To First Byte), and it influences everything that follows. A page cannot be fast if its first byte is slow: every millisecond of TTFB is fully reflected in all subsequent metrics, from the first render to LCP.
TTFB is, however, the great forgotten optimization. It is not part of the Core Web Vitals, it is not visible in a screenshot, and it occurs in layers (network, server, database) less visible than the front-end. It is also a more subtle metric than it appears: depending on the tool that measures it and the definition it uses, two TTFB figures may not be talking about the same thing, and comparing them carelessly leads to bad decisions.
Following our guides on LCP, CLS, and INP, this new article in our series on metrics breaks down Time To First Byte: what it measures exactly, how to evaluate it without error, what degrades it on the network and server side, and the levers to bring it back under the recommended thresholds.
TTFB, the first link in the entire rendering chain
The reference definition, provided by web.dev, is as follows: TTFB is the time elapsed between the start of navigation and the arrival of the first byte of the HTML response. This delay is not a monolithic block: it aggregates a whole series of steps, each of which can become the weak link. Potential redirects, DNS resolution, TCP connection establishment, TLS negotiation, request sending, then server processing time and the response's return trip: TTFB is the sum of everything that precedes the first byte, and optimizing it begins by identifying which of these steps weighs the most.
Regarding thresholds, web.dev recommends aiming for a TTFB of 800 ms or less at the 75th percentile of visits, and considers any value over 1.8 seconds to be poor. The logic behind these numbers is arithmetic: the good LCP threshold is set at 2.5 seconds by the official documentation, and TTFB consumes the first slice of that. A TTFB of 1.8 seconds leaves only 700 ms to download and display the main page element: it's safe to say the game is lost before it even starts. This is precisely what the breakdown of LCP into sub-parts proposed by web.dev shows, with TTFB being the first of the four segments.
One metric, multiple definitions
A warning is necessary before comparing numbers. As detailed by Robin Marx, web performance architect at Akamai, in his article in the Web Performance Calendar 2025, the term TTFB covers several competing definitions depending on the tools: some measure from the start of navigation, including redirects, others from the sending of the request over an already established connection, and still others exclude DNS or TLS. A TTFB measured by curl on a new connection, the one displayed by DevTools, and the one reported by Chrome field data do not measure the exact same interval.
Recent mechanisms like speculative preloading, which we explored in our article on Speculation Rules and prerendering, further blur the interpretation: a prerendered page shows an almost zero TTFB that no longer says anything about the server. The rule of thumb is simple: always compare measurements from the same tool, under the same conditions, and document what is being measured.
How to measure TTFB, in the lab and in the field
The most direct measurement is in the DevTools Network tab: the first line of the waterfall, that of the HTML document, details in its Timing tab the server response waiting time, broken down into phases (DNS, connection, TLS, waiting). In JavaScript, the PerformanceNavigationTiming API exposes the same timestamps, and TTFB corresponds to the responseStart attribute, measured from the start of navigation. It is this definition, including redirects and connection, that is used by Chrome ecosystem tools, and it is the one we use in the rest of this article:
const [nav] = performance.getEntriesByType('navigation');
console.log('TTFB :', nav.responseStart, 'ms');
// Décomposition des étapes qui le composent
console.log('Redirections :', nav.redirectEnd - nav.redirectStart, 'ms');
console.log('DNS :', nav.domainLookupEnd - nav.domainLookupStart, 'ms');
console.log('TCP + TLS :', nav.connectEnd - nav.connectStart, 'ms');
console.log('Requête + serveur :', nav.responseStart - nav.requestStart, 'ms');These lab measurements have a limitation: they describe your connection, from your machine, at a given moment. Your visitors, however, connect from other networks, other continents, other devices. Field data from the Chrome UX Report aggregates the TTFB actually experienced by Chrome users on your site, at the 75th percentile, and is the only reliable basis for judging the real situation.
The distinction between these two families of tools is a subject in itself, which we have covered in our comparison PageSpeed Insights vs. Lighthouse: remember that lab TTFB is used for diagnosis, and field TTFB is used to prioritize and observe progress.
The trap of averages and bimodal distributions
One last measurement reflex makes all the difference: never reason in averages. The TTFB of a cached site typically forms a bimodal distribution: a population of requests served from the cache, in tens of milliseconds, and a population of requests generated on demand, ten to fifty times slower. The average of the two falls into a middle ground that doesn't correspond to anyone's experience, and masks both a poor hit rate and abnormally slow generation.
This is why field data is expressed at the 75th percentile: this value guarantees that three out of four visitors have an experience at least as good as the displayed figure. In practice, the right reflex is to examine the two populations separately: the TTFB of cached pages measures the health of the delivery infrastructure, while that of uncached pages measures the health of generation. Confusing them means optimizing blindly.
On the network side: what happens before your server
Part of the TTFB is consumed even before your server receives the request. At this stage, everything is counted in round trips: each step adds the visitor's latency once to the waiting time, and this latency quickly amounts to tens of milliseconds on a mobile network. Five areas make up this chapter: redirects, connection establishment, protocol, geographical distance, and compression, to which is added a separate mechanism, Early Hints, which does not reduce waiting time but makes it more profitable.
Redirects, latency paid twice
The first, often overlooked, item is redirection: each hop (from HTTP to HTTPS, from apex to www, from an old URL to a new one) costs a full network round trip, and redirect chains add them up. MDN documentation reminds us that they accumulate silently over migrations: an external link in HTTP to an old domain can go through three redirects before reaching the final page, which is three times the visitor's latency added to the TTFB before any useful work is done.
The redirection work is done in two stages. First, the inventory: Search Console crawl reports and a site crawl reveal existing chains, and the curl -IL command allows you to follow the path of a given URL step by step. Then, the reduction: each retained redirection must lead directly to the final URL, in a single hop, including from historical domain variations. Internal site links should never go through a redirection: pointing directly to the canonical URL is a free gain, repeated on every navigation of every visitor.
A special case can be removed rather than optimized: the redirection from HTTP to HTTPS, present on almost all sites. The HSTS header, documented by MDN, instructs the browser to never again attempt the unencrypted version: from the second visit onwards, this hop purely and simply disappears from the path. Registration on the HSTS preload list embedded in browsers extends protection to the very first visit: the HTTP to HTTPS hop is never paid for again.
DNS, TCP, TLS: the entry ticket for every connection
Before the first useful byte, a new connection goes through three stages: DNS resolution, which translates the domain name into an IP address, the TCP handshake, which establishes the channel, and the TLS negotiation, which encrypts it. Each costs one or more round trips, and their total weight depends directly on the latency between the visitor and the server. On a fiber connection with 5 ms latency, the addition is painless; on a mobile in a mid-range area, it can represent several hundred milliseconds of TTFB on its own.
Each stage has its lever, starting with DNS, which is mistakenly thought to be uniform: resolution depends on the provider hosting your zone, and not all offer the same level of performance. Continuous measurements from DNSPerf (secondary source) show significant differences in response times between providers in Europe, with Cloudflare regularly topping the rankings. Changing zone providers is a painless and often free operation, and reasonable TTLs also prevent repeated resolutions.
On the TLS side, the protocol version matters: TLS 1.3, specified by RFC 8446, reduces negotiation to a single round trip where TLS 1.2 required two, and its session resumption further shortens subsequent connections. For critical third-party domains, the rel="preconnect" hint finally allows paying this entry ticket in advance, while the browser is still busy elsewhere.
HTTP/3 and QUIC: merged handshakes
The most radical overhaul of this entry ticket comes from the protocol itself. HTTP/3, standardized by RFC 9114, abandons TCP in favor of QUIC, a transport built on UDP and specified by RFC 9000, which merges channel establishment and its encryption into a single handshake. QUIC even allows, when reconnecting to a previously known server, sending data from the very first packet, and keeps the connection alive when the device switches networks, from Wi-Fi to 4G, without renegotiating everything.
Good news: activation generally requires no work. CDNs and recent web servers offer it as a setting, and the browser discovers the protocol's availability via the Alt-Svc header before switching to subsequent visits. Control is just as simple: availability is checked in the Protocol column of DevTools, where requests served over HTTP/3 appear as h3. A site still entirely on h2, or even http/1.1, leaves round trips on the table with each new connection.
Discovery via Alt-Svc has a limit, however: it only benefits subsequent visits, the very first connection still being established over the classic TCP and TLS stack. DNS SVCB and HTTPS records, standardized by RFC 9460, fill this gap: published in the domain's zone, they announce supported protocols in the DNS response itself. The browser thus knows, even before opening the connection, that it can speak QUIC: HTTP/3 is used from the very first connection, without prior passage through h2. Most CDNs publish these records automatically for the zones they manage; on a manually administered zone, an HTTPS record with the parameter alpn="h3" is sufficient.
Geographic distance: the CDN lever
All previous round trips have a cost proportional to the distance: since physical latency is incompressible, shortening them means bringing things closer. This is the geographical role of the CDN: placing an endpoint near each visitor, so that DNS, handshakes, and encryption are negotiated over a few tens of kilometers rather than across a continent. For international traffic, bringing the connection endpoint closer remains the most effective network lever, far ahead of any fine-tuning of protocols.
The benefit goes far beyond static files: even a dynamic, non-cacheable page benefits from a CDN, because the visitor's connection terminates at the edge, and the edge then communicates with your server over already established, warm connections between requests. The visitor pays for the short latency, the infrastructure pays for the long one.
This long latency, between the edge and the origin, is also optimized. Cloudflare Argo Smart Routing is a good example: rather than following the Internet's default routing, the service routes requests to your server via the fastest and least congested paths on the Cloudflare network, continuously measured, as described in its official documentation. The gain is maximal for visitors farthest from the origin, precisely those whose TTFB suffers the most. Other contributions of these networks, including shared caching, are detailed in our analysis of CDN advantages and disadvantages.
103 Early Hints: making incompressible waiting profitable
When the server genuinely needs time to generate the page, some of the waiting can be leveraged rather than endured. The 103 Early Hints status code, described in the Chrome documentation, allows the server or CDN to send a preliminary response while the page is being generated, instructing the browser on critical resources (stylesheet, font, main image) to prefetch without waiting for the HTML.
The measured TTFB does not change, but the time it represents ceases to be dead time: by the time the first byte arrives, some resources are already being downloaded. It's a second-act mechanism, to be considered once the fundamentals are in place, but it illustrates a useful idea: TTFB is reduced first, and what remains of it can still be made profitable.
In practice, the device assumes a link capable of emitting the 103 before the origin has responded: it is most often the CDN that memorizes the indications and serves them as soon as the next request, as described in the Cloudflare documentation. The gain grows mechanically with the generation time: the longer your server thinks, the wider the window to capitalize on. A site with an already excellent TTFB will gain almost nothing from it; a dynamic site that is slow to generate, a lot.
HTML compression, in the critical path
One last network item hides where you don't expect it: compression. On a dynamic page, the HTML is compressed on the fly, with each request, and this compression time is added to the TTFB. This is what justifies choosing the algorithm according to the type of content, a trade-off that we detailed in our comparison gzip, Brotli or Zstandard: recent algorithms compress dynamic content faster at a comparable ratio, and every millisecond of compression saved is one millisecond less TTFB.
Server-side: where TTFB is gained or lost
Once the request arrives, the stopwatch continues to run while the server generates the response. On a CMS like WordPress or PrestaShop, this generation involves starting PHP, loading the core and extensions, executing the theme, and dozens of database queries.
The quality of the hosting weighs heavily here: a saturated shared hosting, where hundreds of sites share the same PHP processes and the same database, produces erratic response times that no application optimization can fix. The foundations count just as much: a recent PHP version, a properly sized OPcache that avoids recompiling code with each request, and a number of PHP workers adapted to traffic form the foundation without which other optimizations are just patches.
The choice of hosting type deserves to be made with full knowledge. Entry-level shared hosting optimizes site density per machine, not response time for each; the parameters that matter (PHP memory, OPcache settings, database configuration) are fixed and inaccessible. A VPS provides control but transfers responsibility: the settings described in this article are then your responsibility.
Managed hosting specialists, finally, deliver these settings already done, with integrated server cache layers. There is no universal answer, but a simple criterion: the real-world TTFB, measured on your actual site, during your actual traffic hours. Hosting is judged on this curve, not on its price list or its promises.
Plugins that work behind your back
There is a cause of degraded TTFB that front-end audits never see: the background tasks of plugins. Three examples constantly come up in our diagnostics. The Redirection plugin logs by default all 404 errors and redirects for a week: on a busy site, this represents tens of thousands of database writes per day, each executed on the critical path of the visitor's request.
Broken Link Checker periodically recrawls all links on the site, consuming CPU and outgoing connections. Wordfence, finally, scans the file tree at regular intervals, with disk and memory pressure that directly competes with visitor requests.
None of these behaviors are defects: they are default settings, almost always adjustable in each plugin's interface. Reduce the log retention of Redirection, space out link scans to once a month, enable Wordfence's limited resource scan mode: these three settings cost nothing and eliminate permanent background load.
The real danger is their accumulation: a site that simultaneously runs these three processes is constantly affected by one of them, and its average TTFB suffers across all traffic. This is one of the main causes of unexplained degraded TTFB on sites that are otherwise well-optimized on the front end: all the front-end work is done, but the server remains busy with its own tasks.
The database, a silent bottleneck
At the very bottom of the stack, the database sets the floor for generation time. The most determining parameter is the InnoDB buffer pool, the RAM area where MySQL and MariaDB store recently read data: the MariaDB documentation calls it the first setting to examine, as too small a value forces disk reads with every query.
However, the default value, generally 128 MB, is rarely adjusted, even on servers with several gigabytes of memory: the database then rereads from disk data that should live in RAM, and every dynamic page pays the price. Added to this are the slow queries from poorly designed plugins, which a tool like Query Monitor helps to precisely attribute to their responsible party, extension by extension, hook by hook.
Two other items deserve examination on any aging WordPress installation. The first is the options table: each option marked as autoloaded, a behavior documented by the add_option function reference, is read and deserialized on every page view. Uncleaned uninstalled plugins leave kilobytes, sometimes megabytes, of data loaded for nothing on every request.
The second is general database fragmentation: never-purged log tables, thousands of accumulated revisions, missing indexes on extension tables. None of this is visible in an interface, and all of it adds up, request after request, during the generation time.
wp-cron and fixed hourly spikes
WordPress's task scheduler deserves special mention, as its default operation is counter-intuitive: scheduled tasks, described in the developer handbook, do not run at a fixed time but on a visitor's next page load. When a task is due, it's a real visitor's request that triggers it: this visitor pays, in their own TTFB, the cost of the backup, newsletter sending, or cleanup that was in the queue.
On sites with sustained traffic or heavy tasks, the classic workaround is to disable this visitor-triggered execution and delegate execution to a real system cron, at regular intervals and out of the visitors' path:
// wp-config.php : ne plus déclencher les tâches à la visite
define( 'DISABLE_WP_CRON', true );
# crontab du serveur : exécution toutes les 5 minutes, hors trafic
*/5 * * * * curl -s https://www.exemple.fr/wp-cron.php?doing_wp_cron >/dev/null 2>&1This simple move doesn't reduce the amount of work, but it gets it out of the critical path: background tasks run between visits, never during. On real-world TTFB graphs, the effect is immediately visible by the disappearance of periodic spikes that were chopping up the distribution.
Is your site as fast as your visitors expect?
Cache, the number one TTFB lever
All the previous levers reduce the cost of the work the server performs. Cache, on the other hand, eliminates this work. This is what makes it, by far, the most powerful lever on TTFB: a page served from a page cache bypasses PHP and the database, a page served from a CDN's edge even bypasses the trip to your server. The orders of magnitude change category: we're no longer talking about shaving off tens of milliseconds, but about replacing hundreds of milliseconds of generation with a few milliseconds of reading.
The cache is not a single button for all that: it is a stack of layers, each with its own scope and rules. The browser keeps static resources, the CDN shares responses between visitors, the page cache avoids generating anonymous pages, the object cache (Redis, Memcached, or APCu) memorizes SQL queries for pages that cannot be cached, OPcache keeps compiled PHP code, and the buffer pool keeps hot data in memory.
Each layer protects the one below it, and a mature strategy makes them work together: HTTP headers control the browser and the CDN, exclusions protect logged-in users, and purging maintains freshness upon publication. We have dedicated a complete web caching guide to this stack, from the browser to the database, which details the configuration of each level; remember this key takeaway: on most sites with degraded TTFB, the first question is not "why is the server slow?", but "why isn’t this work being cached?".
The site's profile determines where to focus efforts. An editorial or showcase site, with predominantly anonymous traffic, gains the most benefit from page caching and edge caching: when properly configured, its baseline TTFB becomes that of its delivery infrastructure, plus that of its application.
An online store or member area, where each visitor has a session, operates in the opposite situation: its sensitive pages are excluded from page caching, and it's the object cache, OPcache, and the database that determine the experienced TTFB. Both profiles, however, share the same pitfall: believing the cache is active because a plugin is installed. Only by checking the served headers, page by page and cookie by cookie, can you tell what is actually being cached.
Diagnosing high TTFB, step by step
When faced with degraded TTFB, the temptation is to randomly stack optimizations. The rigorous approach consists of breaking down, then isolating. First step: distinguish the network from the server. A tool as simple as curl provides the complete breakdown from the command line:
curl -s -o /dev/null -w "DNS: %{time_namelookup}s
TCP: %{time_connect}s
TLS: %{time_appconnect}s
TTFB: %{time_starttransfer}s
Total: %{time_total}s
" https://www.exemple.fr/If the gap between TLS and TTFB is dominant, time is lost on the server side; if the initial lines weigh heavily, the problem is network-related (slow DNS, no CDN, redirects). Second step: check what the cache is doing. A CDN's cf-cache-status header, headers added by cache plugins, or a simple comparison between an anonymous request and a request with a session cookie immediately reveal whether the measured page was served from a cache or generated on demand: an average TTFB calculated by mixing the two is meaningless.
Third step: repeat the measurement. A single TTFB has no statistical value; measurements spaced over several hours reveal cyclical patterns, those regular peaks that betray a scheduled task, a backup, or a security scan, exactly the kind of cause a single measurement will never show.
The last step connects the symptom to its cause within the application itself: the Server-Timing header allows the server to expose its internal timings (database, rendering, cache) directly in DevTools, and Query Monitor does the same job within WordPress. At this point, the culprit usually has a name: a SQL query, a plugin, a call to an external API made during page generation.
An action plan by order of performance
Once the diagnosis is made, the order of work is as important as the work itself. Our experience converges towards a stable hierarchy. The first task is always page caching for anonymous visitors: it's what changes the order of magnitude, and any fine-tuning done before it will be measured in the noise. Next comes delivery: a CDN in front of the site, clean cache headers, and verification that the hit rate is actually there.
The third task concerns the execution foundations: up-to-date PHP version, sized OPcache, database buffer pool adjusted to available RAM. The fourth tackles parasitic loads: plugin logs, security scans, scheduled tasks moved out of the visitors' path. The last, finally, involves fine-tuning: compression adapted to dynamic content, Early Hints, protocol settings.
This hierarchy is not arbitrary: it ranks levers by expected gain divided by risk of regression, and it avoids the classic pitfall of polishing milliseconds while hundreds of milliseconds are waiting.
A word about what this plan does not include: front-end optimizations. Minifying JavaScript, deferring scripts, or optimizing images has no effect on TTFB, which is entirely consumed before the first byte of HTML. The reverse is not true: a healthy TTFB makes every front-end optimization more visible, as the entire cascade starts earlier. This is the natural order of a performance project: the server first, then the rendering.
From TTFB to LCP: what your visitors experience
TTFB is never an end in itself: your visitors don't perceive bytes, they perceive a page loading. But its position at the start of the chain gives it a multiplying effect. HTML is the resource from which all others derive: until it arrives, the browser knows neither the styles, nor the scripts, nor the images to load. Reducing TTFB by 500 ms means advancing the start of the entire loading cascade by 500 ms, and therefore, mechanically, FCP, LCP, and interactivity. Few performance levers offer this property: a gain in TTFB propagates to all downstream loading metrics.
Your human visitors are not the only ones concerned. Crawlers experience the same first byte, and Google indicates in its crawl budget documentation that a fast-responding site allows Googlebot to crawl more pages, while lengthening response times slow it down. On large sites, a degraded TTFB therefore costs double: a diminished user experience, and dwindling index freshness.
This is also what makes its diagnosis so profitable: the causes of high TTFB (missing cache, undersized hosting, neglected database, background tasks) are precisely those that will eventually degrade the rest of the site. If your field TTFB exceeds the recommended 800 ms, the entire chain deserves an examination, from HTTP headers to the buffer pool. This is the core of our business of web performance optimization: tracing back the first byte chain, measuring each link, and returning to the server what belongs to the cache. Your LCP, and your visitors, will see the difference from the very first byte.
