Cut Your TTFB: a 5-Minute Server-Speed Check

Time to First Byte (TTFB) measures how long a browser waits between requesting a page and receiving the first byte of the response. It captures your server's real responsiveness — DNS, connection, and the time your backend needs to build the page. A slow TTFB delays everything that follows, drags down Core Web Vitals like Largest Contentful Paint, and quietly frustrates users. This five-minute check shows you where the delay lives.

As a rule of thumb, aim for a TTFB under about 800 milliseconds; faster is better, and anything over a second or two signals a real backend problem.

Three quick ways to measure

• Open your browser DevTools, go to the Network tab, reload the page, and read the "Waiting for server response" time on the main document.
• Use a field-data source like Google's Core Web Vitals report to see real-user TTFB, not just one lab test.
• Test from more than one location — a fast time near your data center can hide a slow experience for distant users.

Measure the raw HTML document, not an asset, and test a few times to rule out a one-off spike.

A high TTFB almost always traces back to one of a short list of causes:

• No caching — the server rebuilds the full page on every request.
• Slow database queries or heavy backend logic.
• An overloaded or under-resourced host.
• No CDN, so distant users wait on a single origin server.
• Chained redirects that add a full round trip before the real page loads.

Check redirects first — they are the quickest to spot and often the easiest to remove.

To narrow it down, compare a cached page against an uncached one. If your homepage responds quickly but a fresh product or search page crawls, the delay is in your application layer — database calls, template rendering, or third-party API calls the server waits on before it can respond. That single comparison usually tells you whether to reach for caching or for code and query optimization.

You can land several of these in one short session:

• Turn on full-page caching so repeat requests serve a prebuilt page instantly.
• Put a CDN in front of your site to serve cached HTML and assets from a location near each user.
• Remove redirect chains so links point directly to the final URL.
• Enable compression (Gzip or Brotli) and keep connections alive.
• Upgrade cheap, oversold hosting if your server is simply out of headroom.

Page caching alone often cuts TTFB dramatically, because it skips the database and template work entirely.

If your pages are personalized and cannot be fully cached, you still have options: cache the expensive fragments, add an object cache for repeated database queries, and make sure slow third-party scripts are loaded after the server responds rather than blocking it. Modern protocols like HTTP/2 and HTTP/3 also trim connection overhead, which shaves real milliseconds off that first byte.

Always re-measure so you know the change worked.

1. Re-test the same URL in DevTools and compare the new "waiting" time to your baseline.
2. Check field data over the following days — real-user numbers lag lab tests.
3. Confirm your other pages benefited too, not just the homepage.

A regular technical audit can track TTFB over time so regressions surface before they hit your rankings.

TTFB is your server's reaction time, and it sets the ceiling for how fast a page can feel. Measure it in DevTools, look for missing caching, redirect chains, or an overloaded host, and apply the quick wins — caching, a CDN, and cleaner redirects. Re-measure to confirm. Five minutes of server-speed housekeeping improves Core Web Vitals and gives every page a faster start.