Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://developer.cdn.mozilla.net/en-US/docs/Web/HTTP/Reference/Headers/Server-Timing below:

Server-Timing header - HTTP | MDN

Baseline 2023 *

Newly available

The HTTP Server-Timing response header communicates one or more performance metrics about the request-response cycle to the user agent. It is used to surface backend server timing metrics (for example, database read/write, CPU time, file system access, etc.) in the developer tools in the user's browser or in the PerformanceServerTiming interface.

// A single metric
Server-Timing: <timing-metric>

// Multiple metrics as a comma-separated list
Server-Timing: <timing-metric>, …, <timing-metricN>

A <timing-metric> has a name, and may include an optional duration and an optional description. For example:

// A metric with a name only
Server-Timing: missedCache

// A metric with a duration
Server-Timing: cpu;dur=2.4

// A metric with a description and duration
Server-Timing: cache;desc="Cache Read";dur=23.2

// Two metrics with duration values
Server-Timing: db;dur=53, app;dur=47.2

<timing-metric>

A comma-separated list of one or more metrics with the following components separated by semi-colons:

<name>

A name token (no spaces or special characters) for the metric that is implementation-specific or defined by the server, like cacheHit.

<duration> Optional

A duration as the string dur, followed by =, followed by a value, like dur=23.2.

<description> Optional

A description as the string desc, followed by =, followed by a value as a token or a quoted string, like desc=prod or desc="DB lookup".

Names and descriptions should be kept as short as possible (for example, use abbreviations and omit optional values) to minimize HTTP data overhead.

The Server-Timing header may expose potentially sensitive application and infrastructure information. Decide which metrics to send, when to send them, and who should see them based on the use case. For example, you may decide to only show metrics to authenticated users and nothing on public responses.

In addition to having Server-Timing header metrics appear in the developer tools of the browser, the PerformanceServerTiming interface enables tools to automatically collect and process metrics from JavaScript. This interface is restricted to the same origin, but you can use the Timing-Allow-Origin header to specify the domains that are allowed to access the server metrics. The interface is only available in secure contexts (HTTPS) in some browsers.

The components of the Server-Timing header map to the PerformanceServerTiming properties as follows:

• "name" -> PerformanceServerTiming.name
• "dur" -> PerformanceServerTiming.duration
• "desc" -> PerformanceServerTiming.description

The following response includes a metric custom-metric with a duration of 123.45 milliseconds, and a description of "My custom metric":

Server-Timing: custom-metric;dur=123.45;desc="My custom metric"

In the following response, the Trailer header is used to indicate that a Server-Timing header will follow the response body. A metric custom-metric with a duration of 123.4 milliseconds is sent.

HTTP/1.1 200 OK
Transfer-Encoding: chunked
Trailer: Server-Timing

--- response body ---
Server-Timing: custom-metric;dur=123.4

Warning: Only the browser's DevTools can use the Server-Timing header as a HTTP trailer to display information in the Network -> Timings tab. The Fetch API cannot access HTTP trailers. See Browser compatibility for more information.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4