リソースタイミング

W3C 候補勧告草案

この文書の詳細
このバージョン:
https://www.w3.org/TR/2025/CRD-resource-timing-20250820/
最新公開バージョン:
https://www.w3.org/TR/resource-timing/
最新編集者草案:
https://w3c.github.io/resource-timing/
履歴:
https://www.w3.org/standards/history/resource-timing/
コミット履歴
実装レポート:
https://w3c.github.io/test-results/resource-timing/all.html
編集者:
Yoav Weiss (Google)
(Google)
以前の編集者:
Ilya Grigorik (Google) (2021年1月まで)
(Microsoft Corp.) (2021年1月まで)
(Google Inc.) (2014年12月まで)
(Microsoft Corp.) (2014年2月まで)
Zhiheng Wang (Google Inc.) (2012年7月まで)
Anderson Quach (Microsoft Corp.) (2011年3月まで)
フィードバック:
GitHub w3c/resource-timing (プルリクエスト, 新しいイシュー, オープンイシュー)
public-web-perf@w3.org 件名 [ResourceTiming] (アーカイブ)
ブラウザー対応状況:
caniuse.com

概要

この仕様は、ウェブアプリケーションがドキュメント内のリソースの完全なタイミング情報にアクセスするためのインターフェイスを定義します。

この文書のステータス

このセクションは、公開時点でのこの文書のステータスについて説明しています。現行標準の一覧やこの技術レポートの最新改訂版は、 W3C 標準と草案インデックスで確認できます。

この文書は、Web パフォーマンス作業グループによって、 勧告プロセスを用いて候補勧告草案として公開されました。

候補勧告としての公開は、W3C およびその会員による支持を意味するものではありません。候補勧告草案は、作業グループが次の候補勧告スナップショットに含める予定の変更を前回の候補勧告から統合したものです。

この文書は草案であり、いつでも更新、置換、または廃止される可能性があります。この文書を進行中の作業以外として引用するのは不適切です。

この文書は、 W3C 特許ポリシー の下で運営されるグループによって作成されました。 W3Cは、 グループの成果物に関連するパテント開示の公開リスト を管理しています。そのページにはパテント開示方法の説明もあります。個人が本当にパテントの存在を知っている場合、そのパテントが 必須のクレーム を含むと考える場合は、W3C 特許ポリシー第6節に従って情報を開示しなければなりません。

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

1. はじめに

このセクションは規範的ではありません。

ユーザーの待ち時間(レイテンシ)は、Webアプリケーションの重要な品質指標です。 JavaScriptベースの手法は、アプリケーション内でユーザーの待ち時間を包括的に計測できますが、多くの場合、エンドツーエンドの全体的なレイテンシを把握することはできません。 この文書では、JavaScriptによるメカニズムがドキュメント上のリソースに関する完全なタイミング情報を収集できるようにする PerformanceResourceTiming インターフェイスを導入します。 Navigation Timing 2 [NAVIGATION-TIMING-2]は、ナビゲーションに関連する追加のタイミング情報を提供するために本仕様を拡張します。

例えば、以下のJavaScriptは、リソースの取得に要する時間を計測する単純な例です。

<!doctype html>
<html>
  <head>
  </head>
  <body onload="loadResources()">
    <script>
        function loadResources()
        {
          var start = new Date().getTime();
          var image1 = new Image();
          var resourceTiming = function() {
              var now = new Date().getTime();
              var latency = now - start;
              alert("End to end resource fetch: " + latency);
          };

          image1.onload = resourceTiming;
          image1.src = 'https://www.w3.org/Icons/w3c_main.png';
        }
    </script>
    <img src="https://www.w3.org/Icons/w3c_home.png">
  </body>
</html>

このスクリプトはリソースの取得にかかる時間を計測できますが、各フェーズで費やされた時間を分解して計測することはできません。さらに、 マークアップで記述されたリソースの取得時間を簡単に計測することもできません。

ユーザー体験に関する完全な情報のニーズに対応するため、本仕様では PerformanceResourceTimingインターフェイスを導入しています。 このインターフェイスにより、JavaScriptメカニズムはアプリケーション内でクライアントサイドのレイテンシを完全に計測できます。 このインターフェイスを使えば、先ほどの例をユーザーが体感するリソースのロード時間の計測に書き換えることが可能です。

