Before your browser renders a single pixel, before any image loads, before any JavaScript runs — the browser is waiting for your server to respond. That wait is Time to First Byte, and it sets the floor for every other performance metric on your site.
What TTFB Measures
Time to First Byte is the elapsed time from when a browser sends an HTTP request to when it receives the first byte of the server’s response. It includes three components:
- DNS lookup — translating your domain name to an IP address
- TCP connection — establishing the connection between browser and server
- Server processing time — how long the server takes to generate and start sending the response
Google’s threshold for “Good” TTFB is under 800ms. Competitive sites aim for under 200ms. Sites with TTFB above 1800ms are in “Poor” territory — and that slowness cascades into every subsequent metric: LCP, FCP, and the overall user experience before a single byte of content renders.
Why WordPress Sites Often Have High TTFB
WordPress is a dynamic CMS. Every time a visitor requests a page, WordPress runs a PHP process that queries the database, assembles the template, executes any plugin hooks, and returns the HTML. On a busy or poorly optimized site, this process can take 500ms–2,000ms before a single byte goes to the browser.
The causes compound:
Slow hosting. Shared hosting plans with overloaded servers add 200–400ms of processing overhead before WordPress even starts running.
Unoptimized database queries. Every active plugin adds queries. A WordPress site with 40 active plugins — which is not unusual — might run 80–200 database queries per page load. Slow queries from poorly optimized plugins add directly to TTFB.
No page caching. Without page caching, WordPress rebuilds every page from PHP and database queries on every request. With page caching, the assembled HTML is stored and served instantly — the PHP process runs once, not on every visit.
Unoptimized autoloaded options. WordPress stores options in the wp_options table. Every plugin that stores data there adds to what WordPress loads on every request. A bloated wp_options table with megabytes of autoloaded data is a significant TTFB killer that many sites never audit.
Read more about how plugin accumulation creates these problems in WordPress plugin bloat and how it slows sites down.
The Relationship Between TTFB and Other Performance Metrics
TTFB is upstream from everything else. No matter how optimized your images are, how well you have configured browser caching, or how close your CDN edge nodes are to your visitors — all of that optimization only applies after the server responds.
If your TTFB is 1,500ms, your Largest Contentful Paint (LCP) cannot be under 2.5 seconds. The math is simple: LCP is measured from the time the user navigates to the page. If the server does not respond for 1.5 seconds, LCP cannot occur until at least 1.5 seconds have passed — before any asset has loaded.
Google’s Core Web Vitals are ranking signals. TTFB is not a Core Web Vital itself, but it sets the lower bound on LCP, which is. A fast TTFB does not guarantee good LCP. A slow TTFB guarantees bad LCP.
How Page Caching Fixes TTFB
Page caching stores the fully assembled HTML of each page so WordPress does not have to rebuild it on every request. When a page is cached, the server response skips PHP execution and database queries entirely — it reads a flat file from disk and sends it. This reduces TTFB from 500–2,000ms to 20–80ms on most sites.
This is the single highest-impact TTFB optimization available for WordPress. The implementation options:
Server-level caching — handled by the web server (Nginx FastCGI cache, Apache with mod_cache) before PHP runs. This is the fastest option and requires server configuration access.
Plugin-based caching — WP Rocket, LiteSpeed Cache, W3 Total Cache, and others generate static HTML files that WordPress serves instead of running PHP. These work well and are accessible without server access.
Host-level caching — managed WordPress hosts (Kinsta, WP Engine, Cloudflare Pages) include page caching as infrastructure. This is reliable but expensive compared to VPS hosting with a configured caching layer.
Server Location and Latency
TTFB includes the physical travel time of the request. A server in Virginia responding to a visitor in Sydney adds 150–200ms of irreducible latency before server processing even begins. This is where CDNs help — a CDN that caches your HTML pages at edge nodes eliminates that latency for cached pages.
Cloudflare’s “Cache Everything” feature (available on paid plans) caches WordPress HTML at edge nodes globally. With this configured, your Sydney visitor gets the response from a Cloudflare server in Sydney — 20ms away, not 200ms. This reduces TTFB for international visitors dramatically.
For domestic traffic on a well-hosted US server, distance is less of a factor. But for any site with international traffic, server location and CDN configuration are not optional.
Hosting Quality: The Baseline
Not all hosting environments produce the same TTFB. The differences are concrete:
- Shared hosting (GoDaddy, Bluehost standard plans): 400–800ms TTFB before caching
- Managed WordPress hosting (Kinsta, WP Engine): 100–300ms TTFB with infrastructure caching
- Cloud VPS (DigitalOcean, Vultr) with Nginx + FastCGI cache: 50–150ms TTFB
- Cloudflare Pages / static hosting: 20–50ms TTFB (no server processing)
The performance floor of your hosting is the performance floor of your site. No amount of plugin optimization compensates for a server that is fundamentally slow.
At Designodin, all custom WordPress builds deploy to environments configured for performance — Nginx with FastCGI caching, or managed hosting appropriate to the site’s traffic and requirements. The baseline is in the build, not bolted on afterward.
Measuring Your TTFB
Three ways to check your current TTFB:
Chrome DevTools — open the Network tab, reload the page, click the HTML document request, and look at the “Waiting (TTFB)” value in the Timing section.
WebPageTest.org — the most detailed TTFB analysis available. Shows TTFB at multiple test locations, separately from DNS and connection time. Test from multiple locations to see geographic variance.
Google Search Console — the Core Web Vitals report shows field data (real user measurements) for TTFB, segmented by device type. This is real-world data, not a lab simulation.
honest.designodin.com includes TTFB in its site audit, with specific recommendations based on what is causing the delay.
What a Good TTFB Setup Looks Like
A custom WordPress site with proper infrastructure has:
- Nginx FastCGI page cache or equivalent server-level caching
- Object cache (Redis or Memcached) for database query results
- Optimized
wp_optionstable with minimal autoloaded data - Clean database with no plugin detritus from uninstalled plugins
- CDN with HTML caching for international visitors
On a hand-coded site, this is set up during the build. On a plugin-heavy site that has accumulated performance debt over years, each of these requires investigation and cleanup — the WordPress plugin bloat problem compounds directly into TTFB.
FAQ
What is the difference between TTFB and page load time? TTFB measures the first server response only. Page load time includes everything after that — HTML parsing, asset downloads, JavaScript execution, rendering. TTFB is one component of total load time, but it is the first one, which makes it a bottleneck for everything else.
Can I improve TTFB without changing hosts? Often yes. Installing a page caching plugin is the highest-impact change on most WordPress sites and does not require changing hosts. Database optimization and pruning unnecessary autoloaded options can also reduce TTFB significantly without a hosting change.
Does TTFB affect SEO? Not directly — TTFB is not a Core Web Vital. But it directly limits LCP, which is a Core Web Vital and a ranking signal. Improving TTFB usually improves LCP, which has direct SEO impact.
How much does hosting quality affect TTFB? Significantly. Moving from shared hosting to a VPS with proper caching can reduce TTFB from 600ms to 80ms — a 7x improvement before any code changes. Hosting is infrastructure, and infrastructure has a floor.
Is a TTFB of 800ms acceptable? It is at Google’s “Needs Improvement” threshold, not “Good.” For competitive sites, aim for under 300ms. A TTFB of 800ms means your LCP cannot be under 800ms regardless of how fast everything else loads — and a 2.5-second LCP target requires headroom.
Does a CDN improve TTFB? For cached content, yes — dramatically. For uncached dynamic pages, the CDN adds a small amount of overhead as the request passes through the CDN layer to origin. The net effect depends on how aggressively your CDN caches HTML and how far your visitors are from your origin server.
Every millisecond your server takes to respond is a millisecond your visitor spends waiting. On a custom WordPress build, TTFB is addressed in the infrastructure and codebase from day one — no plugin stack required. If you want to know your current TTFB and what is causing it, honest.designodin.com breaks it down. Ready to fix it properly? Get started.