Website Speed Test
Server/network timing — DNS, TCP, TLS, redirects, and time to first byte. Doesn't measure full-page rendering, JavaScript execution, or Core Web Vitals.
Server/network timing from WebsiteDown's probe location. It checks DNS lookup, TCP connection, TLS handshake, redirects, status code, and time to first byte.
It does not measure full-page rendering, JavaScript execution, images, layout, or Core Web Vitals.
What we measure
Every test records a request waterfall: DNS lookup, TCP connection, TLS handshake, redirects, status code, and time to first byte. The bar chart in the result above shows you which stage is the bottleneck.
Domain Name System — translates a name like example.com into the IP address (e.g. 93.184.216.34) computers actually route to. Every web request starts with this lookup.
DNS time runs before any data leaves for the server, so it adds to every uncached page load. Slow DNS usually points at your DNS provider, the domain's registrar, or low TTLs — not the site itself.
Once we have the IP, the browser opens a TCP connection to the server. TCP is the basic transport layer of the internet — the handshake that establishes a reliable channel before any HTTP data is exchanged.
TCP connect time mostly reflects raw network distance and current server load. The server hasn't done any work yet, so a slow connect points at routing detours, an overloaded accept queue, or no CDN in front of the origin.
The browser and server exchange certificates and agree on encryption keys to upgrade from plain TCP to HTTPS. This is what makes the connection private and verified.
TLS 1.3 finishes in one round-trip; TLS 1.2 takes two. Oversized certificate chains, RSA keys instead of ECDSA, and disabled session resumption all slow this stage down. A fast handshake is a sign of modern, well-tuned TLS config.
Time to First Byte. After the connection is up and the request is sent, this is the time until the first byte of the server's response arrives.
TTFB is mostly server-side work: database queries, application logic, cache lookups, and any third-party APIs the server calls during rendering. It's the single best signal of "is the server slow?" — the rest of the waterfall is mostly network plumbing.
Frequently asked
DNS stands for Domain Name System. It translates a name like example.com into the IP address (e.g. 93.184.216.34) computers actually route to. Every uncached web request starts with a DNS lookup, so a slow DNS provider adds delay to every page load before any data leaves for the server.
TCP is the basic transport layer of the internet — the handshake that establishes a reliable connection between your browser and the server before any HTTP data is exchanged. We measure it separately from DNS and TLS because a slow TCP connect typically means raw network distance or an overloaded server, while DNS and TLS issues have very different causes.
Once the TCP connection is open, the browser and server exchange certificates and agree on encryption keys to upgrade from plain TCP to HTTPS. TLS 1.3 finishes in one round-trip; TLS 1.2 takes two. A slow handshake usually points at older TLS versions, oversized certificate chains, or no session resumption.
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 include slow database queries, missing cache for HTML or API responses, cold serverless functions, expensive server-rendered pages, third-party APIs called during server rendering, or an origin server far from the probe location. 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 focuses on full web-page performance and Lighthouse-style browser diagnostics. WebsiteDown measures the server connection and first byte only, so it also works well for APIs and endpoints that don't render 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.
Check live status of popular services
Speed varies; outages are binary. If a service feels slow, it may also be down for others.