Time to First Byte (TTFB): What It Is and How to Reduce It

Time to First Byte — TTFB — is the time that elapses between a browser sending a request to your web server and receiving the very first byte of the response. It’s one of the earliest measurable moments in the page load process, and because everything else can only start once that first byte arrives, a high TTFB imposes a delay on every other performance metric. Google includes TTFB as an indicator in its Core Web Vitals guidance, and a slow TTFB is often the hidden root cause of poor Largest Contentful Paint scores.

At Xpose, TTFB is one of the first things we check when auditing a slow website. Unlike some performance metrics that require careful analysis to fix, a high TTFB usually has a clear and fixable cause — most commonly an underpowered hosting plan, an unoptimised database, or the absence of server-side caching. This guide explains what contributes to TTFB, what’s an acceptable threshold, and the practical steps businesses can take to bring it down.

What Contributes to a Slow TTFB?

TTFB is made up of three components: the time taken for the DNS lookup (translating your domain name into a server IP address), the time for the TCP connection and TLS handshake (establishing a secure connection), and the time the server takes to process the request and begin sending a response. The third component — server processing time — is where TTFB problems almost always originate. DNS and connection times are typically small and relatively fixed; server processing time varies enormously depending on your hosting, your application, and how efficiently your server is configured.

The most common causes of slow server processing time are: shared hosting where your server is overloaded with other websites competing for the same resources; a WordPress site making dozens of database queries per page load without caching; a PHP application that runs expensive operations on every request instead of caching the result; and a server located geographically far from your typical visitors, adding network latency on top of processing time. Identifying which of these applies to your site determines the right fix.

What’s an Acceptable TTFB?

Google’s guidance suggests a TTFB below 800ms is acceptable, with under 200ms being ideal. In practice, a well-optimised site on good hosting with server-side caching enabled should achieve a TTFB of 100–300ms for visitors in the same country as the server. If your TTFB is above 600ms, it’s worth investigating. If it’s above 1,000ms, it’s almost certainly harming your Core Web Vitals scores and creating a noticeable delay that visitors perceive as sluggishness before the page even starts to render.

You can measure your TTFB in WebPageTest, where it’s shown clearly in the waterfall as the time before the first green bar appears for your HTML document. Google Search Console’s Core Web Vitals report will flag sites with consistently high TTFB as part of its LCP diagnosis. Chrome DevTools Network tab also shows TTFB for any individual request — look at the "Waiting (TTFB)" section in the timing breakdown for your main HTML document.

How to Reduce Your TTFB

The most impactful fixes for a high TTFB, in order of typical impact: first, enable server-side page caching. For WordPress, a caching plugin like WP Rocket, W3 Total Cache, or LiteSpeed Cache stores a static HTML copy of each page, meaning the server can return the response almost instantly without running PHP or querying the database. This single change can reduce TTFB from 800ms to under 100ms on a typical WordPress site. Second, upgrade your hosting. Shared hosting plans that allocate minimal CPU and memory to each site are the most common root cause of chronically high TTFB. Moving to a VPS, managed WordPress host, or cloud hosting with dedicated resources is often the only permanent fix for sites on entry-level shared plans.

Third, use a Content Delivery Network (CDN) to serve your site from a location closer to your visitors. Even with fast server processing, physical distance adds latency — a server in the US serving visitors in the UK adds 80–100ms of network delay before processing begins. A CDN like Cloudflare caches your pages on servers in dozens of countries, dramatically reducing this geographic penalty. Fourth, optimise your database. WordPress sites that have been running for years often accumulate thousands of post revisions, transients, and orphaned data that slow queries down. A plugin like WP-Optimize can clean these up. At Xpose, combining these four steps typically reduces TTFB to well within Google’s recommended thresholds for the sites we manage.