**Time to First Byte (TTFB) is how long your server takes to start sending the page — and everything else waits on it.** This check measures the delay between the request and the first byte of response. A slow TTFB means the browser sits idle before it can even begin rendering, so it caps how fast your page can possibly load, no matter how well the rest is optimised.
It measures the time from the request being sent to the first byte of the response arriving — the delay before anything can start rendering. This covers:
- Server processing — how long the backend takes to build the page (database queries, application logic).
- Network and connection — DNS, connection setup and the round trip to the server.
- Caching and delivery — whether responses are cached or served from a CDN edge close to the user.
A fast TTFB (roughly under 800 ms, ideally under 200) passes; a moderate delay is a warning; a slow response that holds up rendering is a fail.
GEObubbly requests the page and measures how long the server takes to return the first byte. It's a core, scored Performance check that runs partially, since the measured time depends on live server and network conditions at the moment of the request.
TTFB is the foundation everything else is built on: until the first byte arrives, the browser can't download resources, render content or respond to the user. A slow TTFB therefore caps your best possible LCP and overall loading speed — you can optimise images and scripts all you like, but the page still can't start until the server replies. Slow responses usually trace back to unoptimised backend code, slow database queries, missing caching, underpowered hosting, or serving every request from a single distant origin instead of a CDN edge. The fixes are correspondingly direct: cache rendered pages or fragments, optimise slow queries, use a content delivery network so responses come from a server near the user, and choose hosting that matches your traffic. For crawlers, a fast server means more pages crawled per visit; for users, it's the difference between a page that feels instant and one that hangs.
TTFB is the time between a browser requesting a page and the first byte of the server's response arriving. It captures everything that has to happen before content can start rendering: DNS lookup and connection setup, the round trip to the server, and the server's own processing time to build the response. Because nothing else can begin until that first byte lands, TTFB is effectively the floor on how fast your page can load — a slow TTFB delays every subsequent step regardless of how well the rest of the page is optimised.
As a rule of thumb, aim for a TTFB under about 800 milliseconds, and ideally under 200 milliseconds for a fast, well-cached site. Times above 800 ms start to noticeably delay loading and are worth investigating, while consistently slow responses (well over a second) significantly hurt both user experience and Core Web Vitals. The exact figure varies with what the page does, but the principle holds: the faster your server starts responding, the more headroom every other optimisation has to deliver a fast-feeling page.
Common causes include slow backend processing (heavy application logic or unoptimised database queries), a lack of caching so every request is rebuilt from scratch, underpowered or overloaded hosting, and serving all traffic from a single origin server that's geographically far from many users. Third-party calls made server-side before responding can also add delay. Each adds time before the first byte is sent, so diagnosing TTFB usually means finding which of these stages — server processing, caching, or network distance — is the bottleneck.
The highest-impact fixes are caching and delivery: cache fully-rendered pages or expensive fragments so the server doesn't rebuild them on every request, and use a CDN so responses are served from an edge location near the user rather than a distant origin. Beyond that, optimise slow database queries and backend code, and make sure your hosting is sized for your traffic. Together these reduce the time the server spends before sending the first byte, which lifts loading speed and Core Web Vitals across the board.
Yes. TTFB feeds directly into loading speed and Core Web Vitals, which are part of Google's page-experience ranking signals, so a slow server can hold back rankings. It also affects crawling: when your server responds slowly, crawlers — including AI crawlers — fetch fewer pages per visit, so a fast TTFB helps engines cover more of your site efficiently. Improving server response time is one of the most leveraged performance fixes because it benefits users, rankings and crawl efficiency simultaneously.