Website speed test
Measure DNS resolution, TLS handshake, time to first byte (TTFB), and total load time for any website.
What the timing breakdown tells you
A single speed number hides where the time went. Splitting the request into its phases points straight at the layer to fix, which is usually not the one people assume.
- DNS resolution is the lookup before any connection exists. Normally tens of milliseconds. Consistently slow here means the nameservers are far away or overloaded, and no amount of work on the site will help.
- TLS handshake is negotiating encryption. Largely a function of physical distance to the server, so a high value with everything else fast usually means the server is on another continent from the test.
- Time to first byte is how long the server took to start answering. This is the number that reflects your application: database queries, uncached pages, slow plugins. It is the most actionable figure on the page.
- Download is transferring the response. Driven by page size and compression rather than by server speed.
- Compression and caching report whether the response was compressed and whether it may be reused. Both being absent on an HTML response is free performance left on the table.
How to act on the numbers
- High TTFB, small page. The server is thinking too long. Page caching is the usual fix, and it is the single biggest lever on a database driven site.
- Low TTFB, slow total. The backend is fine and the page is too heavy. Compression, image sizes and script count are where to look.
- Everything slow, including DNS. Distance. The server is far from the test location, and a CDN in front is the answer rather than tuning the origin.
- First run slow, second run fast. A cache warmed up. Real visitors arriving on a cold cache get the slow version, so test a URL you have not just requested.
- Compression missing. Text responses should be compressed. This is typically one directive in the web server config and cuts transfer size substantially.
Common questions
What is a good TTFB?
Under 200 milliseconds is good and under 500 is acceptable. Above 800 there is usually a specific cause worth finding rather than general slowness, most often an uncached page running database queries on every request. Distance to the server sets a floor you cannot tune below.
Why is this different from PageSpeed Insights?
This measures the network request: DNS, TLS, server response and download. PageSpeed also renders the page and scores what the visitor experiences, including JavaScript execution and layout. A site can have excellent timing here and still score poorly there, and the two are answering different questions.
My site is fast for me but slow in the test. Why?
Your browser has cached assets, your DNS answer is already resolved, and you may be geographically close to the server. A test from elsewhere on a cold cache is closer to what a first time visitor gets, which is the number that matters for both conversions and search.
Will a CDN fix a slow TTFB?
Only partly. A CDN serves cached content from a nearby location, which helps enormously for static pages and assets. If the slowness comes from the application generating an uncached page, the request still reaches the origin and takes just as long. Fix caching at the origin first.