Server Response Time (TTFB): What It Is and How to Improve It

What Is Time to First Byte?

Time to First Byte (TTFB) is the duration between a client sending an HTTP request and receiving the first byte of the response. It is the most direct measurement of server-side performance available, encompassing DNS resolution, network transit to the server, TLS handshake, server processing, and the initial network transit of the response. When you strip away the front-end variables like image sizes, CSS rendering, and JavaScript execution, TTFB is what remains: the raw speed of your hosting infrastructure.

Google treats TTFB as a diagnostic metric for Core Web Vitals, recommending values under 800ms. But competitive websites typically achieve 100-300ms for dynamic content and under 50ms for cached content. Every millisecond of TTFB delays every subsequent stage of page loading. It is the foundation upon which all other performance metrics rest, and optimizing it produces cascading improvements across your entire page load timeline.

Anatomy of TTFB: What Happens in Those Milliseconds

TTFB is not a single operation. It is the sum of several sequential steps, each of which can be measured and optimized independently:

For a typical website, server processing time dominates TTFB. On an unoptimized WordPress site, PHP execution and database queries can consume 500-2,000ms, dwarfing the network components. This is why server-side optimization yields the most dramatic TTFB improvements.

Server-Side Factors That Affect TTFB

1. Web Server Software and Configuration

The choice of web server has a measurable impact on TTFB. LiteSpeed's event-driven architecture and integrated caching deliver lower TTFB than Apache's process-based model, particularly under concurrent load. On MassiveGRID's high-availability cPanel hosting, LiteSpeed Enterprise processes requests with minimal overhead, and its built-in LSCache can serve cached pages with TTFB under 20ms.

Key web server configurations that affect TTFB:

• Keep-alive connections: Reusing TCP connections for multiple requests eliminates the TCP handshake overhead for subsequent requests. Ensure keep-alive is enabled with a reasonable timeout (15-30 seconds).
• Worker/thread configuration: Too few workers cause requests to queue. Too many waste memory. Match worker count to CPU cores and expected concurrency.
• Compression: Gzip or Brotli compression adds a few milliseconds of CPU time but dramatically reduces transfer size, often reducing total TTFB for larger responses. Brotli provides 15-25% better compression than Gzip.

2. PHP Version and Configuration

PHP is the processing engine behind WordPress, Joomla, Drupal, Magento, and most other CMS platforms. The PHP version directly affects execution speed:

• PHP 7.4 to 8.0: ~10-15% faster execution from engine improvements.
• PHP 8.0 to 8.1: ~5-10% improvement, plus fibers for async operations.
• PHP 8.1 to 8.2: ~3-5% incremental improvement.
• PHP 8.2 to 8.3: JIT compiler improvements, measurable gains for computation-heavy workloads.

Beyond version, PHP configuration matters. OPcache must be enabled to avoid recompiling PHP files on every request. The opcache.revalidate_freq setting should be at least 60 seconds in production to avoid unnecessary file stat checks. The realpath_cache_size should be increased from the default 4K to at least 4M for CMS applications with many included files. See our PHP version performance guide for detailed benchmarks and migration instructions.

3. Database Performance

On a typical WordPress page load, 20-100 database queries execute during server processing. Each query's execution time adds to TTFB. The most common database performance issues:

• Insufficient buffer pool: InnoDB buffer pool too small to cache frequently accessed data, causing disk reads. See our database optimization guide.
• Missing indexes: Queries scanning entire tables instead of using indexes. Common in WordPress sites with large wp_postmeta and wp_options tables.
• Excessive queries: Plugins that run dozens of unnecessary queries on every page load. Use Query Monitor to identify the worst offenders.
• Autoloaded options bloat: WordPress loads all autoloaded options on every request. Sites with hundreds of KB of autoloaded data waste significant processing time.

4. Storage I/O

Every PHP file read, database page fetch, and cache lookup requires a storage read. On HDD storage, each random read takes 8-12ms. On SATA SSD, 0.1ms. On NVMe SSD, 0.02-0.05ms. For a page load that requires 100 random reads, the storage latency alone ranges from 800-1,200ms (HDD) to 2-5ms (NVMe). This explains why NVMe storage is the single most impactful infrastructure upgrade for TTFB.

5. Server-Level Caching

Caching is the most effective TTFB optimization because it eliminates server processing entirely for cached requests. Instead of executing PHP and querying the database, the server returns a pre-rendered HTML page from memory.

The difference between application-level and server-level caching is significant. Application-level caches (like WP Super Cache) still invoke PHP to check for a cached file and serve it. Server-level caches (like LSCache) intercept the request before PHP is invoked, serving the cached response directly from the web server's memory. This explains why LSCache achieves TTFB under 20ms while application-level caches typically deliver 50-150ms.

6. Server Location and Network

