Server-Timing Inspect
Inspect Server-Timing metrics in your browser to quickly identify slow layers. No input is sent to a server.
Status
Runs in your browser. No input is sent to a server.
How to use
Paste Server-Timing and click “Parse” to inspect per-metric dur/desc.
Notes (this tool)
- You can paste either full Server-Timing header lines or raw values.
About this page
What does this tool do?
Split Server-Timing into individual metrics and display `dur` (duration) and `desc` (description) fields.
Useful for quickly spotting latency candidates when responses include multiple timing metrics.
Typical use cases
- Checking whether DB/app/CDN dominates latency in slow API responses
- Validating formatting after rolling out Server-Timing
- Comparing per-metric changes before/after performance tuning
Syntax basics
- Metrics are comma-separated.
- Each metric looks like `name;dur=12.3;desc="db"`.
- `dur` is typically interpreted as milliseconds.
Recommended workflow
- Paste Server-Timing from response headers
- Inspect per-metric dur and focus on top 2-3 contributors
- Drill into the relevant layer (DB query, external API, rendering)
Common pitfalls
- Emitting duplicate metric names and making comparisons harder
- Mixing duration units (seconds output while clients assume ms)
- Leaking internal details via overly verbose desc values in production
What this tool does
- Metric parsing (name/dur/desc/parameters)
- Quick total duration check
- Copyable parsed output
Operational notes
- Server-Timing is observational; use APM/tracing for final diagnosis.
- Cache hits can mask server work; compare separately by cache state.
Referenced specs
- W3C Server Timing
- MDN: Server-Timing
FAQ
Is dur always in ms?
It is generally interpreted as milliseconds. Keep units consistent in your implementation and team conventions.
How detailed should metrics be?
Start coarse (DB/API/APP) and add detail only where needed for manageable operations.
References
Next to view (diagnostic order)
These links are generated from site_map rules in recommended diagnostic order.
- Response Headers Parser — Parse response headers into structured data
- Cache Response Analyzer — Judge cacheability from response headers
- Content-Encoding Inspect — Parse Content-Encoding to verify applied compression
- Transfer-Encoding Inspect — Parse Transfer-Encoding and inspect transfer mode
- Content-Length Inspect — Parse Content-Length and inspect size consistency
- HTTP Status Inspect — Analyze HTTP status codes and suggest handling direction
- How to Diagnose Retry Storms on 429/503 — Isolate Retry-After parsing and client implementation gaps to stop excessive retries
- How to choose response header tools — Map Retry-After, Server-Timing, Link, Content-Type, and nosniff checks by symptom
Same-theme links
Response Header Diagnostics
Step through raw headers to inspect Retry-After, Server-Timing, Link, and Content-Type
- HTTP Header Parser — Parse raw headers into structured lists
- Response Headers Parser — Parse response headers into structured data
- Set-Cookie Inspect — Parse Set-Cookie attributes and review delivery policy
- Cookie Domain/Path Matcher — Evaluate cookie send conditions by Domain/Path/Secure
- SameSite Cookie Simulator — Simulate cookie send behavior from SameSite and request context
- Set-Cookie Conflict Checker — Detect same-name cookie conflicts and overwrite risks
- Cookie Size Checker — Estimate Cookie header size and check limit risks
- Retry-After Inspect — Parse Retry-After and inspect retry wait behavior
- Link Header Inspect — Parse Link headers and inspect rel/as/type
- Content-Type Inspect — Parse Content-Type and inspect MIME/charset
- X-Content-Type-Options Inspect — Parse X-Content-Type-Options and validate nosniff
- HTTP Status Inspect — Analyze HTTP status codes and suggest handling direction
Example
Server-Timing: db;dur=53.2;desc="db query", app;dur=12.1, edge;desc="cdn"