1. Introduction
ユーザー待ち時間は 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. Terminology
「a Foo object」という表現は、実際にはインターフェイスであるFooを実装するオブジェクトを指す
より正確な表現「an object implementing the interface Foo」の代わりに用いられることがあります。
本書を通じて、全ての時刻値は文書のナビゲーション開始からのミリ秒で測定されます([HR-TIME])。例えば、文書のナビゲーション開始は時刻 0 に発生します。
この時刻の定義は High Resolution Time 仕様 [HR-TIME] に基づくもので、Navigation Timing 仕様 [NAVIGATION-TIMING-2] で用いられる定義(1970年1月1日午前0時UTCからのミリ秒)とは異なります。
3. Resource Timing
3.1. Introduction
PerformanceResourceTiming
インターフェイスは、取得された http(s)
リソースのタイミング計測を容易にします。例えば、このインターフェイスは
XMLHttpRequest
オブジェクト [XHR]、HTML 要素
[HTML](iframe、img、script、object、embed
や link 要素(stylesheet)など)、および SVG 要素 [SVG11](svg 等)、EventSource
に対して利用可能です。
3.2.
Resources Included in the PerformanceResourceTiming
Interface
この節は非規範的です。
非 null の クライアント によって Request が
fetch されると、
それらはクライアントのグローバルオブジェクトの Performance Timeline に
PerformanceResourceTiming
オブジェクトとして含まれます(fetch 過程でタイムラインから除外されない限り)。HTTP キャッシュから取り出されたリソースも
PerformanceResourceTiming オブジェクトとして Performance Timeline に含まれます。fetch
が開始されたが後に中止されたリソース(ネットワークエラー等)は、
開始および終了のタイミング情報を持つ PerformanceResourceTiming オブジェクトとして Performance Timeline に含まれます。
例:
- 同一の正規化された URL が2つの HTML
IMG要素のsrc属性として使われている場合、 最初に発起された fetch が Performance Timeline に含まれます。ユーザーエージェントは2つ目の IMG のために再リクエストを行わず、 最初の IMG に対する既存のダウンロードを利用するかもしれません。この場合、最初の IMG による fetch のみが Performance Timeline に現れます。 - スクリプトにより HTML
IMG要素のsrc属性が変更された場合、元のリソースの fetch と新しい URL の fetch の両方が Performance Timeline に PerformanceResourceTiming オブジェクトとして含まれます。 - マークアップで
IFRAME要素が追加されsrc属性が指定されていない場合、ユーザーエージェントはその IFRAME に対してabout:blank文書を読み込むことがあります。 後にスクリプトでsrc属性が動的に変更されると、ユーザーエージェントは IFRAME のために新しい URL のリソースを fetch することがあります。このケースでは、新しい URL の fetch のみが親の Performance Timeline ではなく IFRAME の Performance Timeline に PerformanceResourceTiming オブジェクトとして含まれます。 - 同じ正規化 URL に対して XMLHTTPRequest が二回発行された場合、両方の fetch が Performance Timeline に含まれます。 これは 2 回目の XMLHTTPRequest のための fetch が最初の XMLHTTPRequest のダウンロードを再利用できないためです。
- ページに HTML
IFRAME要素が含まれる場合、そのページに含まれるのは IFRAME のsrc属性で要求されたリソースのみであり、 サブリソースは IFRAME 文書自身の Performance Timeline に含まれ、親文書の Performance Timeline には含まれません。 - HTML
IMG要素のソースがdata: URIの場合、そのリソースは Performance Timeline に含まれません。PerformanceResourceTiming エントリは http(s) リソースに対してのみ報告されます。 - fetch がネットワークエラー(DNS, TCP, TLS 等)により中止された場合、その fetch は startTime、fetchStart、duration、responseEnd のみが設定された PerformanceResourceTiming オブジェクトとして Performance Timeline に含まれます。
- fetch が事前条件(混合コンテンツ、CORS 制限、CSP ポリシー等)により中止された場合、そのリソースは Performance Timeline に PerformanceResourceTiming オブジェクトとして含まれません。
3.3. The PerformanceResourceTiming Interface
[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 DOMHighResTimeStamp ;workerRouterEvaluationStart readonly attribute DOMHighResTimeStamp ;workerCacheLookupStart readonly attribute DOMString ;workerMatchedRouterSource readonly attribute DOMString ;workerFinalRouterSource 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 info としての timing
info が存在します。
PerformanceResourceTiming
には関連付けられた response body info としての resource
info が存在します。
PerformanceResourceTiming
には関連付けられた
status としての
response status が存在します。
PerformanceResourceTiming
には関連付けられた
RenderBlockingStatusType
としての render-blocking status
が存在します。
toJSON が呼ばれたときは、デフォルトの toJSON 手順 を
PerformanceResourceTiming
に対して実行します。
initiatorType の getter 手順は、 initiator type をこのオブジェクトに対して返します。
initiatorType は次のいずれかの値を返します:
-
"navigation"— リクエストが navigation request の場合; -
"body"— リクエストが既に廃止された body 要素のbackground属性の処理の結果である場合。 -
"css"— リクエストが@import url()やbackground: url()のような CSS の url() 指令の処理の結果である場合; [CSS-VALUES]注: CSS の
@font-faceで指定されたフォントリソースの要求は CSS 指令の処理の結果であるため、このフォントリソースのinitiatorTypeは"css"になります。 -
"script"— リクエストが任意のスクリプトの読み込みの結果である場合(classic script、module script、または Worker)。 -
"xmlhttprequest"— リクエストがXMLHttpRequestの処理の結果である場合; -
"font"— リクエストがフォントの処理の結果である場合(例: Incremental Font Transfer を使用する場合など)。 -
"fetch"— リクエストがfetch()の処理の結果である場合; -
"beacon"— リクエストがsendBeacon()の処理の結果である場合; [BEACON] -
"video"— リクエストがvideo要素のposterまたはsrcの処理の結果である場合。 -
"audio"— リクエストがaudio要素のsrcの処理の結果である場合。 -
"track"— リクエストがtrack要素のsrcの処理の結果である場合。 -
"img"— リクエストがimg要素のsrcまたはsrcsetの処理の結果である場合。 -
"image"— リクエストが SVG の image 要素の処理の結果である場合。[SVG2] -
"input"— リクエストが type="image" のinput要素の処理の結果である場合。 -
"ping"— リクエストがa要素のpingの処理の結果である場合。 -
"iframe"— リクエストがiframeのsrcの処理の結果である場合。 -
"frame"— リクエストが古いframe要素の読み込みの結果である場合。 -
"embed"— リクエストがembed要素のsrcの処理の結果である場合。 -
"link"— リクエストがlink要素の処理の結果である場合。 -
"object"— リクエストがobject要素の処理の結果である場合。 -
"early-hints"— リクエストが Early Hints レスポンスの処理の結果である場合。 -
"other"— 上記のどれにも該当しない場合。
initiatorType の設定は、リソースタイミングエントリが報告される各所(例えば Fetch 標準)で行われます。
deliveryType の getter 手順は、このオブジェクトの delivery type を返します。
deliveryType は次のいずれかを返します:
-
"cache"— cache mode が空文字でない場合。 - 空文字
""— 上記のどの条件にも当てはまらない場合。
これは将来的な更新で拡張されることが想定されています(例: プリロード済みリソースやプレフェッチされたナビゲーション要求の取り扱いなど)。
workerStart のゲッター手順は、 取得タイムスタンプの変換を this の timing info の final service worker start time および relevant global object を this に対して実行することである。 詳細は HTTP fetch を参照のこと。
redirectStart のゲッター手順は、 取得タイムスタンプの変換を this の timing info の redirect start time および relevant global object を this に対して実行することである。詳細は HTTP-redirect fetch を参照のこと。
redirectEnd のゲッター手順は、 取得タイムスタンプの変換を this の timing info の redirect end time および relevant global object を this に対して実行することである。詳細は HTTP-redirect fetch を参照のこと。
fetchStart のゲッター手順は、 取得タイムスタンプの変換を this の timing info の post-redirect start time および relevant global object を this に対して実行することである。詳細は HTTP fetch を参照のこと。
domainLookupStart のゲッター手順は、 取得タイムスタンプの変換を this の timing info の final connection timing info の domain lookup start time および relevant global object を this に対して実行することである。 詳細は 接続タイミング情報の記録 を参照のこと。
domainLookupEnd のゲッター手順は、 取得タイムスタンプの変換を this の timing info の final connection timing info の domain lookup end time および relevant global object を this に対して実行することである。 詳細は 接続タイミング情報の記録 を参照のこと。
connectStart のゲッター手順は、 取得タイムスタンプの変換を this の timing info の final connection timing info の connection start time および relevant global object を this に対して実行することである。 詳細は 接続タイミング情報の記録 を参照のこと。
connectEnd のゲッター手順は、 取得タイムスタンプの変換を this の timing info の final connection timing info の connection end time および relevant global object を this に対して実行することである。 詳細は 接続タイミング情報の記録 を参照のこと。
secureConnectionStart のゲッター手順は、 取得タイムスタンプの変換を this の timing info の final connection timing info の secure connection start time および relevant global object を this に対して実行することである。 詳細は 接続タイミング情報の記録 を参照のこと。
nextHopProtocol のゲッター手順は、 isomorphic decode を this の timing info の final connection timing info の ALPN で交渉されたプロトコル に対して実行することである。詳細は 接続タイミング情報の記録 を参照のこと。
Issue 221 は、 nextHopProtocol のサポートを削除することを提案している。これはユーザーのネットワーク構成に関する詳細を 明かしてしまう可能性があるためである。
requestStart のゲッター手順は、 取得タイムスタンプの変換を this の timing info の final network-request start time および relevant global object を this に対して実行することである。詳細は HTTP fetch を参照のこと。
firstInterimResponseStart の ゲッター手順は、 取得タイムスタンプの変換を this の timing info の first interim network-response start time および relevant global object を this に対して実行することである。詳細は HTTP fetch を参照のこと。
finalResponseHeadersStart の ゲッター手順は、 取得タイムスタンプの変換を this の timing info の final network-response start time および relevant global object を this に対して実行することである。詳細は HTTP fetch を参照のこと。
responseStart
のゲッター手順は、
this
の
firstInterimResponseStart
が 0 でない場合はそれを返し、なければ
this
の
finalResponseHeadersStart
を返す。
responseEnd のゲッター手順は 取得タイムスタンプの変換を this の timing info の end time および relevant global object を this に対して実行することである。詳細は fetch を参照のこと。
encodedBodySize のゲッター手順は、 this の resource info の encoded size を返すことである。
decodedBodySize のゲッター手順は、 this の resource info の decoded size を返すことである。
transferSize のゲッター手順は:
-
もしこのオブジェクトの cache mode が "
local" であれば、0 を返す。 -
もし cache mode が "
validated" であれば、300 を返す。 -
上記でない場合、このオブジェクトの resource info の encoded size に 300 を加えた値を返す。
transferSizeに加えられる定数は、HTTP ヘッダの合計バイト数を公開する代わりのものであり、それにより特定のクッキーの存在が露見することを避けます。詳細は この issue を参照してください。
responseStatus の getter 手順は、このオブジェクトの response status を返します。
responseStatus は Fetch で決定されます。クロスオリジンの no-cors リクエストの場合、レスポンスは opaque filtered
response となるため 0 になります。
contentType の getter 手順は、このオブジェクトの resource info の content type を返します。
contentEncoding の getter 手順は、このオブジェクトの resource info の content encoding を返します。
renderBlockingStatus の getter 手順は、このオブジェクトの timing info の render-blocking が true であれば blocking を返し、そうでなければ non-blocking を返します。
workerRouterEvaluationStart の getter 手順は、timing info の service worker timing info の worker router evaluation start を返します。
workerCacheLookupStart の getter 手順は、timing info の service worker timing info の worker cache lookup start を返します。
workerMatchedRouterSource の getter 手順は、timing info の service worker timing info の worker matched router source を返します。
workerFinalRouterSource の getter 手順は、timing info の service worker timing info の worker final router source を返します。
PerformanceResourceTiming を実装するユーザーエージェントは "resource" を
supportedEntryTypes
に含める必要があります。
これにより開発者は Resource Timing のサポートを検出できます。
3.3.1. RenderBlockingStatusType enum
enum {RenderBlockingStatusType ,"blocking" };"non-blocking"
値は次のように定義されます:
- blocking
- リソースはレンダリングを潜在的にブロックする可能性があります。
- non-blocking
- リソースはレンダリングをブロックしません。
3.4.
Extensions to the Performance Interface
ユーザーエージェントは Performance Timeline に含める PerformanceResourceTiming オブジェクトの数を制限することを選択してもよく、
この節は Performance
インターフェイスを拡張して保存される PerformanceResourceTiming オブジェクトの数を制御するための手段を提供します。
推奨される最小の PerformanceResourceTiming オブジェクト数は 250 ですが、これはユーザーエージェントにより変更され得ます。 setResourceTimingBufferSize を呼び出すことでこの制限の変更を要求できます。
各 ECMAScript グローバル環境は以下を持ちます:
- 初期値が 250 以上であるべき resource timing buffer size limit。
- 初期値が 0 の resource timing buffer current size。
- 初期値が false の resource timing buffer full event pending flag。
- 初期値が 0 の resource timing secondary buffer current size。
- 初期は空であり PerformanceResourceTiming オブジェクトを格納するための resource timing secondary buffer。
partial interface Performance {undefined ();clearResourceTimings undefined (setResourceTimingBufferSize unsigned long );maxSize attribute EventHandler ; };onresourcetimingbufferfull
Performance インターフェイスは [HR-TIME] で定義されています。
メソッド clearResourceTimings は次の手順を実行します:
- performance entry buffer 内の全ての
PerformanceResourceTimingオブジェクトを削除する。 - resource timing buffer current size を 0 に設定する。
setResourceTimingBufferSize メソッドは次の手順を実行します:
- resource timing buffer size limit を maxSize 引数に設定する。もし maxSize が resource timing buffer current size より小さい場合は、performance entry buffer から PerformanceResourceTiming オブジェクトを削除しない。
属性 onresourcetimingbufferfull は下記の
resourcetimingbufferfull イベントのイベントハンドラです。
リソースタイミングエントリを追加できるか を確認するには、次の手順を実行する:
- リソースタイミングバッファの現在のサイズ が リソースタイミングバッファのサイズ制限 より小さい場合、true を返す。
- false を返す。
PerformanceResourceTiming エントリ new entry を パフォーマンスエントリバッファ に追加するには、次の手順を実行する:
-
リソースタイミングエントリを追加できるか が true を返し、
リソースタイミングバッファが満杯のイベントの保留フラグ
が false の場合、次のサブステップを実行する:
- new entry を パフォーマンスエントリバッファ に追加する。
- リソースタイミングバッファの現在のサイズ を 1 増やす。
- return する。
-
リソースタイミングバッファが満杯のイベントの保留フラグ
が
false の場合、次のサブステップを実行する:
- リソースタイミングバッファが満杯のイベントの保留フラグ に true を設定する。
- タスクをキューする を パフォーマンスタイムラインタスクソース 上で実行し バッファ満杯イベントを発火する を実行する。
- new entry を リソースタイミング二次バッファ に追加する。
- リソースタイミング二次バッファの現在のサイズ を 1 増やす。
二次バッファをコピーする には、次の手順を実行する:
-
リソースタイミング二次バッファ が空でなく、
リソースタイミングエントリを追加できるか が true
を返す間、次のサブステップを実行する:
- entry を最も古い
PerformanceResourceTimingとして リソースタイミング二次バッファ から取得する。 - entry を パフォーマンスエントリバッファ の末尾に追加する。
- リソースタイミングバッファの現在のサイズ を 1 増やす。
- entry を リソースタイミング二次バッファ から削除する。
- リソースタイミング二次バッファの現在のサイズ を 1 減らす。
- entry を最も古い
バッファ満杯イベントを発火する には、次の手順を実行する:
-
リソースタイミング二次バッファ
が空でない間、次のサブステップを実行する:
- number of excess entries before を リソースタイミング二次バッファの現在のサイズ とする。
- リソースタイミングエントリを追加できるか
が false を返すなら、
イベントを発火する
resourcetimingbufferfullをPerformanceオブジェクト上で発火する。 - 二次バッファをコピーする を実行する。
- number of excess entries after を リソースタイミング二次バッファの現在のサイズ とする。
- number of excess entries before が number of excess entries after 以下の場合、 リソースタイミング二次バッファ からすべてのエントリを削除し、 リソースタイミング二次バッファの現在のサイズ を 0 に設定して、これらの手順を中止する。
-
リソースタイミングバッファが満杯のイベントの保留フラグ
を false にする。
これは、
resourcetimingbufferfullイベントハンドラがバッファに追加するリソース数より多くの空きを作らない場合、 余分なエントリがバッファから破棄されることを意味します。 開発者はresourcetimingbufferfullイベントハンドラでclearResourceTimingsまたは十分にバッファサイズを拡張する (setResourceTimingBufferSizeの呼び出しにより) 必要があります。
3.5. Cross-origin Resources
3.5.1. Introduction
Fetch に詳述されているように、クロスオリジンリソースへのリクエストは PerformanceResourceTiming オブジェクトとして Performance Timeline に含まれます。
timing allow check
アルゴリズムがクロスオリジンリソースに対して失敗すると、そのエントリは opaque entry になります。
そのようなエントリは、クロスオリジンのデータ漏洩を防ぐために多くの属性がマスクされます。したがって opaque entry に対しては、次の属性は常にゼロまたは空文字を返します:
redirectStart,
redirectEnd,
workerStart,
domainLookupStart,
domainLookupEnd,
connectStart,
connectEnd,
requestStart,
firstInterimResponseStart,
finalResponseHeadersStart,
responseStart,
secureConnectionStart,
および
nextHopProtocol。
contentType、encodedBodySize、decodedBodySize のようなプロパティのいくつかは、レスポンスが CORS クロスオリジン の場合に 0 または空文字に設定されます。
transferSize
は timing allow check と CORS クロスオリジンの状況の両方によって影響を受けます。
service worker が respondWith() を使って処理するリクエストについては、報告されるタイミングデータはクライアントとサービスワーカー間の相互作用を反映し、サービスワーカー自身の内部ネットワーク活動を直接反映するものではありません。 例えば、サービスワーカーは同一オリジン要求に対してクロスオリジンレスポンスで応答したり、その逆を行ったり、キャッシュまたは合成レスポンスを返すことがあります。したがって、サービスワーカーから転送されたリソースは fetch の全体像を示さず、timing allow check を通過しません。これらの fetch の完全な情報を得るには、サービスワーカー自身の performance timeline を検査する必要があります。 [SERVICE-WORKERS]
詳細は HTTP Fetch を参照してください。#4 - timing allow check はサービスワーカーからのレスポンスがない場合にのみ実行されます。さらに、respondWith() アルゴリズム内でクローンされる response は内部フェッチの fetch timing info を持たないことに注意してください。
3.5.2.
Timing-Allow-Origin Response Header
サーバー側のアプリケーションは、Timing-Allow-Origin HTTP レスポンスヘッダを返すことで、指定された文書オリジンに対して クロスオリジン制限によりゼロになっていた属性値を完全に公開することを許可できます。
Timing-Allow-Origin ヘッダフィールドは、許可されるオリジンを示すポリシーを伝えるのに使えます。ヘッダの値は次の ABNF で表されます(List Extension を使用):
Timing-Allow-Origin = 1#( origin-or-null / wildcard )
送信者は複数の Timing-Allow-Origin ヘッダフィールドを生成してもよく、受信者は複数フィールドを受け取った場合に値をカンマで連結して結合することができます。
ユーザーエージェントは、Timing-Allow-Origin ヘッダが存在しても transferSize、encodedBodySize、decodedBodySize を 0 にするなどのクロスオリジン制限をまだ強制することがあります。その場合、deliveryType を "" に設定することもあります。
Timing-Allow-Origin ヘッダは FETCH 内で処理され、属性の計算に使われます。
Timing-Allow-Origin ヘッダはキャッシュされたレスポンスの一部として到着することがあります。キャッシュの再検証の場合、RFC 7234 に従い、その値は再検証レスポンスから来るか、もしそこに存在しなければ元のキャッシュ資源から来る可能性があります。
Issues 222 および 223 は、Timing-Allow-Origin からワイルドカードサポートを削除して使用を制限することを提案しています。
3.5.3. IANA Considerations
この節では Timing-Allow-Origin を Provisional Message Header として登録します。
- Header field name:
-
Timing-Allow-Origin
- Applicable protocol:
- http
- Status:
- provisional
- Author/Change controller:
- W3C
- Specification document:
- § 3.5.2 Timing-Allow-Origin Response Header
3.6. Resource Timing Attributes
この節は非規範的です。
次の図は PerformanceResourceTiming インターフェイスで定義されるタイミング属性を示しています。括弧内の属性はクロスオリジンリソースを取得する際に利用できない場合があります。ユーザーエージェントはタイミング間で内部処理を行うことがあり、それによりタイミング間に非規範的な間隔が生じることがあります。
PerformanceResourceTiming
インターフェイスで定義されるタイミング属性を示します。括弧内の属性は timing allow check に失敗した場合に利用できないことを示します。
4. リソースタイミングエントリの作成
リソースタイミングをマークする には、fetch timing info timingInfo、DOMString requestedURL、DOMString initiatorType、グローバルオブジェクト global、文字列 cacheMode、response body info bodyInfo、status responseStatus、および省略可能な文字列 deliveryType(デフォルトは空文字)を与え、以下の手順を実行します:
PerformanceResourceTimingオブジェクト entry を global の realm 内に作成する。- リソースタイミングエントリをセットアップ するために、 entry、initiatorType、requestedURL、timingInfo、cacheMode、 bodyInfo、responseStatus、deliveryType を与える。
- PerformanceEntry entry をキューする。
- 追加する entry を global の パフォーマンスエントリバッファ に。
リソースタイミングエントリをセットアップする
を、DOMString initiatorType、DOMString requestedURL、fetch timing info
timingInfo、DOMString cacheMode、response body info bodyInfo、status
responseStatus、および省略可能な DOMString deliveryType(デフォルトは空文字)を与えて PerformanceResourceTiming
entry に対して実行します:
- cacheMode が空文字列、"
local"、または "validated" であることをアサートする。 - global を entry の 関連グローバルオブジェクト とする。
- 初期化する entry を
変換した
timingInfo の 開始時刻(global を与えて)、
"
resource"、 requestedURL、 さらに 変換した timingInfo の 終了時刻(global を与えて) を与えて実行する。 - entry の イニシエータタイプ に initiatorType を設定する。
- entry の リクエストURL に requestedURL を設定する。
- entry の タイミング情報 に timingInfo を設定する。
- entry の リソース情報 に bodyInfo を設定する。
- entry の キャッシュモード に cacheMode を設定する。
- entry の レスポンスステータス に responseStatus を設定する。
- deliveryType が空文字列で cacheMode が空でない場合、
deliveryType に "
cache" を設定する。 - entry の 配送タイプ に deliveryType を設定する。
フェッチタイムスタンプを変換するには、
DOMHighResTimeStamp
ts および グローバルオブジェクト global を与え、次の手順を実行する:
- ts が 0 の場合、0 を返す。
- それ以外の場合、相対高分解能粗時間 を ts および global を与えて返す。
5. セキュリティに関する考慮事項
PerformanceResourceTiming
インターフェイスは、リソースのタイミング情報を、そのリソースを要求したいかなるウェブページやワーカーにも公開します。アクセスを制限するために、デフォルトで same origin
ポリシーが適用され、特定の属性は HTTP fetch で定義されるように 0 に設定されます。リソース提供者は Timing-Allow-Origin HTTP
レスポンスヘッダーを追加することで、あるリソースに関する全タイミング情報の収集を明示的に許可することができます。このヘッダーはタイミング情報へのアクセスを許可するドメインを指定します。
6. プライバシーに関する考慮事項
統計的フィンガープリンティングはプライバシー上の懸念であり、悪意あるサイトはサードパーティサイトのキャッシュヒット/ミスのタイミングを測定することで、ユーザーが該当サイトを訪れたかどうかを判別できる可能性があります。PerformanceResourceTiming インターフェイスは文書内リソースのタイミング情報を提供しますが、リソースの load イベントはすでに制限的ながらキャッシュヒット/ミスを判断するためのタイミング測定が可能であり、Fetch のクロスオリジン制限が追加情報の漏洩を防ぎます。
7. 謝辞
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 に本作業への貢献に感謝します。