What Is TTFB?
TTFB stands for Time to First Byte. It is a measurement of the responsiveness of your web server and network stack. When a visitor navigates to your website, their browser establishes a TCP connection to your server, sends an HTTP request, and then waits. TTFB is the duration of that wait, measured from the moment the request is sent until the first byte of the HTML response arrives at the browser. It encompasses three components: the time to redirect (if any), the connection time (TCP handshake and TLS negotiation), and the server processing time.
TTFB is included in Google's Core Web Vitals context as part of the Largest Contentful Paint (LCP) pathway. Google classifies a TTFB under 800 milliseconds as Good, between 800 and 1,800 milliseconds as Needs Improvement, and above 1,800 milliseconds as Poor. These thresholds apply to real-user measurements collected through the Chrome User Experience Report (CrUX), meaning your actual visitors' experiences determine your score, not just a lab test.
The primary drivers of a high TTFB are slow server response time, high network latency (often caused by geographic distance between the server and visitor), missing server-side caching, and heavy database queries. For South African businesses on international hosting, the latency component alone can push TTFB above 400 milliseconds before the server has even started processing. This is why local hosting or a well-configured CDN with South African edge nodes is particularly important for achieving Good TTFB scores for local audiences.
Improving TTFB typically requires a combination of approaches. Enabling full-page or object caching at the server level means that repeat requests for the same page are served from memory rather than re-generated from scratch. Using a CDN reduces the network latency component by serving cached HTML from geographically closer nodes. Upgrading from shared hosting to a VPS or dedicated server eliminates resource contention. Optimising slow database queries reduces the time the server spends generating the response.
TTFB In Practice
A Sandton-based financial advisory firm was consistently scoring Poor TTFB values of over 2,100 milliseconds in Google Search Console's Core Web Vitals report. Their WordPress site was hosted on a shared US server with no caching active. After migrating to a South African VPS, installing WP Rocket for full-page caching, and enabling Cloudflare with South African edge nodes, their TTFB dropped to under 220 milliseconds. Their LCP score improved from 5.8 seconds to 1.4 seconds as a direct result, moving from Poor to Good across all measured pages.
When auditing TTFB for a client site, the most useful tool is Chrome DevTools. Open the Network tab, load the page, click on the first HTML document request, and inspect the Timing tab. The "Waiting (TTFB)" line shows exactly how long the browser waited for the first byte. GTmetrix allows you to simulate tests from a South African location for more representative measurements. Cross-referencing lab data with the real-user data in Google Search Console's Core Web Vitals report gives a complete picture of what your actual South African visitors are experiencing.
What affects Time to First Byte
Time to First Byte (TTFB) measures how long from a request until the browser receives the first byte of the response, so it reflects mostly server-side and network delay before anything renders. The main influences are server processing time, how quickly the server builds the page, which slow databases, heavy code or unoptimised platforms worsen; hosting quality and server load; the distance between the server and the user, which a content delivery network reduces by serving from nearby; and whether caching lets the server return a ready-made response instead of rebuilding it. For South African visitors hitting a distant server, network distance alone can add noticeable delay, which is why a CDN and caching often give the biggest TTFB gains.
How to improve TTFB
Improving TTFB targets the server and network stages. Use caching so the server returns a stored response rather than rebuilding the page each time; put a content delivery network in front of the site so content is served from a location near the user; choose fast, appropriately resourced hosting rather than an overloaded shared server; and optimise the back end, efficient code, a well-tuned database, minimal blocking work before the response starts. Because TTFB comes before anything is drawn, a slow figure delays every other loading metric that follows, including Largest Contentful Paint. Fixing it therefore lifts the whole loading experience, not just one number, which is why it is a sensible first place to look at speed.
FAQ
What is a good TTFB score?
Google's Core Web Vitals thresholds classify TTFB under 800 milliseconds as Good, 800 to 1800 milliseconds as Needs Improvement, and over 1800 milliseconds as Poor. For competitive SEO, aiming under 200 milliseconds is ideal. South African sites on local hosting regularly achieve this with proper caching configured.
How do I check my TTFB?
You can check TTFB using Google PageSpeed Insights, GTmetrix, or Chrome DevTools. In Chrome DevTools, open the Network tab, load your page, click the first HTML request, and look at the Waiting (TTFB) row under Timing. GTmetrix lets you test from South African nodes for accurate local measurements that reflect what your visitors experience.
Is TTFB a ranking factor?
Not directly. TTFB is not itself a Google ranking signal, but it feeds the loading metrics that are, notably Largest Contentful Paint, since nothing can render until the first byte arrives. Improving TTFB therefore supports the Core Web Vitals that do influence rankings.
What is the difference between TTFB and page load time?
TTFB measures only the wait until the first byte of the response arrives, reflecting server and network delay. Page load time measures the whole process until the page finishes rendering. TTFB is the starting point; a slow one delays everything that follows.