Server-Timing Header: See Where Your Backend Loses Time

Short answer: Server-Timing is an HTTP response header in which your server reports how long it spent on each part of a request, for example the database, the cache and the template. Browsers show these numbers in the developer tools next to the request, and scripts can read them for real-user monitoring. It turns a vague “the server is slow” into “the database query took 600 ms”. Add it in your application or proxy, keep the names short, and avoid exposing sensitive detail to every visitor.

Why server response time needs a breakdown

Speed tools tell you how long the server took before the first byte arrived. That number, time to first byte, often decides whether a page can be fast at all. Our guide to reducing server response time explains why it matters and what usually causes it.

But a single number does not say where the time went. A one-second response can be caused by a slow database query, a call to an external API, an expired cache, a heavy plugin, or a server that is simply overloaded. Without a breakdown, people guess, and guessing often leads to the wrong fix, such as buying a bigger server for a problem that one missing database index would solve.

Server-Timing gives you that breakdown in the place where you already look: the network panel of the browser.

What the header looks like

The header contains one or more metrics, separated by commas. Each metric has a name, an optional duration in milliseconds and an optional description:

Server-Timing: db;dur=212.4, cache;desc="Page cache miss", app;dur=96.1, total;dur=340

db;dur=212.4 says the database work took about 212 milliseconds.
cache;desc="Page cache miss" carries information without a duration.
app;dur=96.1 is the time spent in your own code and templates.
total;dur=340 is the whole server-side time for the request.

The names are up to you. Short, consistent names are easiest to read and compare. The header is defined in a W3C specification and documented on MDN.

How to read it in the browser

In Chrome or Edge:

Open the developer tools and go to the Network tab.
Reload the page and click the main document request, usually the first one.
Open the Timing tab. Below the usual phases, such as waiting for the server, you will see a “Server Timing” section with your metrics as bars and numbers.

Firefox shows the same data in its own network panel timing view. Compare a request with a warm cache to one with a cold cache, and a fast page to a slow one. Within minutes you see whether the problem lives in the database, in external calls or in the application.

The data is also available to JavaScript through the Performance API, in the serverTiming list of navigation and resource timing entries. Real-user monitoring tools can collect it, so you see the breakdown for real visitors, not just for your own tests. Our guide on reading a waterfall chart shows where server time fits among all the other phases of a page load.

Adding Server-Timing to your site

You add the header where the work happens, in the application, or at a proxy or CDN that knows about caching.

In PHP, measure with hrtime() or microtime(true) around the parts you care about and send the header before any output:

$t = microtime(true);
$rows = run_queries();
$db = (microtime(true) - $t) * 1000;
header(sprintf('Server-Timing: db;dur=%.1f', $db));

In real code you collect several measurements during the request and send them together, or use output buffering so headers can still be sent after the work is done.

In frameworks, middleware is the natural place. Many frameworks and performance packages for Node.js, Python, Ruby and PHP can add the header for database time, view rendering and total request time with little setup.

At the edge, some CDNs and reverse proxies add their own Server-Timing metrics, such as whether the response came from cache. If your server and your CDN both add the header, the browser shows both sets of metrics.

For cross-origin resources, such as an API on another domain, the browser only exposes the timing data to scripts if the response also sends a suitable Timing-Allow-Origin header.

What to measure first

Start with a few metrics that answer the most common questions:

Total server time, so you can compare it with what the browser sees as waiting time. A big gap points to the network, TLS or queueing before your code ran.
Database time and query count. Slow pages with hundreds of queries are a classic sign of a plugin or theme problem. Our guide to finding slow WordPress plugins helps with the next step.
Cache status, hit or miss, for the page cache and the object cache. A slow page that is always a miss needs page caching fixed before anything else.
External calls, such as payment, shipping, CRM or currency APIs. One slow third-party API can add seconds to every page that calls it.
Template or render time, to separate data loading from producing HTML.

Add more metrics only when a question needs them. A header with thirty entries is hard to read and adds bytes to every response.

Security and privacy: what not to expose

Everything in the header is visible to anyone who loads the page. Be careful:

Do not include SQL queries, file paths, user names, internal host names or software versions in descriptions.
Detailed timings can help attackers compare responses, for example to tell whether a user account exists. Keep public metrics coarse, such as total and cache status.
Show detailed metrics only to logged-in administrators, to requests with a secret debug header, or on a staging server.

The same rule applies as for other headers that reveal internals. Our guide to hiding the server software version explains why less detail for outsiders is safer.

Common findings and what they mean

What you see	Likely cause	Next step
High database time on every page	Missing indexes, heavy queries, a bloated options table	Find the slow queries and fix or cache them
Fast when cached, slow on a miss	Cache expires too often or is bypassed by cookies	Review cache rules and lifetimes
One external call dominates	Slow third-party API called during page load	Cache the result or call it in the background
Small app and database times, high browser wait	Network distance, TLS setup or server queueing	Check server location, CDN and capacity
Times vary wildly between requests	Overloaded shared server or noisy neighbours	Compare at quiet hours; consider better hosting

Using Server-Timing in a performance investigation

The header is most useful when you follow a short, repeatable routine instead of looking at single requests at random:

Pick a few representative pages. The home page, a typical article or product page, a category or search page, and the cart or account page if you have one. Slow pages are often the ones that do the most work per request.
Measure each page twice. Once with a cold cache, for example right after clearing it, and once warm. The difference shows how much your cache saves and how slow the uncached path really is.
Write down the biggest metric. Fix only that first. If database time is 70 percent of the total, a faster template engine will not help.
Measure again after the change. Compare the same metrics on the same pages, so you know the fix worked and did not just move the time elsewhere.
Keep the coarse metrics running. Total time and cache status are cheap to send and make the next investigation much faster.

Logged-in users usually bypass the page cache, so their pages show the full uncached cost. If your editors or customers complain that the site is slow while anonymous speed tests look fine, measure while logged in.

How Site AI Audit helps

Site AI Audit measures from the outside. It reports how long your server takes to respond, lists the pages that took over two seconds to load during the crawl, checks whether text files are compressed, and includes Google’s mobile PageSpeed score with LCP, CLS and INP. When those findings point to a slow backend, Server-Timing is the tool that shows you which part to fix. You can run a free check, and the pricing page lists plans with re-checks after every fix.

The bottom line

Server-Timing splits a slow server response into parts you can act on. Add a few metrics for total time, database, cache status and external calls, read them in the browser’s network panel, and fix the biggest part first. Keep public metrics coarse and show detailed ones only to administrators.

FAQ

Does the Server-Timing header make my site faster?

No. It only measures and reports. Its value is that it shows where server time goes, so you can fix the right thing instead of guessing.

Where do I see Server-Timing values?

In the browser’s developer tools: open the Network tab, select the request and open the Timing view. Scripts can also read them through the Performance API.

Is it safe to send Server-Timing to all visitors?

Coarse metrics such as total time and cache status are usually fine. Avoid detailed descriptions, queries, paths or versions, and show detailed metrics only to administrators.

Does Server-Timing affect SEO?

Not directly. Search engines do not rank on this header. It helps you reduce server response time, which improves loading speed for visitors.

Why are some metrics missing for API calls to another domain?

For cross-origin responses, browsers hide timing details from scripts unless the server sends a Timing-Allow-Origin header that permits your site to read them.