// TTFB CHECKER
TTFB checker
A real timed request to your server measures how long the first byte takes — the part of page speed your hosting controls.
What this measures
Time to First Byte (TTFB) is how long your server takes to send the first byte of a page after the browser asks for it. This test makes a real request from our server and breaks the wait into its phases — DNS lookup, TCP connection, TLS handshake, and the server's own processing time — so you can see which part is slow, not just the total.
How to read your result
- Good — under 300 ms
- Your hosting is not holding the page back. If the page still feels slow, the cause is on the page itself: images, scripts, or render-blocking resources.
- Needs work — 300 to 800 ms
- Acceptable but not fast. Server-side caching or a CDN in front of the origin usually brings this range down noticeably.
- Slow — over 800 ms
- Everything else waits behind the first byte. Page-level optimization cannot fix a slow server response.
- The phase waterfall
- The colored bar splits the wait into DNS, connect, TLS, and server-wait. If server-wait dominates, it is a hosting or application problem; if TLS or connect dominates, it is usually distance or handshake overhead a CDN can cut.
- Cold vs warm
- We request the page twice. If the second (warm) request is much faster, caching is working and the cold number is what first-time visitors and search crawlers actually get.
Common causes & fixes
- No page caching
- If two back-to-back requests are equally slow, the server rebuilds the page every time. Enabling full-page caching is usually the single biggest TTFB win.
- Slow application or database
- A dominant server-wait phase points at slow application code or database queries — the work your host's CPU does before responding. Faster hosting or query/caching fixes help.
- Distant server
- A large connect/TLS share means the server is physically far from the test location. A CDN serves visitors from a nearby edge instead.
- Too many redirects
- Each redirect adds a full round trip before the real page starts. Point links directly at the final URL.
Frequently asked questions
What is a good TTFB?
Google's guidance treats a TTFB at or below 800 ms as acceptable. This tool uses a stricter band — under 300 ms is good, over 800 ms is slow, where the server response is likely holding the page back.
Is TTFB the same as page load time?
No. TTFB is only the wait for the first byte from the server. Full load time also includes downloading and rendering HTML, CSS, images, and scripts — all of which happen after the first byte.
Why is my TTFB different each time?
Caching, server load, and network conditions vary between requests. That is why this test shows a cold and a warm measurement and a per-phase breakdown rather than a single number.
Does a CDN improve TTFB?
Usually yes for visitors far from your origin, because a CDN answers from a nearby edge and can serve cached pages without waiting for the origin. It helps least when the slowness is your server's own processing time.
Related guides