Perf Tools > Server Timing

Server Timing Analyzer
Header Parser · Latency Tester · Waterfall

Parse and visualize Server-Timing HTTP headers, test live server latency via the Performance API, and analyze request waterfall timing. No login, client-side.

Header parser Latency tester Waterfall view Client-side

Server Timing Tools

Two tools: parse Server-Timing headers from any response into a visual chart, or test live server latency for any URL using the browser Performance API.

Find it in Chrome DevTools → Network tab → click a request → Response Headers → look for "server-timing". Paste only the header value (not the header name).
Paste a Server-Timing header value above and click Parse & Visualize

Enter URLs to test latency using the browser's fetch + Performance API. Measures DNS lookup, TCP connection, TLS handshake, TTFB, and total time. CORS must allow the request.

Server-Timing Header Guide

How the Server-Timing HTTP header works, what to include, and how to implement it in different backends.

Header syntax

The Server-Timing header uses comma-separated metric definitions. Each metric has a name (required), optional description (desc), and optional duration in milliseconds (dur).

Server-Timing: cache;desc="Cache";dur=23.2,
               db;desc="DB Query";dur=53.1,
               render;dur=12.4

Accessing via JavaScript

The browser exposes Server-Timing data via the Performance API. Use PerformanceServerTiming objects from resource entries:

performance
  .getEntriesByType('resource')
  .forEach(function(e) {
    e.serverTiming.forEach(function(t) {
      console.log(t.name, t.duration);
    });
  });

Node.js implementation

Add Server-Timing headers in your Express or Node.js response. Measure each phase using performance.now():

var start = performance.now();
// ... db query ...
var dbTime = performance.now() - start;
res.setHeader('Server-Timing',
  'db;desc="Database";dur=' + dbTime.toFixed(2));

Security considerations

Server-Timing headers are accessible only to pages served from the same origin (or with Timing-Allow-Origin). Cross-origin requests cannot read Server-Timing metrics without the Timing-Allow-Origin: * response header. This prevents information leakage about backend infrastructure to third-party scripts.

Request Timing Phases

What each phase in the browser navigation/resource timing waterfall represents and what causes slowdowns.

PhaseMeasured byTypical fastSlow indicatorCommon causes of slowness
DNS LookupdomainLookupEnd - domainLookupStart<5ms>50msSlow DNS resolver, TTL too low, no DNS preconnect
TCP ConnectconnectEnd - connectStart<20ms (local), <100ms (global)>200msServer geographically distant, no CDN, server overloaded
TLS HandshakerequestStart - secureConnectionStart<50ms>150msOld TLS version, large certificates, no session reuse
TTFB (Time to First Byte)responseStart - requestStart<200ms>600msSlow server processing, DB queries, no caching
Content DownloadresponseEnd - responseStartDepends on sizeSlow for small resourcesLarge response, slow bandwidth, no compression
Total Durationduration (all phases)<300ms>1sSum of all phases above

Performance Tools

TTFB CheckerTime to First Byte analyzer Request WaterfallVisual request timing breakdown CDN Latency TesterTest CDN edge node latency HTTP Headers AnalyzerParse and inspect response headers Core Web Vitals GuideLCP, FID, CLS explained

Server Timing – FAQ

What is the Server-Timing HTTP header?+
The Server-Timing header is an HTTP response header (defined in W3C spec) that communicates backend performance metrics from the server to the browser. It can report metrics like database query time, cache hit/miss, rendering time, or any custom measurement. Format: Server-Timing: metric-name;desc="Description";dur=23.2. The browser exposes this data via the PerformanceServerTiming API and shows it in the DevTools Network tab waterfall.
How do I find Server-Timing headers on my site?+
Open Chrome DevTools (F12) → Network tab → click any request → scroll to Response Headers. Look for a header named "server-timing". If present, copy its value and paste into the Header Parser tab above. You can also check via command line: curl -I https://yoursite.com | grep -i server-timing. Most servers don't send Server-Timing by default — you need to add it in your application code or web server configuration.
What is TTFB and how do I improve it?+
TTFB (Time to First Byte) is the time from sending an HTTP request to receiving the first byte of the response. It includes DNS + TCP + TLS + server processing time. Good TTFB: under 200ms (Google recommends under 800ms for LCP). To improve: use a CDN to reduce network hops, implement server-side caching (Redis, Varnish), optimize database queries, add HTTP caching headers (Cache-Control), and use HTTP/2 or HTTP/3. The Latency Tester above measures TTFB for any URL.
Why does the latency tester show "CORS error"?+
The latency tester uses the browser fetch API, which enforces CORS. In No-CORS mode, the request is sent as a HEAD request with no-cors mode — you can measure timing but can't read the response body or headers. In CORS mode, the server must send Access-Control-Allow-Origin headers to allow reading the response. If you get CORS errors, try switching to No-CORS mode — timing data is still collected via the Performance API even for opaque responses.
What is the difference between server timing and server latency?+
Server latency (TTFB) is the total time from request to first response byte — a single number covering network + server processing. Server timing is the internal breakdown reported by the server via the Server-Timing header — it shows how the server spent its processing time (database: 53ms, cache: 2ms, render: 12ms). Server timing is a subset of TTFB. Use TTFB to identify that a server is slow; use Server-Timing to understand why it's slow.