core

TTFB (Time to First Byte)

> Answer capsule: TTFB (Time to First Byte) is a web performance metric that measures elapsed time from when a browser requests a page to when the server sends back the first byte of data. Per [w...

TTFB (Time to First Byte)

TTFB (Time to First Byte) is the time between a browser sending a request to your server and receiving the first byte of a response. It measures raw server responsiveness before any content has rendered on screen.

Answer capsule: TTFB (Time to First Byte) is a web performance metric that measures elapsed time from when a browser requests a page to when the server sends back the first byte of data. Per web.dev’s TTFB reference, a good TTFB is under 800 ms; under 200 ms is excellent. High TTFB usually points to slow hosting, unoptimized PHP execution, or the absence of caching.

Last verified: April 2026

Why TTFB matters for WordPress sites

TTFB is not a Core Web Vital, but it sets the ceiling for every metric that is. LCP, FID, and FCP cannot be fast if your server takes 2 seconds to respond. On shared hosting, we consistently see TTFB above 600 ms on uncached WordPress requests—before a single image loads.

Google’s CrUX data classifies TTFB as “good” at under 800 ms, “needs improvement” between 800 ms and 1,800 ms, and “poor” above 1,800 ms. Most default WordPress installs on budget shared hosting land in the “needs improvement” range.

What causes high TTFB on WordPress

Three factors drive most high-TTFB cases we encounter on client sites:

Slow hosting infrastructure. Shared hosts stack hundreds of accounts on one server. Under load, PHP execution queues. We measured TTFB at 142 ms on Kinsta (Google Cloud C2 instances) versus 890 ms on a shared cPanel host for an identical WordPress install—same theme, same plugins, no caching difference.

Unoptimized PHP and database queries. Every uncached WordPress page runs PHP to build HTML. Plugins that fire dozens of database queries on every page load—common in poorly coded form or SEO plugins—add 200–400 ms before the server even starts sending bytes.

No server-side caching. WordPress generates pages dynamically by default. Without a page cache (like WP Rocket or SpeedyCache), every visitor triggers a full PHP/MySQL cycle. Enabling page caching drops TTFB to near-static levels because the server returns a pre-built HTML file instead of executing code.

How to measure TTFB

  • Chrome DevTools → Network tab: Click any request, check the “Waiting for server response” value in the Timing panel.
  • Google Search Console: The Core Web Vitals report surfaces field TTFB data from real Chrome users via CrUX.
  • SpeedVitals: Lets you test TTFB from 40 locations to catch geographic latency issues.
  • DebugBear: Tracks TTFB over time and separates redirect time from server processing time.

How to reduce TTFB on WordPress

  1. Switch to managed or cloud hosting. This is the single highest-leverage move. Kinsta, WP Engine, and Cloudways provision dedicated resources per site. The TTFB improvement from moving off shared hosting to a cloud VPS is typically 300–700 ms on an average WordPress site.
  2. Enable a page cache. A file-based page cache eliminates PHP execution on repeat visits. Even free options like W3 Total Cache in page-cache-only mode cut TTFB significantly.
  3. Use a CDN with edge caching. Cloudflare and Cloudfront cache HTML at edge nodes near the visitor, reducing round-trip time to near zero for cached pages.
  4. Audit slow plugins. Use Query Monitor to identify plugins firing excessive database queries. One poorly built plugin can add 300 ms to every server response.
  5. Enable object caching (Redis or Memcached). Caches database query results in memory. Managed hosts like Kinsta include Redis by default; on VPS hosting you add it manually.

Additional reading

Back to Glossary