次のスクリプトは、ページ内のすべてのリソース(マークアップで定義されたものも含む)を取得するのにかかる時間を計算します。 この例では、ページが https://www.w3.org にホストされていると仮定しています。また、 PerformanceResourceTimingインターフェイスを使えば、 リソース取得の各フェーズにかかる時間も測定できます。

<!doctype html>
<html>
  <head>
  </head>
  <body onload="loadResources()">
    <script>
      function loadResources()
      {
          var image1 = new Image();
          image1.onload = resourceTiming;
          image1.src = 'https://www.w3.org/Icons/w3c_main.png';
      }

      function resourceTiming()
      {
          var resourceList = window.performance.getEntriesByType("resource");
          for (i = 0; i < resourceList.length; i++)
          {
              if (resourceList[i].initiatorType == "img")
              {
                alert("End to end resource fetch: " + (resourceList[i].responseEnd - resourceList[i].startTime));
              }
          }
      }
    </script>
    <img id="image0" src="https://www.w3.org/Icons/w3c_home.png">
  </body>
</html>

2. 適合性

非規範的と記載されたセクションだけでなく、この仕様書のすべての著者向けガイドライン、図、例、注記も非規範的です。それ以外のすべてが規範的です。

この文書中のキーワード MAYMUST、および SHOULD は、 BCP 14 [RFC2119] [RFC8174] に記載されている通り、全て大文字で表示されている場合のみそれぞれの意味で解釈されます。

アルゴリズムの一部として命令形で記述された要件(例えば「先頭のスペース文字をすべて削除する」や「falseを返してこれらの手順を中止する」など)は、アルゴリズムの導入に用いられたキーワード("MUST"、"SHOULD"、"MAY"など)の意味で解釈されます。

属性、メソッド、オブジェクトに対する要件として記述されている適合要件の一部は、ユーザーエージェントに対する要件として解釈されます。

アルゴリズムや具体的な手順として記述されている適合要件は、最終的な結果が同等である限り、どのような方法で実装してもかまいません。(特に、この仕様で定義されているアルゴリズムは理解しやすいことを目的としており、性能を意図したものではありません。)

3. 用語

実際にはインターフェイスである Foo に対して、「Foo オブジェクト」という構文が用いられる場合がありますが、これはより正確には「インターフェイス Foo を実装するオブジェクト」を意味します。

本仕様全体では、すべての時間値はドキュメントのナビゲーション開始からのミリ秒単位で測定されます [HR-TIME]。例えば、 ドキュメントのナビゲーション開始は、時刻0で発生します。

この時間の定義は、High Resolution Time仕様 [HR-TIME]に基づいており、Navigation Timing仕様 [NAVIGATION-TIMING-2]で用いられている、 時間が1970年1月1日午前0時(UTC)からのミリ秒で測定される定義とは異なります。

4. リソースタイミング

4.1 はじめに

このセクションは規範的ではありません。

PerformanceResourceTiming インターフェイスは、 フェッチされた http(s) リソースのタイミング計測を可能にします。例えば、このインターフェイスは XMLHttpRequest オブジェクト [XHR] や、 iframeimgscriptobjectembedlink (linkタイプが stylesheetの場合)などの HTML要素 [HTML] や、 svg などの SVG要素 [SVG11]、 EventSource に対して利用可能です。

4.2 PerformanceResourceTiming インターフェイスに含まれるリソース

このセクションは規範的ではありません。

非nullのclientによって Requestフェッチされると、 PerformanceResourceTiming オブジェクトとして グローバルオブジェクトPerformance Timelineに含まれます。 ただし、フェッチ処理の一部として タイムラインから除外される場合は含まれません。HTTPキャッシュから取得されたリソースも PerformanceResourceTiming オブジェクトとして Performance Timelineに含まれます。 フェッチが開始されたが後に中断された(例:ネットワークエラー等)リソースも、 開始・終了タイミングとともに PerformanceResourceTiming オブジェクトとして Performance Timelineに含まれます。

例:

4.3 PerformanceResourceTiming インターフェイス

