How to Reduce Time to First Byte (TTFB) on Modern Websites

When optimizing web applications, developers often spend countless hours compressing images, minifying JavaScript bundles, and fine-tuning font loading. While these frontend optimizations are critical for Core Web Vitals, they cannot fix a foundational issue: if the browser is waiting several hundred milliseconds just to receive the very first byte of HTML, every downstream metric—from First Contentful Paint (FCP) to Largest Contentful Paint (LCP)—suffers automatically.

Time to First Byte (TTFB) measures the duration from the user initiating a page request to the exact moment the client receives the initial byte of the response. Google considers a TTFB below 800 milliseconds acceptable, but modern web standards demand far better. For an optimal user experience and search ranking advantage, your target should be under 200 milliseconds. Here is how to diagnose latency bottlenecks and systematically reduce TTFB across your infrastructure.

Diagnosing Where Latency Actually Occurs

Before modifying web server configurations or rewriting database queries, you must isolate the root cause of your slow TTFB. Time to First Byte is not a single server-side metric; it is an aggregate of several network and application phases:

DNS Resolution: The time required for the client to resolve your domain to an IP address.
TCP Connection & TLS Handshake: Establishing the secure socket connection across physical distances.
Server Processing: The time your backend takes to route requests, query the database, run business logic, and assemble the response.
Network Transit: The time required for the first packet of data to travel back across the wire.

You can dissect these distinct phases from your terminal using a lightweight curl diagnostic command:

curl -o /dev/null -s -w '
DNS Resolution:   %{time_namelookup}s
TCP Connect:      %{time_connect}s
TLS Handshake:    %{time_appconnect}s
TTFB (Server):    %{time_starttransfer}s
Total Time:       %{time_total}s

' https://yourdomain.com

If time_appconnect is low (under 50ms) but time_starttransfer spikes significantly, your bottleneck lies within server processing or database execution. If the initial connection times are high, your issue is geographic routing or network transport.

Eliminating Latency at the Edge with Smart Caching

The fastest server response is one that never has to hit your origin server at all. Serving dynamic web pages directly from an edge CDN (such as Cloudflare, Fastly, or AWS CloudFront) brings response times down from 600ms to an astonishing 20ms–50ms by terminating requests at the point of presence (PoP) closest to the user.

Implementing Edge Page Caching

For marketing sites, blogs, and public web pages, you can cache entire HTML responses at the edge while bypassing cache only for authenticated users or active carts. In Nginx or your application headers, ensure you specify caching directives clearly:

# Serve dynamic content with edge micro-caching
add_header Cache-Control "public, max-age=60, s-maxage=3600, stale-while-revalidate=86400";

The s-maxage=3600 directive instructs the CDN edge to hold the cached HTML for an hour, while stale-while-revalidate allows the CDN to return the cached response instantly while fetching a fresh copy in the background if the asset has expired.

Application Micro-Caching for Dynamic Backends

Full page caching is straightforward for static content, but what about data-heavy internal dashboards where responses are constantly changing? In dynamic systems, executing repetitive database queries on every HTTP hit creates massive server queues.

For example, when architecting KasKita Financial Ledger—a multi-entity cash flow and financial bookkeeping system engineered by Study Morph—calculating real-time transaction reconciliation and audit-ready reports across thousands of journal entries naturally generated heavy database load. By implementing localized Redis micro-caching paired with instant cache invalidation upon ledger mutations, our team cut dynamic dashboard TTFB from over 650ms down to 45ms without sacrificing financial audit precision.

Streamlining the Backend and Database Pipeline

When a request must reach your origin server, your application code and database layout determine whether TTFB remains under 200ms or climbs past a full second.

1. Enable Persistent Connections and Connection Pooling

Opening a fresh database connection on every single HTTP request adds 20ms to 80ms of internal latency. Ensure your application framework utilizes an active database connection pool (such as PgBouncer for PostgreSQL, or built-in persistent PDO connections in PHP) so worker processes immediately grab ready-to-use connections without waiting on TCP handshakes.

2. Configure Nginx FastCGI Micro-Caching

If you run dynamic applications (like WordPress or Laravel) behind Nginx, you can cache dynamic HTML blocks in memory for just 1 to 5 seconds. This technique absorbs sudden traffic surges while keeping the origin response virtually instantaneous:

# Inside your nginx.conf http block
fastcgi_cache_path /tmp/nginx_cache levels=1:2 keys_zone=MICROCACHE:100m inactive=60m max_size=1g;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

server {
    # Inside your PHP location block
    location ~ .php$ {
        fastcgi_cache MICROCACHE;
        fastcgi_cache_valid 200 301 302 5s;
        fastcgi_cache_use_stale updating error timeout invalid_header http_500;
        fastcgi_pass unix:/var/run/php/php8.3-fpm.sock;
        include fastcgi_params;
    }
}

Under heavy traffic loads, Nginx will serve cached dynamic responses in under 15ms directly from RAM while your PHP-FPM pool handles subsequent updates smoothly.

Infrastructure and Transport Layer Improvements

Finally, inspect the network transport layer itself. Modern protocol upgrades require zero changes to your application codebase yet yield immediate improvements in handshake speed.

Upgrade to HTTP/2 or HTTP/3 (QUIC): HTTP/3 runs over UDP, effectively eliminating head-of-line blocking and reducing TLS round trips. Modern CDNs allow you to toggle HTTP/3 with a single click.
Enable TLS 1.3 with 0-RTT: TLS 1.3 cuts connection handshake time in half compared to TLS 1.2 by completing the cryptographic exchange in a single round trip. Zero Round-Trip Time (0-RTT) allows returning visitors to transmit request data immediately alongside the initial handshake packet.
Optimize PHP-FPM / Worker Pools: Ensure your process manager isn’t bottlenecked. If your worker pool reaches capacity (pm.max_children), incoming requests sit waiting in the backlog queue before being assigned a worker, inflating TTFB without appearing in slow query logs.

Summary & Best Practices

Time to First Byte sets the performance ceiling for your entire digital product. When your origin server responds quickly, browsers can discover stylesheets, fetch render-critical fonts, and parse scripts earlier in the page lifecycle.

To keep TTFB consistently low across your applications:

Benchmark regularly: Use curl or real-user monitoring (RUM) tools to distinguish network round-trip latency from origin processing delays.
Push caching to the edge: Leverage CDNs for static assets and public HTML pages via smart Cache-Control headers.
Protect the origin database: Implement caching layers like Redis for computationally expensive queries to prevent slow processing from bottlenecking web worker threads.
Leverage modern transport protocols: Enforce HTTP/3 and TLS 1.3 to minimize connection handshake friction across high-latency mobile networks.