Website speed & TTFB test
Before the browser can paint anything, your server has to answer. This free scan measures real Time To First Byte and checks whether text compression is enabled — the two server-side signals that shape how fast every page feels.
Free, read-only, no signup. See our methodology.
What the speed test measures
The scanner makes one real HTTPS request and records exactly what the server does with it.
| Signal | What we report |
|---|---|
| Time To First Byte | The measured milliseconds from request to the first byte of the response, graded from excellent to slow. |
| Text compression | Whether a content-encoding header (Brotli or Gzip) is present, which shrinks the transfer size of your HTML, CSS and JavaScript. |
| HTTP protocol version | The protocol negotiated on the connection, so you can see whether a modern stack is in use. |
The TTFB grade follows clear thresholds: 200 ms or under is excellent, up to 600 ms is good, up to 1200 ms is fair, and anything over 1.2 seconds is flagged as slow.
Why TTFB matters
Time To First Byte is the delay before anything can happen. Every image, stylesheet and script waits behind that first response, so a slow TTFB pushes back the entire loading timeline — including Largest Contentful Paint, the metric visitors actually feel. A fast first byte doesn’t guarantee a fast page, but a slow one guarantees a slow one. It’s usually caused by server work: uncached database queries, an overloaded host, or a server physically far from the visitor.
How to improve your response time
- Cache aggressively. Serve cached HTML where you can so the server isn’t rebuilding every page from scratch on each request.
- Add a CDN. A content delivery network answers from a location near the visitor, cutting network round-trip time.
- Turn on compression. If the scan shows no
content-encoding, enable Brotli (or Gzip as a fallback) to reduce transfer size. - Trim the critical path. Profile slow database queries and heavy application logic that run before the first byte is sent.
Performance guides
What Is TTFB (Time to First Byte)?
What Time to First Byte measures, what counts as good, and the most common causes of a slow TTFB.
Read guide →Performance & Core Web VitalsCore Web Vitals Explained for Non-Developers
LCP, INP and CLS in plain language — what Google measures, the thresholds, and how they affect rankings.
Read guide →Performance & Core Web VitalsHow to Improve Largest Contentful Paint (LCP)
Practical, prioritized steps to bring LCP under 2.5 seconds, from image handling to render-blocking resources.
Read guide →Frequently asked questions
Does this test measure full page load speed?
No. It measures how quickly your server sends the first byte of the response (TTFB) and whether text compression is enabled. It does not render the page or run a full Lighthouse-style audit, so it won’t report LCP, INP or CLS.
What is a good TTFB?
On this scan, 200 ms or under is excellent, up to 600 ms is good, up to 1200 ms is fair, and above 1.2 seconds is slow and worth investigating.
How do I make my server respond faster?
Enable server-side caching, put a CDN in front of the site, make sure Brotli or Gzip compression is on, and reduce slow database or application work on the critical path.