Website Speed Test

How long it takes to resolve the domain to an IP address. Slow DNS often points to your DNS provider, not the site itself.

Time to open a TCP connection to the server. Reflects raw network distance and current server load.

Negotiating HTTPS encryption. Older protocols, oversized certificates, or distant servers slow this down.

How fast the server starts replying once the request is in. The single best signal of server-side speed.

Time to First Byte — how long the server takes to start sending its response after receiving the request. The single most useful number for answering "is the server slow?". It excludes the time to download the rest of the page.

Under 200ms TTFB is excellent (grade A). Under 500ms is good (B). Above one second usually means the server has work to do — slow database queries, missing caches, or distant infrastructure between you and the origin.

Common causes: slow database queries, no CDN in front of static assets, the host is far from your users, expensive server-rendered pages, or third-party scripts blocking the response. The waterfall above shows which stage is the bottleneck — DNS, TCP, TLS, or TTFB.

No. We measure the network handshake and server response only — the time it takes the server to start replying. Tools like PageSpeed Insights and Lighthouse measure how long the page takes to render in a real browser, which includes images, JavaScript, and CSS.

PageSpeed Insights measures Core Web Vitals from a real browser running Lighthouse. We measure the raw network handshake and server response from our server. Both matter — ours is faster, simpler, and works on APIs and endpoints that don't render full pages.

Cache aggressively, put a CDN in front of static assets, choose a host close to your users, optimise the slowest backend operation (usually a database query), and prefer modern HTTP (HTTP/2 or HTTP/3). For TTFB specifically, look at the server's work — caching the response is the fastest win.