Server Performance That Makes the Difference

Time to First Byte measures the time between the browser's HTTP request and the arrival of the first response byte. Google considers a TTFB under 800 milliseconds acceptable but recommends values under 200 milliseconds for optimal performance (web.dev, 2024). Every millisecond of TTFB delays the Largest Contentful Paint and thus the perceived loading speed. In our optimization projects, we typically reduce TTFB by 70 to 90 percent by eliminating bottlenecks across all layers of the server infrastructure. The impact is directly measurable: faster server responses improve not only the user experience but also crawling efficiency by search engines. A low TTFB signals to Google that your website is technically sound and can lead to more frequent and deeper indexing.

Before the server can deliver an HTML page, every request passes through multiple stages. Each stage can become a bottleneck. Effective server optimization requires analyzing and improving all stages, not just the most obvious ones. The following components directly influence TTFB and form the framework of our optimization work.

The transfer protocol determines how efficiently browser and server communicate. While HTTP/1.1 can process only one request per connection at a time, HTTP/2 enables simultaneous transfer of multiple resources over a single connection (multiplexing). HTTP/3 goes further, building on the QUIC protocol that better compensates for packet loss and accelerates connection establishment. According to the Web Almanac 2024, 37 percent of all websites already use HTTP/3 (HTTP Archive, 2024). We configure your server infrastructure for both protocols and ensure that older clients seamlessly fall back to HTTP/2 or HTTP/1.1.

Text compression reduces the amount of data transferred between server and browser. Gzip has been the standard for over two decades, but Brotli offers 15 to 25 percent better compression ratios at comparable decompression speeds (Google Research, 2015). We configure Brotli as the primary compression format with Gzip as a fallback for older clients. For static assets, we use Brotli level 11 (maximum compression), precomputed during the build process. For dynamic content, we use Brotli level 4 to 6, balancing compression ratio against CPU load. In practice, this configuration reduces the transferred data for HTML, CSS and JavaScript by 70 to 85 percent compared to uncompressed files.

A frequently overlooked aspect is the compression of JSON API responses and SVG files. Both formats are text-based and benefit significantly from Brotli compression. In a typical Shopware shop with extensive API calls for product data and filter options, compressing JSON responses alone can reduce transferred data by 80 percent and noticeably improve load times.

A content delivery network distributes your content to edge servers worldwide, reducing the physical distance between server and user. For websites with a primarily German audience, this means edge servers in Frankfurt, Amsterdam and Zurich with response times under 20 milliseconds. For international projects, a CDN shortens load times for overseas visitors by 200 to 500 milliseconds. We implement CDN strategies that go beyond simple asset caching and intelligently cache dynamic content as well.

A reverse proxy is the single most effective measure for reducing server response time. Varnish and nginx can hold pre-rendered HTML pages in memory and deliver them on repeated requests in under 5 milliseconds without even contacting the application. In our 50+ optimization projects, we regularly achieve cache hit rates exceeding 90 percent with reverse proxy configurations (project experience). This means nine out of ten page views are answered directly from the proxy cache.

PHP-FPM (FastCGI Process Manager) manages the PHP processes that execute your application. Misconfiguration leads either to wasted resources (too many processes) or wait times under load (too few processes). We size PHP-FPM pools based on actual memory consumption per request and expected concurrency. A typical PHP process requires 30 to 80 megabytes of memory, depending on the application and loaded extensions.

OPcache stores precompiled PHP bytecode in shared memory, eliminating the parsing and compilation step on every request. Without OPcache, PHP must re-read and compile all involved files on every page load. With properly configured OPcache, PHP execution time is reduced by 50 to 70 percent (php.net, 2024). We configure OPcache with sufficient memory for all PHP files in your application and enable validation checks only in development environments. In production, file checking is disabled and the cache is explicitly flushed only during deployments.

PHP 8.x additionally offers JIT compilation (Just-In-Time), which translates bytecode into native machine code at runtime. For typical web applications, the gain from JIT is limited since most bottlenecks lie in I/O operations. For compute-intensive tasks such as image processing, PDF generation or complex price calculations, JIT can deliver noticeable improvements. We evaluate the JIT benefit individually and enable it only when measurable advantages exist. Furthermore, we use PHP preloading to load frequently used classes and frameworks into memory when the PHP-FPM process starts, further reducing initialization time per request.

The database is the primary performance bottleneck in most web applications. A single inefficient query can delay the entire page response by seconds. We systematically analyze your database layer and implement optimizations that improve both individual query performance and overall throughput.

In-memory caches like Redis and Memcached store frequently queried data in memory and deliver responses in under one millisecond. Compared to database queries that typically take 5 to 50 milliseconds, a cache hit accelerates data access by a factor of 10 to 100. We decide on a project basis which system is the best choice and implement multi-tier caching strategies covering session management, application cache and fragment caching.

When optimization of individual components reaches its limits, scaling becomes necessary. Vertical scaling (more CPU, RAM, faster disks) is simple to implement but hits physical and economic boundaries. Horizontal scaling (more servers) offers theoretically unlimited capacity but requires adjustments to the application architecture. We advise which scaling strategy suits your project and implement the infrastructure accordingly.

TLS configuration affects both the security and performance of your website. We implement a TLS configuration that combines maximum security with minimal latency. TLS 1.3 reduces the handshake from two roundtrips to one. Session tickets and session caching speed up repeated connections. OCSP stapling avoids the separate certificate status check with the certificate authority. The choice of modern cipher suites with ECDHE key exchange and ChaCha20-Poly1305 or AES-GCM encryption minimizes CPU load.

For HTTP/3, we configure QUIC, which integrates the TLS negotiation into the connection setup and thereby saves a complete roundtrip. On reconnections, 0-RTT enables immediate data transfer without a preceding handshake phase. We activate early data with appropriate replay protection measures to further reduce latency on return visits. The entire configuration is regularly reviewed against current best practices and known vulnerabilities.

DNS resolution stands at the beginning of every connection yet is frequently neglected. A DNS lookup can take between 5 and 300 milliseconds depending on the provider, geographic distance and cache state. We optimize DNS configuration on multiple levels.

Performance optimization is not a one-time project but a continuous process. New features, traffic spikes, data imports and software updates can affect performance at any time. As our reference projects demonstrate, we implement monitoring systems that detect bottlenecks early and enable proactive action before users are affected.

The following values show typical improvements from our server optimization projects. Actual results depend on the initial state and application complexity (project experience).