WebIDL[Exposed=(Window,Worker)]
interface PerformanceResourceTiming : PerformanceEntry {
    readonly attribute DOMString initiatorType;
    readonly attribute DOMString deliveryType;
    readonly attribute ByteString nextHopProtocol;
    readonly attribute DOMHighResTimeStamp workerStart;
    readonly attribute DOMHighResTimeStamp redirectStart;
    readonly attribute DOMHighResTimeStamp redirectEnd;
    readonly attribute DOMHighResTimeStamp fetchStart;
    readonly attribute DOMHighResTimeStamp domainLookupStart;
    readonly attribute DOMHighResTimeStamp domainLookupEnd;
    readonly attribute DOMHighResTimeStamp connectStart;
    readonly attribute DOMHighResTimeStamp connectEnd;
    readonly attribute DOMHighResTimeStamp secureConnectionStart;
    readonly attribute DOMHighResTimeStamp requestStart;
    readonly attribute DOMHighResTimeStamp finalResponseHeadersStart;
    readonly attribute DOMHighResTimeStamp firstInterimResponseStart;
    readonly attribute DOMHighResTimeStamp responseStart;
    readonly attribute DOMHighResTimeStamp responseEnd;
    readonly attribute unsigned long long  transferSize;
    readonly attribute unsigned long long  encodedBodySize;
    readonly attribute unsigned long long  decodedBodySize;
    readonly attribute unsigned short responseStatus;
    readonly attribute RenderBlockingStatusType renderBlockingStatus;
    readonly attribute DOMString contentType;
    readonly attribute DOMString contentEncoding;
    [Default] object toJSON();
};

PerformanceResourceTiming には DOMStringの initiator type が関連付けられています。

PerformanceResourceTiming には DOMStringの delivery type が関連付けられています。

PerformanceResourceTiming には DOMStringの requested URL が関連付けられています。

PerformanceResourceTiming には DOMStringの cache mode (空文字列、"local"、または "validated")が関連付けられています。

PerformanceResourceTiming には fetch timing infotiming info が関連付けられています。

PerformanceResourceTiming には response body inforesource info が関連付けられています。

PerformanceResourceTiming には statusresponse status が関連付けられています。

PerformanceResourceTiming には RenderBlockingStatusTyperender-blocking status が関連付けられています。

toJSON が呼び出されたときは、 default toJSON stepsPerformanceResourceTiming に対して実行します。

initiatorType のgetter手順は、initiator typethis に対して返します。

initiatorType は次のいずれかの値を返します:

  • "navigation":リクエストが navigation request の場合
  • "body":リクエストが body 要素の background 属性の処理によるもので、すでに廃止されています。
  • "css":リクエストがCSSの url() 指令( @import url()background: url()など)による場合。[CSS-VALUES]

    注:CSSの @font-face で指定されたフォントリソースへのリクエストもCSS指令の処理によるものです。 したがってこのフォントリソースの initiatorType"css" です。

  • "script":リクエストが script(クラシック scriptmodule scriptWorker)の ロードによる場合
  • "xmlhttprequest":リクエストが XMLHttpRequest の処理による場合
  • "font":リクエストがフォントの処理による場合。これは、フォントが追加リソースをリクエストするときなど (例:Incremental Font Transfer利用時)に発生します。
  • "fetch":リクエストが fetch() メソッドの処理による場合
  • "beacon":リクエストが sendBeacon() メソッドの処理による場合[BEACON]
  • "video":リクエストが video 要素の postersrc の処理による場合
  • "audio":リクエストが audio 要素の src の処理による場合
  • "track":リクエストが track 要素の src の処理による場合
  • "img":リクエストが img 要素の srcsrcset の処理による場合
  • "image":リクエストが image 要素の処理による場合。[SVG2]
  • "input":リクエストが input 要素( typeimage )の処理による場合
  • "ping":リクエストが a 要素の ping の処理による場合
  • "iframe":リクエストが iframesrc の処理による場合
  • "frame":リクエストが frame のロードによる場合
  • "embed":リクエストが embed 要素の src の処理による場合
  • "link":リクエストが link 要素の処理による場合
  • "object":リクエストが object 要素の処理による場合
  • "early-hints":リクエストが Early hints レスポンスの処理による場合
  • "other":上記のいずれにも該当しない場合

initiatorTypeの設定は、リソースタイミングエントリが報告されるさまざまな場所(例えばfetch標準)で行われます。

deliveryType のgetter手順は、 delivery typethis に対して返します。

deliveryTypeは次のいずれかの値を返します:

  • "cache"cache mode が空文字列でない場合
  • 上記に該当しない場合は空文字列""

この値は、今後の仕様更新で拡張される予定です(例:プリロードリソースやプリフェッチナビゲーションリクエストの記述)。

workerStart のgetter手順は、fetchタイムスタンプの変換thistiming infofinal service worker start time および relevant global object に対して実行します。詳細は HTTP fetch を参照してください。

redirectStart のgetter手順は、fetchタイムスタンプの変換thistiming inforedirect start time および relevant global object に対して実行します。詳細は HTTP-redirect fetch を参照してください。

redirectEnd のgetter手順は、fetchタイムスタンプの変換thistiming inforedirect end time および relevant global object に対して実行します。詳細は HTTP-redirect fetch を参照してください。

fetchStart のgetter手順は、fetchタイムスタンプの変換thistiming infopost-redirect start time および relevant global object に対して実行します。詳細は HTTP fetch を参照してください。

domainLookupStart のgetter手順は、fetchタイムスタンプの変換thistiming infofinal connection timing infodomain lookup start time および relevant global object に対して実行します。詳細は 接続タイミング情報の記録 を参照してください。

domainLookupEnd のgetter手順は、fetchタイムスタンプの変換thistiming infofinal connection timing infodomain lookup end time および relevant global object に対して実行します。詳細は 接続タイミング情報の記録 を参照してください。

connectStart のgetter手順は、fetchタイムスタンプの変換thistiming infofinal connection timing infoconnection start time および relevant global object に対して実行します。詳細は 接続タイミング情報の記録 を参照してください。

connectEnd のgetter手順は、fetchタイムスタンプの変換thistiming infofinal connection timing infoconnection end time および relevant global object に対して実行します。詳細は 接続タイミング情報の記録 を参照してください。

secureConnectionStart のgetter手順は、fetchタイムスタンプの変換thistiming infofinal connection timing infosecure connection start time および relevant global object に対して実行します。詳細は 接続タイミング情報の記録 を参照してください。

nextHopProtocol のgetter手順は、 isomorphic decodethistiming infofinal connection timing infoALPN negotiated protocol に対して実行します。詳細は 接続タイミング情報の記録 を参照してください。

Issue 221は nextHopProtocolのサポートを削除することを提案しています。これは、ユーザーのネットワーク構成に関する詳細を暴露する可能性があるためです。

requestStart のgetter手順は、fetchタイムスタンプの変換thistiming infofinal network-request start time および relevant global object に対して実行します。詳細は HTTP fetch を参照してください。

firstInterimResponseStart のgetter手順は、 fetchタイムスタンプの変換thistiming infofirst interim network-response start time および relevant global object に対して実行します。詳細は HTTP fetch を参照してください。

finalResponseHeadersStart のgetter手順は、 fetchタイムスタンプの変換thistiming infofinal network-response start time および relevant global object に対して実行します。詳細は HTTP fetch を参照してください。

responseStart のgetter手順は、 thisfirstInterimResponseStart が 0 でない場合はそれを返し、そうでなければ thisfinalResponseHeadersStart を返します。

responseEnd のgetter手順は、fetchタイムスタンプの変換thistiming infoend time および relevant global object に対して実行します。詳細は fetch を参照してください。

encodedBodySize のgetter手順は、 thisresource infoencoded size を返します。

decodedBodySize のgetter手順は、 thisresource infodecoded size を返します。

transferSize のgetter手順は以下の通りです:

  1. thiscache mode が "local" の場合は 0 を返す。

  2. thiscache mode が "validated" の場合は 300 を返す。

  3. thisresponse body infoencoded size に 300 を加えて返す。

    transferSizeに加算される定数値は、HTTPヘッダーの総バイト数を公開するかわりです。これは特定のクッキーの存在を暴露する可能性があるためです。詳細は このissue を参照してください。

responseStatus のgetter手順は、 thisresponse status を返します。

responseStatusFetch で決定されます。クロスオリジンの no-cors リクエストの場合、 レスポンスは opaque filtered response となるため、0 になります。

contentType のgetter手順は、 thisresource infocontent type を返します。

contentEncoding のgetter手順は、 thisresource infocontent encoding を返します。

renderBlockingStatus のgetter手順は、 blocking を返します。 ただし thistiming inforender-blocking が true の場合のみで、 それ以外は non-blocking を返します。

PerformanceResourceTiming を実装するユーザーエージェントは "resource"supportedEntryTypes に含める必要があります。これにより、開発者はResource Timingのサポートを検出できます。

4.3.1 RenderBlockingStatusType 列挙型

WebIDLenum RenderBlockingStatusType {
    "blocking",
    "non-blocking"
};

値の定義は以下の通りです:

blocking
リソースは、レンダリングをブロックする可能性があります。
non-blocking
リソースはレンダリングをブロックしません。

4.4 Performance インターフェイスへの拡張

ユーザーエージェントは、PerformanceResourceTiming オブジェクトとして Performance Timeline [PERFORMANCE-TIMELINE-2] に含まれるリソース数を 制限することが できます。 本セクションは、Performance インターフェイスに、PerformanceResourceTiming オブジェクトの保存数を制御する機能を追加します。

推奨される PerformanceResourceTiming オブジェクトの最小数は 250 ですが、これはユーザーエージェントによって変更可能です。 この制限の変更は setResourceTimingBufferSize を呼び出して要求できます。

ECMAScript グローバル環境は次を持ちます:

WebIDLpartial interface Performance {
          undefined clearResourceTimings ();
          undefined setResourceTimingBufferSize (unsigned long maxSize);
          attribute EventHandler onresourcetimingbufferfull;
        };

Performance インターフェイスは [HR-TIME] で定義されています。

clearResourceTimings メソッドは次の手順を実行します:

  1. PerformanceResourceTiming オブジェクトを performance entry buffer からすべて削除します。
  2. リソースタイミングバッファ現在サイズ を0に設定します。

setResourceTimingBufferSize メソッドは次の手順を実行します:

  1. リソースタイミングバッファサイズ制限maxSize パラメータに設定します。 maxSize パラメータが リソースタイミングバッファ現在サイズ より小さい場合、 PerformanceResourceTiming オブジェクトは performance entry buffer から削除しません。

onresourcetimingbufferfull 属性は、 以下で説明する resourcetimingbufferfull イベントのイベントハンドラーです。

リソースタイミングエントリ追加可能か を判定するには、次の手順を実行します:

  1. リソースタイミングバッファ現在サイズ リソースタイミングバッファサイズ制限 より小さい場合、trueを返す。
  2. falseを返す。

PerformanceResourceTimingエントリ追加new entry)を performance entry buffer に追加するには、次の手順を実行します:

  1. リソースタイミングエントリ追加可能か がtrueで リソースタイミングバッファフルイベント保留フラグ がfalseの場合、以下を実行:
    1. new entryperformance entry buffer に追加
    2. リソースタイミングバッファ現在サイズ を1増やす
    3. 終了
  2. リソースタイミングバッファフルイベント保留フラグ が falseの場合、以下を実行:
    1. リソースタイミングバッファフルイベント保留フラグ を trueに設定
    2. タスクをキューに追加 performance timeline task source)して バッファフルイベント発火 を実行
  3. new entryリソースタイミングセカンダリバッファ に追加
  4. リソースタイミングセカンダリバッファ現在サイズ を1増やす

セカンダリバッファのコピー は次の手順で実行します:

  1. リソースタイミングセカンダリバッファ が空でなく リソースタイミングエントリ追加可能か がtrueの場合、以下を繰り返す:
    1. entryPerformanceResourceTiming のうち最も古いものとして リソースタイミングセカンダリバッファから取得
    2. entryperformance entry buffer の末尾に追加
    3. リソースタイミングバッファ現在サイズ を1増やす
    4. entryリソースタイミングセカンダリバッファ から削除
    5. リソースタイミングセカンダリバッファ現在サイズ を1減らす

バッファフルイベント発火 は次の手順で実行します:

  1. リソースタイミングセカンダリバッファ が空でない限り、以下を繰り返す:
    1. number of excess entries beforeリソースタイミングセカンダリバッファ現在サイズ とする
    2. リソースタイミングエントリ追加可能か がfalseの場合、 イベントを発火(名前:resourcetimingbufferfull)、 Performance オブジェクトに対して
    3. セカンダリバッファのコピー を実行
    4. number of excess entries afterリソースタイミングセカンダリバッファ現在サイズ とする
    5. number of excess entries beforenumber of excess entries after 以下の場合、 リソースタイミングセカンダリバッファ をすべて削除し、 リソースタイミングセカンダリバッファ現在サイズ を0に設定し、 この手順を中止
  2. リソースタイミングバッファフルイベント保留フラグ を falseに設定

    これは resourcetimingbufferfull イベントハンドラーが バッファに追加するリソースより多くのバッファ領域を追加しない場合、 余分なエントリがバッファから破棄されることを意味します。 開発者は resourcetimingbufferfull イベントハンドラーで clearResourceTimings を呼び出すか、十分にバッファ拡張 (setResourceTimingBufferSize の呼び出し)するようにしてください。

4.5 クロスオリジンリソース

Fetchで説明されている通り、クロスオリジンリソースへのリクエストは PerformanceResourceTiming オブジェクトとして Performance Timelineに含まれます。 クロスオリジンリソースに対するtiming allow checkアルゴリズムが失敗すると、 エントリはopaque entryとなります。 このようなエントリは、クロスオリジンデータの漏洩を防ぐため、ほとんどの属性がマスクされます。 そのため、opaque entry の場合、 以下の属性は全て0に設定されます: redirectStart, redirectEnd, workerStart, domainLookupStart, domainLookupEnd, connectStart, connectEnd, requestStart, firstInterimResponseStart, finalResponseHeadersStart, responseStart, secureConnectionStart, transferSize, encodedBodySize, および decodedBodySize。 さらに、 nextHopProtocol 属性は空文字列に設定されます。

サーバーサイドアプリケーションは、Timing-Allow-Origin HTTPレスポンスヘッダーを返すことで、ドキュメントのオリジン(指定されたもの)に対し、クロスオリジン制限でゼロになった属性値を完全に公開することができます。

4.5.1 Timing-Allow-Origin レスポンスヘッダー

Timing-Allow-Origin HTTPレスポンスヘッダーフィールドは、 クロスオリジン制限によりゼロになる属性値を閲覧できるオリジンを示すポリシーを通知するために使用できます。 ヘッダー値は、以下のABNF [RFC5234](List Extension [RFC9110]を利用)で表されます:

Timing-Allow-Origin = 1#( origin-or-null / wildcard )

送信者は複数のTiming-Allow-Originヘッダーフィールドを生成することができます。 受信者は複数のTiming-Allow-Originヘッダーフィールドを結合することができます。 各フィールド値を順にコンマ区切りで連結します。

ユーザーエージェントは、Timing-Allow-Originヘッダーがあってもクロスオリジン制限を適用し、 transferSize、encodedBodySize、decodedBodySize属性をゼロに設定することができます。 その場合、deliveryTypeも""に設定することができます

Timing-Allow-Originヘッダーは FETCHで処理され、属性値が適切に計算されます。

Timing-Allow-Originヘッダーはキャッシュされたレスポンスの一部として到着する場合があります。 キャッシュ再検証の場合、RFC 7234に従い、 ヘッダー値は再検証レスポンスから、そこに存在しない場合は元のキャッシュリソースから取得されることがあります。

Issue 222 および 223 は Timing-Allow-Originのワイルドカードサポートを削除し、利用を制限することを提案しています。

4.5.2 IANAに関する考慮事項

本セクションは Timing-Allow-Origin仮メッセージヘッダーとして登録します。

ヘッダーフィールド名:
Timing-Allow-Origin
適用プロトコル:
http
ステータス:
provisional
著者/変更管理者:
W3C
仕様書:
4.5.1 Timing-Allow-Origin レスポンスヘッダー

4.6 リソースタイミング属性

このセクションは規範的ではありません。

以下のグラフは、PerformanceResourceTimingインターフェイスで定義されるタイミング属性を示します。 括弧内の属性は、クロスオリジンリソースのフェッチ時に利用できない場合があります。 ユーザーエージェントはタイミング間で内部処理を行うことがあり、タイミング間に非規範的な間隔が発生する場合があります。

