Website Speed Test

What is TTFB?

Time To First Byte (TTFB) is the number of milliseconds between sending an HTTP request and receiving the first byte of the response. It captures DNS resolution + TCP/TLS handshake + the time your server spent thinking before it started replying. TTFB is the floor of the page's loading experience: nothing else can start until the first byte arrives. Anything above 600 ms typically points at a slow backend, a missing cache, or a far-away origin.

Response size

The size of the HTML response (not the full page weight — just the document) is a useful proxy for server-side bloat. Pages with embedded base64 images, inlined critical CSS thousands of lines long, or huge JSON state blobs often weigh in at hundreds of KB before any external resource is loaded. Aim for the initial HTML to be under ~100 KB compressed; everything else can come from cache.

Redirect chain

Each redirect adds another DNS lookup, TLS handshake, and round-trip — easily 200 ms per hop on mobile networks. http://example.com → https://example.com → https://www.example.com → https://www.example.com/home is four chained requests for what should be one. Audit the chain on every important entry URL and collapse where possible.

HTTP status

A 200 is healthy. A 301 / 308 means a permanent redirect (canonical URLs probably need updating elsewhere). A 302 / 307 means temporary — usually a sign of A/B testing or feature flags. A 4xx or 5xx is a broken link or broken server; chase it. The status code also matters for SEO: search engines treat 200 and 301 as canonical signals; 302 keeps ranking on the old URL.

Raw speed checks vs. Lighthouse

This tool measures the raw HTTP request: TTFB, status, size, redirects. It does not run JavaScript, parse the DOM, or load external assets. That gives a fast, deterministic measurement of how the origin behaves — which is exactly what you want when isolating backend regressions.

Lighthouse, PageSpeed Insights, and WebPageTest do the opposite: they boot a headless browser, load every resource, and synthesize a score across LCP, CLS, INP, and dozens of audits. That's the right tool when you're optimizing user experience. The two views answer different questions and ideally you use both.

Why measuring from multiple regions matters

A page that's 80 ms from Frankfurt can be 400 ms from São Paulo because of network distance, CDN cache misses, and TLS resumption behavior. If you only measure from one region you'll miss whole continents of degraded experience. The minimum useful set is: same continent as your origin, one ocean away, and one mobile network. Synthetic tools provide that; this single-shot tool measures from one fixed location (so use it for quick comparisons, not for an SLO).

How OpenAnalyticsAPI tracks performance over time

The tracking snippet pulls Navigation Timing and Paint Timing from window.performance on every pageview, so the console can show TTFB, FCP, and LCP distributions per page, per country, per device. Synthetic tests are useful for catching regressions in your origin; real-user metrics tell you what your actual visitors experience — and you usually need both.