TTFB test:How fast does your server answer?
See how long your server takes to send the first byte, from our Frankfurt test location, a Lighthouse run and real users, plus the redirects in front of the page.
- Free, no account
- Results in under a minute
- Tested from Frankfurt, Germany
example-shop.hr
WordPress 6.8Sample shop · homepage · mobile Chrome · the same check you get for your own site
4 passed · 0 failed · 0 warnings. Nothing to fix here.
Lab data from Google PageSpeed Insights (Lighthouse 12.8.2) · desktop score 100 · no field data: not enough real Chrome users visit this page yet
Lab (Lighthouse 12.8.2)
| Metric | Value | Rating |
|---|---|---|
| First Contentful Paint | 0.8 s | good |
| Largest Contentful Paint | 0.8 s | good |
| Total Blocking Time | 0 ms | good |
| Cumulative Layout Shift | 0 | good |
| Speed Index | 4.3 s | needs work |
| Time to First Byte | Root document took 30 ms | good |
LCP element: <p>
Field (Core Web Vitals)
Filmstrip
0.4 s- 0.8 s
- 1.2 s
- 1.6 s
- 2.0 s
- 2.4 s
- 2.8 s
3.2 s
Waterfall · top 1 of 1 requests
- example.com/0 KB
What we found
Everything this tool checks passed.
Show 4 passed checks
What this tool checks
Time to First Byte from three sources, plus the redirect hops that each add a full round trip.
Time to First Byte
How long the server takes to start answering, which delays everything else on the page.
Real-user Time to First Byte
How long real visitors wait for the server's first byte, against Google's 800 ms target.
Server response time
Checks how fast the server sends the first byte, which caching and hosting usually fix.
Redirects before the page
Measures time lost to redirects before the page loads, each one a full round trip.
Redirect chains
Checks how many redirects happen before the page loads, since each hop adds delay and loses ranking value.
Show 1 more checks
Redirect chains
Checks how many redirects happen before the page loads, since each hop adds delay and loses ranking value.
How it works
Time the first byte
We request your page from our test location in Frankfurt and measure how long the server takes to send the first byte.
Compare with Lighthouse and users
The first byte time from Lighthouse's throttled run and from the Chrome UX Report is shown beside ours, where Google has real-user data.
Count the redirects
Redirect chains before the page are listed, and the server response time audit flags a slow back end.
We test from one location, Frankfurt, so visitors far from your server can see a slower first byte than we measure.
Questions
Is this really free?
Yes. getReport is funded by donations, not plans. This tool runs the full report and shows you the part it is about; the complete report with all seven modules is one click away, also free.
Where do you test from?
Frankfurt, Germany. A US test location switches on for everyone once monthly donations reach the threshold on the funding page.
My TTFB is fine but the page is slow. Why?
Then the time goes into what happens after the first byte, such as render-blocking CSS and scripts, big images or heavy JavaScript. Run the full speed test to see the waterfall.
Can I run this on many sites?
You can check 10 sites every 10 minutes and 50 a day from one connection. For more at once, the bulk URL checker and the bulk PageSpeed checker take lists of URLs; a free API is in development. Cached reports never count against the limit.
Why does TTFB matter?
Nothing can render before the first byte arrives, so a slow server pushes every other metric back. Google wants TTFB under 800 ms; under 200 ms is what a cached page on a decent host delivers. The usual fixes are page caching, a faster hosting plan, a CDN in front of the origin, or removing a redirect. All of them are one setting, not a rebuild.
Related free tools
All 41 tools →Free, funded by the people who use it
€0 of €75 this month. At €75, site crawl up to 500 pages + weekly re-check switches on for everyone.