1. 序論
◎非規範的利用者が知覚し得る待時間は Web ~appにとり重要な品質~benchmarkである。 ~JSに基づく仕組みは、 ~appにおける利用者~側の待時間を測定するための包括的な~~手段を供せるが、 端点間の待時間については,多くの事例で,完全な様相を供せない。 この仕様は、 `PerformanceResourceTiming$I ~interfaceを導入する。 それは、 ~JSにより,文書~上の資源に関係する完全な計時~情報を収集するための仕組みである。 `NAVIGATION-TIMING-2$r は、 この仕様を拡張して,~naviに関わる追加的な計時~情報を供する。 ◎ User latency is an important quality benchmark for Web Applications. While JavaScript-based mechanisms can provide comprehensive instrumentation for user latency measurements within an application, in many cases, they are unable to provide a complete end-to-end latency picture. This document introduces the PerformanceResourceTiming interface to allow JavaScript mechanisms to collect complete timing information related to resources on a document. Navigation Timing 2 [NAVIGATION-TIMING-2] extends this specification to provide additional timing information associated with a navigation.
例えば、 次のような~JSで, 資源~fetchにかかった時間を単純に測定しようと試みた場合: ◎ For example, the following JavaScript shows a simple attempt to measure the time it takes to fetch a resource:
<!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>
この~scriptは,資源~fetchに要した時間は測定できるが、 その内訳を成す各~相に費やされた時間は測定できない。 更に、 ~markupにより記述された資源に費やされた時間を, この~scriptで測定することは容易でない。 ◎ Though this script can measure the time it takes to fetch a resource, it cannot break down the time spent in various phases. Further, the script cannot easily measure the time it takes to fetch resources described in markup.
利用者~体験に関する完全な情報の必要性に取組むため、 この文書は `PerformanceResourceTiming$I ~interfaceを導入する。 この~interfaceは、 ~JSによる[ ~client側~appにおける待時間の完全な測定を可能にする仕組み ]を供する。 この~interfaceにより、 前の例は,利用者が知覚する資源の読込n時間を測定-可能なものに仕立て上げられる。 ◎ To address the need for complete information on user experience, this document introduces the PerformanceResourceTiming interface. This interface allows JavaScript mechanisms to provide complete client-side latency measurements within applications. With this interface, the previous example can be modified to measure a user's perceived load time of a resource.
次の~scriptは、 ~markupにより定義されたものまで含め, ~page内の各~資源~fetchに要した時間の~~長さを計算する。 この例は、 ~pageが https://www.w3.org の下に~hostされていると見做している。 その気になれば、 `PerformanceResourceTiming$I ~interfaceを利用して, 資源~fetchingの各~相に要した時間も測定できる。 ◎ The following script calculates the amount of time it takes to fetch every resource in the page, even those defined in markup. This example assumes that this page is hosted on https://www.w3.org. One could further measure the amount of time it takes in every phase of fetching a resource with the PerformanceResourceTiming interface.
<!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. 適合性の要件
【 この節の内容は `~W3C日本語訳 共通~page@~W3Ccommon#conformance$ に移譲。 】
3. 各種用語
【 この節の内容の和訳は、 省略する。 】 ◎ The construction "a Foo object", where Foo is actually an interface, is sometimes used instead of the more accurate "an object implementing the interface Foo. ◎ Throughout this work, all time values are measured in milliseconds since the start of navigation of the document [HR-TIME]. For example, the start of navigation of the document occurs at time 0. ◎ Note This definition of time is based on the High Resolution Time specification [HR-TIME] and is different from the definition of time used in the Navigation Timing specification [NAVIGATION-TIMING-2], where time is measured in milliseconds since midnight of January 1, 1970 (UTC).
【この訳に特有な表記規約】
◎表記記号4. 資源~計時
4.1. 序論
◎非規範的`PerformanceResourceTiming$I ~interfaceは、 `~fetch$される `http(s)@~FETCH#http-scheme$ 資源の計時~測定を手助けする。 例えば、 次に挙げるものに利用できる:
- `XMLHttpRequest$I ~obj `XHR$r
- `iframe$e, `img$e, `script$e, `object$e, `embed$e, [ ~link型 `stylesheet$v を伴う `link$e ]などの~HTML要素 `HTML$r
- `svg$e などの~SVG要素 `SVG11$r
- `EventSource$I
4.2. `PerformanceResourceTiming^I ~interfaceが対象にする資源
◎非規範的~NULL でない`~client$rqからの`要請$により`~fetch$される すべての資源 — ~HTTP~cache【あるいは~sw】から検索取得されたものも含む — は、 `~fetching$の一部として除外されない限り, `PerformanceResourceTiming$I ~objとして`~client$rqの`大域~obj$の`処理能~時列線$に含まれる。 ~fetchにより起動されたが後で中止された資源は (例:~network~errorなどに因り)、 その[ 開始, 終了 ]の計時を伴って,`処理能~時列線$に含まれる。 ◎ Resource Requests fetched by a non-null client are included as PerformanceResourceTiming objects in the client's global object's Performance Timeline, unless excluded from the timeline as part of the fetching process. Resources that are retrieved from HTTP cache are included as PerformanceResourceTiming objects in the Performance Timeline. Resources for which the fetch was initiated, but was later aborted (e.g. due to a network error) are included as PerformanceResourceTiming objects in the Performance Timeline, with their start and end timing.
例えば: ◎ Examples:
- 複数の~HTML `img$e 要素の `src^a 属性に,正準-形が同じになる~URL( `the same canonical URL^en 【すなわち,同じ資源を指す~URL】 )が利用されている場合、[ 最初に資源`~fetch$を起動した `img^e 要素 ]の方が[ `PerformanceResourceTiming$I ~objとして`処理能~時列線$に含められる ]ことになろう。 ~UAは、 2 個目以降の `img^e 要素の~URLに対しては、 再~要請することなく, 最初に起動された方による既存の~downloadを利用すると見込まれるので。 この場合,`処理能~時列線$には、 最初に起動された `img^e 要素に対する資源`~fetch$による結果のみが現れることになる。 ◎ If the same canonical URL is used as the src attribute of two HTML IMG elements, the fetch of the resource initiated by the first HTML IMG element would be included as a PerformanceResourceTiming object in the Performance Timeline. The user agent might not re-request the URL for the second HTML IMG element, instead using the existing download it initiated for the first HTML IMG element. In this case, the fetch of the resource by the first IMG element would be the only occurrence in the Performance Timeline.
- ~HTML `img$e 要素の `src^a 属性が~scriptから変更された場合、 元々の資源`~fetch$のみならず,新たな~URLへの`~fetch$も[ `PerformanceResourceTiming$I ~objとして`処理能~時列線$に含められる ]ことになる。 ◎ If the src attribute of a HTML IMG element is changed via script, both the fetch of the original resource as well as the fetch of the new URL would be included as PerformanceResourceTiming objects in the Performance Timeline.
- ~HTML `iframe$e 要素の~markupに `src^a 属性が指定されていない場合、 ~UAは `about:blank^c 文書を読込むことになる。 後で~scriptから `src^a 属性が動的に変更された場合、 その新たな~URLの資源へ`~fetch$されることになる。 この場合、新たな~URLによる`~fetch$のみが[ `PerformanceResourceTiming$I ~objとして`処理能~時列線$に含められる ]ことになる。 ◎ If an HTML IFRAME element is added via markup without specifying a src attribute, the user agent may load the about:blank document for the IFRAME. If at a later time the src attribute is changed dynamically via script, the user agent may fetch the new URL resource for the IFRAME. In this case, only the fetch of the new URL would be included as a PerformanceResourceTiming object in the Performance Timeline.
- 正準-形が同じになる~URL用に,複数の `XMLHttpRequest$I が生成された場合、 いずれの資源`~fetch$も[ `PerformanceResourceTiming$I ~objとして`処理能~時列線$に含められる ]ことになる — 後続する資源~fetch要請には、 先行する要請による~downloadを再利用できないので。 ◎ If an XMLHttpRequest is generated twice for the same canonical URL, both fetches of the resource would be included as a PerformanceResourceTiming object in the Performance Timeline. This is because the fetch of the resource for the second XMLHttpRequest cannot reuse the download issued for the first XMLHttpRequest.
- ~page内の~HTML `iframe$e 要素に内包された文書により要請される下位資源は、 親~文書の`処理能~時列線$ではなく,内包された文書の`処理能~時列線$に含められる。 `iframe^e に対し`処理能~時列線$に含められるのは、 その `src^a 属性により要請される資源に限られる。 ◎ If an HTML IFRAME element is included on the page, then only the resource requested by IFRAME src attribute is included as a PerformanceResourceTiming object in the Performance Timeline. Sub-resources requested by the IFRAME document will be included in the IFRAME document's Performance Timeline and not the parent document's Performance Timeline.
- HTML `img$e 要素の~sourceが `data: URI@~RFCx/rfc2397.html$ `RFC2397$r である場合、 その資源は,`処理能~時列線$には含められない。 `PerformanceResourceTiming$I ~entryは、 `http(s)@~FETCH#http-scheme$ 資源~用に限り報告される。 ◎ If an HTML IMG element has a data: URI as its source [RFC2397], then this resource will not be included as a PerformanceResourceTiming object in the Performance Timeline. PerformanceResourceTiming entries are only reported for http(s) resources.
- 資源`~fetch$が~network~error( ~DNS, ~TCP, ~TLS ~errorなど)に因り中止された場合、 その~fetchは, `PerformanceResourceTiming$I ~objとして — [ `startTime$m, `fetchStart$m, `duration$m, `responseEnd$m ]に限り,設定された上で — `処理能~時列線$に含められることになる。 ◎ If a resource fetch was aborted due to a networking error (e.g. DNS, TCP, or TLS error), then the fetch will be included as a PerformanceResourceTiming object in the Performance Timeline with only the startTime, fetchStart, duration and responseEnd set.
- 資源`~fetch$が事前条件 (例: 混在内容( `mixed content^en ), ~CORS制約, ~CSP施策, など) に失敗したことにより中止された場合、 その資源については,`処理能~時列線$には含められないことになる。 ◎ If a resource fetch is aborted because it failed a fetch precondition (e.g. mixed content, CORS restriction, CSP policy, etc), then this resource will not be included as a PerformanceResourceTiming object in the Performance Timeline.
4.3. `PerformanceResourceTiming^I ~interface
[`Exposed$=(Window,Worker)] interface `PerformanceResourceTiming@I : `PerformanceEntry$I { readonly attribute `DOMString$ `initiatorType$m; readonly attribute `DOMString$ `deliveryType$m; readonly attribute `ByteString$ `nextHopProtocol$m; readonly attribute `DOMHighResTimeStamp$ `workerStart$m; readonly attribute `DOMHighResTimeStamp$ `redirectStart$m; readonly attribute `DOMHighResTimeStamp$ `redirectEnd$m; readonly attribute `DOMHighResTimeStamp$ `fetchStart$m; readonly attribute `DOMHighResTimeStamp$ `domainLookupStart$m; readonly attribute `DOMHighResTimeStamp$ `domainLookupEnd$m; readonly attribute `DOMHighResTimeStamp$ `connectStart$m; readonly attribute `DOMHighResTimeStamp$ `connectEnd$m; readonly attribute `DOMHighResTimeStamp$ `secureConnectionStart$m; readonly attribute `DOMHighResTimeStamp$ `requestStart$m; readonly attribute `DOMHighResTimeStamp$ `finalResponseHeadersStart$m; readonly attribute `DOMHighResTimeStamp$ `firstInterimResponseStart$m; readonly attribute `DOMHighResTimeStamp$ `responseStart$m; readonly attribute `DOMHighResTimeStamp$ `responseEnd$m; readonly attribute `unsigned long long$ `transferSize$m; readonly attribute `unsigned long long$ `encodedBodySize$m; readonly attribute `unsigned long long$ `decodedBodySize$m; readonly attribute `unsigned short$ `responseStatus$m; readonly attribute `RenderBlockingStatusType$I `renderBlockingStatus$m; readonly attribute `DOMString$ `contentType$m; [`Default$] `object$ `toJSON$m(); };
各 `PerformanceResourceTiming$I ~objには、 次に挙げるものが結付けられる: ◎ ↓
- `起動元~種別@pT ⇒ `文字列$ ◎ A PerformanceResourceTiming has an associated DOMString initiator type.
- `送達~種別@pT ⇒ `文字列$ ◎ A PerformanceResourceTiming has an associated DOMString delivery type.
- `要請~URL@pT ⇒ `文字列$ ◎ A PerformanceResourceTiming has an associated DOMString requested URL.
- `~cache~mode@pT ⇒ `文字列$ — 次のいずれか ⇒# 空~文字列 / `local^l / `validated^l ◎ A PerformanceResourceTiming has an associated DOMString cache mode (the empty string, "local", or "validated").
- `計時~報@pT ⇒ `~fetch計時~報$ ◎ A PerformanceResourceTiming has an associated fetch timing info timing info.
- `資源~情報@pT ⇒ `応答~本体~報$ ◎ A PerformanceResourceTiming has an associated response body info resource info.
- `応答~状態s@pT ⇒ `状態s$ ◎ A PerformanceResourceTiming has an associated status response status.
- `具現化を阻むか@pT ⇒ `RenderBlockingStatusType$I 値 ◎ A PerformanceResourceTiming has an associated RenderBlockingStatusType render-blocking status.
`toJSON()@m は、 `PerformanceResourceTiming$I 用の`既定の~toJSON手続き$ `WEBIDL$r を走らす。 ◎ When toJSON is called, run the default toJSON steps for PerformanceResourceTiming.
`initiatorType@m 取得子~手続きは ⇒ ~RET コレの`起動元~種別$pT ◎ initiatorType getter steps are to return the initiator type for this.
注記: `initiatorType$m は、 次に挙げるいずれかの値を返す: ◎ Note initiatorType returns one of the following values:
- `navigation^l ⇒ 当の要請は、 `~navi要請$である場合 ◎ "navigation", if the request is a navigation request;
- `css^l ⇒ 当の要請は、 ある~CSS `url()$v 指令 `CSS-VALUES$r — `@import url()^css や `background: url()^css など — を処理した結果である場合 ◎ "css", if the request is a result of processing a CSS url() directive such as @import url() or background: url(); [CSS-VALUES]
-
`script^l ⇒ 当の要請は、 `~script$ ( `古典~script$ / `~module~script$ / `Worker$I ) を読込むもの【!読込んだ結果】である場合
【 ~module~scriptには、 ~CSS~module~scriptも含まれる。 字義通り解釈するなら、 これも `css^l ではなく `script^l を返すことになる。 】
◎ "script", if the request is a result of loading any script (a classic script, a module script, or a Worker). - `xmlhttprequest^l ⇒ 当の要請は、 `XMLHttpRequest$I を処理した結果である場合 ◎ "xmlhttprequest", if the request is a result of processing an XMLHttpRequest;
- `fetch^l ⇒ 当の要請は、 `fetch()$m ~methodを処理した結果である場合 ◎ "fetch", if the request is the result of processing the fetch() method;
- `beacon^l ⇒ 当の要請は、 `sendBeacon()$m ~method `BEACON$r を処理した結果である場合 ◎ "beacon", if the request is the result of processing the sendBeacon() method; [BEACON]
- `video^l ⇒ 当の要請は、 `video$e 要素の[ `poster$a / `src!media$a ]属性を処理した結果である場合 ◎ "video", if the request is the result of processing the video element's poster or src.
- `audio^l ⇒ 当の要請は、 `audio$e 要素の `src!media$a 属性を処理した結果である場合 ◎ "audio", if the request is the result of processing the audio element's src.
- `track^l ⇒ 当の要請は、 `track$e 要素の `src!track$a 属性を処理した結果である場合 ◎ "track", if the request is the result of processing the track element's src.
- `img^l ⇒ 当の要請は、 `img$e 要素の[ `src!img$a / `srcset$a ]属性を処理した結果である場合 ◎ "img", if the request is the result of processing the img element's src or srcset.
- `image^l ⇒ 当の要請は、 `image$e 要素 `SVG2$r を処理した結果である場合 ◎ "image", if the request is the result of processing the image element. [SVG2]
- `input^l ⇒ 当の要請は、 `input$e 要素のうち[ `type$a 属性が `image$v 状態にあるもの ]を処理した結果である場合 ◎ "input", if the request is the result of processing an input element of type image.
- `a^l ⇒ 当の要請は、 `a$e 要素の[ `download$a / `ping$a ]属性を処理した結果である場合 ◎ "a", if the request is the result of processing an a element's download or ping.
- `iframe^l ⇒ 当の要請は、 `iframe$e の `src!iframe$a 属性を処理した結果である場合 ◎ "iframe", if the request is the result of processing an iframe's src.
- `frame^l ⇒ 当の要請は、 `frame$e を読込むもの【!読込んだ結果】である場合 ◎ "frame", if the request is the result of loading a frame.
- `other^l ⇒ 上に挙げた どの条件にも合致しない場合 ◎ "other", if none of the above conditions match.
注記: `initiatorType^m は、[ 資源~計時~entryが報告される,異なる何箇所 ]かで設定される — `~fetching$ `FETCH$r など。 ◎ Note The setting of initiatorType is done at the different places where a resource timing entry is reported, such as the fetch standard.
注記: `deliveryType$m は、 次に挙げるいずれかの値を返す: ◎ Note deliveryType returns one of the following values:
- `cache^l ⇒ `~cache~mode$pT ~NEQ 空~文字列 の場合 ◎ "cache", if the cache mode is not the empty string.
- 空~文字列 ⇒ 上に挙げた どの条件にも合致しない場合 ◎ the empty string "", if none of the above conditions match.
これは、 この仕様に対する将来の更新により拡げられるものと期待される — 例: ~preloadされた資源や~prefetchされた~navi要請を消費したことを述べるために。 ◎ This is expected to be expanded by future updates to this specification, e.g. to describe consuming preloaded resources and prefetched navigation requests.
`workerStart@m 取得子~手続きは ⇒ ~RET `~fetch時刻印を変換する$( コレの`計時~報$pTの`最終-~sw開始~時刻$fT, コレに`関連な大域~obj$ ) ◎ The workerStart getter steps are to convert fetch timestamp for this's timing info's final service worker start time and the relevant global object for this.\
更なる情報は、 `~HTTP~fetch$を見よ。 ◎ See HTTP fetch for more info.
`redirectStart@m 取得子~手続きは ⇒ ~RET `~fetch時刻印を変換する$( コレの`計時~報$pTの`~redirect開始~時刻$fT, コレに`関連な大域~obj$ ) ◎ The redirectStart getter steps are to convert fetch timestamp for this's timing info's redirect start time and the relevant global object for this.\
更なる情報は、 `~HTTP~redirect~fetch$を見よ。 ◎ See HTTP-redirect fetch for more info.
`redirectEnd@m 取得子~手続きは ⇒ ~RET `~fetch時刻印を変換する$( コレの`計時~報$pTの`~redirect終了~時刻$fT, コレに`関連な大域~obj$ ) ◎ The redirectEnd getter steps are to convert fetch timestamp for this's timing info's redirect end time and the relevant global object for this.\
更なる情報は、 `~HTTP~redirect~fetch$を見よ。 ◎ See HTTP-redirect fetch for more info.
`fetchStart@m 取得子~手続きは ⇒ ~RET `~fetch時刻印を変換する$( コレの`計時~報$pTの`~redirect後からの開始~時刻$fT, コレに`関連な大域~obj$ ) ◎ The fetchStart getter steps are to convert fetch timestamp for this's timing info's post-redirect start time and the relevant global object for this.\
更なる情報は、 `~HTTP~fetch$を見よ。 ◎ See HTTP fetch for more info.
`domainLookupStart@m 取得子~手続きは ⇒ ~RET `~fetch時刻印を変換する$( コレの`計時~報$pTの`最終-接続~計時~報$fTの`~domain検索~開始~時刻$cT, コレに`関連な大域~obj$ ) ◎ The domainLookupStart getter steps are to convert fetch timestamp for this's timing info's final connection timing info's domain lookup start time and the relevant global object for this.\
更なる情報は、 `接続~計時~報を記録する$を見よ。 ◎ See Recording connection timing info for more info.
`domainLookupEnd@m 取得子~手続きは ⇒ ~RET `~fetch時刻印を変換する$( コレの`計時~報$pTの`最終-接続~計時~報$fTの`~domain検索~終了~時刻$cT, コレに`関連な大域~obj$ ) ◎ The domainLookupEnd getter steps are to convert fetch timestamp for this's timing info's final connection timing info's domain lookup end time and the relevant global object for this.\
更なる情報は、 `接続~計時~報を記録する$を見よ。 ◎ See Recording connection timing info for more info.
`connectStart@m 取得子~手続きは ⇒ ~RET `~fetch時刻印を変換する$( コレの`計時~報$pTの`最終-接続~計時~報$fTの`接続~開始~時刻$cT, コレに`関連な大域~obj$ ) ◎ The connectStart getter steps are to convert fetch timestamp for this's timing info's final connection timing info's connection start time and the relevant global object for this.\
更なる情報は、 `接続~計時~報を記録する$を見よ。 ◎ See Recording connection timing info for more info.
`connectEnd@m 取得子~手続きは ⇒ ~RET `~fetch時刻印を変換する$( コレの`計時~報$pTの`最終-接続~計時~報$fTの`接続~終了~時刻$cT, コレに`関連な大域~obj$ ) ◎ The connectEnd getter steps are to convert fetch timestamp for this's timing info's final connection timing info's connection end time and the relevant global object for this.\
更なる情報は、 `接続~計時~報を記録する$を見よ。 ◎ See Recording connection timing info for more info.
`secureConnectionStart@m 取得子~手続きは ⇒ ~RET `~fetch時刻印を変換する$( コレの`計時~報$pTの`最終-接続~計時~報$fTの`~secure接続~開始~時刻$cT, コレに`関連な大域~obj$ ) ◎ The secureConnectionStart getter steps are to convert fetch timestamp for this's timing info's final connection timing info's secure connection start time and the relevant global object for this.\
更なる情報は、 `接続~計時~報を記録する$を見よ。 ◎ See Recording connection timing info for more info.
`nextHopProtocol@m 取得子~手続きは ⇒ ~RET `同型に復号する$( コレの`計時~報$pTの`最終-接続~計時~報$fTの`折衝した~ALPN~protocol~ID$cT ) ◎ The nextHopProtocol getter steps are to isomorphic decode this's timing info's final connection timing info's ALPN negotiated protocol.\
更なる情報は、 `接続~計時~報を記録する$を見よ。 ◎ See Recording connection timing info for more info.
注記: `221$issue にて, `nextHopProtocol^m 用の~supportを除去するよう示唆されている — それは、 利用者の~network環境設定についての詳細を露呈し得るので。 ◎ Note Issue 221 suggests to remove support for nextHopProtocol, as it can reveal details about the user's network configuration.
`requestStart@m 取得子~手続きは ⇒ ~RET `~fetch時刻印を変換する$( コレの`計時~報$pTの`最終-~network要請~開始~時刻$fT, コレに`関連な大域~obj$ ) ◎ The requestStart getter steps are to convert fetch timestamp for this's timing info's final network-request start time and the relevant global object for this.\
注記: 更なる情報は、 `~HTTP~fetch$を見よ。 ◎ See HTTP fetch for more info.
`firstInterimResponseStart@m 取得子~手続きは ⇒ ~RET `~fetch時刻印を変換する$( コレの`計時~報$pTの`最初の非最終-~network応答~開始~時刻$fT, コレに`関連な大域~obj$ ) ◎ The firstInterimResponseStart getter steps are to convert fetch timestamp for this's timing info's first interim network-response start time and the relevant global object for this.\
注記: 更なる情報は、 `~HTTP~fetch$を見よ。 ◎ See HTTP fetch for more info.
`finalResponseHeadersStart@m 取得子~手続きは ⇒ ~RET `~fetch時刻印を変換する$( コレの`計時~報$pTの`最終-~network応答~開始~時刻$fT, コレに`関連な大域~obj$ ) ◎ The finalResponseHeadersStart getter steps are to convert fetch timestamp for this's timing info's final network-response start time and the relevant global object for this.\
更なる情報は、 `~HTTP~fetch$を見よ。 ◎ See HTTP fetch for more info.
`responseStart@m 取得子~手続きは:
- %最初の非最終-応答~開始 ~LET コレの `firstInterimResponseStart$m
- ~IF[ %最初の非最終-応答~開始 ~NEQ 0 ] ⇒ ~RET %最初の非最終-応答~開始
- ~RET コレの `finalResponseHeadersStart$m
`responseEnd@m 取得子~手続きは ⇒ ~RET `~fetch時刻印を変換する$( コレの`計時~報$pTの`終了~時刻$fT, コレに`関連な大域~obj$ ) ◎ The responseEnd getter steps are to convert fetch timestamp for this's timing info's end time and the relevant global object for this.\
更なる情報は、 `~fetch$を見よ。 ◎ See fetch for more info.
`encodedBodySize@m 取得子~手続きは ⇒ ~RET コレの`資源~情報$pTの`符号化された~size$fT ◎ The encodedBodySize getter steps are to return this's resource info's encoded size.
`decodedBodySize@m 取得子~手続きは ⇒ ~RET コレの`資源~情報$pTの`復号した~size$fT ◎ The decodedBodySize getter steps are to return this's resource info's decoded size.
`transferSize@m 取得子~手続きは: ◎ The transferSize getter steps are to perform the following steps:
-
~RET コレの`~cache~mode$pT に応じて ⇒# `local^l ならば 0 / `validated^l ならば 300 / ~ELSE_ コレの`資源~情報$pT【!response body info】の`符号化された~size$fT ~PLUS 300 † ◎ If this's cache mode is "local", then return 0. ◎ If this's cache mode is "validated", then return 300. ◎ Return this's response body info's encoded size plus 300.
注記†: ~sizeに加算される定数 300 は、 ~HTTP~messageの`~header節$の総~byte~sizeを置換するものであり, ある種の~cookieの有無が公開されないようにするためである。 `課題 #238@https://github.com/w3c/resource-timing/issues/238$ を見よ。 ◎ Note The constant number added to transferSize replaces exposing the total byte size of the HTTP headers, as that may expose the presence of certain cookies. See this issue.
`responseStatus@m 取得子~手続きは ⇒ ~RET コレの`応答~状態s$pT ◎ The responseStatus getter steps are to return this's response status.
注記: `responseStatus$m は`~fetch$内で決定される。 それは、 `要請$が非同一-生成元で[ `~mode$rq ~EQ `no-cors^l【!~FETCH#dom-requestmode-no-cors】 ]の場合には 0 になる — 対する応答は、 `不透明な絞込み応答$になるので。 ◎ Note responseStatus is determined in Fetch. For a cross-origin no-cors request it would be 0 because the response would be an opaque filtered response.
`contentType@m 取得子~手続きは ⇒ ~RET コレの`計時~報$pTの`内容~型$fT ◎ The contentType getter steps are to return this's resource info's content type.
`renderBlockingStatus@m 取得子~手続きは ⇒ ~RET コレの`計時~報$pTの`具現化を阻んでいるか$fTに応じて ⇒# ~T ならば `blocking$l / ~F ならば `non-blocking$l ◎ The renderBlockingStatus getter steps are to return blocking if this's timing info's render-blocking is true; otherwise non-blocking.
注記: `PerformanceResourceTiming$I を実装する~UAは、 その~supportを開発者が検出できるよう, `supportedEntryTypes$m 内に `resource^l を含める必要がある。 ◎ Note A user agent implementing PerformanceResourceTiming would need to include "resource" in supportedEntryTypes. This allows developers to detect support for Resource Timing.
4.3.1. `RenderBlockingStatusType^I 列挙型
enum `RenderBlockingStatusType@I { `blocking$l, `non-blocking$l };
値は、 次に従って定義される: ◎ The values are defined as follows:
- `blocking@l
- 当の資源は、 具現化を阻むものになり得る。 ◎ The resource can potentially block rendering.
- `non-blocking@l
- 当の資源は、 具現化を阻まない。 ◎ The resource will not block rendering.
4.4. `Performance^I ~interfaceに対する拡張
~UAは、 `PerformanceResourceTiming$I ~objとして`処理能~時列線$ `PERFORMANCE-TIMELINE-2$r に含み得る資源の個数を制限してもヨイ。 この節では、 `Performance$I ~interfaceを拡張して, 格納される `PerformanceResourceTiming$I ~objの個数について制御できるようにする。 ◎ The user agent MAY choose to limit how many resources are included as PerformanceResourceTiming objects in the Performance Timeline [PERFORMANCE-TIMELINE-2]. This section extends the Performance interface to allow controls over the number of PerformanceResourceTiming objects stored.
推奨される `PerformanceResourceTiming$I ~objの最小~個数は 250 である — ~UAはこれを変更してもヨイが。 この上限は、 `setResourceTimingBufferSize()$m を~callすることにより,変更を要請できる。 ◎ The recommended minimum number of PerformanceResourceTiming objects is 250, though this may be changed by the user agent. setResourceTimingBufferSize can be called to request a change to this limit.
各`~JS環境@~WEBIDLjs#js-environment$【!ECMAScript global environment】は、 次に挙げるものを持つ: ◎ Each ECMAScript global environment has:
- `資源~計時~bufferの~size上限@ ◎ A resource timing buffer size limit\
-
初期~時は 250 以上【が推奨される】。
◎
which should initially be 250 or greater.
- `資源~計時~bufferの現-~size@ ◎ A resource timing buffer current size\
- 0 以上の整数 — 初期~時は 0 とする。 ◎ which is initially 0.
- `資源~計時~buffer満杯~eventは処理待ちか@ ◎ A resource timing buffer full event pending flag\
- 真偽値 — 初期~時は ~F とする。 ◎ which is initially false.
- `資源~計時~副-~bufferの現-~size@ ◎ A resource timing secondary buffer current size which is initially 0.
- 【 `資源~計時~副-~buffer$を成す~entryの個数を表すが、 この訳では,この用語は利用しない。 代わりに,~algoの記述にて等価に表現する (`副-~buffer内の~entryを移動する$における,真偽値 %移動したか )。 そうした方が簡潔かつ簡明に記述できるので。 】
- `資源~計時~副-~buffer@ ◎ A resource timing secondary buffer\
- `PerformanceResourceTiming$I ~objたちが成す~list — 初期~時は空とする。 ◎ to store PerformanceResourceTiming objects that is initially empty.
partial interface `Performance$I { `undefined$ `clearResourceTimings()$m; `undefined$ `setResourceTimingBufferSize$m(`unsigned long$ %maxSize); attribute `EventHandler$I `onresourcetimingbufferfull$m; };
`Performance$I ~interfaceは `HR-TIME$r にて定義される。 ◎ The Performance interface is defined in [HR-TIME].
`clearResourceTimings()@m ~method手続きは: ◎ The method clearResourceTimings runs the following steps:
- `処理能~entry~buffer$から 次を満たす~entryをすべて除去する ⇒ `PerformanceResourceTiming$I ~objである ◎ Remove all PerformanceResourceTiming objects in the performance entry buffer.
- `資源~計時~bufferの現-~size$ ~SET 0 ◎ Set resource timing buffer current size to 0.
`setResourceTimingBufferSize(maxSize)@m ~method手続きは ⇒ `資源~計時~bufferの~size上限$ ~SET %maxSize ◎ The setResourceTimingBufferSize method runs the following steps: • Set resource timing buffer size limit to the maxSize parameter.\
注記: [ %maxSize ~LT `資源~計時~bufferの現-~size$ ]であっても,`処理能~entry~buffer$から `PerformanceResourceTiming$I ~objは除去されない。 ◎ If the maxSize parameter is less than resource timing buffer current size, no PerformanceResourceTiming objects are to be removed from the performance entry buffer.
`onresourcetimingbufferfull@m は、 `resourcetimingbufferfull@et ~event用の~event~handlerである。 【`~buffer満杯~eventを発火する$を見よ。】 ◎ The attribute onresourcetimingbufferfull is the event handler for the resourcetimingbufferfull event described below.
`資源~計時~entryを追加でき@ るとは、 次が満たされることをいう ⇒ `資源~計時~bufferの現-~size$ ~LT `資源~計時~bufferの~size上限$ ◎ To check if can add resource timing entry, run the following steps: • If resource timing buffer current size is smaller than resource timing buffer size limit, return true. • Return false.
`処理能~entry~bufferに~entryを追加する@ ときは、 所与の ( `処理能~entry~buffer$ %~buffer, `PerformanceResourceTiming$I ~obj %新たな~entry ) に対し,次を走らす: ◎ To add a PerformanceResourceTiming entry new entry into the performance entry buffer, run the following steps:
-
~IF[ `資源~計時~entryを追加でき$る ]~AND[ `資源~計時~buffer満杯~eventは処理待ちか$ ~EQ ~F ]: ◎ If can add resource timing entry returns true and resource timing buffer full event pending flag is false, run the following substeps:
- %~buffer に %新たな~entry を追加する ◎ Add new entry to the performance entry buffer.
- `資源~計時~bufferの現-~size$ ~INCBY 1 ◎ Increase resource timing buffer current size by 1.
- ~RET ◎ Return.
-
~IF[ `資源~計時~buffer満杯~eventは処理待ちか$ ~EQ ~F ]: ◎ If resource timing buffer full event pending flag is false, run the following substeps:
- `資源~計時~buffer満杯~eventは処理待ちか$ ~SET ~T ◎ Set resource timing buffer full event pending flag to true.
-
`~taskを~queueする$( `処理能~時列線~task~source$, 次の手続き )
手続きは ⇒ `~buffer満杯~eventを発火する$()◎ Queue a task on the performance timeline task source to run fire a buffer full event.
- `資源~計時~副-~buffer$に %新たな~entry を付加する ◎ Add new entry to the resource timing secondary buffer. ◎ Increase resource timing secondary buffer current size by 1.
`副-~buffer内の~entryを移動する@ ときは、 次を走らす: ◎ To copy secondary buffer, run the following steps:
- %移動したか ~LET ~F ◎ ↓↓
-
~WHILE[ `資源~計時~副-~buffer$は空でない ]~AND[ `資源~計時~entryを追加でき$る ]: ◎ While resource timing secondary buffer is not empty and can add resource timing entry returns true, run the following substeps:
- %~entry ~LET `資源~計時~副-~buffer$内の最初の(最も旧い) `PerformanceResourceTiming$I ~obj ◎ Let entry be the oldest PerformanceResourceTiming in resource timing secondary buffer.
- `処理能~entry~buffer$の末尾に %~entry を追加する ◎ Add entry to the end of performance entry buffer.
- `資源~計時~bufferの現-~size$ ~INCBY 1 ◎ Increment resource timing buffer current size by 1.
- `資源~計時~副-~buffer$から %~entry を除去する ◎ Remove entry from resource timing secondary buffer.
- %移動したか ~SET ~T ◎ Decrement resource timing secondary buffer current size by 1.
- ~RET %移動したか
`~buffer満杯~eventを発火する@ ときは、 次を走らす: ◎ To fire a buffer full event, run the following steps:
-
~WHILE[ `資源~計時~副-~buffer$は空でない ]: ◎ While resource timing secondary buffer is not empty, run the following substeps:
- ~IF[ `資源~計時~entryを追加でき$ない ] ⇒ `~eventを発火する$( `Performance$I ~obj, `resourcetimingbufferfull$et ) ◎ Let number of excess entries before be resource timing secondary buffer current size. ◎ If can add resource timing entry returns false, then fire an event named resourcetimingbufferfull at the Performance object.
- %移動したか ~LET `副-~buffer内の~entryを移動する$() ◎ Run copy secondary buffer.
- ~IF[ %移動したか ~EQ ~F ] ⇒# `資源~計時~副-~buffer$からすべての~entryを除去する†; ~BREAK ◎ Let number of excess entries after be resource timing secondary buffer current size. ◎ If number of excess entries before is lower than or equals number of excess entries after, then remove all entries from resource timing secondary buffer, set resource timing secondary buffer current size to 0, and abort these steps.
- `資源~計時~buffer満杯~eventは処理待ちか$ ~SET ~F ◎ Set resource timing buffer full event pending flag to false.
注記:† 移動できなかった~entryは、 ~bufferから落とされる。 開発者は、 `resourcetimingbufferfull$et ~event用の~event~handler内で, 次のいずれかをしておくべきである ⇒# `clearResourceTimings()$m を~callする/ `setResourceTimingBufferSize()$m を~callして,~bufferが足りるよう拡張する ◎ Note This means that if the resourcetimingbufferfull event handler does not add more room in the buffer than it adds resources to it, excess entries will be dropped from the buffer. Developers should make sure that resourcetimingbufferfull event handlers call clearResourceTimings or extend the buffer sufficiently (by calling setResourceTimingBufferSize).
4.5. 非同一-生成元~資源
注記: `FETCH$r にて詳細されるとおり、 非同一-生成元~資源への要請は, `PerformanceResourceTiming$I ~objとして`処理能~時列線$に含められる。 非同一-生成元~資源に対し`~TAO検査$に失敗した場合、 `当の~entryは不透明になる@~FETCH#create-an-opaque-timing-info$。 そのような~entryのほとんどの属性は、 他では公開されない非同一-生成元~dataが漏洩するのを防止するため,~maskされる — すなわち,不透明な~entryの属性のうち: ◎ Note As detailed in Fetch, requests for cross-origin resources are included as PerformanceResourceTiming objects in the Performance Timeline. If the timing allow check algorithm fails for a cross-origin resource, the entry will be an opaque entry. Such entries have most of their attributes masked in order to prevent leaking cross-origin data that isn't otherwise exposed. So, for an opaque entry,\
- 次に挙げるものは、 0 に設定される ⇒# `redirectStart$m, `redirectEnd$m, `workerStart$m, `domainLookupStart$m, `domainLookupEnd$m, `connectStart$m, `connectEnd$m, `requestStart$m, `firstInterimResponseStart$m, `finalResponseHeadersStart$m, `responseStart$m, `secureConnectionStart$m, `transferSize$m, `encodedBodySize$m, `decodedBodySize$m ◎ the following attributes will be set to zero: redirectStart, redirectEnd, workerStart, domainLookupStart, domainLookupEnd, connectStart, connectEnd, requestStart, firstInterimResponseStart, finalResponseHeadersStart, responseStart, secureConnectionStart, transferSize, encodedBodySize, and decodedBodySize.\
- `nextHopProtocol$m は、 空~文字列に設定される。 ◎ Further, the nextHopProtocol attribute will be set to the empty string.
~server側~appは、 `Timing-Allow-Origin$h ~HTTP応答~header返してもヨイ — 上に挙げた[ 非同一-生成元に対する制約に因り,値が 0 にされる属性 ]すべてを[ ~header内に指定された文書~生成元(たち)に公開する ]ことを~UAに許容するためとして。 ◎ Server-side applications may return the Timing-Allow-Origin HTTP response header to allow the User Agent to fully expose, to the document origin(s) specified, the values of attributes that would have been zero due to those cross-origin restrictions.
4.5.1. `Timing-Allow-Origin^h 応答~header
`Timing-Allow-Origin@h ~HTTP応答~headerを利用すれば、[[ 非同一-生成元に対する制約に因り 0 にされていた属性 ]の値を見ることが許容され得る生成元(たち) ]を指示する施策を通信できる。 この~headerの値は、 次の~ABNF `RFC5234$r と`その~list拡張@~HTTPinfra#abnf.extension$ `RFC9110$r を利用して表現される: ◎ The Timing-Allow-Origin HTTP response header field can be used to communicate a policy indicating origin(s) that may be allowed to see values of attributes that would have been zero due to the cross-origin restrictions. The header's value is represented by the following ABNF [RFC5234] (using List Extension, [RFC9110]):
Timing-Allow-Origin = 1#( `origin-or-null$P / `wildcard$P )
送信者は、 複数個の `Timing-Allow-Origin$h ~headerを生成してもヨイ。 受信者は、 複数個の `Timing-Allow-Origin$h ~headerに対しては, それらの~headerの値を順に~commaで分離して連結して 1 個の~headerに結合してもヨイ。 ◎ The sender MAY generate multiple Timing-Allow-Origin header fields. The recipient MAY combine multiple Timing-Allow-Origin header fields by appending each subsequent field value to the combined field value in order, separated by a comma.
~UAは, `Timing-Allow-Origin$h ~headerを受信した【!with HTTP response header fields】場合でも、 非同一-生成元に対する制約を施行して,[ `transferSize$m, `encodedBodySize$m, `decodedBodySize$m ]属性を 0 に設定してもヨイ — そうする場合、 `deliveryType$m も空~文字列に設定してヨイ。 ◎ The user agent MAY still enforce cross-origin restrictions and set transferSize, encodedBodySize, and decodedBodySize attributes to zero, even with Timing-Allow-Origin HTTP response header fields. If it does, it MAY also set deliveryType to "".
`Timing-Allow-Origin$h ~headerは、 `~TAO検査$にて処理され,各 属性は それに則って算出される。 ◎ The Timing-Allow-Origin headers are processed in FETCH to compute the attributes accordingly.
注記: `Timing-Allow-Origin$h ~headerは、 ~cacheされた応答の一部として到着することもある。 ~cache再検証の事例では、 `~HTTP~cache法に則って@~HTTPcache#freshening.responses$ 【!~RFCx/rfc7234#section-4.3.4】,~headerの値は[ 再検証~応答,そこに無ければ~cacheされた元の資源 ]から来ることもある。 ◎ Note The Timing-Allow-Origin header may arrive as part of a cached response. In case of cache revalidation, according to RFC 7234, the header's value may come from the revalidation response, or if not present there, from the original cached resource.
注記: `222$issue, `223$issue にて, `Timing-Allow-Origin$h から `wildcard^P の~supportを除去するよう示唆されている — それの利用を制約するため。 ◎ Note Issues 222 and 223 suggest to remove wildcard support from Timing-Allow-Origin in order to restrict its use.
4.5.2. IANA 考慮点
この節では、 `Timing-Allow-Origin$h を`暫定的な~message~header@~HTTPinfra#fields.registry$【!~RFCx/rfc3864.html#section-4.2.2】として登録する。 ◎ This section registers Timing-Allow-Origin as a Provisional Message Header.
- ~header~field名 ⇒ `Timing-Allow-Origin^h ◎ Header field name: • Timing-Allow-Origin
- 適用-可能な~protocol ⇒ http ◎ Applicable protocol: • http
- 位置付け ⇒ 暫定的 ◎ Status: • provisional
- 著作者/変更~制御者 ⇒ `W3C@https://www.w3.org/$ ◎ Author/Change controller: • W3C
- 仕様~文書 ⇒ § `Timing-Allow-Origin^h 応答~header ◎ Specification document: • § 4.5.1 Timing-Allow-Origin Response Header
4.6. 資源~計時~属性
◎非規範的`PerformanceResourceTiming$I ~interfaceに定義される各種 計時~属性を次の図式に示す。 括弧内の属性は、 資源が非同一-生成元から`~fetch$されているときは可用でない。 ~UAは、 規範的でない時区間を許容するために, 各 計時の合間に内部~処理を行ってもヨイ。 ◎ The following graph illustrates the timing attributes defined by the PerformanceResourceTiming interface. Attributes in parenthesis may not be available when fetching cross-origin resources. User agents may perform internal processing in between timings, which allow for non-normative intervals between timings.
4.7. 資源~計時~entryの作成-法
`資源~計時を~markする@ ときは、所与の ⇒# `~fetch計時~報$ %計時~報, `文字列$ %要請された~URL, `文字列$ %起動元~種別, `大域~obj$enV %大域~obj, `文字列$ %~cache~mode, `応答~本体~報$ %本体~報, `状態s$ %応答~状態s, 文字列 %送達~種別(省略時は空~文字列) ◎終 に対し,次を遂行する: ◎ To mark resource timing given a fetch timing info timingInfo, a DOMString requestedURL, a DOMString initiatorType a global object global, a string cacheMode, a response body info bodyInfo, a status responseStatus, and an optional string deliveryType (by default, the empty string), perform the following steps:
- %~entry ~LET %大域~obj の`~realm$gLに属する新たな `PerformanceResourceTiming$I ~obj ◎ Create a PerformanceResourceTiming object entry in global's realm.
- `資源~計時~entryを設定しておく$( ↓ ) ⇒# %~entry, %起動元~種別, %要請された~URL, %計時~報, %~cache~mode, %本体~報, %応答~状態s, %送達~種別 ◎ Setup the resource timing entry for entry, given initiatorType, requestedURL, timingInfo, cacheMode, bodyInfo, responseStatus, and deliveryType. and responseStatus.
- `処理能~entryを~queueする$( %~entry ) ◎ Queue entry.
- `処理能~entry~bufferに~entryを追加する$( %~entry, %大域~obj 【の`処理能~entry~buffer~map$[ `resource^l ] 】 の`処理能~entry~buffer$ ) ◎ Add entry to global's performance entry buffer.
`資源~計時~entryを設定しておく@ ときは、所与の ⇒# `PerformanceResourceTiming$I %~entry, `文字列$ %起動元~種別, `文字列$ %要請された~URL, `~fetch計時~報$ %計時~報, `文字列$ %~cache~mode, `応答~本体~報$ %本体~報, `状態s$ %応答~状態s, 文字列 %送達~種別(省略時は空~文字列) ◎終 に対し,次を遂行する: ◎ To setup the resource timing entry for PerformanceResourceTiming entry given DOMString initiatorType, DOMString requestedURL, fetch timing info timingInfo, a DOMString cacheMode, a response body info bodyInfo, a status responseStatus, and an optional DOMString deliveryType (by default, the empty string), perform the following steps:
- ~Assert: %~cache~mode ~IN { 空~文字列, `local^l, `validated^l } ◎ Assert that cacheMode is the empty string, "local", or "validated".
- %大域~obj ~LET %~entry に`関連な大域~obj$ ◎ Let global be entry's relevant global object.
- %~entry を`初期化する$PE( ↓ ) ⇒# `~fetch時刻印を変換する$( %計時~報 の`開始~時刻$fT, %大域~obj ), `resource^l, %要請された~URL, `~fetch時刻印を変換する$( %計時~報 の`終了~時刻$fT, %大域~obj ) ◎ Initialize entry given the result of converting timingInfo's start time given global, "resource", requestedURL, and the result of converting timingInfo's end time given global.
- ~IF[ %送達~種別 ~EQ 空~文字列 ]~AND[ %~cache~mode ~NEQ 空~文字列 ] ⇒ %送達~種別 ~SET `cache^l ◎ ↓
- %~entry の ⇒# `起動元~種別$pT ~SET %起動元~種別, `要請~URL$pT ~SET %要請された~URL, `計時~報$pT ~SET %計時~報, `資源~情報$pT【!response body info】 ~SET %本体~報, `~cache~mode$pT ~SET %~cache~mode, `応答~状態s$pT ~SET %応答~状態s, `送達~種別$pT ~SET %送達~種別 ◎ Set entry's initiator type to initiatorType. ◎ Set entry's requested URL to requestedURL. ◎ Set entry's timing info to timingInfo. ◎ Set entry's response body info to bodyInfo. ◎ Set entry's cache mode to cacheMode. ◎ Set entry's response status to responseStatus. ◎ If deliveryType is the empty string and cacheMode is not, then set deliveryType to "cache". ◎ Set entry's delivery type to deliveryType.
`~fetch時刻印を変換する@ ときは、所与の ( `DOMHighResTimeStamp$I %時刻印, `大域~obj$enV %大域~obj ) に対し ⇒ ~RET [ %時刻印 ~EQ 0 ならば 0 / ~ELSE_ 次の結果 ] ⇒ `相対的な粗い高分解能~時刻$( %時刻印, %大域~obj ) ◎ To convert fetch timestamp given DOMHighResTimeStamp ts and global object global, do the following: • If ts is zero, return zero. • Otherwise, return the relative high resolution coarse time given ts and global.
4.8. ~securityの考慮点
◎非規範的`PerformanceResourceTiming$I ~interfaceは、 資源を要請した[ ~web~page/~worker ]に,その資源の計時~情報を公開する。 `PerformanceResourceTiming$I ~interfaceへの~accessを制限するため、 既定では`同一-生成元$ 施策が施行される。 その結果,一部の属性は、 `~HTTP~fetch$にて述べられるとおり, 0 に設定される。 資源を供する側は、[ `Timing-Allow-Origin$h ~HTTP応答~headerを追加して,その値に 計時~情報への~accessを許容する~domainを指定する ]ことにより,資源~用のすべての計時~情報の収集を明示的に許容できる。 ◎ The PerformanceResourceTiming interface exposes timing information for a resource to any web page or worker that has requested that resource. To limit the access to the PerformanceResourceTiming interface, the same origin policy is enforced by default and certain attributes are set to zero, as described in HTTP fetch. Resource providers can explicitly allow all timing information to be collected for a resource by adding the Timing-Allow-Origin HTTP response header, which specifies the domains that are allowed to access the timing information.
4.9. ~privacyの考慮点
◎非規範的悪意的な~web~siteは、 第三者-主体~web~site内の資源に対する~cache[ ~hit/~miss ]の時機を測定することにより, 利用者が第三者-主体~siteを訪問したかどうかを決定し得る — そのような~privacyの懸念は、 統計的~指紋収集( `statistical fingerprinting^en )と称される。 `PerformanceResourceTiming$I ~interfaceは, 文書~内の資源の計時~情報を供するが、 すでに,資源に対する `load^et ~eventにより — 制限された流儀ではあるが — 時機を測定して~cache[ ~hit/~miss ]を決定できることに加え、 `~HTTP~fetch$における非同一-生成元に対する制約により, 追加的な情報の漏洩eは防止される。 ◎ Statistical fingerprinting is a privacy concern where a malicious web site may determine whether a user has visited a third-party web site by measuring the timing of cache hits and misses of resources in the third-party web site. Though the PerformanceResourceTiming interface gives timing information for resources in a document, the load event on resources can already measure timing to determine cache hits and misses in a limited fashion, and the cross-origin restrictions in HTTP Fetch prevent the leakage of any additional information.
謝辞
この仕事に貢献された次の方々に謝意を:
Thanks to 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, and Alex Christensen for their contributions to this work.