TTFB Optimization: Reduce Server Response Time to Under 200 ms
A high Time to First Byte delays everything else — LCP, FCP, INP. We analyze your entire delivery chain from hosting to database query and reduce server response time to a level Google rates as excellent.
94ms
median TTFB after optimization (project experience)
78%
typical TTFB reduction in the first step (project experience)
< 2.5s
target LCP
50+
TTFB projects completed
Time to First Byte (TTFB) measures the time from sending the HTTP request to the arrival of the first response byte in the browser. Google recommends values under 800 milliseconds as acceptable and under 200 milliseconds as excellent (web.dev, 2024). A high TTFB is not a minor issue: it delays the Largest Contentful Paint, reduces the crawling efficiency of search engines and noticeably impairs the user experience — especially on mobile connections. We treat TTFB as a standalone discipline and address all causes systematically: hosting infrastructure, PHP runtime, caching architecture, database queries and the application's render path.
Getting started with TTFB optimization
- Server response time measured across multiple page types
- Prioritized action plan with expected TTFB impact
- Clear recommendation: tune the configuration or switch hosting
- Optional Core Web Vitals monitoring from €59 per month net
A free initial assessment to start: you describe your system, we check your current TTFB and name the biggest levers — no obligation. The performance quick check (from €349 net) then delivers a documented short report, the full performance audit (from €1,490 net) the complete analysis of multiple page types.
What Influences Time to First Byte
TTFB is not a single value but the sum of several sub-times. Every stage on the path from browser to server and back contributes to it. Only by knowing and measuring all stages can you intervene precisely where the greatest lever sits. In our analysis projects, we measure TTFB with synthetic tests from multiple locations and consistently distinguish between network latency, protocol overhead and actual server processing time. The latter is generally the only part that optimization can directly influence.
Network Latency and DNS
DNS resolution and the physical distance between user and server create an unavoidable base latency. We minimize it through fast DNS providers with anycast networks, low TTL values for dynamic records and CDN integration for static content.
TLS Handshake Overhead
TLS 1.2 requires two roundtrips for the connection setup; TLS 1.3 reduces this to one. With session tickets and 0-RTT reconnects, TLS overhead on subsequent visits drops to near zero. OCSP stapling prevents additional roundtrips to the certificate authority.
PHP Processing Time
Of all factors, PHP processing time has the greatest optimization potential. OPcache, JIT compilation, PHP preloading and a correctly sized PHP-FPM pool reduce pure compute time by 50 to 70 percent (project experience).
Database Query Time
Missing indices, N+1 queries and uncached queries are the most common cause of TTFB values above one second. Even a few targeted optimizations to the most frequent queries reduce database time by 80 to 95 percent (project experience).
Cache Hit Rate
Every cache hit replaces a full PHP execution with a memory operation taking under one millisecond. A high hit rate at the right cache layer — OPcache, application cache, reverse proxy — is the single most effective lever for a low TTFB.
Hosting Infrastructure
Shared hosting with overloaded servers, limited RAM or outdated PHP versions sets an upper limit on every optimization. We assess your current infrastructure and recommend migration to better-suited hosting options when needed.
Hosting as the Foundation of TTFB
Hosting infrastructure defines the frame within which all other optimizations operate. Shared hosting with overloaded CPU slots, heavily limited memory and slow I/O systems cannot be tuned to TTFB values under 200 milliseconds through configuration changes alone. We analyze your current hosting environment and identify whether and where an infrastructure upgrade makes sense. This does not necessarily mean more expensive plans — often a switch to a specialized VPS or managed server at similar cost is the better choice.
- Shared hosting: Suitable for static pages with little traffic. PHP processing time varies greatly depending on server load and is outside your control. TTFB targets below 500 ms are often unrealistic.
- Managed VPS / Cloud VPS: Dedicated CPU resources and own memory provide the foundation for OPcache, PHP-FPM tuning and reverse proxy setup. Recommended base for most mid-sized WordPress, TYPO3 and Shopware projects.
- Dedicated server: Maximum control over all parameters. PHP-FPM pools, MariaDB configuration and caching layers can be optimized without restrictions. Worthwhile from medium traffic volumes or high concurrency.
- Server location: Physical distance to the user directly affects TTFB. For a German audience we recommend data centers in Frankfurt, Düsseldorf or Hamburg with typical round-trip times under 10 milliseconds.
- NVMe storage: Database access and PHP file operations benefit significantly from NVMe storage compared to SATA SSD. We check whether the I/O performance of your environment is a bottleneck.
PHP Runtime: OPcache, FPM and Preloading
The PHP runtime is the single largest TTFB lever in most web applications. Without OPcache, PHP reads all involved files from the filesystem on every page request, parses them and compiles them to bytecode — a process that costs 100 to 400 milliseconds depending on application size. With OPcache, the compiled bytecode is held in shared memory and is immediately available. For large frameworks such as Symfony, Laravel or the Shopware core, OPcache reduces PHP initialization time by 60 to 80 percent (php.net, 2024). We configure OPcache with sufficient memory for all PHP files in your application and enable PHP preloading, which loads frequently used classes into memory when the PHP-FPM process starts.
Practical note: sizing OPcache memory correctly
OPcache and PHP-FPM: the single biggest lever
The PHP runtime determines the majority of server processing time. With a correctly sized OPcache, PHP preloading and a worker pool matched to your load profile, the server handles every request without recompiling — pure PHP time drops noticeably.
- OPcache with a memory buffer for all PHP files in the application
- PHP preloading loads framework core classes at process start
- Worker pool sized by real memory demand, not by rule of thumb
PHP-FPM: Worker Sizing and Pool Configuration
PHP-FPM manages the pool of PHP worker processes that handle incoming requests. Too few workers cause queuing under load and elevated TTFB. Too many workers exhaust available memory and trigger swapping — which also massively increases TTFB. We size the worker count based on actual memory consumption per PHP process, available RAM minus reserves for database and caches, and expected concurrency level. Typical applications need 30 to 80 megabytes per worker — a server with 4 GB RAM can reliably run around 30 to 60 PHP workers after accounting for all other services.
Process Manager: dynamic
In dynamic mode, PHP-FPM starts new workers on demand and releases them during inactivity. This saves resources at low traffic and scales at peak load. We configure pm.min_spare_servers, pm.max_spare_servers and pm.max_children for your load profile.
Request Timeout
request_terminate_timeout limits the maximum execution time of a single PHP request. This prevents stalled requests from permanently blocking workers and raising TTFB for all other users. We set conservative timeouts and monitor terminated requests.
Slow Log Analysis
The PHP-FPM slow log records all requests above a defined threshold, including a full stack trace. These data are the most reliable source for slow code paths and complement the view a Lighthouse audit provides on the frontend.
Where does your TTFB stand right now?
We measure your server response time across all important page types and show the biggest levers — free and without obligation, before you decide on an optimization.
Database Optimization: Queries, Indices and Connection Pooling
The database is the primary TTFB driver in most dynamic web applications. A single page in WordPress, TYPO3 or Shopware CE can trigger 50 to 250 database queries. Every query without a matching index leads to a full table scan — on tables with hundreds of thousands of rows, individual queries can stretch to several hundred milliseconds. We enable the slow query log, analyze the most frequent and slowest queries with EXPLAIN ANALYZE and implement targeted indices and query rewrites. In our projects we typically reduce database query time per page request by 70 to 90 percent, which reflects directly in TTFB (project experience).
Slow Query Log
All queries above a configurable threshold are logged with execution time, table count and affected rows. The most common patterns reveal where a single index has the greatest impact.
Index Strategy
Composite indices for typical WHERE combinations, covering indices for SELECT-heavy queries and partial indices for selective filter criteria. No index without prior testing with realistic data volumes.
Fixing N+1 Problems
N+1 queries arise when a loop executes a separate database call for each record. We identify these patterns in ORM code and resolve them with eager loading or dedicated batch queries.
InnoDB Buffer Pool
The InnoDB buffer pool keeps frequently accessed data and index pages in RAM. A buffer pool sized at 70 to 80 percent of available RAM eliminates disk I/O for most read operations almost entirely.
Connection Pooling
Every new database connection costs 1 to 5 milliseconds. Connection pooling keeps a defined number of connections open and assigns them immediately to incoming requests. Under high concurrency the saving adds up significantly.
Query Cache via Redis
Frequently retrieved, rarely changing datasets — navigation trees, configurations, category lists — are cached in Redis. Cache hits deliver responses in under one millisecond instead of 20 to 50 milliseconds.
Caching Architecture for Maximum TTFB Reduction
Simply enabling a single caching tool is rarely sufficient. Effective TTFB reduction requires a multi-tier caching architecture in which each layer relieves the one below it. The top layer — reverse proxy or full-page cache — intercepts the majority of all requests before PHP even starts. The middle layer — application cache in Redis or Memcached — accelerates the remaining dynamic requests. The lowest layer — OPcache — ensures that even cache misses are processed as quickly as possible. We design this architecture as a unit and align caching strategies, invalidation rules and TTL values with each other.
Layer 1: Reverse Proxy Cache
nginx or Varnish holds fully rendered HTML pages in working memory and delivers them in under 5 milliseconds. For websites with many anonymous visitors this is the single most effective lever: cache hit rates of 85 to 95 percent are achievable in practice (project experience). We configure cache keys, cookie exclusions for logged-in users and tag-based invalidation for targeted cache busting on content changes.
Layer 2: Application Full-Page Cache
CMS full-page cache systems such as the Shopware HTTP cache, the TYPO3 page cache or the WordPress page cache operate within the application and can handle login-dependent content more granularly than an upstream proxy. We configure cache warmup routines that pre-fill the most important pages after deployments so users never experience an empty cache.
Layer 3: Object Cache / Application Cache
Database queries, API calls and expensive computations are cached in Redis. Even when a page cannot be fully cached — such as with personalized content — the object cache reduces database query time to a minimum. We configure Redis database partitions, TTL strategies and eviction policies to match the workload.
Layer 4: OPcache and Preloading
As the lowest layer, OPcache ensures PHP code does not need to be recompiled on every request. PHP preloading loads framework core classes when the PHP-FPM process starts, eliminating initialization time per request. This layer acts on every single PHP request, even when all upper layers record a cache miss.
Multi-tier caching: each layer relieves the next
A single cache plugin is rarely enough. We layer reverse proxy, full-page cache, object cache and OPcache so that the majority of requests are answered before PHP even starts — and even cache misses stay fast.
- Reverse proxy serves cached pages in under 5 milliseconds
- Object cache in Redis reduces database time to a minimum
- Coordinated invalidation instead of flushing the entire cache
TTFB optimization in practice
Anonymized, illustrative project histories (project experience). We discuss concrete results for your specific configuration.
TTFB on CMS Platforms: WordPress, TYPO3 and Shopware
Each platform has its own TTFB characteristics. WordPress loads all active plugins on every request, which on poorly configured installations means 80 to 200 active database queries per page. TYPO3 offers a powerful built-in page cache that, when correctly configured, answers nearly all frontend requests without any database access. Shopware CE has a Symfony-based HTTP cache that, together with the ESI mechanism, efficiently separates personalized and anonymous content. We know the platform-specific tuning parameters and apply them precisely without jeopardizing application stability.
WordPress TTFB Optimization
Object cache with Redis via a Redis adapter, query profiling for analysis, rerouting WP-Cron to a real cron job, cleaning up transient option autoloading and removing unnecessary plugin hooks. Complement with our WordPress performance service for a complete optimization.
TYPO3 TTFB Optimization
Correctly configure the page cache (cache identifier, tags, lifetime), enable Extbase query caching, reduce DataProcessor calls, simplify TypoScript conditions and use the cacheflush hook precisely to invalidate only affected cache areas.
Shopware CE TTFB Optimization
Enable and correctly configure the HTTP cache, set ESI tags for the cart widget and login area, accelerate product list API via Elasticsearch, offload message queue consumers to a dedicated worker and enable Twig template caching. More detail in our Shopware performance service.
Measurement and Diagnosis: How We Find the TTFB Bottleneck
Before we optimize, we measure precisely. A high TTFB can have many causes, and any measure applied in the wrong place wastes resources. Our diagnostic process starts with synthetic tests from multiple locations — this isolates actual server processing time from network latency. We then profile the application under live conditions and measure at every layer: PHP execution time, database query time, cache hit rate and queue wait time. The result is a prioritized list of measures with expected TTFB impact and estimated effort.
Synthetic tests vs. field data
The TTFB Optimization Process at a Glance
Baseline Measurement and Infrastructure Audit
We measure TTFB from multiple locations and across multiple page types (home, category, product detail, API endpoints). Simultaneously we capture the complete infrastructure configuration: PHP version and OPcache settings, PHP-FPM configuration, database version and configuration, existing caching layers, hosting environment and current resource utilization. Result: a clear picture of the current state and initial hypotheses about the main causes.
Profiling and Root Cause Analysis
Profiling tools analyze the most time-consuming code path per page type. The slow query log delivers the slowest database queries including execution plans. Server metrics show whether CPU, RAM or I/O is the limiting factor. At the end of this step we know the three to five measures with the highest TTFB impact.
Implementation of Measures
We implement measures in order of expected impact and measure TTFB after each change. This allows us to quickly identify when a measure does not deliver the hoped-for effect and adjust accordingly. Typical measures: OPcache sizing, PHP-FPM tuning, database indices, Redis integration, reverse proxy setup, TLS optimization.
Validation Under Load
After configuration changes we simulate realistic load scenarios and verify that the optimized TTFB remains stable under production conditions. We specifically test cold-cache scenarios after deployments and verify that cache warmup routines work correctly.
Documentation and Monitoring
Every measure is documented: before/after TTFB, configuration change, rationale. We set up monitoring with automatic alerts so a TTFB increase caused by new features or traffic spikes is detected early. The documentation also serves as a reference for your developers on future changes.
Typical Results: What TTFB Optimization Achieves
The following values show typical improvements from our TTFB projects. Concrete results depend on the starting situation, application complexity and hosting environment (project experience). On request we discuss realistic target values for your specific configuration.
From bottleneck to excellent response time
The biggest jumps happen where several causes combine: weak hosting, missing OPcache and unfavourable database queries. When they are fixed in the right order, TTFB falls from several seconds to a two-digit millisecond value (project experience).
- Starting values above 2 seconds are normal with untuned PHP
- Reverse proxy and OPcache deliver the biggest single jump
- Every measure is measured and documented before and after
| Metric | Typical Starting Value | After TTFB Optimization |
|---|---|---|
| TTFB (cached page, reverse proxy) | none (no proxy in place) | under 10 ms |
| TTFB (dynamic page, PHP) | 800 – 3,500 ms | 80 – 250 ms |
| PHP execution time per request | 350 – 1,200 ms | 50 – 180 ms |
| Database queries per page load | 60 – 250 | 10 – 40 |
| OPcache hit rate | 0 % or poorly configured | 98 – 99.5 % |
| Google LCP (field data) | poor / needs improvement | good / excellent |
TTFB and Core Web Vitals are directly linked
TTFB Optimization for International Websites
For websites serving users in multiple countries, network latency is an independent TTFB factor. While a user in Germany with a server in Frankfurt can expect a round-trip time below 5 milliseconds, the same user from an Australian location experiences 260 to 300 milliseconds from physical distance alone. CDN edge caching and the offloading of static assets to geographically distributed networks are in this case the most important TTFB measure. We design CDN strategies that go beyond simple asset caching and also cache HTML pages at the edge where this is possible without correctness loss. Combined with our server optimization and efficient caching architecture, we achieve TTFB values for international projects that are rated excellent even from abroad. For further reading we recommend our articles on TTFB and server response time and Brotli and Zstandard.
The essentials of TTFB optimization
- Google rates a TTFB under 200 ms as excellent (web.dev, 2024) — dynamic pages reach this with OPcache, database indices and multi-tier caching
- The single biggest lever is usually the PHP runtime: OPcache and preloading noticeably reduce pure compute time
- A reverse proxy cache delivers cached pages in under 5 milliseconds and intercepts the majority of anonymous requests
- Without optimization, dynamic-page TTFB is often above 2 seconds — after optimization in the double- to low triple-digit millisecond range (project experience)
- Start with the free initial assessment; performance quick check from €349 net, full performance audit from €1,490 net, optional monitoring from €59 per month net (net)