Digitalprahlad TTFB Tester

A free website ping and Time to First Byte test from 22 locations worldwide. See server response time, DNS, TCP and TLS timings, CDN cache status and response headers in one test.

Tip: run the test twice. The second run shows how your cache behaves once it is warm.

What is TTFB?

Time to First Byte (TTFB) is the time between a browser starting a request and receiving the first byte of the response. It covers the DNS lookup, the connection and TLS setup, and the time the server needs to start sending the page.

What is a good TTFB?

How to improve TTFB

• Serve pages from a CDN with full-page caching, and confirm a cache HIT in the Cache column.
• Host the origin close to your main audience.
• Keep the application and database fast: object caching, query tuning, enough CPU and RAM.
• Use HTTP/2 or HTTP/3 and TLS 1.3 to cut connection time.
• Remove redirect chains before the final page.

TTFB tester FAQs

Results vary with each test and can differ slightly from real visitor experience depending on network conditions at the time of the test.

TTFB vs. Page Load Time: What's the Difference?

TTFB only measures how long it takes the server to start responding, it stops the moment the first byte arrives. Page load time (or "fully loaded" time) measures everything after that too: downloading the full HTML, then every image, script, stylesheet and font the page needs, plus however long the browser takes to render it all. A page can have an excellent TTFB and still load slowly overall if it ships bloated CSS, unoptimized images, or dozens of render-blocking scripts. TTFB is the foundation; it tells you whether your server and network path are fast, not whether your whole page is lightweight.

Does TTFB Affect SEO and Core Web Vitals?

Indirectly, yes. TTFB isn't itself one of Google's three Core Web Vitals (Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift), but it's the floor every one of those metrics is built on. A slow TTFB delays the browser from receiving any HTML at all, which pushes back LCP, delays when scripts can start executing, and can indirectly worsen INP. Google has also said server response time is a factor search engines can weigh when crawling and ranking pages, so a server stuck at 1.5 seconds of TTFB is working against both user experience and search visibility at the same time.

Common Causes of High TTFB

• No full-page caching. If every request has to run through your application and database from scratch, TTFB balloons under any real traffic. Confirm a cache HIT in this tool's Cache column after a second run.
• Distance from the origin server. A visitor in Mumbai hitting a server in Virginia with no CDN in front of it is paying for every millisecond of that physical distance, twice, for the TCP handshake and again for the actual request.
• Slow database queries or unoptimized application code. Even a cached homepage can't save you if every other page triggers a dozen uncached database calls before it can respond.
• Shared hosting resource contention. On a budget shared plan, your site's response time can degrade when neighboring sites on the same server spike in traffic or run heavy processes.
• DNS and SSL/TLS overhead. A slow DNS provider or an outdated TLS configuration (no TLS 1.3, no session resumption) adds real, avoidable milliseconds before the server even starts processing the request.

How This Tool Compares to a Single-Location Speed Test

Browser-based tools like Chrome DevTools or a single PageSpeed Insights run only tell you how your site performs from wherever that one test happened to run, often a data center in the US. If most of your actual visitors are elsewhere, that number can be misleading. Testing from 22 locations across six continents at once shows the real spread: a site that looks instant from Virginia can be genuinely slow for visitors in Southeast Asia or South Africa if there's no CDN or regional caching catching those requests.