TTFB: Why Server Response Time Determines Everything

TTFB is not a single value but the sum of several sequential phases. The total time consists of DNS resolution (translating the domain name to an IP address), TCP connection establishment (three-way handshake), TLS handshake (encryption negotiation for HTTPS) and server processing time (the actual backend logic: routing, database queries, template rendering, response generation). Each of these phases offers distinct optimization potential.

The weighting of individual phases varies greatly depending on the setup. On a well-configured server with CDN, DNS resolution typically accounts for 10-30 milliseconds, the TCP/TLS handshake for 20-80 milliseconds and server processing for the remainder. On a poorly configured shared hosting server, server processing alone can exceed one second. Chrome DevTools show individual phases for each request in the Network panel -- the 'DNS Lookup', 'Initial Connection', 'SSL' and 'Waiting (TTFB)' fields break down the times precisely.

It is important to distinguish between Document TTFB and Resource TTFB. Document TTFB refers to the main HTML page and is the value Google evaluates for Core Web Vitals. Resource TTFB concerns subsequently loaded resources like CSS, JavaScript and images. A slow Document TTFB delays the entire rendering process because the browser can only discover and load additional resources after receiving the HTML document.

DNS resolution is the first phase of every HTTP connection and is frequently overlooked. Before the browser can establish a connection to the server, it must translate the domain name into an IP address. This process traverses multiple DNS servers: the ISP's local resolver, potentially a recursive resolver and finally the domain's authoritative nameserver. With well-configured DNS infrastructure this takes 10-30 milliseconds; with poorly configured setups it can exceed 200 milliseconds.

The most important DNS optimizations are: Anycast DNS with globally distributed nameservers that automatically route requests to the nearest location. Low TTL values (Time to Live) of 300-3600 seconds for frequently visited domains to keep resolver DNS caches current. DNS Prefetching via in the HTML head for third-party domains needed on the page. And DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) for encrypted DNS queries that prevent manipulation.

An often neglected aspect is the number of DNS lookups per page. Every embedded third-party domain -- analytics, fonts, CDN, social media widgets -- requires a separate DNS lookup. A typical e-commerce page with 15-20 third-party domains can spend 500-800 milliseconds on DNS resolution alone. Consolidating resources to fewer domains and using dns-prefetch for unavoidable external domains reduces this overhead significantly. In our technical analysis we identify all DNS lookups and their respective resolution times.

The TLS handshake is the process where browser and server negotiate encryption for the HTTPS connection. With TLS 1.2 this requires two roundtrips, costing 50-150 milliseconds depending on network latency. TLS 1.3 -- standardized since 2018 and supported by all modern browsers -- reduces this to a single roundtrip and additionally supports 0-RTT Resumption: on repeat visits, encryption can resume without an additional roundtrip (Source: IETF RFC 8446).

Migrating to TLS 1.3 is one of the most effective measures for TTFB reduction. Further TLS optimizations include OCSP Stapling: instead of the browser querying certificate status from the CA's OCSP server (which requires an additional DNS lookup and HTTP request), the server delivers the OCSP response directly with the certificate. HTTP/2 and HTTP/3: while HTTP/2 enables multiplexing over a single TLS connection, HTTP/3 with QUIC goes further and integrates the TLS handshake directly into connection establishment -- the first request can be sent concurrently with the TLS handshake.

The certificate chain also plays a role: a certificate with a long chain (Root CA, Intermediate CA, server certificate) requires more data in the handshake than one with a short chain. ECDSA certificates are significantly smaller than RSA certificates (256-bit vs. 2048-4096-bit key length) and noticeably speed up the handshake. In our server optimization we configure the optimal TLS setup for minimal handshake times.

Server processing time is in most cases the dominant TTFB component. It encompasses everything happening on the server after the request is received: routing, middleware execution, database queries, template rendering and response generation. On a typical PHP-based CMS or shop system (WordPress, Shopware, TYPO3), processing consists of hundreds of function calls, dozens of database queries and assembling the HTML document.

The most effective lever is the OPcache (Opcode Cache). PHP code is interpreted on every request: source code is read, parsed, compiled to opcodes and executed. OPcache stores compiled opcodes in memory and skips the parse and compilation phases on subsequent requests. Enabling OPcache typically reduces PHP execution time by 50-70% (Source: PHP.net, 2024). The JIT compiler in PHP 8.x goes further and translates frequently executed opcodes into native machine code.

