How We Achieve 122ms Median TTFB on Production WordPress

UnionStack delivers a 122ms median Time to First Byte (TTFB) on production WordPress sites running 12 active plugins, including WooCommerce and Elementor. This is 4-6x faster than industry averages. Here's how we do it.

The Problem: WordPress is Slow

The median TTFB for WordPress hosting ranges from 500-800ms on shared hosting environments. This isn't WordPress's fault—it's infrastructure. Traditional LAMP stacks on shared hosting introduce multiple bottlenecks:

• Resource contention: 200+ sites sharing the same Apache/nginx process pool
• PHP-FPM worker exhaustion: Limited to 5-10 workers per server
• MySQL query queuing: Shared database server handling thousands of concurrent queries
• No object caching: Every request hits MySQL for wp_options, wp_posts
• Disk I/O contention: HDD-based storage with high latency

Our Stack: Kubernetes + Bitpoke + Hetzner

UnionStack runs on a purpose-built stack designed for WordPress performance at scale:

1. Kubernetes 1.28+ (k3s Distribution)

Every WordPress site runs in its own Kubernetes pod with dedicated resources. No noisy neighbor problem. When traffic spikes on one site, it doesn't affect others. Each pod gets:

• 1 CPU core (guaranteed)
• 1Gi RAM (dedicated allocation)
• Isolated network namespace
• Dedicated PHP-FPM worker pool (4 workers per pod)

2. Bitpoke WordPress Operator

We use the open-source Bitpoke WordPress Operator (formerly Presslabs) to manage WordPress lifecycle. It handles:

• PHP-FPM tuning: Optimized pm.max_children, pm.start_servers based on memory limits
• OPcache configuration: 128MB opcache.memory_consumption, 10000 opcache.max_accelerated_files
• Object caching: Automatic Memcached sidecar (64MB per pod)
• CDN integration: CloudFront-compatible media offloading

3. MySQL 8.0 with InnoDB Buffer Pool Tuning

Database performance is critical. We run MySQL 8.0 on dedicated nodes with:

• innodb_buffer_pool_size=8G (holds hot data in memory)
• innodb_flush_log_at_trx_commit=2 (performance vs durability trade-off)
• innodb_flush_method=O_DIRECT (bypass OS cache for writes)
• NVMe SSDs with 4000 IOPS sustained throughput

4. Hetzner Cloud Bare Metal

Our infrastructure runs on Hetzner Cloud data centers in Falkenstein, Germany. Why Hetzner?

• Network latency: Sub-1ms latency between nodes (same DC)
• AMD EPYC processors: High single-thread performance for PHP
• NVMe local storage: Direct-attached, no network overhead
• 10 Gbps networking: Low-latency east-west traffic
• Cost efficiency: 60% cheaper than AWS/GCP for equivalent specs

Performance Optimizations

HTTP/2 with Traefik 2.10

Traefik acts as our reverse proxy and load balancer. Benefits:

• HTTP/2 multiplexing: Single connection for all assets
• Automatic Let's Encrypt: TLS termination at edge (no backend overhead)
• Keep-alive pooling: Persistent connections to backend pods
• Compression: Brotli/gzip at edge (offloads PHP)

WP Super Cache + Memcached

Every WordPress site includes:

• WP Super Cache: Page caching for anonymous users (99% of traffic)
• Memcached object cache: Eliminates wp_options queries (typically 20-30 per page load)
• Transient caching: API responses cached for 300 seconds

PHP 8.2 with JIT Compilation

PHP 8.2's JIT compiler provides 10-15% performance improvement on WordPress workloads:

• opcache.jit=1255 (tracing JIT mode)
• opcache.jit_buffer_size=100M
• Warm-up phase: First 100 requests compile hot paths

The Results

For context, industry benchmarks show:

• Shared hosting: 800-1200ms median TTFB
• Managed WordPress (WP Engine, Kinsta): 200-400ms median TTFB
• UnionStack: 122ms median TTFB

Trade-offs and Limitations

Kubernetes adds operational complexity. We had to build:

• Custom WordPress provisioning pipeline (5 minutes cold start)
• Automated backup system (S3-compatible daily snapshots)
• Monitoring stack (Prometheus + Grafana + Alertmanager)
• Update safety system (pre-flight testing in ephemeral pods)

But for users, it's invisible. You click "Create Project," and 5 minutes later you have a WordPress site running on enterprise infrastructure.

Conclusion

Achieving 122ms median TTFB on WordPress requires:

1. Resource isolation: Kubernetes pods eliminate noisy neighbor problem
2. Dedicated resources: Every site gets 1 CPU core + 1Gi RAM
3. Database optimization: MySQL 8.0 with large InnoDB buffer pool
4. Object caching: Memcached sidecars eliminate wp_options queries
5. PHP tuning: PHP 8.2 JIT + OPcache + optimized FPM workers
6. Low-latency infrastructure: Hetzner bare metal with NVMe + 10 Gbps networking

This architecture isn't theoretical—it's running in production on every UnionStack WordPress site, from €7/month Starter plans to unlimited Business plans. Same infrastructure, same performance guarantees.

Published February 10, 2026. Benchmark data collected via k6 load testing and Lighthouse CI on demo.unionstack.dev. Full methodology available at /benchmarks.