Copyright © 2025 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":リクエストがCSSの url() 指令(
@import
url()やbackground: 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 を返します。
The workerRouterEvaluationStart getter の手順は
this の
timing info の
service worker
timing info の
worker
router evaluation start を返します。
The workerCacheLookupStart getter の手順は
this の
timing info の
service worker
timing info の
worker
cache lookup start を返します。
The workerMatchedRouterSource getter の手順は
this の
timing info の
service worker
timing info の
worker
matched router source を返します。
The workerFinalRouterSource getter の手順は
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アルゴリズムが失敗すると、
エントリは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レスポンスヘッダーを返すことで、ドキュメントのオリジン(指定されたもの)に対し、クロスオリジン制限でゼロになった属性値を完全に公開することができます。
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に従い、 ヘッダー値は再検証レスポンスから、そこに存在しない場合は元のキャッシュリソースから取得されることがあります。
本セクションは Timing-Allow-Origin を 仮メッセージヘッダーとして登録します。
Timing-Allow-Origin
Timing-Allow-Origin レスポンスヘッダー
このセクションは規範的ではありません。
以下のグラフは、PerformanceResourceTimingインターフェイスで定義されるタイミング属性を示します。 括弧内の属性は、クロスオリジンリソースのフェッチ時に利用できない場合があります。 ユーザーエージェントはタイミング間で内部処理を行うことがあり、タイミング間に非規範的な間隔が発生する場合があります。
PerformanceResourceTiming
インターフェイスで定義されるタイミング属性を示します。括弧内の属性は、
リソースがtiming allow
checkアルゴリズムに失敗した場合に
利用できない可能性があります。
mark resource timing を行うには、fetch timing info timingInfo、 DOMString requestedURL、 DOMString initiatorType、 global object global、 string cacheMode、 response body info bodyInfo、 status responseStatus、 およびオプションの string deliveryType (デフォルトは空文字列)を与え、以下の手順を実行します:
PerformanceResourceTiming オブジェクト
entry を
global の realm
に作成します。
リソースタイミングエントリのセットアップ を
PerformanceResourceTiming
entry に対して、
DOMString initiatorType、DOMString requestedURL、fetch timing info
timingInfo、DOMString cacheMode、response body info
bodyInfo、status
responseStatus、およびオプションのDOMString deliveryType(デフォルトは空文字列)を与え、以下の手順を実行します:
local"、または "validated" であることを確認します。
resource"、requestedURL、
および fetchタイムスタンプの変換で得た
timingInfo の
end
time を与えます。
cache" に設定します。
fetchタイムスタンプの変換は、
DOMHighResTimeStamp
ts と global object
global を与えて、以下を実行します:
このセクションは規範的ではありません。
PerformanceResourceTiming インターフェイスは、
リソースのタイミング情報をリソースをリクエストしたすべてのウェブページやワーカーに公開します。
PerformanceResourceTiming
インターフェイスへのアクセスを制限するために、
デフォルトで 同一オリジン ポリシーが適用され、
一部の属性がゼロに設定されます(詳細は HTTP fetch を参照)。
リソース提供者は、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: