How to Use Server-Timing to Diagnose Website Performance

The Server-Timing HTTP response header lets a server or intermediary report named measurements for handling a request. To use it for diagnosis, instrument meaningful work such as cache lookup, database queries, or application processing; emit those metrics in the response; then inspect them beside the browser’s timing breakdown in DevTools. For automation, read serverTiming from navigation and resource entries in the Performance API.

These values are diagnostic clues about measured server-side components. They do not automatically identify a root cause, represent the full page load, or share a synchronized clock with browser timings. [MDN: Server-Timing header] [W3C: Server Timing Working Draft]

1. What Server-Timing tells you

A response can report one or more named metrics. A metric can have a name, duration, description, or a combination of them. For example:

Server-Timing: cache;desc="Cache Read";dur=23.2, db;dur=53, app;dur=47.2

Here, the server reports a cache metric described as “Cache Read” with a duration of 23.2, plus database and application durations. The units for dur are milliseconds. The names, descriptions, and values are chosen by the server or intermediary; the header does not measure work by itself. Keep names and descriptions short to limit header overhead, and avoid exposing sensitive internal details on public responses. [MDN] [W3C draft]

Use metrics to narrow an investigation: a large database duration may justify inspecting query behavior, while a cache metric may help distinguish cache work when the server actually reports it. A metric is evidence about the measured component, not proof that it caused a user-visible delay.

2. Instrument and emit server metrics

Start by choosing a small set of components that matter to the request. Measure them on the server or intermediary, then serialize the results into the response header. The exact instrumentation code depends on your server framework; the wire format is HTTP response metadata.

Example response

HTTP/1.1 200 OK
Content-Type: text/html
Server-Timing: cache;desc="Cache Read";dur=23.2, db;dur=53, app;dur=47.2

Useful metrics often represent cache lookup, database work, or application processing. Report only work that you can measure meaningfully. Multiple metrics are allowed, and their order is not significant. Avoid treating the example names or values as defaults or expected performance.

Instrumentation checklist

Measure clearly defined work for the specific request.
Choose stable, concise names and descriptions so measurements can be compared over time.
Decide whether public responses should expose the detail, or whether richer metrics belong only on authenticated or internal responses.
Keep units consistent and document the scope of each metric for your team.
Verify that the response actually contains the header; the browser cannot report metrics the server did not emit.

3. Inspect a request in browser DevTools

Open the browser’s developer tools and select the Network panel.
Reload the page or repeat the action that triggers the slow request.
Select the request whose delay you are investigating.
Inspect its response headers for Server-Timing, then examine the request’s timing breakdown.
Compare the server-reported components with browser-observed network stages and the user-visible behavior.

Chrome DevTools can show network activity and the selected request’s timing details. The exact presentation can differ across browsers and browser versions. [Chrome for Developers: Inspect network activity]

Keep the scopes separate. Browser timing describes the request in the context of client-visible network activity; Server-Timing describes selected work that the server or intermediary chose to report. Do not assume the component durations add up to the full browser interval. They can cover different work and may be measured at different points in a request path. The Server Timing design does not rely on synchronized client, server, or intermediary clocks. [W3C draft] [W3C Server Timing explainer]

4. Collect metrics with the Performance API

For browser-side analysis, the serverTiming property is available on navigation and resource performance entries. Each item exposes name, duration, and description. There are no standalone performance entries of type server-timing; the metrics are attached to the relevant navigation or resource entry. [MDN: PerformanceServerTiming]

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    for (const metric of entry.serverTiming ?? []) {
      console.log({
        entryName: entry.name,
        entryType: entry.entryType,
        metricName: metric.name,
        description: metric.description,
        durationMs: metric.duration,
      });
    }
  }
});

observer.observe({ type: "navigation", buffered: true });
observer.observe({ type: "resource", buffered: true });

This observer reads metrics exposed by response headers; it does not create server measurements. Your server must still instrument its work and emit Server-Timing. The buffered option lets the observer receive matching entries that were recorded before it started observing.

Read entries directly

const navigation = performance.getEntriesByType("navigation")[0];

if (navigation) {
  for (const metric of navigation.serverTiming ?? []) {
    console.log(metric.name, metric.description, metric.duration);
  }
}

for (const entry of performance.getEntriesByType("resource")) {
  for (const metric of entry.serverTiming ?? []) {
    console.log(entry.name, metric.name, metric.duration);
  }
}

Use navigation entries for the document request and resource entries for subresources. If your page makes many requests, filter by entry name or another application-specific rule before storing or reporting metrics.

5. Cross-origin access, privacy, and trailers

JavaScript access to PerformanceServerTiming follows same-origin restrictions. For a cross-origin resource, its response can use Timing-Allow-Origin to permit specified origins to access timing information. Confirm the response policy for the actual resource and browser you support; DevTools may show information that page scripts cannot read. Some browsers also require a secure context for the JavaScript interface. [MDN: PerformanceServerTiming] [MDN: Timing-Allow-Origin]

Server-Timing values can reveal application structure or infrastructure. Avoid sending sensitive metric names, descriptions, or measurements indiscriminately on public pages. If diagnostic detail is intended only for operators, consider limiting it to authenticated users or internal tools.

