Copyright © 2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
この仕様は、ウェブアプリケーションがドキュメント内のリソースの完全なタイミング情報にアクセスするためのインターフェイスを定義します。
このセクションは、公開時点でのこの文書のステータスについて説明しています。現行標準の一覧やこの技術レポートの最新改訂版は、 W3C 標準と草案インデックスで確認できます。
この文書は、Web パフォーマンス作業グループによって、 勧告プロセスを用いて候補勧告草案として公開されました。
候補勧告としての公開は、W3C およびその会員による支持を意味するものではありません。候補勧告草案は、作業グループが次の候補勧告スナップショットに含める予定の変更を前回の候補勧告から統合したものです。
この文書は草案であり、いつでも更新、置換、または廃止される可能性があります。この文書を進行中の作業以外として引用するのは不適切です。
この文書は、 W3C 特許ポリシー の下で運営されるグループによって作成されました。 W3Cは、 グループの成果物に関連するパテント開示の公開リスト を管理しています。そのページにはパテント開示方法の説明もあります。個人が本当にパテントの存在を知っている場合、そのパテントが 必須のクレーム を含むと考える場合は、W3C 特許ポリシー第6節に従って情報を開示しなければなりません。
この文書は 2025年8月18日 W3C プロセス文書によって管理されています。
このセクションは規範的ではありません。
ユーザーの待ち時間(レイテンシ)は、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>
非規範的と記載されたセクションだけでなく、この仕様書のすべての著者向けガイドライン、図、例、注記も非規範的です。それ以外のすべてが規範的です。
この文書中のキーワード MAY、MUST、および SHOULD は、 BCP 14 [RFC2119] [RFC8174] に記載されている通り、全て大文字で表示されている場合のみそれぞれの意味で解釈されます。
アルゴリズムの一部として命令形で記述された要件(例えば「先頭のスペース文字をすべて削除する」や「falseを返してこれらの手順を中止する」など)は、アルゴリズムの導入に用いられたキーワード("MUST"、"SHOULD"、"MAY"など)の意味で解釈されます。
属性、メソッド、オブジェクトに対する要件として記述されている適合要件の一部は、ユーザーエージェントに対する要件として解釈されます。
アルゴリズムや具体的な手順として記述されている適合要件は、最終的な結果が同等である限り、どのような方法で実装してもかまいません。(特に、この仕様で定義されているアルゴリズムは理解しやすいことを目的としており、性能を意図したものではありません。)
実際にはインターフェイスである Foo に対して、「Foo オブジェクト」という構文が用いられる場合がありますが、これはより正確には「インターフェイス
Foo を実装するオブジェクト」を意味します。
本仕様全体では、すべての時間値はドキュメントのナビゲーション開始からのミリ秒単位で測定されます [HR-TIME]。例えば、 ドキュメントのナビゲーション開始は、時刻0で発生します。
この時間の定義は、High Resolution Time仕様 [HR-TIME]に基づいており、Navigation Timing仕様 [NAVIGATION-TIMING-2]で用いられている、 時間が1970年1月1日午前0時(UTC)からのミリ秒で測定される定義とは異なります。
このセクションは規範的ではありません。
PerformanceResourceTiming インターフェイスは、
フェッチされた
http(s)
リソースのタイミング計測を可能にします。例えば、このインターフェイスは
XMLHttpRequest オブジェクト [XHR] や、
iframe、
img、
script、
object、
embed、
link
(linkタイプが
stylesheetの場合)などの
HTML要素 [HTML] や、
svg などの SVG要素 [SVG11]、
EventSource
に対して利用可能です。
PerformanceResourceTiming
インターフェイスに含まれるリソース
このセクションは規範的ではありません。
非nullのclientによって
Requestが
フェッチされると、
PerformanceResourceTiming オブジェクトとして
グローバルオブジェクトの
Performance
Timelineに含まれます。
ただし、フェッチ処理の一部として
タイムラインから除外される場合は含まれません。HTTPキャッシュから取得されたリソースも
PerformanceResourceTiming オブジェクトとして
Performance
Timelineに含まれます。
フェッチが開始されたが後に中断された(例:ネットワークエラー等)リソースも、
開始・終了タイミングとともに
PerformanceResourceTiming オブジェクトとして
Performance
Timelineに含まれます。
例:
IMG要素のsrc属性として使用された場合、最初のHTML IMG要素によって開始された
フェッチは
PerformanceResourceTiming
オブジェクトとして
Performance
Timelineに含まれます。
ユーザーエージェントは2つ目のHTML IMG要素用にURLを再度リクエストせず、最初のHTML IMG要素のために開始された
既存のダウンロードを利用する場合があります。この場合、最初のIMG要素による
フェッチのみが
Performance
Timelineに記録されます。
IMG要素のsrc属性がスクリプトにより変更された場合、元のリソースの
フェッチと、
新しいURLのフェッチの両方が
PerformanceResourceTiming
オブジェクトとして
Performance
Timelineに含まれます。
IFRAME要素がマークアップで追加され、src属性が指定されていない場合、
ユーザーエージェントはabout:blankドキュメントをロードする場合があります。
後でsrc属性がスクリプトで動的に変更された場合、ユーザーエージェントは新しいURLリソースを
フェッチする場合があります。
この場合、新しいURLの
フェッチのみが
PerformanceResourceTiming
オブジェクトとして
Performance
Timelineに含まれます。
XMLHttpRequestが2回生成された場合、両方の
フェッチは
PerformanceResourceTiming
オブジェクトとして
Performance
Timelineに含まれます。
これは、2回目のXMLHttpRequestのリソースフェッチが最初のXMLHttpRequestで発行されたダウンロードを
再利用できないためです。
IFRAME要素がページに含まれている場合、
IFRAMEのsrc属性によってリクエストされたリソースのみが
PerformanceResourceTiming
オブジェクトとして
Performance
Timelineに含まれます。
IFRAMEドキュメントでリクエストされるサブリソースは
IFRAMEドキュメントの
Performance
Timelineに含まれ、
親ドキュメントのPerformance
Timelineには含まれません。
IMG要素が
data: URIをソースとして持つ場合
[RFC2397]、
このリソースは
PerformanceResourceTiming オブジェクトとして
Performance
Timelineに含まれません。
PerformanceResourceTiming エントリは
http(s)リソースのみが報告されます。
PerformanceResourceTiming
オブジェクトとして
Performance
Timelineに含まれ、
startTime、fetchStart、duration、responseEndのみが設定されます。
PerformanceResourceTiming
オブジェクトとして
Performance
Timelineに含まれません。
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 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 が呼び出されたときは、
default toJSON
steps
を PerformanceResourceTiming に対して実行します。
initiatorType のgetter手順は、initiator type を this に対して返します。
initiatorType は次のいずれかの値を返します:
"navigation":リクエストが navigation request の場合
"body":リクエストが
body
要素の background 属性の処理によるもので、すでに廃止されています。
"css"。リクエストが
@import
url()
や
background: url()
のような CSS の
url() 指令を処理した結果である場合。
[CSS-VALUES]
注: CSS において @font-face で指定されたフォント・リソースへのリクエストは、CSS
指令を処理した結果である。したがって、このフォント・リソースの initiatorType は "css" である。
"script":リクエストが
script(クラシック
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":リクエストが
image
要素の処理による場合。[SVG2]
"input":リクエストが
input
要素(
type
が
image
)の処理による場合
"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 を this に対して返します。
deliveryTypeは次のいずれかの値を返します:
"cache":cache mode
が空文字列でない場合
""この値は、今後の仕様更新で拡張される予定です(例:プリロードリソースやプリフェッチナビゲーションリクエストの記述)。
workerStart のgetter手順は、fetchタイムスタンプの変換を
this の
timing info の
final
service worker start time および
relevant
global object に対して実行します。詳細は HTTP fetch を参照してください。
redirectStart のgetter手順は、fetchタイムスタンプの変換を
this の
timing info の
redirect start time
および
relevant
global object に対して実行します。詳細は HTTP-redirect fetch を参照してください。
redirectEnd のgetter手順は、fetchタイムスタンプの変換を
this の
timing info の
redirect end time および
relevant
global object に対して実行します。詳細は HTTP-redirect fetch を参照してください。
fetchStart のgetter手順は、fetchタイムスタンプの変換を
this の
timing info の
post-redirect start
time および
relevant
global object に対して実行します。詳細は HTTP fetch を参照してください。
domainLookupStart のgetter手順は、fetchタイムスタンプの変換を
this の
timing info の
final
connection timing info の
domain lookup
start time および
relevant
global object に対して実行します。詳細は 接続タイミング情報の記録 を参照してください。
domainLookupEnd のgetter手順は、fetchタイムスタンプの変換を
this の
timing info の
final
connection timing info の
domain lookup
end time および
relevant
global object に対して実行します。詳細は 接続タイミング情報の記録 を参照してください。
connectStart のgetter手順は、fetchタイムスタンプの変換を
this の
timing info の
final
connection timing info の
connection start
time および
relevant
global object に対して実行します。詳細は 接続タイミング情報の記録 を参照してください。
connectEnd のgetter手順は、fetchタイムスタンプの変換を
this の
timing info の
final
connection timing info の
connection end
time および
relevant
global object に対して実行します。詳細は 接続タイミング情報の記録 を参照してください。
secureConnectionStart のgetter手順は、fetchタイムスタンプの変換を
this の
timing info の
final
connection timing info の
secure
connection start time および
relevant
global object に対して実行します。詳細は 接続タイミング情報の記録 を参照してください。
nextHopProtocol のgetter手順は、
isomorphic decode を
this の
timing info の
final
connection timing info の
ALPN
negotiated protocol に対して実行します。詳細は 接続タイミング情報の記録 を参照してください。
Issue 221は nextHopProtocolのサポートを削除することを提案しています。これは、ユーザーのネットワーク構成に関する詳細を暴露する可能性があるためです。
requestStart のgetter手順は、fetchタイムスタンプの変換を
this の
timing info の
final
network-request start time および
relevant
global object に対して実行します。詳細は HTTP fetch を参照してください。
firstInterimResponseStart のgetter手順は、
fetchタイムスタンプの変換を
this の
timing info の
first
interim network-response start time および
relevant
global object に対して実行します。詳細は HTTP fetch を参照してください。
finalResponseHeadersStart のgetter手順は、
fetchタイムスタンプの変換を
this の
timing info の
final
network-response start time および
relevant
global object に対して実行します。詳細は HTTP fetch を参照してください。
responseStart のgetter手順は、
this の
firstInterimResponseStart
が 0 でない場合はそれを返し、そうでなければ
this の
finalResponseHeadersStart
を返します。
responseEnd のgetter手順は、fetchタイムスタンプの変換を
this の
timing info の
end time
および
relevant
global object に対して実行します。詳細は
fetch を参照してください。
encodedBodySize のgetter手順は、
this の
resource info の
encoded size を返します。
decodedBodySize のgetter手順は、
this の
resource info の
decoded size を返します。
transferSize のgetter手順は以下の通りです:
this の
cache mode が "local"
の場合は 0 を返す。
this の
cache mode が "validated"
の場合は 300 を返す。
this の response body info の encoded size に 300 を加えて返す。
transferSizeに加算される定数値は、HTTPヘッダーの総バイト数を公開するかわりです。これは特定のクッキーの存在を暴露する可能性があるためです。詳細は
このissue を参照してください。
responseStatus のgetter手順は、
this の
response status を返します。
responseStatusは Fetch で決定されます。クロスオリジンの
no-cors リクエストの場合、
レスポンスは opaque filtered
response
となるため、0 になります。
contentType のgetter手順は、
this の
resource info の
content
type を返します。
contentEncoding のgetter手順は、
this の
resource info の
content encoding
を返します。
renderBlockingStatus のgetter手順は、
blocking を返します。
ただし
this の
timing info の
render-blocking が true
の場合のみで、
それ以外は
non-blocking を返します。
workerRouterEvaluationStart の getter 手順は、次を返すことである:
this の timing
info の service worker
timing info の
worker
router evaluation start。
workerCacheLookupStart の getter 手順は、次を返すことである:
this の timing
info の service worker
timing info の
worker
cache lookup start。
workerMatchedRouterSource の getter 手順は、次を返すことである:
this の timing
info の service worker
timing info の
worker
matched router source。
workerFinalRouterSource の getter 手順は、
return
this の timing
info の service worker
timing info の
worker
final router source を返すことである。
PerformanceResourceTiming
を実装するユーザーエージェントは
"resource" を
supportedEntryTypes
に含める必要があります。これにより、開発者はResource Timingのサポートを検出できます。
WebIDLenum RenderBlockingStatusType {
"blocking",
"non-blocking"
};
値の定義は以下の通りです:
blocking
non-blocking
ユーザーエージェントは、PerformanceResourceTiming オブジェクトとして
Performance Timeline
[PERFORMANCE-TIMELINE-2] に含まれるリソース数を
制限することが できます。
本セクションは、Performance
インターフェイスに、PerformanceResourceTiming
オブジェクトの保存数を制御する機能を追加します。
推奨される PerformanceResourceTiming
オブジェクトの最小数は 250 ですが、これはユーザーエージェントによって変更可能です。
この制限の変更は setResourceTimingBufferSize
を呼び出して要求できます。
各 ECMAScript グローバル環境は次を持ちます:
PerformanceResourceTiming
オブジェクトを格納、初期値は空)
WebIDLpartial interface Performance {
undefined clearResourceTimings ();
undefined setResourceTimingBufferSize (unsigned long maxSize);
attribute EventHandler onresourcetimingbufferfull;
};
Performance インターフェイスは
[HR-TIME] で定義されています。
clearResourceTimings メソッドは次の手順を実行します:
PerformanceResourceTiming オブジェクトを
performance entry
buffer からすべて削除します。
setResourceTimingBufferSize メソッドは次の手順を実行します:
PerformanceResourceTiming オブジェクトは
performance entry
buffer から削除しません。
onresourcetimingbufferfull 属性は、
以下で説明する resourcetimingbufferfull イベントのイベントハンドラーです。
リソースタイミングエントリ追加可能か を判定するには、次の手順を実行します:
PerformanceResourceTimingエントリ追加(new entry)を performance entry buffer に追加するには、次の手順を実行します:
セカンダリバッファのコピー は次の手順で実行します:
PerformanceResourceTiming
のうち最も古いものとして
リソースタイミングセカンダリバッファから取得
バッファフルイベント発火 は次の手順で実行します:
resourcetimingbufferfull)、
Performance オブジェクトに対して
これは resourcetimingbufferfull イベントハンドラーが
バッファに追加するリソースより多くのバッファ領域を追加しない場合、
余分なエントリがバッファから破棄されることを意味します。
開発者は resourcetimingbufferfull イベントハンドラーで
clearResourceTimings を呼び出すか、十分にバッファ拡張
(setResourceTimingBufferSize の呼び出し)するようにしてください。
この節は非規範である。
Fetch で詳述されているとおり、 クロスオリジン・リソースに対するリクエストはPerformanceResourceTiming オブジェクトとして
Performance
Timeline に含まれる。
クロスオリジン・リソースに対して timing
allow check アルゴリズムが失敗した場合、
エントリは 不透明エントリ となる。そのような
エントリでは、他に公開されていないクロスオリジン・データの漏えいを防ぐため、
属性の大部分がマスクされる。したがって、
不透明エントリ では、次の
属性は常に 0 または空文字列を返す:
redirectStart,
redirectEnd,
workerStart,
domainLookupStart,
domainLookupEnd,
connectStart,
connectEnd,
requestStart,
firstInterimResponseStart,
finalResponseHeadersStart,
responseStart,
secureConnectionStart,
および nextHopProtocol.
contentType,
encodedBodySize,
および
decodedBodySize
のようないくつかのプロパティは、レスポンスが
CORS-cross-origin であるとき、
0(contentType の場合は空文字列)
に設定される。
transferSize は、
timing
allow check と
CORS-cross-origin
状態の双方の影響を受ける。
service
worker が respondWith()
を用いて処理するリクエストでは、報告されるタイミング・データは、
service worker 自身の内部ネットワーク活動ではなく、
クライアントと service worker の相互作用を反映する。
例えば、service worker は同一オリジンのリクエストに対してクロスオリジンのレスポンスを返すことも、その逆もあり得るし、
どちらに対してもキャッシュ済みまたは合成(synthetic)レスポンスを返すこともある。
このため、service worker から転送されたリソースは、リソースの取得の全体像を示すものではなく、
timing
allow check を通過しない。
これらの fetch について完全な情報を得るには、service worker 自身の performance timeline を調べることができる。 [SERVICE-WORKERS]
詳細は HTTP Fetch #4 を参照 —
timing
allow check は、service worker からのレスポンスがない場合にのみ実行される。
さらに、respondWith()
アルゴリズムで複製(clone)される response は、内部 fetch の
fetch timing
info
を保持しない。というのも、その情報は response ではなく
fetch に付随するためである。
サーバー側アプリケーションは、ユーザーエージェントが、指定された文書オリジンに対して、 これらのクロスオリジン制限により 0 となっていた属性値を完全に公開できるようにするため、 Timing-Allow-Origin HTTP レスポンス・ヘッダーを返してよい。
Timing-Allow-Origin HTTP レスポンス・ヘッダー・フィールドは、 クロスオリジン制限により 0 となっていた属性値を参照することが許可される オリジンを示すポリシーを伝達するために使用できる。 ヘッダーの値は、次の ABNF [RFC5234](List Extension を使用、[RFC9110])で表される:
Timing-Allow-Origin = 1#( origin-or-null / wildcard )
送信者は Timing-Allow-Origin ヘッダー・フィールドを複数生成してもよい。 受信者は、複数の Timing-Allow-Origin ヘッダー・フィールドを、 後続の各フィールド値を順に結合フィールド値へ付加し、コンマで区切ることで、結合してもよい。
ユーザーエージェントは、Timing-Allow-Origin HTTP レスポンス・ヘッダー・フィールドがあっても、 なおクロスオリジン制限を強制し、transferSize、encodedBodySize、decodedBodySize 属性を 0 に設定してもよい。そうする場合、deliveryType を "" に設定してもよい。
Timing-Allow-Origin ヘッダーは、 属性を適切に計算するために FETCH で処理される。
Timing-Allow-Origin ヘッダーは、キャッシュされたレスポンスの一部として到着することがある。 キャッシュ再検証の場合、RFC 7234 によれば、 ヘッダーの値は再検証レスポンスに由来することがあり、そこに存在しない場合は、 元のキャッシュ済みリソースに由来し得る。
この節は Timing-Allow-Origin を 暫定メッセージ・ヘッダー として登録する。
Timing-Allow-Origin
Timing-Allow-Origin レスポンス・ヘッダー
この節は非規範である。
次の図は、 PerformanceResourceTiming インターフェイスで定義されるタイミング属性を示す。 括弧内の属性は、 クロスオリジン・リソースを 取得 する際に利用できない場合がある。ユーザーエージェントは タイミングの合間に内部処理を行うことがあり、 その結果、タイミング間に非規範な間隔が生じ得る。
PerformanceResourceTiming
インターフェイスで定義されるタイミング属性を示す。
括弧内の属性は、リソースが
timing allow
check アルゴリズムに失敗した場合に利用できない可能性があることを示す。
fetch timing info timingInfo、 DOMString requestedURL、DOMString initiatorType、グローバル・オブジェクト global、文字列 cacheMode、response body info bodyInfo、 status responseStatus、 および省略可能な 文字列 deliveryType(既定では空文字列) が与えられたときに リソース・タイミングをマークする には、 次の手順を実行する:
PerformanceResourceTiming オブジェクト
entry を、
global の realm
内に作成する。
DOMString
initiatorType、DOMString requestedURL、
fetch timing info
timingInfo、DOMString cacheMode、
response body info
bodyInfo、
status
responseStatus、
および省略可能な DOMString deliveryType(既定では空文字列)
が与えられたときに
PerformanceResourceTiming
entry に対して
リソース・タイミング・エントリをセットアップする には、
次の手順を実行する:
local"、または "validated" であることを表明する。
resource"、requestedURL、
および global が与えられたときの
timingInfo の
終了時刻 を
変換 した結果で与えられる結果に基づいて行う。
cache" に設定する。
DOMHighResTimeStamp
ts と
グローバル・オブジェクト
global が与えられたときに
fetch
timestamp を変換する には、次のとおりにする:
この節は非規範である。
PerformanceResourceTiming インターフェイスは、
そのリソースを要求した任意のウェブページまたはワーカーに対して、
リソースのタイミング情報を公開する。PerformanceResourceTiming インターフェイスへの
アクセスを制限するため、
同一オリジン ポリシーが既定で強制され、
HTTP fetch に記述されるとおり、
いくつかの属性は 0 に設定される。
リソース提供者は、アクセスが許可されるドメインを指定する
Timing-Allow-Origin
HTTP レスポンス・ヘッダーを追加することにより、
リソースに関するすべてのタイミング情報が収集されることを明示的に許可できる。
この節は非規範である。
統計的フィンガープリンティングは、悪意のあるウェブサイトが、
サードパーティのウェブサイト上のリソースについてキャッシュ・ヒット/ミスのタイミングを測定することで、
ユーザーがそのサードパーティ・ウェブサイトを訪問したかどうかを判定し得る、というプライバシー上の懸念である。
PerformanceResourceTiming
インターフェイスは文書内のリソースに関するタイミング情報を提供するが、
リソースに対する load イベントでも、限定的な形ではキャッシュ・ヒット/ミスを判定するためのタイミング測定をすでに行える。
また、HTTP
Fetch におけるクロスオリジン制限は、追加情報の漏えいを防ぐ。
本作業への貢献に対し、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 に感謝する。
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in: