サーバタイミング

W3C作業草案,

この文書の詳細
このバージョン:
https://www.w3.org/TR/2026/WD-server-timing-20260316/
最新公開バージョン:
https://www.w3.org/TR/server-timing/
編集者草案:
https://w3c.github.io/server-timing/
以前のバージョン:
履歴:
https://www.w3.org/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)

概要

本仕様は、サーバがリクエスト・レスポンスサイクルに関するパフォーマンス指標をユーザーエージェントに伝達できるようにします。 また、アプリケーションがこれらの指標を収集、処理、活用してアプリケーション配信を最適化するためのJavaScriptインターフェイスも標準化します。

この文書のステータス

このセクションは、本書の発行時点でのステータスについて説明します。 最新のW3C出版物一覧およびこの技術レポートの最新版は W3C標準・草案インデックスで確認できます。

この文書は Web Performance Working Group によって 作業草案として Recommendation track を用いて公開されました。 作業草案としての公開は W3C およびその会員による承認を意味するものではありません。

この文書は草案であり、時々更新されたり、他の文書に置き換えられたり廃止される場合があります。 この文書を進行中の作業以外として引用するのは適切ではありません。

GitHub Issues にてこの仕様に関する議論を推奨します。

この文書は 2025年8月18日 W3Cプロセス文書 に従って管理されています。

この文書は W3C特許ポリシー の下で運用するグループによって作成されました。 W3Cはグループの成果物に関連して行われた 公開特許申告リスト を管理しています。 そのページには特許申告方法の案内もあります。 個人が特許に関する実際の知識を持ち、その特許が Essential Claim(s) を含むと考える場合は、 W3C特許ポリシー第6節 に従って情報を公開しなければなりません。

1. 導入

このセクションは非規範的です。

Webアプリケーションのパフォーマンス特性を正確に測定することは、Webアプリケーションを高速化する上で重要な側面です。 [NAVIGATION-TIMING][RESOURCE-TIMING] は ドキュメントやそのリソースの詳細なリクエストタイミング情報(リクエスト開始時刻や、接続確立・レスポンス受信に至る様々なマイルストーンなど)を提供します。 しかし、ユーザーエージェントはリクエストのタイミングデータを観測できても、 リクエスト応答サイクルのある段階がなぜどれだけ時間がかかったかについては把握できません―例えば、リクエストがどのようにルーティングされたか、 サーバ上のどこで時間を消費したのかなどです。

本仕様は PerformanceServerTiming インターフェースを導入します。 これにより、サーバはリクエスト応答サイクルのパフォーマンス指標をユーザーエージェントに伝達でき、アプリケーションはその指標を収集・処理・活用して配信最適化を行うJavaScriptインターフェースを利用できます。

2. Server-Timingヘッダー・フィールド

Server-Timingヘッダーフィールド は、指定されたリクエスト応答サイクルに関する1つまたは複数の指標と説明の伝達に使われます。 [RFC5234] に基づく Server-Timingヘッダーフィールド の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

[RFC7230]#, *, OWS, token, quoted-string の定義も参照してください。

レスポンスには同じ metric-name を持つ server-timing-metric が複数含まれる可能性があり、ユーザーエージェントは全てのエントリを処理・公開しなければなりません。

ユーザーエージェントは、提供された指標を任意の順序で表示してもよく、HTTPヘッダーフィールド内の指標順序は重要ではありません。

このヘッダーフィールドは、将来的なパラメータ追加に対応できる拡張可能な構文として定義されています。レスポンスのServer-Timingヘッダーフィールド内で特定の server-timing-param-name をユーザーエージェントが認識しない場合は、そのトークンを無視して処理を継続し、エラー通知は行いません。

曖昧さを避けるため、各 server-timing-param-nameserver-timing-metric 内で複数回出現しないようにするべきです。複数回指定された場合、最初のもののみ考慮され、たとえ server-timing-param が不完全・不正でも次以降は一切無視し、エラー通知や処理変更もしません。パラメータ順序が重要となる唯一のケースです。

ユーザーエージェントは server-timing-param-value の後、次の server-timing-paramserver-timing-metric の前までに現れる不要な文字を無視しなければなりません。

ユーザーエージェントは metric-name の後、初めの server-timing-param の前や次の server-timing-metric の前までに現れる不要な文字を無視しなければなりません。

本仕様は server-timing-param-name で "dur" を duration, "desc" を description として定義します。どちらもオプションです。

Server-Timingヘッダーフィールドを解析する 手順:文字列 field を受け取る。

  1. position位置変数として field の先頭を指す。

  2. nameコードポイント列収集field から U+003B(;) でないものを position指定で取得する。

  3. 先頭と末尾のASCII空白除去name に実行。

  4. name が空文字列なら null を返す。

  5. metric を新しい PerformanceServerTiming として生成し、その metric namename である。

  6. params を空の 順序付きマップにする。

  7. positionfield の末尾でない間:

    1. position を1進める。

    2. paramNameコードポイント列収集field から U+003D(=)でないものを position指定で取得。

    3. 先頭と末尾のASCII空白除去paramName に実行。

    4. paramName が空文字列または params[paramName] が 存在する場合、continue

    5. position を1進める。

    6. paramValue を空文字列にする。

    7. ASCII空白スキップfieldposition で実行。

    8. positionfield 内の コードポイント が U+0022(") なら:

      1. paramValueHTTP引用文字列収集(field, position, extract-valueフラグ指定)の結果にする。

      2. コードポイント列収集field から U+003B(;)でないものを position指定で取得。結果は使わない。

    9. それ以外の場合:

      1. rawParamValueコードポイント列収集field から U+003B(;)でないものを position指定で取得。

      2. paramValuerawParamValue の先頭末尾ASCII空白除去の結果にする。

  8. metric の params を params に設定

  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]default toJSON steps を実行する。

3.1. name 属性

name のゲッター手順は、thisメトリック名 を返すことです。

3.2. duration 属性

duration のゲッター手順は、次の処理を行います:

  1. thisparams["dur"] が 存在しない場合は、0 を返します。

  2. dur を、thisparams["dur"] を 浮動小数点数値の解析ルールに従って解析した結果とします。

  3. dur がエラーの場合、0 を返し、そうでなければ dur を返します。

durationDOMHighResTimeStamp なので、通常はミリ秒単位の 継続時間 を表します。 実際には強制力はありませんが、duration は任意の時間単位を表すことができ、ミリ秒単位の 継続時間 を推奨します。

3.3. description 属性

description のゲッター手順は、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 のゲッター手順は次の通りです:

  1. entries を新しい リストとします。

  2. fieldthistiming infoserver-timing headers に対して:

    1. metricサーバタイミングヘッダーフィールドの解析 の結果とします。

    2. metric が null でなければ、追加 metricentries にします。

  3. entries を返します。

4. プライバシーとセキュリティ

このセクションは非規範的です。

本仕様で定義されるインターフェースは、サーバタイミング指標を通知したリソースを組み込んだウェブページに対して、アプリケーションやインフラの秘匿情報を公開する可能性があります。 このため、PerformanceServerTiming インターフェースへのアクセスは既定で 同一オリジンポリシーにより制限されています。 リソース提供者は [RESOURCE-TIMING] で定義された Timing-Allow-Origin HTTPレスポンスヘッダーを追加することで サーバ指標へのアクセス許可するドメインを明示的に指定できますが、ユーザーエージェントは引き続き 同一オリジン ポリシー制限を維持してもよいです。

Timing-Allow-Origin HTTPレスポンスヘッダーに加え、サーバは返却する指標の種類・タイミング・対象ユーザーを制御する論理も利用できます。 例えば、正規認証されたユーザーにのみ指標を返し、その他には何も返さないという運用も可能です。

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
名前 時間 説明
miss
db 53
app 47.2
customView
dc atl
cache 23.2 Cache Read
total 123.4

上記ヘッダーフィールドは、サーバがユーザーエージェントへデータ伝達するあらゆるパターン(指標名のみ、値付指標、値+説明付指標、説明付指標)の6つの指標例を示しています。 例えば example.com/resource.jpg の取得の場合:

  1. キャッシュミスが発生した
  2. リクエストが "atl" データセンター("dc")経由でルートされた
  3. データベース("db")処理時間が53msだった
  4. キャッシュリードは23.2ms
  5. アプリケーションサーバ("app")による "customView" テンプレートまたは関数処理は47.2ms
  6. サーバ上のリクエスト応答サイクル全体では123.4msが掛かり、これはレスポンス末尾のトレーラーフィールドで通知される

アプリケーションは提供されたJavaScriptインターフェイスを使って、これらの指標を収集・処理・活用できます:

// serverTiming のエントリは 'navigation' および 'resource' エントリに存在し得ます
for (const entryType of ['navigation', 'resource']) {
  for (const {name: url, serverTiming} of performance.getEntriesByType(entryType)) {
    // serverTiming 配列を走査
    for (const {name, duration, description} of serverTiming) {
      // "遅い"ものだけ考慮
      if (duration > 200) {
        console.info('遅い server-timing エントリ =',
          JSON.stringify({url, entryType, name, duration, description}, null, 2))
      }
    }
  }
}