HTTP trailers are a special case: MDN notes that DevTools can display a Server-Timing trailer in the Network timing view, while Fetch cannot access HTTP trailers. Do not base a Fetch-based collection pipeline on trailer visibility. [MDN: Server-Timing header]

6. A practical diagnosis workflow

Reproduce the slow action. Identify the specific document or resource request involved rather than reasoning from an overall page impression alone.
Check whether metrics exist. Inspect the response for the header. If it is absent, add server instrumentation and response emission before expecting a metric in the browser.
Read each metric’s scope. Confirm what the name measures, where it is measured, and whether it represents a component, an intermediary, or a broader operation.
Compare with browser timing. Look for whether browser-observed delay appears in network stages or whether reported server components provide a lead for further investigation.
Follow the lead with the relevant system’s own diagnostics. For example, investigate database behavior when a measured database component is high. Treat the metric as a clue, then validate the suspected cause with appropriate server-side evidence.
Automate carefully. Collect navigation and resource entries where browser support and cross-origin policy allow it. Keep the request identity with each observation so metrics are not detached from the request they describe.

Never add component durations and present the sum as total page load time unless your instrumentation defines a complete, non-overlapping measurement that actually supports that interpretation. Server and browser clocks are not presumed synchronized, so their timestamps should not be aligned by assumption. [W3C Server Timing explainer]

7. Performance, reliability, and cost considerations

Header overhead: keep metric names and descriptions concise, and avoid an unnecessarily large set of metrics on every response. [MDN]
Measurement cost: instrumentation itself has a cost that depends on how the server measures work. Prefer measurements that answer a diagnostic question and avoid adding expensive measurement work to the request path without a reason.
Reliability: a missing or inaccessible metric is not evidence that the server did no work. Check that the server emitted it, the relevant response is being inspected, the entry type is correct, and browser origin policy permits script access.
Interpretation: metric availability and meaning depend on the server or intermediary. Server-Timing does not automatically classify every cache outcome or explain every delay.
Exposure: public diagnostics can disclose internal structure. Choose what to reveal and under what conditions.

The W3C publication available for this research is a Working Draft dated April 7, 2026, not a Recommendation; the draft may change. MDN describes the header as widely available across browsers since March 2023, while noting support details can vary. Check target browsers, particularly for the JavaScript interface’s secure-context requirements and trailer behavior. [W3C Working Draft] [MDN]

8. Troubleshooting common problems

Symptom	Likely cause	Fix
No Server-Timing row or header appears	The server or intermediary did not instrument or emit metrics, or you selected a different request.	Inspect the exact response headers and add instrumentation and header emission for the request you want to diagnose.
DevTools shows metrics, but JavaScript returns none	Cross-origin timing policy may block access; the visible information may be a trailer; or the entry may not be the one being inspected.	Check the resource’s `Timing-Allow-Origin` response policy, inspect the correct navigation or resource entry, and do not rely on Fetch to read HTTP trailers.
Cross-origin entries have no readable timing data	The resource response does not grant timing access to the page’s origin.	Configure `Timing-Allow-Origin` for the intended origin where appropriate, then verify the response in the target browser.
The observer logs no entries	Observation started after entries were recorded without buffering, the observed type is wrong, or the API is unavailable in the current browser context.	Observe both `navigation` and `resource` with `buffered: true`, check the browser’s support and secure-context requirements, and reproduce the request.
Metric durations do not match the request’s DevTools duration	The measurements cover different scopes or points in the request path; they are not necessarily additive or clock-aligned.	Document what each metric measures and compare components as diagnostic clues rather than expecting their sum to equal browser timing.
A metric is always zero, missing, or inconsistent	The instrumentation may measure the wrong boundary, fail to emit a value for some code paths, or report a component that was not run.	Review the server-side measurement and response construction on each relevant path, and define how skipped work should be represented.
Metrics expose details you do not want public	Diagnostic names, descriptions, or timings reveal internal behavior.	Reduce public detail or emit richer metrics only for authenticated users or internal tools.

9. Or skip the browser setup

If your goal is to inspect how a page looks without setting up browser automation, ScreenshotNeo is a website screenshot API and MCP server. One GET request returns a screenshot or PDF; it does not expose the page’s Server-Timing values or replace server-side performance instrumentation.

Use the ScreenshotNeo API documentation for request options and response details. This runnable cURL example captures a page as WebP:

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://stripe.com \
  -o shot.webp

Or request the same capture with Python:

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)

Or with Node.js:

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://stripe.com',
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);

const fs = await import('node:fs/promises');
await fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer()));

ScreenshotNeo removes cookie banners, popups, and chat widgets before the shot. Bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. Sign up for free and get 1,000 screenshots a month with no card.

10. FAQ

Does Server-Timing measure the request automatically?

No. The server or intermediary must measure work and emit the header.

Can I use it to identify the root cause of a slow page?

It can point to a component worth investigating, but a reported duration alone does not prove the cause of the user-visible delay.

Are the metrics a replacement for browser timing?

No. Browser timing and server-reported metrics describe different scopes and should be read together.

Does the JavaScript API work for every cross-origin resource?

No. Cross-origin access is restricted unless the response grants timing access, commonly through Timing-Allow-Origin.

Is the W3C Server Timing document final?

The cited W3C publication is a Working Draft, not a Recommendation.