The second major lever is database queries. A typical Shopware product detail page executes 30-80 SQL queries -- for product data, variants, prices, images, categories, SEO URLs and cross-selling. Each query is sent to the database, parsed, optimized, executed and the result returned. Missing indexes, suboptimal JOINs and unnecessary queries quickly add up to several hundred milliseconds of processing time. Systematically analyzing and optimizing database queries is one of the most impactful steps in server optimization.

Database optimization starts with enabling the slow query log. MySQL and MariaDB can log all queries exceeding a configurable threshold (recommended: 0.1 seconds). This log reveals the slowest queries, their frequency and missing indexes -- these are the queries that impact TTFB most.

The next step is EXPLAIN analysis of identified slow queries. The EXPLAIN statement shows how the database executes a query: which indexes are used, how many rows are scanned and whether a full table scan occurs. A full table scan on a table with 500,000 products can take hundreds of milliseconds -- the right index reduces this to under one millisecond. Composite indexes for frequently queried column combinations, covering indexes for queries that only access indexed columns and avoiding SELECT * in favor of specific column selection are the most important optimization patterns.

Buffer pool dimensioning is the third critical factor. The InnoDB buffer pool is the memory area where the database caches frequently queried data and indexes. A buffer pool that is too small forces the database to read data from disk -- orders of magnitude slower than memory. The rule of thumb: the buffer pool should comprise 60-80% of available RAM on dedicated database servers. The variable Innodb_buffer_pool_read_requests vs. Innodb_buffer_pool_reads shows the cache hit rate -- it should be above 99%.

Caching is the most effective method to reduce TTFB because it partially or completely skips backend processing. A well-designed caching concept operates on multiple levels: opcode cache (OPcache), object cache (Redis/Memcached), full-page cache (Varnish/Nginx FastCGI Cache) and CDN cache (edge caching). Each level reduces the amount of work the origin server must perform.

The full-page cache has the greatest impact: instead of repeating entire PHP processing, database queries and template rendering on every request, the finished HTML document is stored in the memory of a reverse proxy like Varnish and served directly on subsequent requests. TTFB drops from typically 300-800 milliseconds (backend processing) to 5-20 milliseconds (Varnish delivery). The challenge lies in correct cache invalidation: when products change, prices are adjusted or content is updated, the cache must be selectively invalidated for affected pages.

The object cache with Redis or Memcached stores frequently queried datasets in memory: product catalogs, category structures, configuration settings and session data. Instead of loading this data from the database on every request, it is read from the fast in-memory cache. Redis offers the advantage of persistence: cached data survives server restarts. For Shopware shops a properly configured Redis cache typically reduces database queries per request by 60-80% (project experience).

A Content Delivery Network (CDN) distributes content across servers (Points of Presence, PoPs) worldwide and serves them from the nearest location. The physical advantage: light requires approximately 5 milliseconds per 1,000 kilometers of fiber optic cable. A user in Munich whose server is in Frankfurt (300 km) has a minimum network latency of about 3 milliseconds per roundtrip. A user in New York (6,000 km) faces at least 30 milliseconds. A CDN PoP in New York eliminates this additional latency for North American users.

Modern CDNs go beyond serving static files. Edge computing enables logic execution directly at PoPs -- such as rendering personalized content, A/B test variants or geo-based adjustments without a roundtrip to the origin server. Stale-while-revalidate strategies serve cached content immediately while loading an updated version from the origin server in the background. This technique combines low TTFB values with high content freshness.

CDN configuration requires a differentiated strategy. Static assets (images, CSS, JavaScript, fonts) should be cached with long TTLs (at least 30 days), HTML documents with short TTLs (60-300 seconds) or stale-while-revalidate. Personalized content (cart, logged-in areas) must not be cached and needs cache bypass routing to the origin. In our server optimization we configure the optimal CDN strategy for your specific website architecture.

Systematic TTFB diagnosis starts with measurements from multiple locations. A TTFB of 200 milliseconds in Frankfurt but 1,200 milliseconds in New York points to a CDN issue. Consistently high TTFB regardless of location indicates a backend problem. Tools like WebPageTest enable tests from over 30 locations worldwide and display TTFB components (DNS, Connect, TLS, Wait) individually.

The next level is server-side analysis. Xdebug profiling for PHP applications shows exactly which functions consume how much time. The MySQL slow query log identifies slow database queries. Tools like top, htop and vmstat show server utilization in real-time -- high CPU load, memory swapping or I/O bottlenecks are common causes of fluctuating TTFB values.

