B2 · Performance & Mobile UX

    TTFB Checker — how fast does your server respond?

    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.
    Updated June 2026 · Technical SEO & GEO · Part of Performance & Mobile UX

    Check your server response time

    Paste a URL — GEObubbly measures how quickly your server returns the first byte and flags slow responses.

    ✓ Free check1 signal✓ No signup required
    In short: Time To First Byte measures how quickly your server starts responding. A slow TTFB delays everything else — and AI fetchers, which favor fast origins, will drop a sluggish or timing-out server.

    What does the TTFB check measure?

    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.

    How is it evaluated, and how is it scored?

    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.

    Why server response speed matters for SEO and GEO

    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.

    How this check scores
    Pass: TTFB ≤ ~0.8s.
    Warning: TTFB roughly 0.8–1.8s.
    Fail: TTFB > 1.8s, or frequent timeouts.

    FAQ

    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.

    Related checks in Performance & Mobile UX

    B1
    Core Web Vitals (LCP, INP, CLS)
    B8
    CDN usage
    B5
    Render-blocking resources & page weight

    Audit your page across all 9 checks in Performance & Mobile UX

    See which checks pass, warn or fail — in seconds.

    Run a free audit →
    ← Back to the full Performance & Mobile UX guide
    Free TrialContact