1 この図は PerformanceResourceTiming インターフェイスで定義されるタイミング属性を示します。括弧内の属性は、 リソースがtiming allow checkアルゴリズムに失敗した場合に 利用できない可能性があります。
Resource Timing属性

4.7 リソースタイミングエントリの作成

mark resource timing を行うには、fetch timing info timingInfo、 DOMString requestedURL、 DOMString initiatorTypeglobal object global、 string cacheModeresponse body info bodyInfostatus responseStatus、 およびオプションの string deliveryType (デフォルトは空文字列)を与え、以下の手順を実行します:

  1. PerformanceResourceTiming オブジェクト entryglobalrealm に作成します。
  2. リソースタイミングエントリのセットアップentry に対して、initiatorTyperequestedURLtimingInfocacheModebodyInforesponseStatusdeliveryType を与えて実行します。
  3. キューに追加 entry を行います。
  4. 追加 entryglobalperformance entry buffer に追加します。

リソースタイミングエントリのセットアップPerformanceResourceTiming entry に対して、 DOMString initiatorType、DOMString requestedURLfetch timing info timingInfo、DOMString cacheModeresponse body info bodyInfostatus responseStatus、およびオプションのDOMString deliveryType(デフォルトは空文字列)を与え、以下の手順を実行します:

  1. cacheMode が空文字列、"local"、または "validated" であることを確認します。
  2. globalentryrelevant global object とします。
  3. PerformanceEntryの初期化entry に対して行います。引数は global を与えて fetchタイムスタンプの変換で得た timingInfostart time、 "resource"、requestedURL、 および fetchタイムスタンプの変換で得た timingInfoend time を与えます。
  4. entryinitiator typeinitiatorType に設定します。
  5. entryrequested URLrequestedURL に設定します。
  6. entrytiming infotimingInfo に設定します。
  7. entryresponse body infobodyInfo に設定します。
  8. entrycache modecacheMode に設定します。
  9. entryresponse statusresponseStatus に設定します。
  10. deliveryType が空文字列で cacheMode が空でない場合、 deliveryType を "cache" に設定します。
  11. entrydelivery typedeliveryType に設定します。

fetchタイムスタンプの変換は、 DOMHighResTimeStamp tsglobal object global を与えて、以下を実行します:

  1. ts がゼロの場合はゼロを返します。
  2. それ以外の場合は、相対高精度コース時間tsglobal に与えて返します。

4.8 セキュリティに関する考慮事項

このセクションは規範的ではありません。

PerformanceResourceTiming インターフェイスは、 リソースのタイミング情報をリソースをリクエストしたすべてのウェブページやワーカーに公開します。 PerformanceResourceTiming インターフェイスへのアクセスを制限するために、 デフォルトで 同一オリジン ポリシーが適用され、 一部の属性がゼロに設定されます(詳細は HTTP fetch を参照)。 リソース提供者は、Timing-Allow-Origin HTTPレスポンスヘッダーを追加することで、どのドメインがタイミング情報へアクセス可能かを指定し、全てのタイミング情報の収集を明示的に許可できます。

4.9 プライバシーに関する考慮事項

このセクションは規範的ではありません。

統計的フィンガープリントは、悪意のあるウェブサイトが、第三者サイトのリソースに対するキャッシュヒットとミスのタイミングを測定することで、 ユーザーが第三者サイトへアクセスしたことがあるかどうかを判定できてしまうというプライバシー上の懸念です。 PerformanceResourceTiming インターフェイスは ドキュメント内のリソースのタイミング情報を提供しますが、 リソースの load イベントでも既に限定的にキャッシュヒット/ミスを判定するタイミング計測は可能ですし、 HTTP Fetch の クロスオリジン制限により、それ以上の情報漏洩は防止されます。

4.10 謝辞

Anne Van Kesteren、Annie Sullivan、Arvind Jain、Boris Zbarsky、Darin Fisher、Jason Weber、Jonas Sicking、James Simonsen、 Karen Anderson、Kyle Scholz、Nic Jansma、Philippe Le Hegaret、Sigbjørn Vik、Steve Souders、Todd Reifsteck、Tony Gentilcore、 William Chan、Alex Christensen 各氏に、この仕様への貢献に感謝します。

A. 参考文献

A.1 規範的参考文献

[dom]
DOM標準.Anne van Kesteren.WHATWG.現行標準.URL: https://dom.spec.whatwg.org/
[FETCH]
Fetch標準.Anne van Kesteren.WHATWG.現行標準.URL: https://fetch.spec.whatwg.org/
[HR-TIME]
高精度時間.Yoav Weiss.W3C.2024年11月7日.W3C作業草案.URL: https://www.w3.org/TR/hr-time-3/
[HTML]
HTML標準.Anne van Kesteren;Domenic Denicola;Dominic Farolino;Ian Hickson;Philip Jägenstedt;Simon Pieters.WHATWG.現行標準.URL: https://html.spec.whatwg.org/multipage/
[infra]
Infra標準.Anne van Kesteren;Domenic Denicola.WHATWG.現行標準.URL: https://infra.spec.whatwg.org/
[NAVIGATION-TIMING-2]
Navigation Timing Level 2. Yoav Weiss;Noam Rosenthal.W3C.2025年2月13日.W3C作業草案.URL: https://www.w3.org/TR/navigation-timing-2/
[PERFORMANCE-TIMELINE-2]
Performance Timeline.Nicolas Pena Moreno.W3C.2025年5月21日.CRD.URL: https://www.w3.org/TR/performance-timeline/
[RFC2119]
RFCで要求レベルを示すためのキーワード.S. Bradner.IETF.1997年3月.Best Current Practice.URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC2397]
"data" URLスキーム.L. Masinter.IETF.1998年8月.提案標準.URL: https://www.rfc-editor.org/rfc/rfc2397
[RFC5234]
構文仕様のための拡張BNF: ABNF.D. Crocker, Ed.;P. Overell.IETF.2008年1月.インターネット標準.URL: https://www.rfc-editor.org/rfc/rfc5234
[RFC8174]
RFC 2119キーワードにおける大文字と小文字の曖昧性.B. Leiba.IETF.2017年5月.Best Current Practice.URL: https://www.rfc-editor.org/rfc/rfc8174
[RFC9110]
HTTPセマンティクス.R. Fielding, Ed.;M. Nottingham, Ed.;J. Reschke, Ed..IETF.2022年6月.インターネット標準.URL: https://httpwg.org/specs/rfc9110.html
[WEBIDL]
Web IDL標準.Edgar Chen;Timothy Gu.WHATWG.現行標準.URL: https://webidl.spec.whatwg.org/

A.2 参考情報

[BEACON]
Beacon.Ilya Grigorik;Alois Reitbauer.W3C.2022年8月3日.CRD.URL: https://www.w3.org/TR/beacon/
[CSS-VALUES]
CSS値と単位モジュール レベル3.Tab Atkins Jr.;Elika Etemad.W3C.2024年3月22日.CRD.URL: https://www.w3.org/TR/css-values-3/
[css-values-4]
CSS値と単位モジュール レベル4.Tab Atkins Jr.;Elika Etemad.W3C.2024年3月12日.W3C作業草案.URL: https://www.w3.org/TR/css-values-4/
[EARLY_HINTS]
Early hints.URL: https://httpwg.org/specs/rfc8297.html
[INCREMENTAL_FONT_TRANSFER]
Incremental Font Transfer.URL: https://www.w3.org/TR/IFT/
[SVG11]
Scalable Vector Graphics (SVG) 1.1(第二版).Erik Dahlström;Patrick Dengler;Anthony Grasso;Chris Lilley;Cameron McCormack;Doug Schepers;Jonathan Watt;Jon Ferraiolo;Jun Fujisawa;Dean Jackson 他.W3C.2011年8月16日.W3C勧告.URL: https://www.w3.org/TR/SVG11/
[SVG2]
Scalable Vector Graphics (SVG) 2.Amelia Bellamy-Royds;Bogdan Brinza;Chris Lilley;Dirk Schulze;David Storey;Eric Willigers.W3C.2018年10月4日.W3C候補勧告.URL: https://www.w3.org/TR/SVG2/
[XHR]
XMLHttpRequest標準.Anne van Kesteren.WHATWG.現行標準.URL: https://xhr.spec.whatwg.org/