A frequently overlooked factor is TTFB spikes under load. A server delivering 200 milliseconds TTFB on individual requests can spike to 2 seconds with 50 concurrent requests -- because PHP workers are exhausted, database connections are waiting or memory is insufficient. Load tests with tools like k6 or Apache Bench simulate realistic traffic and uncover scaling issues before they occur in production. Our performance analysis always includes load tests under realistic conditions.

The HTTP protocol has evolved significantly in recent years. HTTP/2 (standardized since 2015) introduced multiplexing -- the ability to send multiple requests over a single TCP connection in parallel instead of establishing a new connection for each request. Header compression (HPACK) reduces the overhead of repeated HTTP headers. Server Push allowed the server to proactively send resources -- but was discontinued by Chrome in 2022 as the practical benefit was minimal.

HTTP/3 (standardized since 2022, Source: IETF RFC 9114) takes a fundamental step further with the QUIC protocol: it replaces TCP with UDP and integrates TLS encryption directly into connection establishment. The advantage: 0-RTT Connection Establishment -- on repeat visits the first request can be sent immediately without waiting for a handshake. Additionally, QUIC solves HTTP/2's head-of-line blocking problem: when a single TCP packet is lost in HTTP/2, all parallel streams are blocked. With HTTP/3, packet loss only affects the affected stream.

Enabling HTTP/3 is straightforward on modern web servers (Nginx from 1.25, LiteSpeed, Caddy) and backward-compatible -- browsers that do not support HTTP/3 automatically fall back to HTTP/2. According to W3Techs (2025), 32% of all websites already use HTTP/3. The TTFB advantage of HTTP/3 over HTTP/2 is typically 30-80 milliseconds on the first connection and is especially noticeable with high network latency (mobile, international access).

Compressing the server response reduces the amount of data transmitted over the network and thus shortens the time to receive the complete document. Gzip is the minimum standard, supported by all browsers and servers -- it typically reduces HTML, CSS and JavaScript files by 60-80%. Brotli (developed by Google, standardized since 2015) achieves 15-25% better compression ratios than Gzip at comparable decompression speed (Source: Google, 2024).

The optimal compression structure differentiates static and dynamic content. Static assets (CSS, JavaScript, SVG) should be pre-compressed with maximum Brotli compression (level 11) -- the high compression time is irrelevant because files are compressed once and then served directly by the CDN or web server. Dynamic HTML responses are compressed in real-time and require lower compression levels (Brotli 4-6) to keep CPU load manageable.

The TTFB impact of Brotli versus Gzip is especially noticeable with larger documents. A 50 KB HTML document (uncompressed) compresses to approximately 12 KB with Gzip and approximately 10 KB with Brotli -- the saved 2 KB means approximately 20 milliseconds less transfer time on a 3G connection. On a typical e-commerce category page with 150 KB HTML, savings add up to 50-80 milliseconds. Enabling Brotli is one of the simplest and most effective measures in server optimization.

TTFB optimization follows a clear priority order. First the quick wins: enable and configure OPcache (validate_timestamps, memory_consumption), enable Brotli compression, enforce TLS 1.3 and set up OCSP stapling, enable HTTP/2 or HTTP/3. These measures can typically be implemented within an hour and already reduce TTFB significantly.

The second step involves medium-term optimizations: enable slow query log and optimize the top 10 slowest queries, set up Redis or Memcached as object cache, implement full-page cache with Varnish or Nginx FastCGI cache and update PHP to the current stable version (each PHP major version typically brings 10-20% performance improvement). These measures require server configuration and testing but pay off through dramatically reduced TTFB.

The third step is architectural optimization: CDN integration with differentiated cache strategy, database replication for read-heavy workloads, PHP worker pool dimensioning based on load profiles and offloading asynchronous tasks (email sending, indexing) to background workers. These measures require deeper technical understanding and are individually planned in our performance consulting.

The results of systematic TTFB optimization are typically impressive. In a typical Shopware project we reduce TTFB from an initial 800-1,500 milliseconds to below 200 milliseconds for cached pages and below 400 milliseconds for dynamic pages (project experience). This directly impacts the LCP value and thus the Core Web Vitals. Server response time is the foundation of every further optimization -- without a fast server, frontend optimizations remain limited in their effectiveness.