7. ユースケース

このセクションは非規範的です。

7.1. 開発者ツールでのサーバタイミング

サーバ処理時間は、リクエスト全体の時間の主要な部分を占めることがあります。 例として、動的なレスポンスでは複数回のデータベースクエリやキャッシュ検索、API呼び出し、関連データの処理やレスポンスの描画などが必要となる場合があります。同様に、静的レスポンスであっても、サーバの過負荷やキャッシュの遅延、その他の理由によって遅くなることがあります。

現在、ユーザーエージェントの開発者ツールではリクエスト開始・レスポンスの最初および最後のバイト受信時刻は表示できますが、サーバ内のどこでどう時間を費やしたかの可視性はありません。そのため、開発者はサーバのパフォーマンスボトルネックや構成要素特定が困難です。これを知るには、サーバログの確認、レスポンス内へのパフォーマンスデータ埋め込み(可能なら)、外部ツール利用など異なる手法が必要になり、診断が難しく非実用的な場合も多いです。

Server Timingは、サーバがクライアントへ関連パフォーマンス指標を伝達し、クライアントで開発者ツールへ直接表示する標準機構を定義します―例えばリクエストへサーバ送信指標の注釈を付与することで、レスポンス生成時の時間消費箇所への洞察が得られます。

7.2. 自動分析のためのサーバタイミング

開発者ツールでサーバ送信パフォーマンス指標を表示するだけでなく、標準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]

本仕様の例は「for example」で始まるか、 もしくは class="example" で規範テキストから区別されています。 例えば次のようになります:

これは情報的な例です。

情報的注記は「Note」で始まり、class="note" によって規範テキストから区別されています。 例えば次のようになります:

Note, これは情報的注記です。

適合アルゴリズム

アルゴリズムの一部として命令形で表現される要件(例: "先頭の空白文字を除去する" や "falseを返してこの手順を中断する")は、 アルゴリズム導入部分で使われているキーワード("must", "should", "may" 等)と同じ意味で解釈されます。

アルゴリズムや具体的手順として表現された適合性要件は、その結果が同等である限り、任意の方法で実装可能です。 特に、本仕様で定義されるアルゴリズムは分かりやすさを重視しており、性能を意図するものではありません。 実装者は最適化を推奨されます。

索引

本仕様で定義される用語

参照による定義用語

参考文献

規範的参照

[FETCH]
Anne van Kesteren. Fetch Standard. Living Standard. URL: https://fetch.spec.whatwg.org/
[HR-TIME-3]
Yoav Weiss. High Resolution Time. 2026年3月2日. WD. URL: https://www.w3.org/TR/hr-time-3/
[HTML]
Anne van Kesteren; et al. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[INFRA]
Anne van Kesteren; Domenic Denicola. Infra Standard. Living Standard. URL: https://infra.spec.whatwg.org/
[RESOURCE-TIMING]
Yoav Weiss; Noam Rosenthal. Resource Timing. 2026年2月17日. CRD. URL: https://www.w3.org/TR/resource-timing/
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. 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. 2004年9月. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc3864
[RFC5234]
D. Crocker, Ed.; P. Overell. Augmented BNF for Syntax Specifications: ABNF. 2008年1月. Internet Standard. 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. 2014年6月. Proposed Standard. URL: https://httpwg.org/specs/rfc7230.html
[WEBIDL]
Edgar Chen; Timothy Gu. Web IDL Standard. Living Standard. URL: https://webidl.spec.whatwg.org/

情報提供的参照

[NAVIGATION-TIMING]
Zhiheng Wang. Navigation Timing. 2012年12月17日. REC. URL: https://www.w3.org/TR/navigation-timing/
[PERFORMANCE-TIMELINE-2]
Nicolas Pena Moreno. Performance Timeline. 2025年5月21日. CRD. URL: https://www.w3.org/TR/performance-timeline/
[RFC6797]
J. Hodges; C. Jackson; A. Barth. HTTP Strict Transport Security (HSTS). 2012年11月. 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

In all current engines.

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

PerformanceServerTiming/description

In all current engines.

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

PerformanceServerTiming/duration

In all current engines.

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

PerformanceServerTiming/name

In all current engines.

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

PerformanceServerTiming/toJSON

In all current engines.

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

PerformanceServerTiming

In all current engines.

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

Headers/Server-Timing

Firefox61+Safari?Chrome65+
Opera?Edge79+
Edge (Legacy)NoneIENone
Firefox for Android?iOS Safari?Chrome for Android?Android WebView?Samsung Internet?Opera Mobile?