Most performance conversations jump straight to images, caching plugins, and code minification. All of that matters, but none of it starts until TTFB is done. TTFB is the delay before your page even begins loading, and if it’s slow, everything downstream is delayed with it.
What TTFB actually measures
Time to First Byte is the time between a browser requesting a page and receiving the first byte of the response from the server. It covers three things happening before any HTML, CSS, or images even reach the browser: the DNS lookup, the server processing the request (running PHP, querying the database, building the page), and the network time for that first byte to travel back.
A slow TTFB means the delay is happening before the page starts rendering at all, which is why it’s one of the most important, and most overlooked, numbers in performance audits.
What actually causes slow TTFB
Hosting and server resources. This is the biggest factor by far. Shared hosting under heavy load, or a server without enough allocated resources, adds delay before your site even starts responding. This is one of the clearest ways hosting choice shows up as a performance number, not just a monthly bill.
Database queries. WordPress builds pages dynamically, querying the database for content, settings, and plugin data on every request. A bloated database, or poorly optimized queries from a plugin, slows this step down directly.
No server-side caching. Without caching, WordPress rebuilds the same page from scratch on every single request, running the same database queries and PHP processes repeatedly, even for visitors seeing identical content.
Distance to the server. If your server is physically far from the visitor, the network round trip itself adds to TTFB, independent of how fast your server processes the request.
Unoptimized plugins. Some plugins run expensive processes on every page load, even on pages where their functionality isn’t being used. That overhead adds directly to TTFB.
What actually fixes it
Server-side caching (page caching, object caching) is usually the single biggest improvement available, since it lets WordPress skip rebuilding the page from scratch for every visitor.
A CDN reduces the network distance between your server and visitors, cutting the network portion of TTFB for visitors far from your origin server.
Database cleanup (removing post revisions, spam comments, expired transients) reduces the query load on every page build.
Better hosting, specifically hosting with resources tuned for WordPress, addresses the biggest single lever directly, rather than working around a server that’s fundamentally under-resourced.
Auditing plugins for ones running unnecessary processes on every load. Fewer, better-built plugins beat a large stack of convenience plugins every time.
Google considers under 800ms a good TTFB, with anything under 200ms considered excellent. If you’re auditing your own site, that’s the number to check first, before diving into image sizes or code minification, since a slow TTFB delays every optimization downstream of it.
TTFB is usually the first thing we check in a performance audit, precisely because it affects everything that comes after it.