The speed of light imposes a hard minimum on network latency. Light travels through fiber optic cable at roughly 200,000 km/s, meaning a one-way trip from New York to London (5,500 km) takes approximately 28ms. With routing hops and processing at network nodes, the practical round-trip latency between New York and London is 70-100ms.

This network latency adds to TTFB for every request. For the TLS handshake alone, which requires 1-2 round trips, a 100ms network RTT adds 100-200ms to TTFB. Choosing a server location close to your primary audience is one of the most impactful TTFB optimizations. MassiveGRID offers data centers in New York, London, Frankfurt, and Singapore, and a CDN can further reduce latency for global audiences.

Practical TTFB Optimization Checklist

The following checklist is ordered by impact, with the highest-impact optimizations first:

1. Enable server-level caching. If your host runs LiteSpeed, install and configure the LiteSpeed Cache plugin. This alone typically reduces TTFB by 90-99% for cacheable pages.
2. Verify NVMe storage. Run fio or check with your host. If you are on HDD or SATA SSD, consider migrating to NVMe-based hosting like MassiveGRID's cPanel hosting.
3. Upgrade PHP. Switch to the latest stable PHP 8.x version via cPanel's MultiPHP Manager.
4. Enable OPcache. Verify that PHP OPcache is enabled and properly configured with sufficient memory (128MB+) and appropriate revalidation frequency.
5. Enable object caching. If Redis or Memcached is available, enable it to reduce database query volume.
6. Optimize slow database queries. Use the MySQL slow query log or Query Monitor to identify queries taking more than 100ms and add appropriate indexes.
7. Reduce autoloaded options. For WordPress, audit the wp_options table and set unnecessary autoloaded options to no.
8. Enable Brotli or Gzip compression. Ensure the server compresses HTML, CSS, and JS responses.
9. Enable TLS 1.3. Reduces the TLS handshake from 2 round trips (TLS 1.2) to 1 round trip.
10. Consider HTTP/3. QUIC eliminates the separate TCP handshake and supports 0-RTT resumption for returning visitors.

Measuring Your TTFB Improvements

After implementing optimizations, measure the impact using the benchmarking tools and methodology described in our speed testing guide. Key measurements to capture:

• Cached TTFB from server location: Should be under 50ms. This confirms caching is working.
• Uncached TTFB from server location: Should be under 300ms. This is your dynamic performance baseline.
• TTFB from primary audience location: Should be under 500ms. This is what your visitors experience.
• TTFB under concurrent load (25-50 users): Should not degrade more than 50% from single-user TTFB. Significant degradation indicates insufficient server resources.

TTFB Targets by Website Type

If your site consistently exceeds these targets, the root cause is almost certainly in one of the six server-side factors detailed above. Systematic optimization, starting with caching and storage, will bring TTFB into the target range for any well-coded application running on properly configured hosting infrastructure.

Frequently Asked Questions

What is the difference between TTFB and page load time?

TTFB measures only the time until the first byte of the HTML document arrives. Page load time includes everything that happens afterward: downloading all resources (CSS, JavaScript, images, fonts), parsing and rendering HTML, executing JavaScript, and painting the final visual result. TTFB is typically 10-30% of total page load time, but it is the portion most directly controlled by your hosting infrastructure.

Can a CDN reduce TTFB for dynamic content?

Traditional CDNs cache only static assets (images, CSS, JS) and do not reduce TTFB for the HTML document itself, which is the most critical component. However, some CDNs offer edge computing or full-page caching that can cache HTML at the edge, effectively reducing TTFB for visitors far from the origin server. This requires careful cache invalidation configuration to avoid serving stale HTML. Our CDN vs. fast hosting guide explores this in detail.

Why is my TTFB good on desktop but poor on mobile?

If you are measuring TTFB from the same location, it should be identical on desktop and mobile because TTFB is measured before any rendering occurs. However, mobile network latency (4G/5G) adds 30-100ms compared to wired connections, increasing the total TTFB. Additionally, some tools measure TTFB differently on simulated mobile devices, adding throttling that artificially inflates the number. When comparing, ensure you are measuring from the same network connection.

Is 0ms TTFB possible?

In theory, no, because some processing and network transit time always exists. In practice, TTFB under 5ms is achievable for cached requests when the test originates from the same machine or local network as the server. For remote visitors, practical minimums are determined by the speed-of-light network latency between the visitor and the server, plus a few milliseconds of server processing for cache lookup.

How does TTFB relate to Largest Contentful Paint (LCP)?

TTFB is the first phase of LCP. The LCP timeline is: TTFB + resource load delay + resource load duration + element render delay = LCP. High TTFB pushes the entire LCP timeline later, making it the single most impactful factor in LCP scores. A server delivering 50ms TTFB gives you 2,450ms of headroom to achieve a "good" 2.5s LCP. A server delivering 800ms TTFB leaves only 1,700ms for everything else, making a good LCP score very difficult to achieve, especially on mobile devices.