For competitive performance: under 200ms is excellent. Under 400ms is good. Over 600ms should be investigated. Google's Core Web Vitals assessment uses 800ms as the "Needs Improvement" threshold, but top-performing sites typically achieve 50–200ms.

What causes high TTFB?

Main causes: slow hosting server, missing server-side caching (PHP/Python/Ruby processing on every request), slow database queries, geographic distance between server and user (solved by CDN), and unoptimised server configuration.

Can I fix high TTFB without changing hosting?

Yes. Implementing a full-page caching plugin (WordPress) or server-side caching (Varnish, Redis, Nginx FastCGI cache) can reduce TTFB by 80–90% without changing hosting. Adding a CDN also reduces effective TTFB significantly for geographically distributed audiences.

Browse tools

Free · Fast · Privacy-first

Check TTFB Online (Time to First Byte)

Time to First Byte (TTFB) measures how long it takes your server to start responding after a browser requests a page. A high TTFB means a slow server, missing caching, or a CDN not working correctly. FixTools measures TTFB instantly for any URL.

⚡ Use Tool Now How it works

Cost: Free forever
Sign-up: Not required
Processing: In your browser
Privacy: Files stay local

⚡

TTFB measurement to millisecond precision

🔒

Diagnosis guidance for high TTFB

✨

Comparison against good/poor thresholds

Web Tool

Website Speed Test

All processing happens in your browser — your files are never uploaded to any server.

🚀Open Website Speed Test

100% Free · No account · Works on any device

How to use this tool

💡

Enter your URL to measure TTFB and diagnose server-side performance.

How It Works

Step-by-step guide to check ttfb online (time to first byte):

1
Enter your URL
Paste the page URL to test TTFB for.
2
Review the TTFB result
Check TTFB. Good: under 200ms (for competitive performance). Acceptable: 200–600ms. Poor for SEO: over 800ms (Google's Core Web Vitals threshold for TTFB).
3
Diagnose based on TTFB cause
High TTFB with no CDN: add a CDN. High TTFB on cached pages: investigate hosting. High TTFB on uncached pages: investigate database and server-side code performance.
4
Implement and re-test
After each server-side change (caching, CDN, hosting upgrade), re-test TTFB to confirm improvement.

Real-world examples

Common situations where this approach makes a real difference:

Hosting upgrade evaluation

A site owner testing a new managed WordPress host uses the TTFB checker to compare the current host (850ms TTFB) versus the new host (95ms TTFB) on the same page, providing clear evidence the upgrade is justified before migrating.

CDN effectiveness verification

A developer enabling a CDN for the first time checks TTFB before and after to confirm the CDN is correctly serving cached responses. TTFB drops from 420ms to 45ms from a geographically distant location, confirming CDN is working.

Database query optimisation

An e-commerce developer investigating high TTFB on product category pages uses the TTFB data alongside database query profiling to identify an unindexed database query adding 1.2 seconds to server response time.

When to use this guide

Use this when investigating slow overall load times, when diagnosing server-side performance before optimising the front-end, or when evaluating a new hosting provider.

Pro tips

Get better results with these expert suggestions:

Target TTFB under 200ms for good performance

Google's Core Web Vitals guidelines consider a TTFB under 800ms as "Good", but for a competitive website, targeting under 200ms gives the best foundation. A 500ms TTFB adds 500ms to every metric including LCP.

TTFB is the foundation of all other metrics

LCP cannot be faster than your TTFB. If TTFB is 1.5 seconds, LCP will be at least 1.5 seconds even with perfect front-end optimisation. Fix server speed first.

Implement full-page caching before other optimisations

For WordPress and CMS sites, a full-page caching plugin (WP Rocket, W3 Total Cache) can reduce TTFB from 1–2 seconds to under 100ms by serving cached HTML instead of processing PHP/database on every request.