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 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
を返します。
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: