Real-world performance metrics
Server-side performance metrics: TTFB, DNS, TCP, TLS, compression, caching — no Google API, no browser required. Get a performance score 0–100 with actionable recommendations in seconds.
Newsletter
Get more from your audits
TTFB too slow? Get weekly performance tips from real inspections.
What page speed metrics actually matter
Not all page speed metrics have equal impact on real users or search rankings. The ByteWaveNetwork Page Speed Inspector focuses on the metrics that directly affect server response time and network efficiency — the layer you control before any JavaScript or rendering kicks in.
The single most important server-side metric. TTFB reflects how long your server takes to process the request and start sending a response. Google's Core Web Vitals recommend under 800 ms.
How long it takes to resolve your domain name to an IP address. Typically 20–120 ms. Slow DNS (over 300 ms) can be fixed by switching to a faster DNS provider or using a CDN with anycast DNS.
Time to establish a TCP connection. Largely determined by geographic distance between client and server. A CDN or edge hosting reduces this by serving from a nearby point of presence.
Time to negotiate an HTTPS connection. Modern TLS 1.3 is faster than TLS 1.2 due to fewer round trips. Session resumption can reduce this to near-zero for repeat visitors.
gzip reduces text payloads by 60–80%. Brotli (br) achieves 15–25% better compression than gzip at similar CPU cost. If compression is absent, enabling it is the single fastest win on transfer size.
Proper caching lets browsers and CDNs reuse responses without hitting your server. Static assets should have long max-age (1 year + immutable). HTML should use short max-age or revalidate strategies.
HTTP/2 multiplexes multiple requests over a single connection, eliminating head-of-line blocking. HTTP/1.1 sites pay a per-request connection cost that adds up with many assets.
Scripts in <head> without defer/async block HTML parsing. Every render-blocking script delays the moment the browser can start rendering the page. Aim for zero synchronous scripts in <head>.
Understanding TTFB (Time to First Byte)
TTFB is the elapsed time from when a client makes an HTTP request to when the first byte of the response body arrives. It is the sum of network latency (DNS + TCP + TLS) plus server processing time.
A TTFB dominated by network time (large DNS + TCP values relative to total TTFB) is a hosting or geography problem — solved by CDN, edge hosting, or relocating servers closer to users. A TTFB where network time is small but total is still high indicates slow server-side processing: uncached database queries, heavy middleware, or underpowered compute.
Google's threshold for a "good" TTFB is under 800 ms. TTFB over 1800 ms is classified as "poor" and will negatively affect Largest Contentful Paint (LCP), the Core Web Vital most directly tied to perceived page load speed.
How compression affects page load time
Text compression (gzip, Brotli) is one of the easiest wins in web performance. A typical uncompressed HTML document of 50 KB compresses to around 12–15 KB with gzip — a 70–75% reduction in bytes transferred.
Brotli (the br content-encoding) achieves roughly 15–25% better compression ratios than gzip
at equivalent CPU usage. All modern browsers support Brotli. It is supported natively in Node.js via
zlib.createBrotliCompress() and can be enabled in nginx with brotli on;
(requires the ngx_brotli module) or in Caddy with encode zstd gzip.
The Page Speed Inspector checks the Content-Encoding response header. If absent or set to
identity, compression is not enabled — a deduction of 10 points on the performance score.
Enabling compression on an Express server requires just two lines: npm install compression
and app.use(require('compression')()).
Cache-Control and browser caching
The Cache-Control header controls how long browsers, CDNs, and intermediate proxies can
cache a response. Without it, each user request hits your origin server even if the content has not changed.
The inspector classifies cache policies into four levels based on the max-age directive:
- Immutable —
max-age ≥ 31536000(1 year). For fingerprinted static assets that never change. - Long —
max-age ≥ 3600(1 hour). For semi-static assets like fonts and images. - Short —
max-age > 0. For content that changes regularly. - Revalidate —
no-cachewith ETag or Last-Modified. Browser checks freshness on every request but downloads the body only if changed.
HTML documents typically use short or revalidate strategies. The immutable directive should
only be used on assets whose URLs change when their content changes (via cache-busting hashes).
HTTP/2 vs HTTP/1.1
HTTP/2 was standardised in 2015 and is supported by over 98% of browsers. Its key advantage for page performance is multiplexing: multiple requests and responses can be in flight simultaneously over a single TCP connection. HTTP/1.1 allows at most six parallel connections per host, meaning browsers must queue requests when loading many assets.
The inspector detects HTTP version from the Node.js http.IncomingMessage.httpVersion property.
Serving over HTTP/1.1 deducts 5 points. To enable HTTP/2, ensure your server or reverse proxy supports it —
nginx supports HTTP/2 with listen 443 ssl http2;, and Node.js supports it natively via
the built-in http2 module.
Render-blocking resources
When a browser encounters a <script src="..."> tag without defer
or async in the document <head>, it must stop parsing HTML, fetch
the script, and execute it before continuing. This delays the moment the browser can start rendering
the page — directly harming First Contentful Paint (FCP) and LCP.
Render-blocking stylesheets (<link rel="stylesheet"> in <head>)
block rendering too, though this is unavoidable for critical CSS. The mitigation is to inline critical
CSS and lazy-load non-critical sheets with media="print" onload="this.media='all'".
For scripts, add defer to scripts that do not need to execute before the DOM is ready,
or async for scripts that are fully independent (analytics, chat widgets).
Scripts with type="module" are deferred by default and are not counted as render-blocking.
Frequently Asked Questions
- It measures DNS lookup time, TCP connection time, TLS handshake time (HTTPS only), Time to First Byte (TTFB), and download time. It also checks HTTP version (HTTP/1.1 vs HTTP/2), response compression (gzip, Brotli, deflate), Cache-Control header policy, render-blocking scripts and stylesheets in the HTML head, images missing width/height attributes, and presence of the viewport meta tag.
- Google PageSpeed Insights runs in a simulated browser (Lighthouse) and measures client-side metrics like LCP, FID, and CLS. The ByteWaveNetwork Page Speed Inspector makes a raw server-side HTTP request and measures pure network and server timing — no Google API key, no browser, no quota limits. It is ideal for measuring raw server response time and infrastructure configuration (caching, compression, HTTP version) independently of client-side JavaScript or rendering performance.
- TTFB (Time to First Byte) is the time from the start of a request until the first byte of the response body is received. It reflects server processing time — how long your server takes to generate and begin delivering the page. Google's Core Web Vitals guidelines recommend TTFB under 800 ms. A high TTFB often indicates slow database queries, missing server-side caching, or underpowered hosting.
- Under 200 ms is excellent for a server close to the user. Under 800 ms is good and within Google's recommended threshold. 800–1500 ms is acceptable but warrants investigation. Over 1500 ms is poor and will negatively affect Core Web Vitals scores and user experience. For global audiences, a CDN can reduce geographic latency, but server processing time must be optimised separately.
Related tools
- → SEO Site Audit — run a full SEO crawl including Lighthouse performance scores
- → Redirect Tracer — identify multi-hop redirect chains adding to your load time
- → Link Checker — find broken links that cause 404 errors and hurt Core Web Vitals