服务器计时

W3C 工作草案,

关于此文档的更多细节
此版本
https://w3org.cn/TR/2026/WD-server-timing-20260407/
最新发布版本
https://w3org.cn/TR/server-timing/
编辑草案
https://w3c.github.io/server-timing/
历史版本
历史
https://w3org.cn/standards/history/server-timing/
反馈
public-web-perf@w3.org,主题行为 “[server-timing] … message topic …”(归档
GitHub
测试套件
http://w3c-test.org/server-timing/
编辑
Yoav Weiss (Shopify)
前任编辑
(Akamai)
Ilya Grigorik (Google)

摘要

本规范使服务器能够向用户代理(user agent)传达有关请求‑响应周期的性能度量。它还标准化了一套 JavaScript 接口,使应用程序能够收集、处理并依据这些度量采取行动,以优化应用交付。

关于本文档

本节描述了本文件发布时的状态。当前 W3C 出版物列表及本技术报告的最新修订版可在 W3C 标准和草案索引中找到。

本文档由 Web Performance 工作组工作草案形式发布,使用 推荐轨道。以工作草案形式发布并不表示得到 W3C 及其成员的认可。

这是一个草案文档,可能随时会被其他文档更新、替换或废弃。将其作为进展中的工作之外的任何内容进行引用是不恰当的。

GitHub Issues 是讨论本规范的首选渠道。

本文件受 2025 年 8 月 18 日 W3C 流程文件的管辖。

本文档由遵守 W3C 专利政策 的小组制作。W3C 维护一份 与小组交付成果相关的专利披露公开列表;该页面还包括披露专利的说明。实际了解某项专利且认为该专利包含 必要权利要求 的个人必须按照 W3C 专利政策第 6 节披露信息。

1. 引言

本节是非规范性的。

准确地测量 Web 应用的性能特性是加速 Web 应用的关键环节。[NAVIGATION-TIMING][RESOURCE-TIMING] 为文档及其资源提供了详细的请求计时信息,包括请求发起时间以及协商连接和接收响应过程中的各项里程碑。然而,尽管用户代理能够观察到请求的计时数据,却无法洞悉请求‑响应周期中某些阶段耗时的原因——例如请求是如何路由的、服务器内部的耗时分布等。

本规范引入了 PerformanceServerTiming 接口,使服务器能够向用户代理传达请求‑响应周期的性能度量,并提供 JavaScript 接口,使应用程序能够收集、处理并依据这些度量进行优化。

2. Server-Timing 头字段

Server-Timing 头字段 用于在给定的请求‑响应周期中传递一个或多个度量及其描述。[RFC5234] 中的 ABNF(增强巴克斯‑诺尔形式)语法如下:

Server-Timing             = #server-timing-metric
server-timing-metric      = metric-name *( OWS ";" OWS server-timing-param )
metric-name               = token
server-timing-param       = server-timing-param-name OWS "=" OWS server-timing-param-value
server-timing-param-name  = token
server-timing-param-value = token / quoted-string

有关 #*OWStokenquoted-string 的定义,请参见 [RFC7230]

响应可以包含多个拥有相同 metric-nameserver-timing-metric 条目,用户代理 **必须** 处理并公开所有这些条目。

用户代理 **可以** 以任意顺序呈现提供的度量——即 HTTP 头字段中度量的顺序并不重要。

此头字段采用可扩展的语法,以便将来添加参数。若用户代理未识别响应中 Server-Timing 头字段的特定 server-timing-param-name,则 **必须** 忽略这些令牌并继续处理,而不是报告错误。

为避免任何可能的歧义,单个 server-timing-param-name **不应** 在同一 server-timing-metric 中出现多次。如果同一参数名出现多次,只应使用第一次出现的值,即使该 server-timing-param 不完整或无效。所有后续出现 **必须** 被忽略,且不产生错误或改变对 server-timing-metric 的处理方式。这是唯一一次参数顺序被视为重要的情况。

用户代理 **必须** 忽略位于 server-timing-param-value 之后、下一个 server-timing-param 之前以及当前 server-timing-metric 结束之前的多余字符。

用户代理 **必须** 忽略位于 metric-name 之后、首个 server-timing-param 之前以及下一个 server-timing-metric 之前的多余字符。

本规范为服务器‑计时参数定义了参数名 “dur”(对应 duration)和 “desc”(对应 description),两者均为可选。

解析 server-timing 头字段,给定字符串 field

  1. position 为一个位置变量,最初指向 field 的开头。

  2. name 为从 field收集一系列码点的结果,收集过程在遇到 U+003B (;) 前停止,起始位置为 position

  3. 去除 name 两端的 ASCII 空白字符。

  4. 如果 name 为空字符串,返回 null

  5. 创建一个新的 PerformanceServerTiming 实例 metric,其度量名称name

  6. params 为一个空的有序映射

  7. position 未到达 field 末尾时

    1. position 前移 1。

    2. paramName 为从 field收集一系列码点的结果,收集过程在遇到 U+003D (=) 前停止,起始位置为 position

    3. 去除 paramName 两端的 ASCII 空白字符。

    4. 如果 paramName 为空字符串或 params[paramName] 已存在继续下一次循环。

    5. position 前移 1。

    6. paramValue 为空字符串。

    7. 跳过 field 中位于 position 的 ASCII 空白字符。

    8. 如果 position 位置的码点 为 U+0022 ("),则

      1. paramValue 设为从 fieldpositionextract-value 标志 打开的收集 HTTP 引号字符串 的结果。

      2. 收集一系列码点,直到遇到 U+003B (;) 为止,起始位置为 position。收集结果不予使用。

    9. 否则

      1. rawParamValue 为从 field 中收集、直至遇到 U+003B (;) 为止的码点序列的结果,起始位置为 position

      2. paramValue 为对 rawParamValue 进行去除空白后的结果。

  8. 设置 metricparamsparams

  9. 返回 metric

3. PerformanceServerTiming 接口

[Exposed=(Window,Worker)]
interface PerformanceServerTiming {
  readonly attribute DOMString name;
  readonly attribute DOMHighResTimeStamp duration;
  readonly attribute DOMString description;
  [Default] object toJSON();
};

当调用 toJSON 时,执行 [WEBIDL] 中的默认 toJSON 步骤

3.1. name 属性

name 的 getter 步骤返回 this度量名称

3.2. duration 属性

duration 的 getter 步骤如下:

  1. 如果 thisparams["dur"] 不存在,返回 0。

  2. dur 为对 thisparams["dur"] 使用浮点数值解析规则进行解析的结果。

  3. 如果 dur 为错误,返回 0;否则返回 dur

由于 duration 是一个 DOMHighResTimeStamp,它通常表示以毫秒为单位的持续时间。由于在实践中难以强制执行此约定,duration 可以使用任意时间单位,而推荐使用毫秒作为单位。

3.3. description 属性

description 的 getter 步骤返回 thisparams["desc"](若 存在),否则返回空字符串。

一个 PerformanceServerTiming 关联有一个字符串 度量名称,初始为空字符串。

一个 PerformanceServerTiming 关联有一个有序映射 params,初始为空。

3.4. PerformanceResourceTiming 接口的扩展

PerformanceResourceTiming 接口(本规范对其作部分扩展)定义于 [RESOURCE-TIMING]

[Exposed=(Window,Worker)]
partial interface PerformanceResourceTiming {
  readonly attribute FrozenArray<PerformanceServerTiming> serverTiming;
};

3.5. serverTiming 属性

serverTiming 的 getter 步骤如下:

  1. entries 为一个新的列表

  2. 遍历 fieldthis时序信息server‑timing 头部集合 中的每个 field

    1. metric解析 field 的结果。

    2. 如果 metric 不为 null,将其追加entries

  3. 返回 entries

4. 隐私与安全

本节是非规范性的。

本规范中定义的接口会向任何包含了宣告 Server Timing 度量的资源的网页暴露可能敏感的应用与基础设施信息。因此,默认情况下,PerformanceServerTiming 接口的访问受到同源策略的限制。资源提供者可以通过添加 Timing-Allow-Origin HTTP 响应头(如[RESOURCE-TIMING] 中所定义)来显式允许服务器计时信息被访问,指定哪些域可访问服务器度量;但用户代理 **仍可** 保持同源策略的限制。

除了使用 Timing-Allow-Origin 响应头之外,服务器还可以使用相应的逻辑控制返回哪些度量、何时返回以及返回给谁——例如,仅向已正确认证的用户提供特定度量,对其他所有用户则不返回任何信息。

5. IANA 考量

应当使用以下登记([RFC3864])更新永久消息头字段注册表:

5.1. Server-Timing 头字段

头字段名称
Server-Timing
适用协议
http
状态
标准
作者/变更控制者
W3C
规范文档
本规范(参见 Server-Timing 头字段

6. 示例

本节是非规范性的。
> GET /resource HTTP/1.1
> Host: example.com

< HTTP/1.1 200 OK
< Server-Timing: miss, db;dur=53, app;dur=47.2
< Server-Timing: customView, dc;desc=atl
< Server-Timing: cache;desc="Cache Read";dur=23.2
< Trailer: Server-Timing
< (... snip response body ...)
< Server-Timing: total;dur=123.4
名称持续时间 (Duration)描述
miss
db53
app47.2
customView
dc atl
缓存23.2 Cache Read
全序123.4

上述头字段传递了六个不同的度量,展示了服务器向用户代理传递数据的所有可能方式:仅度量名称、度量加数值、度量加数值与描述、以及度量加描述。例如,上面的度量可用于指示针对 example.com/resource.jpg 的抓取:

  1. 出现了缓存未命中。
  2. 请求被路由至 “atl” 数据中心(“dc”)。
  3. 数据库(“db”)耗时 53 ms。
  4. 一次缓存读取耗时 23.2 ms。
  5. 应用服务器(“app”)耗时 47.2 ms 处理 “customView” 模板或函数。
  6. 服务器端的整个请求‑响应周期耗时 123.4 ms,此值在响应结束时记录并通过 trailer 字段传递。

应用程序可通过提供的 JavaScript 接口收集、处理并依据这些度量采取相应操作。

// serverTiming entries can live on 'navigation' and 'resource' entries
for (const entryType of ['navigation', 'resource']) {
  for (const {name: url, serverTiming} of performance.getEntriesByType(entryType)) {
    // iterate over the serverTiming array
    for (const {name, duration, description} of serverTiming) {
      // we only care about "slow" ones
      if (duration > 200) {
        console.info('Slow server-timing entry =',
          JSON.stringify({url, entryType, name, duration, description}, null, 2))
      }
    }
  }
}

7. 使用场景

本节是非规范性的。

7.1. 开发者工具中的 Server Timing

服务器处理时间往往占总请求时间的相当大比例。例如,动态响应可能需要一次或多次数据库查询、缓存查找、API 调用、数据处理与渲染等步骤。即便是静态响应,也可能因服务器过载、缓存慢或其他原因被延迟。

目前,用户代理的开发者工具只能显示请求的发起时间以及收到的首字节和末字节的时间。然而,它们无法展示服务器端的耗时分布,这导致开发者难以及时判断服务器是否存在性能瓶颈以及瓶颈位于哪个组件。为了解答此类问题,开发者只能依赖多种手段:检查服务器日志、在响应中嵌入性能数据(若可能)、使用外部工具等。这使得定位与诊断性能瓶颈既困难又在很多情况下不切实际。

Server Timing 定义了一套标准机制,使服务器能够将相关性能度量发送给客户端,并允许客户端在开发者工具中直接展示这些度量——例如,请求可以被标注上服务器发送的度量,以便洞察生成响应时的时间消耗位置与原因。

7.2. 用于自动化分析的 Server Timing

除了在开发者工具中展示服务器端的性能度量之外,标准的 JavaScript 接口还能让分析工具自动收集、处理、上报并聚合这些度量,以用于运营及性能分析。

7.3. 测量请求路由性能

Server Timing 使源服务器能够报告请求在处理期间时间的消耗位置与方式。但同一请求与响应也可能经由一个或多个代理(如缓存服务器、负载均衡器等)转发,每个代理都可能引入自身的延迟,并希望提供关于时间消耗的性能度量。

例如,CDN 边缘节点可能需要报告所使用的数据中心、资源是否命中缓存,以及从缓存或源服务器检索响应所耗时间。此外,其他代理也可能进行相同的报告,从而实现对请求路由全过程以及时间消耗位置的完整可视化。

同理,当 Service Worker 处于激活状态时,部分或全部导航与资源请求可能经由它转发。实际上,激活的 Service Worker 相当于一个本地代理,能够重新路由请求、提供缓存响应、合成响应等。因此,Server Timing 使 Service Worker 能够报告自定义的性能度量,说明请求是如何被处理的:是否从服务器抓取、是否从本地缓存提供、相关处理步骤的耗时等。

8. 致谢

本节是非规范性的。

本文档重用了来自 [NAVIGATION-TIMING][RESOURCE-TIMING][PERFORMANCE-TIMELINE-2][RFC6797] 规范的文本,遵循这些规范的许可协议进行使用。

一致性

文档约定

一致性要求通过描述性断言和 RFC 2119 术语相结合来表达。本文档规范性部分中的关键词“MUST”(必须)、“MUST NOT”(不得)、“REQUIRED”(必需)、“SHALL”(应)、“SHALL NOT”(不应)、“SHOULD”(推荐)、“SHOULD NOT”(不推荐)、“RECOMMENDED”(建议)、“MAY”(可以)和“OPTIONAL”(可选)应按照 RFC 2119 中的描述进行解释。然而,为了可读性,这些词在本文档中不以全大写形式出现。

本规范的所有文本均为规范性文本,明确标记为非规范性的部分、示例和注释除外。 [RFC2119]

本规范中的示例均以“例如”一词引入,或者通过 class="example" 与规范性文本隔开,如下所示

这是一个说明性示例。

说明性注释以“Note”一词开头,并使用 class="note" 与规范性文本隔开,如下所示

注意,这是一个说明性注释。

一致性算法

作为算法一部分的祈使语气要求(例如“去除任何前导空格字符”或“返回 false 并中止这些步骤”)应根据引入算法时使用的关键词(“必须”、“应该”、“可以”等)进行解释。

以算法或具体步骤表述的一致性要求可以用任何方式实现,只要最终结果等效即可。特别地,本规范定义的算法旨在易于理解,而不旨在提高性能。鼓励实现者进行优化。

索引

本规范定义的术语

通过引用定义的术语

引用

规范性引用

[FETCH]
Anne van Kesteren. 提取标准 (Fetch Standard). 生活标准. URL: https://fetch.spec.whatwg.org/
[HR-TIME-3]
Yoav Weiss. 高分辨率时间. 2026年3月24日. WD. URL: https://w3org.cn/TR/hr-time-3/
[HTML]
Anne van Kesteren; et al. HTML 标准. Living Standard. URL: https://html.whatwg.cn/multipage/
[INFRA]
Anne van Kesteren; Domenic Denicola. Infra 标准. Living Standard. URL: https://infra.spec.whatwg.org/
[RESOURCE-TIMING]
Yoav Weiss; Noam Rosenthal. Resource Timing. 23 March 2026. CRD. URL: https://w3org.cn/TR/resource-timing/
[RFC2119]
S. Bradner. RFC 中用于指示要求级别的关键词. 1997年3月. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
[RFC3864]
G. Klyne; M. Nottingham; J. Mogul. Registration Procedures for Message Header Fields. September 2004. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc3864
[RFC5234]
D. Crocker, Ed.; P. Overell. 语法规范的增强 BNF: ABNF. 2008 年 1 月. 互联网标准. URL: https://www.rfc-editor.org/rfc/rfc5234
[RFC7230]
R. Fielding, Ed.; J. Reschke, Ed.. Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7230.html
[WEBIDL]
Edgar Chen; Timothy Gu. Web IDL 标准. Living Standard. URL: https://webidl.spec.whatwg.org/

参考资料

[NAVIGATION‑TIMING]
Zhiheng Wang. Navigation Timing. 17 December 2012. REC. URL: https://w3org.cn/TR/navigation-timing/
[PERFORMANCE-TIMELINE-2]
Nicolas Pena Moreno. Performance Timeline. 21 May 2025. CRD. URL: https://w3org.cn/TR/performance-timeline/
[RFC6797]
J. Hodges; C. Jackson; A. Barth. HTTP Strict Transport Security (HSTS). November 2012. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc6797

IDL 索引

[Exposed=(Window,Worker)]
interface PerformanceServerTiming {
  readonly attribute DOMString name;
  readonly attribute DOMHighResTimeStamp duration;
  readonly attribute DOMString description;
  [Default] object toJSON();
};

[Exposed=(Window,Worker)]
partial interface PerformanceResourceTiming {
  readonly attribute FrozenArray<PerformanceServerTiming> serverTiming;
};

MDN

PerformanceResourceTiming/serverTiming

在所有当前引擎中。

Firefox61+Safari16.4+Chrome65+
Opera?Edge79+
Edge (旧版)?IE
Firefox for Android?iOS Safari?Chrome for Android?Android WebView?Samsung Internet?Opera Mobile?
MDN

PerformanceServerTiming/description

在所有当前引擎中。

Firefox61+Safari16.4+Chrome65+
Opera?Edge79+
Edge (旧版)?IE
Firefox for Android?iOS Safari?Chrome for Android?Android WebView?Samsung Internet?Opera Mobile?
MDN

PerformanceServerTiming/duration

在所有当前引擎中。

Firefox61+Safari16.4+Chrome65+
Opera?Edge79+
Edge (旧版)?IE
Firefox for Android?iOS Safari?Chrome for Android?Android WebView?Samsung Internet?Opera Mobile?
MDN

PerformanceServerTiming/name

在所有当前引擎中。

Firefox61+Safari16.4+Chrome65+
Opera?Edge79+
Edge (旧版)?IE
Firefox for Android?iOS Safari?Chrome for Android?Android WebView?Samsung Internet?Opera Mobile?
MDN

PerformanceServerTiming/toJSON

在所有当前引擎中。

Firefox61+Safari16.4+Chrome65+
Opera?Edge79+
Edge (旧版)?IE
Firefox for Android?iOS Safari?Chrome for Android?Android WebView?Samsung Internet?Opera Mobile?
MDN

PerformanceServerTiming

在所有当前引擎中。

Firefox61+Safari16.4+Chrome65+
Opera?Edge79+
Edge (旧版)?IE
Firefox for Android?iOS Safari?Chrome for Android?Android WebView?Samsung Internet?Opera Mobile?
MDN

Headers/Server-Timing

Firefox61+Safari?Chrome65+
Opera?Edge79+
Edge (旧版)IE
Firefox for Android?iOS Safari?Chrome for Android?Android WebView?Samsung Internet?Opera Mobile?