# Server response checker

Before a page can paint anything, the server has to answer. This tool asks twice, times the second answer to the first byte and to the end, reads which protocol the server negotiates, whether it compresses, how it asks browsers to cache, and the security headers it sends, and judges each against the thresholds web.dev publishes.

Updated 2026-09-14 · Source: https://porteur.ai/tools/server-response-checker

## What it checks

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.

## Why the first byte matters

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.

> This measures the server from one place. Field data in Search Console's Core Web Vitals report is what Google ranks on; use this to find the cause, and that to confirm the effect.

## How to read the result

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.

| Reading | Good | Look | Fix |
| --- | --- | --- | --- |
| Time to first byte | under 0.8 s | 0.8 to 1.8 s | past 1.8 s |
| Compression on text | br or gzip |  | none |
| Protocol | HTTP/2, HTTP/3 advertised | HTTP/1.1 only |  |
| Redirects before the page | none or one | two or more |  |
| HSTS on https | present | missing |  |
| Cache-Control on an asset | max-age set | missing or no max-age |  |
| X-Powered-By | absent | present |  |

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.

## What to do with it

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. **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. **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. **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. **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.

## Limits

- 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.

## Questions

### What is a good time to first byte?

web.dev puts good under 0.8 s and poor past 1.8 s, measured in the field at the 75th percentile. On a cached page from a CDN, under 200 ms is normal.

### Why are the two runs so different?

The first run often includes name resolution, the connection, the TLS handshake and a cold cache at the edge; the second reuses what it can and reads the page the edge now holds. When both are slow, nothing is caching the HTML and the server renders every request.

### Does HTTP/2 make a page faster?

It lets the browser fetch many assets over one connection at once instead of a few at a time. Pages with dozens of scripts, styles and images gain; a page with three assets barely notices. HTTP/3 adds a faster handshake on poor connections.

### Is time to first byte a ranking factor?

Not by itself. It feeds Largest Contentful Paint, which is a Core Web Vital, and Core Web Vitals are a ranking signal at the Good thresholds. A slow first byte makes a good LCP hard to reach.

### What does Cache-Control: private, no-store mean for a marketing page?

That no cache anywhere may keep a copy, so every visitor waits for the server. Right for a page behind sign-in; wrong for the home page, which can be cached for a minute at the edge with no visible difference.

## Read next

- [Time to first byte: the delay every other metric inherits](https://porteur.ai/guides/time-to-first-byte): TTFB sets the pace for every other speed metric. See what it includes, how to test it in field and lab, the causes on product sites, and the fixes.
- [Does page speed affect SEO? What Google has said and what the data does](https://porteur.ai/guides/does-page-speed-affect-seo): Yes, speed affects SEO, but only at Core Web Vitals’ Good thresholds. Here is what Google measures, what the data shows, and what to fix first.
- [Render-blocking resources: what blocks the first paint and how to unblock it](https://porteur.ai/guides/render-blocking-resources): Stop CSS and synchronous scripts from blocking first paint. Read the Lighthouse audit and fix in order: defer, inline critical CSS, split CSS, and handle fonts.
- [Core Web Vitals checker](https://porteur.ai/tools/core-web-vitals-checker): Paste a URL for one Lighthouse run on a simulated phone: LCP, CLS, TBT and FCP against Google's thresholds, the biggest savings, the failing audits.
- [Redirect checker](https://porteur.ai/tools/redirect-checker): Follow a URL's redirects hop by hop: each status and destination, the time each took, the kind of hop, meta and script redirects, one rule to replace it.
- [HTTPS](https://porteur.ai/glossary/https): HTTPS is a small ranking signal. Serve every page over HTTPS, one‑hop redirect HTTP to HTTPS, fix mixed content, keep canonicals and sitemaps on HTTPS.
- [301 redirect](https://porteur.ai/glossary/301-redirect): A 301 redirect is a permanent move. Use it to send users and bots to a new URL, keep signals, avoid chains, and choose 308 when methods must persist.
- [How to read PageSpeed Insights: field data first, then the score](https://porteur.ai/guides/how-to-read-pagespeed-insights): Start with field data, not the score. Learn what Google uses, why scores vary, and how to turn a PageSpeed Insights run into a clear order of fixes.

This times one answer from one server. The free check loads your home page on a simulated phone and reads the site, its searches and its rivals in the same pass, so the speed finding sits next to the pages it costs you. Free check: https://porteur.ai/