Server response checker

The tool requests the address twice from the same server. The first request warms whatever cache sits in front of the site; the second is the one timed, because that is what a visitor sees once the edge holds the page. Both clocks are shown. For the second request it records the time to the first byte of the response headers and the time to the end of the body, and on the first it also notes when the name resolved, when the connection opened and when the TLS handshake finished, whenever the socket reports them.

• Time to first byte, judged against web.dev's thresholds: good under 0.8 s, poor past 1.8 s.
• The protocol negotiated over TLS: HTTP/2, or HTTP/1.1 only, and whether HTTP/3 is advertised.
• Compression: brotli, gzip, or none.
• Cache-Control and its max-age, ETag and Last-Modified, Vary.
• Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy.
• Server, X-Powered-By, and the cache status headers CDNs add.
• Redirects before the page, hop by hop, and the size on the wire.

Time to first byte is the delay every other metric inherits. First Contentful Paint cannot happen before the HTML arrives; Largest Contentful Paint waits on the HTML to discover the image; the whole Lighthouse score sits on top of it. A server that takes 1.5 s to answer has spent most of the 2.5 s LCP budget before the browser has a byte to work with.

The causes are few and they show in the headers. A page rendered on every request with no cache in front (no Cache-Control, a slow first byte, a fast second one). A server far from the visitor (a long connect time). A chain of redirects before the page (each one a round trip). No compression (a 400 KB HTML file that could be 60). HTTP/1.1 on a page with sixty assets (one lane at a time). Each is a configuration change, not a rewrite.

The verdict leads with the first byte. Under it: the timed run and the cold run side by side, the protocol, the compression, the caching and security headers, then the findings marked fix or look, then every header read, and the redirect chain when there is one.

A worked example. yourproduct.com answers in 1.4 s on the cold run and 1.3 s on the warm one, over HTTP/2, gzip on, Cache-Control: private, no-store. The warm run being as slow as the cold one is the tell: nothing caches the HTML, so every visitor waits for the server to render the page. Serving the marketing pages as static files or letting the CDN cache them for a minute brings the warm run under 100 ms; the cold run then only matters to the first visitor after each change.

1. 1

   Cache or pre-render the pages that do not change per visitor

   The home page, the pricing page, the guides. A static file or an edge cache with a short max-age turns a 1 s render into a 50 ms answer. Keep the app behind sign-in dynamic; the marketing site rarely needs to be.

2. 2

   Turn compression on

   brotli where the server or CDN offers it, gzip otherwise, for HTML, CSS, JavaScript, JSON and SVG. Images and fonts are already compressed and should not be.

3. 3

   Collapse the redirects

   http to https, www to apex, a trailing slash: one rule that sends the first address straight to the last, at the edge or in the server, so no visitor pays for two hops.

4. 4

   Send long cache lifetimes on hashed assets

   Files whose name changes with their content can carry max-age of a year and immutable. HTML should carry a short one or none, so a deploy shows at once.

5. 5

   Add HSTS and drop the headers that say too much

   Strict-Transport-Security tells browsers never to try http again. X-Powered-By tells the world the stack for no gain.

• The clock runs from one server in Europe. A visitor in another continent sees a longer connect time to an origin without a CDN; the first-byte figure here is a lower bound for them, and a fair one for the server's own share.
• Node's HTTP client speaks HTTP/1.1, so the timed request runs over 1.1 even when the server offers HTTP/2; the protocol is read from a separate TLS handshake. The first-byte time is the same on both.
• The first byte is measured to the response headers, which on most servers arrive with the first bytes of the body; on a server that streams, the body can lag a little behind.
• Two requests per check, thirty checks an hour per visitor, public addresses only, two megabytes read at most. Nothing is stored.