リソースの計時 — Resource Timing Level 2

【この訳に固有の表記規約】

この訳の，~algoや定義の記述に利用されている各種記号（ ~LET, ~EQ, ~IF, ~EACH (…), ~RET, 等々）の意味や定義の詳細は、~SYMBOL_DEF_REFを~~参照されたし。

簡潔に記すため、次の非公式な用語も導入する：

`~redirect等@

~HTTP~redirect応答または（他の~protocolにおける） それに等価なもの を指す総称。

`局所~cache等@

［ `関連する~app~cache$, または局所~資源 ］を指す総称。

4.1. 序論

4.2. `PerformanceResourceTiming^I ~interfaceが対象にする資源

次に挙げる資源は、 `PerformanceResourceTiming$I ~objとして，関連する大域~環境の`処理能時列線$に含められ~MUST／含められて~MAY： ◎ ↓

• 現在の［ `閲覧文脈$ ／ ~worker文脈 ］下で`~fetch$されたすべての資源は、含められ~MUST。 ◎ All resources fetched by the current browsing or worker [WORKERS] context's MUST be included as PerformanceResourceTiming objects in the Performance Timeline of the relevant context.＼
• `局所~cache等$から検索取得された資源は、含められ~MUST。 ◎ Resources that are retrieved from relevant application caches or local resources MUST be included as PerformanceResourceTiming objects in the Performance Timeline [PERFORMANCE-TIMELINE-2].＼
• ~fetchにより起動されたが，（~network~errorなどに因り）後で中止された資源は、含められて~MAY — この場合の各種~属性の値は、処理~modelによる手続き（後述）の中で初期化され~MUST。 ◎ Resources for which the fetch was initiated, but was later aborted (e.g. due to a network error) MAY be included as PerformanceResourceTiming objects in the Performance Timeline and MUST contain initialized attribute values for processed substeps of the processing model.

この節の残りの部分は規範的ではない。 ◎ The rest of this section is non-normative.

例： ◎ Examples:

• 複数の~HTML `img$e 要素の `src^a 属性に，正準形が同じになる~URL（ `the same canonical URL^en 【すなわち，同じ資源を指す~URL】 ）が利用されている場合、［ 最初に資源`~fetch$を起動させた `img^e 要素 ］の方が `PerformanceResourceTiming$I ~objとして`処理能時列線$に含められる~SHOULDである。 ~UAは、二番目以降の `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 should 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 `RFC2397$r を持つ場合、その資源は，`処理能時列線$には含められない。 data: URI は埋込みの~dataであり、`~fetch$を要さないものと定義されているので。 ◎ 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. By definition data: URI contains embedded data and does not require a fetch.
• 資源`~fetch$が~network~error（ DNS, TCP, TLS ~errorなど）に因り中止された場合、その~fetchは，失敗した時点までの属性~値で初期化された `PerformanceResourceTiming$I ~objとして`処理能時列線$に含められてよい — 例えば TCP ~handshake~errorは、 要請に対する DNS 時刻印を報告するべきである, 等々。 ◎ If a resource fetch was aborted due to a networking error (e.g. DNS, TCP, or TLS error), then the fetch may be included as a PerformanceResourceTiming object in the Performance Timeline with initialized attribute values up to the point of failure - e.g. a TCP handshake error should report DNS timestamps for the request, and so on.
• 資源`~fetch$が，事前条件（例： 混在内容（ `mixed content^en ）, CORS 制約, CSP ~policy, など）に失敗したことにより中止された場合、その資源については，`処理能時列線$には含められるべきでない。 ◎ If a resource fetch is aborted because it failed a fetch precondition (e.g. mixed content, CORS restriction, CSP policy, etc), then this resource should not not be included as a PerformanceResourceTiming object in the Performance Timeline.

4.3. `PerformanceResourceTiming^I ~interface

`PerformanceResourceTiming$I ~interfaceは、`処理能時列線$に関与し， `PerformanceEntry$I ~interfaceの次の属性を拡張する： ◎ The PerformanceResourceTiming interface participates in the Performance Timeline and extends the following attributes of the PerformanceEntry interface:

`name@m

取得子は、要請された資源の`解決-済み~URL$ を返さ~MUST。 この属性は、`~fetch$先が異なる~URLに~redirectされても，変化しては~MUST_NOT。 ◎ This attribute MUST return the resolved URL of the requested resource. This attribute must not change even if the fetch redirected to a different URL.

`entryType@m

取得子は、 `resource^l を返さ~MUST。 ◎ The entryType attribute MUST return the DOMString "resource".

`startTime@m

取得子は、［ ~UAが資源`~fetching$を~queueする直前の時刻 ］を表す，［ `DOMHighResTimeStamp$I 型 `HR-TIME-2$r の値 ］を返さ~MUST。 資源~fetchの間に`~redirect等$が生じたときは、次で与えられる値を返さ~MUST：

• どの`~redirect等$に対しても、［ `現在の文書$と`同一生成元$であるか, または`計時~許可検査$に合格する ］ならば、 `redirectStart$m と同じ値。
• 他の場合、 `fetchStart$m と同じ値。

◎ The startTime attribute MUST return a DOMHighResTimeStamp [HR-TIME-2] with the time immediately before the user agent starts to queue the resource for fetching. If there are HTTP redirects or equivalent when fetching the resource, and if all the redirects or equivalent are from the same origin as the current document or the timing allow check algorithm passes, this attribute MUST return the same value as redirectStart. Otherwise, this attribute MUST return the same value as fetchStart.

`duration@m

取得子は、 `responseEnd$m の， `startTime$m からの差分を表す `DOMHighResTimeStamp$I を返さ~MUST ◎ The duration attribute MUST return a DOMHighResTimeStamp equal to the difference between responseEnd and startTime, respectively.

[`Exposed$=(Window,Worker)]
interface `PerformanceResourceTiming@I : `PerformanceEntry$I {
  readonly attribute `DOMString$ `initiatorType$m;
  readonly attribute `DOMString$ `nextHopProtocol$m;
  readonly attribute `DOMHighResTimeStamp$I `workerStart$m;
  readonly attribute `DOMHighResTimeStamp$I `redirectStart$m;
  readonly attribute `DOMHighResTimeStamp$I `redirectEnd$m;
  readonly attribute `DOMHighResTimeStamp$I `fetchStart$m;
  readonly attribute `DOMHighResTimeStamp$I `domainLookupStart$m;
  readonly attribute `DOMHighResTimeStamp$I `domainLookupEnd$m;
  readonly attribute `DOMHighResTimeStamp$I `connectStart$m;
  readonly attribute `DOMHighResTimeStamp$I `connectEnd$m;
  readonly attribute `DOMHighResTimeStamp$I `secureConnectionStart$m;
  readonly attribute `DOMHighResTimeStamp$I `requestStart$m;
  readonly attribute `DOMHighResTimeStamp$I `responseStart$m;
  readonly attribute `DOMHighResTimeStamp$I `responseEnd$m;
  readonly attribute unsigned long long `transferSize$m;
  readonly attribute unsigned long long `encodedBodySize$m;
  readonly attribute unsigned long long `decodedBodySize$m;
  [`Default$] `object$ `toJSON$m();
};

`toJSON()@m

~call時には、 `WebIDL$r による`既定の~toJSON演算$を走らす。 ◎ When toJSON is called, run [WEBIDL]'s default toJSON operation.

`initiatorType@m

取得子は、何が資源の~fetch要請を生じさせたかに応じて，次を返さ~MUST： ◎ On getting, the initiatorType attribute MUST return one of the following DOMString values:

• 要請は`要素$を処理した結果による場合 ⇒ 当の要素の`局所~名$ ◎ The same value as the localName of that element [DOM], if the request is a result of processing the element;
• 要請は `url()$css による指令（ `@import url()^css や `background: url()^css など） `CSS-SYNTAX-3$r を処理した結果による場合 ⇒ `css@l ◎ "css", if the request is a result of processing a CSS url() directive [CSS-SYNTAX-3], such as @import url() or background: url();
• 要請は `~navi要請$である場合 ⇒ `navigation@l ◎ "navigation", if the request is a navigation request;
• 要請は `XMLHttpRequest$I ~obj `XHR$r を処理した結果による場合 ⇒ `xmlhttprequest@l ◎ "xmlhttprequest", if the request is a result of processing an XMLHttpRequest object [XHR];
• 要請は `fetch()$m ~method `FETCH$r を処理した結果による場合 ⇒ `fetch@l ◎ "fetch", if the request is the result of processing the Fetch method [FETCH];
• 要請は `sendBeacon()$m ~method `BEACON$r を処理した結果による場合 ⇒ `beacon@l ◎ "beacon", if the request is the result of processing the sendBeacon method [BEACON];
• 上に挙げたどれにも該当しない場合 ⇒ `other@l ◎ "other", if none of the above conditions match.

`nextHopProtocol@m

取得子は、［ 当の資源が`局所~cache等$から検索取得されているならば 空~文字列 ／ ~ELSE_ ~ALPN~protocol~ID — `ALPN Protocol ID^en `RFC7301$r — として識別される，資源~fetchに利用された~network~protocol ］を返さ~MUST。 ~proxyが環境設定されている下では、次を返さ~MUST：

• ~tunnel接続が確立された場合 ⇒ その~tunnelされた~protocolの~ALPN~protocol~ID
• 他の場合 ⇒ ~proxyへの最初の hop の~ALPN~protocol~ID

~ALPN~protocol~IDを精確に表現するため、次の拘束も適用される：

• ~ALPN~protocol内の~octetのうち， `%^l を除く妥当な~token文字は~percent符号化されては~MUST_NOT。
• ~percent符号化には，大文字の 16 進~数字を用い~MUST。

◎ On getting, the attribute nextHopProtocol returns the network protocol used to fetch the resource, as identified by the ALPN Protocol ID [RFC7301]; resources retrieved from relevant application caches or local resources, return an empty string. When a proxy is configured, if a tunnel connection is established then this attribute MUST return the ALPN Protocol ID of the tunneled protocol, otherwise it MUST return the ALPN Protocol ID of the first hop to the proxy. In order to have precisely one way to represent any ALPN protocol ID, the following additional constraints apply: octets in the ALPN protocol MUST NOT be percent-encoded if they are valid token characters except "%", and when using percent-encoding, uppercase hex digits MUST be used.

登録-済み~ALPN~protocol~IDは、以前は IANA により文書~化されていた。 ~UAは、試験的な未登録の~protocolを利用している事例では，~ALPN用に折衝されている値があれば それを利用し~MUST — ~ALPNは~protocol折衝~用に利用されていない場合、別の記述的な文字列を利用して~MAY ◎ Formally registered ALPN protocol IDs are documented by IANA. In case the user agent is using an experimental, non-registered protocol, the user agent MUST use the ALPN negotiated value if any. If ALPN was not used for protocol negotiations, the user agent MAY use another descriptive string. Note

注記： ~ALPN~ID `hq^l は、 `HTTP over QUIC Internet Draft^en 内の `HTTP over QUIC protocol^en の最終~version用に定義されている。 ◎ Note The "hq" ALPN ID is defined for the final version of the HTTP over QUIC protocol in the HTTP over QUIC Internet Draft.

この属性は、実際に折衝された方法に関わらず，~fetch用に利用~中の~network~protocolを識別するためとして意図されていることに注意。 すなわち、~network~protocolを折衝するために~ALPNが利用されていなくても、この属性は，依然として，~ALPN~protocol~IDを利用して利用~中の~protocolを指示する。 ◎ Note that the nextHopProtocol attribute is intended to identify the network protocol in use for the fetch regardless of how it was actually negotiated; that is, even if ALPN is not used to negotiate the network protocol, this attribute still uses the ALPN Protocol ID's to indicate the protocol in use.

`workerStart@m

取得子は、次を走らせ~MUST： ◎ On getting, the workerStart attribute MUST return as follows:

1. ~IF［ 現在の［ `閲覧文脈$ ／ ~worker文脈 ］には`作動中の~worker$ %worker はある `service-workers-1$r ］： ◎ If the current browsing or worker context's have an active worker [service-workers-1]:

   1. ~IF［ %worker はすでに可用である ］ ⇒ ~RET ~UAが［ %worker に向けて，`名前~fetch_evの~eventを発火する$ ］直前の時刻 ◎ the time immediately before the user agent fires an event named `fetch` at the active worker if the worker is available.
   2. ~RET ~UAが［ %worker を`走らす$ ］直前の時刻 ◎ the time immediately before the user agent runs the worker required to service the request.
2. ~RET 0 ◎ zero, otherwise.

`redirectStart@m

取得子は、次を走らせ~MUST： ◎ On getting, the redirectStart attribute MUST return as follows:

1. ~IF［ 資源`~fetching$において`~redirect等$が生じている ］~AND［ それらの`~redirect等$すべてが，`計時~許可検査$に合格した ］ ⇒ ~RET ［ ~redirectを起動させた`~fetch$を開始した ］直前の時刻 ◎ The time immediately before the user agent starts to fetch the resource that initiates the redirect, if there are HTTP redirects or equivalent when fetching the resource and all the redirects or equivalent pass the timing allow check algorithm.
2. ~RET 0 ◎ zero, otherwise.

`redirectEnd@m

取得子は、次を走らせ~MUST： ◎ On getting, the redirectEnd attribute MUST return as follows:

1. ~IF［ 資源`~fetching$において`~redirect等$が生じている ］~AND［ それらの`~redirect等$すべてが，`計時~許可検査$に合格した ］ ⇒ ~RET ［ 最後の~redirectに対する応答の最後の~byteを受信した ］直後の時刻 ◎ The time immediately after receiving the last byte of the response of the last redirect, if there are HTTP redirects or equivalent when fetching the resource and all the redirects or equivalent pass the timing allow check algorithm.
2. ~RET 0 ◎ zero, otherwise.

`fetchStart@m

取得子は、次を走らせ~MUST： ◎ On getting, the fetchStart attribute MUST return as follows:

1. ~IF［ `~redirect等$が生じている ］ ⇒ ~RET ~UAが［ ~redirectされなかった最後の資源`~fetch$を開始した ］直前の時刻 ◎ The time immediately before the user agent starts to fetch the final resource in the redirection, if there are HTTP redirects or equivalent.
2. ~RET ~UAが［ 資源`~fetch$を開始した ］直前の時刻 ◎ The time immediately before the user agent starts to fetch the resource otherwise.

`domainLookupStart@m

取得子は、次を走らせ~MUST： ◎ On getting, the domainLookupStart attribute MUST return as follows:

1. ~IF［ `持続的~接続$ `RFC7230$r が利用されている ］~OR［ 資源は`局所~cache等$から検索取得されている ］ ⇒ ~RET `fetchStart$m と同じ値 ◎ The same value as fetchStart, if a persistent connection [RFC7230] is used or the resource is retrieved from relevant application caches or local resources.
2. ~IF［ ~UAの~cache内に~domain情報がある ］ ⇒ ~RET ~UAが［ ~domain情報~cacheから~domain~dataを検索取得し始めた ］直前の時刻 ◎ The time immediately after the user agent before the domain data retrieval from the domain information cache, if the user agent has the domain information in cache.
3. ~IF［ ~redirectされなかった最後の資源`~fetch$は，`計時~許可検査$に合格した ］ ⇒ ~RET ~UAが［ 資源に対する~domain名~検索を開始した ］直前の時刻 ◎ The time immediately before the user agent starts the domain name lookup for the resource, if the last non-redirected fetch of the resource passes the timing allow check algorithm.
4. ~RET 0 ◎ zero, otherwise.

`domainLookupEnd@m

取得子は、次を走らせ~MUST： ◎ On getting, the domainLookupEnd attribute MUST return as follows:

1. ~IF［ `持続的~接続$ `RFC7230$r が利用されている ］~OR［ 資源は`局所~cache等$から検索取得されている ］ ⇒ ~RET `fetchStart$m と同じ値 ◎ The same value as fetchStart, if a persistent connection [RFC7230] is used or the resource is retrieved from relevant application caches or local resources.
2. ~IF［ ~UAの~cache内に~domain情報がある ］ ⇒ ~RET ~UAが［ ~domain情報~cacheからの~domain~dataを検索取得し終えた ］直後の時刻 ◎ The time immediately after the user agent ends the domain data retrieval from the domain information cache, if the user agent has the domain information in cache.
3. ~IF［ ~redirectされなかった最後の資源`~fetch$は，`計時~許可検査$に合格した ］ ⇒ ~RET ~UAが［ 資源に対する~domain名~検索を終えた ］直前の時刻 ◎ The time immediately before the user agent finishes the domain name lookup for the resource, if the last non-redirected fetch of the resource passes the timing allow check algorithm.
4. ~RET 0 ◎ zero, otherwise.

`connectStart@m

取得子は、次を走らせ~MUST： ◎ On getting, the connectStart attribute MUST return as follows:

1. ~IF［ `持続的~接続$ `RFC7230$r が利用されている ］~OR［ 資源は`局所~cache等$から検索取得されている ］ ⇒ ~RET `fetchStart$m と同じ値。 ◎ The same value as fetchStart, if a persistent connection [RFC7230] is used or the resource is retrieved from relevant application caches or local resources.

2. ~IF［ ~redirectされなかった最後の資源`~fetch$は，`計時~許可検査$に合格した ］ ⇒ ~RET ~UAが［ 資源を検索取得するために，~serverとの接続の確立を開始した ］直前の時刻 ◎ The time immediately before the user agent start establishing the connection to the server to retrieve the resource, if the last non-redirected fetch of the resource passes the timing allow check algorithm.

   ~transport接続が失敗して，~UAが接続を再~openした場合、 `connectStart$m は，新たな接続に対応する値を返す~SHOULDである。 ◎ If the transport connection fails and the user agent reopens a connection, connectStart should return the corresponding value of the new connection.

3. ~RET 0 ◎ zero, otherwise.

`connectEnd@m

取得子は、次を走らせ~MUST： ◎ On getting, the connectEnd attribute MUST return as follows:

1. ~IF［ `持続的~接続$ `RFC7230$r が利用されている ］~OR［ 資源は`局所~cache等$から検索取得されている ］ ⇒ ~RET `fetchStart$m と同じ値。 ◎ The same value as fetchStart, if a persistent connection [RFC7230] is used or the resource is retrieved from relevant application caches or local resources.

2. ~IF［ ~redirectされなかった最後の資源`~fetch$は，`計時~許可検査$に合格した ］ ⇒ ~RET ~UAが［ 資源を検索取得するために，~serverとの接続の確立を終えた ］直後の時刻 ◎ The time immediately after the user agent finish establishing the connection to the server to retrieve the resource, if the last non-redirected fetch of the resource passes the timing allow check algorithm.

   返される値には、SSL ~handshakeや SOCKS 認証などの他の所要時間も含む、~transport接続の確立に要した時間も含まれ~MUST。 ◎ The returned time MUST include the time interval to establish the transport connection, as well as other time intervals such as SSL handshake and SOCKS authentication.

   ~transport接続が失敗して，~UAが接続を再~openした場合、 `connectEnd$m は，新たな接続に対応する値を返す~SHOULDである。 ◎ If the transport connection fails and the user agent reopens a connection, connectEnd should return the corresponding value of the new connection.

3. ~RET 0 ◎ zero, otherwise.

`secureConnectionStart@m

取得子は、次を走らせ~MUST： ◎ On getting, the secureConnectionStart attribute MUST return as follows:

1. ~IF［ `持続的~接続$ `RFC7230$r が利用されている ］~OR［ 資源は`局所~cache等$から検索取得されている ］ ⇒ ~RET `fetchStart$m と同じ値 ◎ The same value as fetchStart, if a persistent connection [RFC7230] is used or the resource is retrieved from relevant application caches or local resources.
2. ~IF［ 保安的~transportが利用されている ］~AND［ ~redirectされなかった最後の資源`~fetch$は，`計時~許可検査$に合格した ］ ⇒ ~RET ~UAが［ 現在の接続を保安化する~handshake処理を開始した ］直前の時刻 ◎ The time immediately before the user agent starts the handshake process to secure the current connection, if a secure transport is used and the last non-redirected fetch of the resource passes the timing allow check algorithm.
3. ~RET 0 ◎ zero, otherwise.

`requestStart@m

取得子は、次を走らせ~MUST： ◎ On getting, the requestStart attribute MUST return as follows:

1. ~IF［ ~redirectされなかった最後の資源`~fetch$は，`計時~許可検査$に合格した ］ ⇒ ~RET ~UAが［［ `局所~cache等$, または ~server ］に向けて，その資源~要請を開始した ］直前の時刻 ◎ The time immediately before the user agent starts requesting the resource from the server, or from relevant application caches or from local resources, if the last non-redirected fetch of the resource passes the timing allow check algorithm.

   要請の送信-後に~transport接続が失敗して，~UAが接続を再~openして要請を再送信した場合、その新たな要請に対応する値を返さ~MUST。 ◎ If the transport connection fails after a request is sent and the user agent reopens a connection and resend the request, requestStart MUST return the corresponding values of the new request.

2. ~RET 0 ◎ zero, otherwise.

注記： この~interfaceは、要請の送信~完了を表現する “`requestEnd^m” の類の属性は含まない。 ◎ Note ◎ This interface does not include an attribute to represent the completion of sending the request, e.g. requestEnd.

• ~UAからの要請の送信~完了は、［ その種の属性が最も役立つ，~network~transportにおける 対応する完了~時刻 ］を常に指示するものではない。 ◎ Completion of sending the request from the user agent does not always indicate the corresponding completion time in the network transport, which brings most of the benefit of having such an attribute.
• 一部の~UAは、~HTTP層の~encapsulationに因り，実際の完了~時刻を決定する~costが高くつく。 ◎ Some user agents have high cost to determine the actual completion time of sending the request due to the HTTP layer encapsulation.

`responseStart@m

取得子は、次を走らせ~MUST： ◎ On getting, the responseStart attribute MUST return as follows:

1. ~IF［ ~redirectされなかった最後の資源`~fetch$は，`計時~許可検査$に合格した ］ ⇒ ~RET ~UAの~HTTP構文解析器が［ `局所~cache等$, または~server ］から［ 応答の最初の~byte（例： HTTP/2 に対しては ~frame~headerの~byte列 ／ HTTP/1.x に対しては 応答の~status行 ） ］を受信した直後の時刻 ◎ The time immediately after the user agent's HTTP parser receives the first byte of the response (e.g. frame header bytes for HTTP/2, or response status line for HTTP/1.x) from relevant application caches, or from local resources or from the server if the last non-redirected fetch of the resource passes the timing allow check algorithm.
2. ~RET 0 ◎ zero, otherwise.

注記： 何が “最初の~byteを受信した” かの定義には、 ~kernel, ~browserの~network~stack, ~HTTP構文解析器, ~renderer, 等々，いくつか理に適うものがある。 上では~HTTP構文解析器と定めているので、それが~dataを受信する前に［ ~clientの~kernel~buffer, その他の手続き ］の内側にて~dataを~queueする時間も含まれ得る。 ◎ Note ◎ There are many reasonable definitions of "receipt of first byte": as seen by the kernel, by the browsers network stack / HTTP parser, by the renderer, and so on. The above definition is with respect to the HTTP parser, and thus may include queuing time inside of client's kernel buffers and other steps that may preceed receipt of data by the HTTP parser.

注記： ~fetchが複数の要請からなる場合（例： 予行（ `preflight^en ）, 認証~challenge応答, ~redirect, 等々）、報告される `responseStart^m 値は，最後の要請のそれになる。 また、要請に対する応答が複数ある場合 — すなわち， `1xx$st ( Informational ) 応答がある場合 — 報告される `responseStart^m 値は，最後の要請に対する最初の応答のそれになる。 ◎ Note ◎ For fetches composed of multiple requests (e.g. preflights, authentication challenge-response, redirects, and so on), the reported responseStart value is that of the last request. In the case where more than one response is available for a request, due to an Informational 1xx response, the reported responseStart value is that of the first response to the last request.

`responseEnd@m

取得子は、次を走らせ~MUST： ◎ On getting, the responseEnd attribute MUST return as follows:

1. ~IF［ ~UAは~network~errorにより~fetchを中止した ］ ⇒ ~RET 中止した時刻 ◎ ↓

2. ~RET 次のうち，早い方の時刻

   • ~UAが［［ `局所~cache等$, または~server ］から資源の最後の~byteを受信した ］直後の時刻
   • ~transport接続が~closeされる直前の時刻
   ◎ The time immediately after the user agent receives the last byte of the response or immediately before the transport connection is closed, whichever comes first. The resource here can be received either from relevant application caches, local resources, or from the server. ◎ The time immediately before the user agent aborts the fetch due to a network error.

`transferSize@m

取得子は、次を走らせ~MUST： ◎ On getting, the transferSize attribute MUST return as follows:

1. ~IF［ ~redirectされなかった最後の資源`~fetch$は，`計時~許可検査$に合格した ］ ⇒ ~RET ［ `~HTTP~network~fetch$から受信された，応答の［ 一連の~header, および`~payload本体$ `RFC7230$r ］に消費された~size ］ ◎ the size, in octets received from a HTTP-network fetch, consumed by the response header fields and the response payload body [RFC7230] if the last non-redirected fetch of the resource passes the timing allow check algorithm.

   ~navigateするときに`~redirect等$があって，すべての`~redirect等$が同じ`生成元$ `RFC6454$r からである場合、それらの~redirectにより被った~HTTP~overheadも含まれる~SHOULDである。 ◎ If there are HTTP redirects or equivalent when navigating and if all the redirects or equivalent are from the same origin [RFC6454], this attribute should include the HTTP overhead of incurred redirects.

   この属性は、~HTTPによる~overhead（ HTTP/1.1 における，`~chunked符号法$や~headerの前後の空白（改行文字も含む） ／ `HTTP/2$ における，同じ~stream上の 他の［ ~serverから~clientへの~frame ］による~overhead）を含める~SHOULDである一方、低層の~protocolにおける~overhead（ TLS `RFC5246$r や TCP によるものなど）は，含める~SHOULDでない。 ◎ This attribute should include HTTP overhead (such as HTTP/1.1 chunked encoding and whitespace around header fields, including newlines, and HTTP/2 frame overhead, along with other server-to-client frames on the same stream), but should not include lower-layer protocol overhead (such as TLS [RFC5246]or TCP).

   注記： `transferSize$m 値が `encodedBodySize$m より低くなることもある： ~cache済みの応答が成功裡に再検証されたとき、 `transferSize$m は，再検証する際に被った~HTTP応答~headerたちの~sizeを報告し、 `encodedBodySize$m は，以前に検索取得された~payload本体の~sizeを報告する。 ◎ Note ◎ It is possible for transferSize value to be lower than encodedBodySize: when a cached response is successfully revalidated the transferSize reports the size of the response HTTP headers incurred during the revalidation, and encodedBodySize reports the size of the previously retrieved payload body.

2. ~RET 0 — 資源が`局所~cache等$から検索取得された場合も含め ◎ zero otherwise, including for resources retrieved from relevant application caches or from local resources.

`encodedBodySize@m

取得子は、次を走らせ~MUST： ◎ On getting, the encodedBodySize attribute MUST return as follows:

1. ~IF［ ~redirectされなかった最後の資源`~fetch$は，`計時~許可検査$に合格した ］ ⇒ ~RET `~HTTP~network-or-cache~fetch$から受信された `~payload本体$ `RFC7230$r の~octet数による~size — 適用されている`内容~符号法たち$ `RFC7231$r があれば それを~~復号する前の ◎ The size, in octets, received from a HTTP-network-or-cache fetch, of the payload body [RFC7230], prior to removing any applied content-codings [RFC7231], if the last non-redirected fetch of the resource passes the timing allow check algorithm.
2. ~IF［ 資源は`局所~cache等$から検索取得されている ］ ⇒ ~RET ~payload本体の~octet数による~size — 適用されている`内容~符号法たち$があれば それを~~復号する前の ◎ The size, in octets, of the payload body prior to removing any applied content-codings if the resource is retrieved from relevant application caches or from local resources.
3. ~RET 0 ◎ zero, otherwise.

注記： `encodedBodySize^m は、`応答~code$に依存して 0 にもなることもある — 例えば~HTTP `204$st (No Content), `3XX$st, 等々。 ◎ Note ◎ The encodedBodySize may be zero depending on the response code - e.g. HTTP 204 (No Content), 3XX, etc.

`decodedBodySize@m

取得子は、次を走らせ~MUST： ◎ On getting, the decodedBodySize attribute MUST return as follows:

1. ~IF［ ~redirectされなかった最後の資源`~fetch$は，`計時~許可検査$に合格した ］ ⇒ ~RET `~HTTP~network-or-cache~fetch$から受信された`~message本体$ † `RFC7230$r の~octet数による~size — 適用されている`内容~符号法たち$ `RFC7231$r を~~復号した後の

   【† 厳密には，`~payload本体$であろう（それ以前に`転送~符号法$も~~復号される必要がある筈なので） 】

   ◎ The size, in octets, received from a HTTP-network-or-cache fetch, of the message body [RFC7230], after removing any applied content-codings [RFC7231], if the last non-redirected fetch of the resource passes the timing allow check algorithm.
2. ~IF［ 資源は`局所~cache等$から検索取得された ］ ⇒ ~RET ~payloadの~size — 適用されている`内容~符号法たち$があればそれを~~復号した後の ◎ The size, in octets, of the payload after removing any applied content-codings, if the resource is retrieved from relevant application caches or from local resources.
3. ~RET 0 ◎ zero, otherwise.

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 を呼び出すことにより，変更-を要請できる。 ◎ 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.

各 `ECMAScript 大域~環境$は、次のものを持つ： ◎ Each ECMAScript global environment has:

• `資源~計時~buffer~size上限@ — 初期~時は 250 以上【が推奨される】。 ◎ a resource timing buffer size limit which should initially be 250 or greater.
• `資源~計時~buffer現size@ — 初期~時は 0 。 ◎ a resource timing buffer current size which is initially 0.
• `資源~計時~buffer満杯~flag@ — 初期~時は ~OFF 。 ◎ a resource timing buffer full flag which is initially false.

partial interface `Performance$I {
  void `clearResourceTimings()$m;
  void `setResourceTimingBufferSize$m(unsigned long %maxSize);

  attribute `EventHandler$I `onresourcetimingbufferfull$m;
};

`Performance$I ~interfaceは `HR-TIME-2$r にて定義される。 ◎ The Performance interface is defined in [HR-TIME-2].

`clearResourceTimings()@m

被呼出時には、次を走らせ~MUST： ◎ The method clearResourceTimings runs the following steps:

1. `処理能~entry~buffer$から すべての `PerformanceResourceTiming$I ~objを除去する ◎ remove all PerformanceResourceTiming objects in the performance entry buffer.
2. `資源~計時~buffer現size$ ~SET 0 ◎ set resource timing buffer current size to 0.
3. `資源~計時~buffer満杯~flag$ ~SET ~OFF ◎ set resource timing buffer full flag to false.

`setResourceTimingBufferSize(maxSize)@m

被呼出時には、次を走らせ~MUST： ◎ The setResourceTimingBufferSize method runs the following steps:

1. `資源~計時~buffer~size上限$ ~SET `maxSize^V

   ［ `maxSize^V ~LT `資源~計時~buffer現size$ ］であっても，`処理能~entry~buffer$からは `PerformanceResourceTiming$I ~objを除去しない。

   ◎ Set resource timing buffer size limit to the maxSize parameter. If the maxSize parameter is less than resource timing buffer current size, no PerformanceResourceTiming objects are to be removed from the performance entry buffer.
2. ~IF［ `maxSize^V ~GT `資源~計時~buffer現size$ ］ ⇒ `資源~計時~buffer満杯~flag$ ~SET ~OFF ◎ If the maxSize parameter is greater than resource timing buffer current size, set resource timing buffer full flag to false.

`onresourcetimingbufferfull@m

下に述べる `resourcetimingbufferfull^et ~event用の~event~handler。 ◎ The attribute onresourcetimingbufferfull is the event handler for the resourcetimingbufferfull event described below.

`処理能~entry~buffer$に新たな `PerformanceResourceTiming$I ~obj `~entry^V を `追加する@ ときは、次の手続きを走らす： ◎ To add a PerformanceResourceTiming entry (new entry) in the performance entry buffer, run the following steps:

1. ~IF［ `資源~計時~buffer現size$ ~LT `資源~計時~buffer~size上限$ ］： ◎ If resource timing buffer current size is less than resource timing buffer size limit, run the following substeps:

   1. `処理能~entry~buffer$に `~entry^V を追加する ◎ Add new entry to the performance entry buffer.
   2. `資源~計時~buffer現size$ ~INCBY 1 ◎ Increase resource timing buffer current size by 1.

2. ~IF［ `資源~計時~buffer現size$ ~GTE `資源~計時~buffer~size上限$ ］~AND［ `資源~計時~buffer満杯~flag$ ~EQ ~OFF ］： ◎ If resource timing buffer current size is greater than or equal to resource timing buffer size limit and the resource timing buffer full flag is false, run the following substeps:

   1. `資源~計時~buffer満杯~flag$ ~SET ~ON ◎ Set the resource timing buffer full flag to true.
   2. `Performance$I ~objに向けて，名前 `resourcetimingbufferfull$et の`~eventを発火する$ — 次のように初期化して ⇒＃ `bubbles^m 属性 ~SET ~T ◎ Fire an event named resourcetimingbufferfull at the Performance object, with its bubbles attribute initialized to true.

4.5. 非同一生成元~資源

~server側~appは、この節で前に指定された，［ さもなければ`非同一生成元$の制約から値が 0 にされる属性 ］の，~UAにおける公開を許容するために、当の文書~生成元を値とする `Timing-Allow-Origin$h ~HTTP応答~header返してもよい。 ◎ 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 the cross-origin restrictions previously specified in this section.

Timing-Allow-Origin = 1#( `origin-or-null$P / `wildcard$P )

5.1. 処理~model

`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 resources from different origins. User agents may perform internal processing in between timings, which allow for non-normative intervals between timings.

現在の`閲覧文脈$において ~fetch される ~EACH ( 資源 ) に対し： ◎ For each resource fetched by the current browsing context, excluding resources fetched by cross-origin stylesheets fetched with no-cors policy, perform the following steps:

1. ~IF［ 資源は `no-cors^i ~policyの下で~fetchされる 非同一生成元~stylesheetである ］ ⇒ ~CONTINUE ◎ ↑

   この非同一生成元の除外は、 Fetch registry を介して定義されるべきである： CSS については、 Fetch の用語, および［ no-CORS CSS 下位資源に対し 何らかの “不透明な要請~flag” のような類の~flagを ~ON にすること ］を通して定義される必要がある。 しかる後、 Resource Timing において，資源~fetch~eventを表面化させるために Fetch registry と~interfaceするべきである。 Issue 27 ◎ Above cross-origin exclusion should be defined via Fetch registry: CSS needs to be defined in terms of Fetch and set some kind of "opaque request flag" for no-CORS CSS subresources. In turn, Resource Timing should interface with Fetch registry to surface resource fetch events. ◎ Issue 27

2. `~obj作成@i：

   1. %object ~SET 新たな `PerformanceResourceTiming$I ~obj ◎ ↓
   2. %object の `entryType$m ~SET `resource^l ◎ Create a new PerformanceResourceTiming object and set entryType to the DOMString resource.
   3. 資源の検索取得を~queueする直前に ⇒＃ %object の `startTime$m ~SET `現在の時刻$； %object の `nextHopProtocol$m ~SET 空~文字列 ◎ Immediately before the user agent starts to queue the resource for retrieval, record the current time in startTime, and set nextHopProtocol to the empty DOMString.
   4. %object の `initiatorType$m ~SET 資源の起動元 ◎ Record the initiator of the resource in initiatorType.
   5. %object の `name$m ~SET 要請した資源の`解決-済み~URL$ ◎ ↓

   6. ~IF［ 現在の［ `閲覧文脈$ ／ ~worker文脈 ］に`合致する作動中の~worker$ %worker はある `service-workers-1$r ］：

      1. ~IF［ %worker はすでに可用である ］ ⇒ %worker に向けて`名前~fetch_evの~eventを発火する$直前に ⇒ %object の `workerStart$m ~SET `現在の時刻$
      2. ~ELSE ⇒ %worker を`走らす$直前に ⇒ %object の `workerStart$m ~SET `現在の時刻$
      ◎ Record the resolved URL of the requested resource in name. If there is an active worker ([service-workers-1]) matching the current browsing or worker context's, immediately before the user agent runs the worker record the time as workerStart, or if the worker is already available, immediately before the event named `fetch` is fired at the active worker record the time as workerStart. Otherwise, if there is no matching service worker registration, set workerStart value to zero.
   7. ~ELSE（合致する`~service~worker登録$はない） ⇒ %object の `workerStart$m ~SET 0 ◎ ↑

3. `~fetch開始@i：

   1. %fetchStart ~LET `現在の時刻$
   2. %object の `fetchStart$m ~SET %fetchStart
   3. `~fetching$を開始する直前に ⇒ %object の［ `domainLookupStart$m, `domainLookupEnd$m, `connectStart$m, `connectEnd$m ］ ~SET %fetchStart
   ◎ Immediately before a user agent starts the fetching process, record the current time as fetchStart. Let domainLookupStart, domainLookupEnd, connectStart and connectEnd be the same value as fetchStart.

4. `収集~開始@i：

   1. ~IF［ 別の既存の~data, あるいは すでに完了した［ `現在の文書$から起動された`~fetch$ ］による~dataを再利用する ］ ⇒ ~RET ◎ If the user agent is to reuse the data from another existing or completed fetch initiated from the current document, abort the remaining steps.

   2. ~IF［ ~redirectされなかった最後の資源`~fetch$は，`計時~許可検査$に合格しなかった ］：

      1. %object の［ `redirectStart$m, `redirectEnd$m, `domainLookupStart$m, `domainLookupEnd$m, `connectStart$m, `connectEnd$m, `requestStart$m, `responseStart$m, `secureConnectionStart$m ］属性 ~SET 0
      2. ~GOTO `応答~終了0$i
      ◎ If the last non-redirected fetch of the resource fails the timing allow check, the user agent MUST set redirectStart, redirectEnd, domainLookupStart, domainLookupEnd, connectStart, connectEnd, requestStart, responseStart and secureConnectionStart to zero and go to step 16.
   3. %object の［ `domainLookupStart$m, `domainLookupEnd$m, `connectStart$m, `connectEnd$m ］属性 ~SET %fetchStart ◎ Let domainLookupStart, domainLookupEnd, connectStart and connectEnd be the same value as fetchStart.
   4. ~IF［ 資源は`局所~cache等$（ `~HTTP~cache$ `RFC7234$r も含む）から~fetchされている ］ ⇒ ~GOTO `要請~開始$i ◎ If the resource is fetched from the relevant application cache or local resources, including the HTTP cache [RFC7234], go to step 14.
   5. ~IF［ ~domain~検索は不要 ］ ⇒ ~GOTO `接続-開始$i ◎ ↓
   6. ~domain名~検索を開始する直前に ⇒ %object の `domainLookupStart$m ~SET `現在の時刻$ ◎ If no domain lookup is required, go to step 12. Otherwise, immediately before a user agent starts the domain name lookup, record the time as domainLookupStart.

   7. ~domain名~検索を終えた直後に（~UAは、その前に複数の再試行を要し得る）：

      1. ~IF［ 検索は成功した ］~OR［ 資源は `計時~許可検査$に合格した ］ ⇒ %object の `domainLookupEnd$m ~SET `現在の時刻$
      2. ~IF［ 検索は失敗した ］ ⇒ ~GOTO `最終~記録-$i
      ◎ Record the time as domainLookupEnd immediately after the domain name lookup is successfully done. A user agent may need multiple retries before that. If the domain name lookup fails and resource passes the timing allow check record the time as domainLookupEnd and go to step 17.

5. `接続-開始@i：

   1. ~IF［ 資源`~fetch$に持続的~transport接続が利用されている ］ ⇒ %object の［ `connectStart$m, `connectEnd$m ］ ~SET %object の `domainLookupEnd$m と同じ値 ◎ ↓

   2. ~ELSE：

      1. ~serverへの接続を起動する直前に ⇒ %object の `connectStart$m ~SET `現在の時刻$
      2. 接続-処理-を終えた時点で（~UAは、この時点より前に複数の再試行を要し得る） ⇒ %object の `connectEnd$m ~SET `現在の時刻$
      3. ~IF［ ~serverまたは~proxyへの接続を確立できた ］ ⇒ %object の `nextHopProtocol$m 値 ~SET 接続に利用されている~ALPN~ID
      4. ~ELSE（接続を確立できなかった） ⇒ ~GOTO `最終~記録-$i
      ◎ If a persistent transport connection is used to fetch the resource, let connectStart and connectEnd be the same value of domainLookupEnd. Otherwise, record the time as connectStart immediately before initiating the connection to the server and record the time as connectEnd immediately after the connection to the server or the proxy is established. A user agent may need multiple retries before this time. Once connection is established set the value of nextHopProtocol to the ALPN ID used by the connection. If a connection can not be established, record the time up to the connection failure as connectEnd and go to step 17.
   3. ~IF［ 保安的~transportが利用されている ］ ⇒ 接続を保安化する~handshake処理-の直前に ⇒ %object の `secureConnectionStart$m ~SET `現在の時刻$ ◎ The user agent MUST set the secureConnectionStart attribute as follows: ◎ When a secure transport is used, the user agent MUST record the time as secureConnectionStart immediately before the handshake process to secure the connection.
   4. ~ELSE ⇒ %object の `secureConnectionStart$m ~SET 0 ◎ When a secure transport is not used, the user agent MUST set the value of secureConnectionStart to 0.
6. `要請~開始@i ⇒ 資源に対する要請の送信を開始する直前に ⇒ %object の `requestStart$m ~SET `現在の時刻$ ◎ Immediately before a user agent starts sending the request for the resource, record the current time as requestStart.
7. `応答~開始@i ⇒ 応答の最初の~byteを受信した直後に ⇒ %object の `responseStart$m ~SET `現在の時刻$ ◎ Record the time as responseStart immediately after the user agent receives the first byte of the response.

8. `応答~終了0@i：

   1. ~IF［ 要請の送信-, または応答~全体の受信-に失敗したため，接続を再~openする必要がある ］ ⇒ ~GOTO `接続-開始$i ◎ Record the time as responseEnd immediately after receiving the last byte of the response.↓ ◎ Return to step 12 if the user agent fails to send the request or receive the entire response, and needs to reopen the connection.

      例えば，`持続的~接続$ `RFC7230$r が可能化されているときは、まず最初に，要請を送信するための~open接続の再利用を（その接続は`非同期に~close$され得るが）試行してよい。 そのような場合、［ `connectStart$m, `connectEnd$m, `requestStart$m ］は，再~open接続において収集された計時~情報を表現するべきである。 ◎ When persistent connection [RFC7230] is enabled, a user agent may first try to re-use an open connect to send the request while the connection can be asynchronously closed. In such case, connectStart, connectEnd and requestStart should represent timing information collected over the re-open connection.

   2. 応答の最後の~byteを受信した直後に ⇒ %object の `responseEnd$m ~SET `現在の時刻$ ◎ ↑
   3. %object の［ `transferSize$m, `encodedBodySize$m, `decodedBodySize$m ］ ~SET それぞれの属性の定義に従う値 — これらは、`計時~許可検査$の対象になる。 ◎ Set the value of transferSize, encodedBodySize, decodedBodySize to corresponding values, subject to timing allow check algorithm.

9. `最終~記録-@i：

   1. ~IF［ %object の `responseEnd$m はまだ設定されていない ］ ⇒ %object の `responseEnd$m ~SET `現在の時刻$
   2. %object の `duration$m ~SET ( %object の `responseEnd$m ) − ( %object の `startTime$m )
   ◎ If responseEnd is not set, set it to the current time. Record the difference between responseEnd and startTime in duration.

10. ~IF［ 資源が~fetchされた結果が`~redirect等$になった ］： ◎ If the fetched resource results in an HTTP redirect or equivalent, then

    1. `新たな資源^V ~SET ~redirect先の資源 ◎ ↓
    2. ~IF［ 現在の資源と `新たな資源^V は，いずれも［［ `現在の文書$と`同一生成元$からのものでない ］~AND［ `計時~許可検査$の結果 ~EQ `不合格^i ］］］ ⇒ %object の［ `redirectStart$m, `redirectEnd$m ］~SET 0 ◎ If the current resource and the redirected resource are not from the same origin as the current document, and the timing allow check algorithm fails for either resource, set redirectStart and redirectEnd to 0. Then, return to step 5 with the new resource.

    3. ~ELSE：

       1. ~IF［ %object の `redirectStart$m の値はまだ設定されていない ］ ⇒ %object の `redirectStart$m ~SET %fetchStart ◎ If the value of redirectStart is not set, let it be the value of fetchStart.
       2. %object の `redirectEnd$m ~SET %object の `responseEnd$m の値 ◎ Let redirectEnd be the value of responseEnd.
       3. ［［ `startTime$m, `redirectStart$m, `redirectEnd$m, `initiatorType$m ］を除く， %object のすべての属性 ］ ~SET 0 ◎ Set all the attributes in the PerformanceResourceTiming object to 0 except startTime, redirectStart, redirectEnd, and initiatorType.
    4. 資源 ~SET `新たな資源^V ◎ ↓
    5. ~GOTO `~fetch開始$i ◎ Return to step 5 with the new resource.
11. `処理能~entryを~queueする$( %object ) ◎ Queue the PerformanceResourceTiming object.
12. %object を`処理能~entry~buffer$に`追加する$ ◎ Add the PerformanceResourceTiming object to the performance entry buffer.

~entryが いつ`処理能~entry~buffer$に追加されるかを明確化する。 この仕様は、［ 最後の 2 つの段を，資源の `load^et ~eventが生じる前後のどちらに走らすべきか ］は，指定しない。 関係する論点は issue 82 を見よ。 ◎ Issue 82: Clarify when entry is added to performance entry buffer ◎ This specification does not specify whether steps 20 and 21 should run before or after the load event of the resource—see issue 82 for related discussion. ◎ Issue 82: Clarify when entry is added to performance entry buffer

5.2. 単調増加~clock

計時~属性の値は、資源`~fetch$の間，計時~属性が~system~clock調整により~skewされないように、単調増加で~MUST。 時系列順に記録された２つの計時~属性の差分は決して負であっては~MUST_NOT。 文書の下位~資源も含めた，すべての資源において、~UAは根元の文書~naviの開始時点の~system~clockを記録し，後続の計時~属性は、~naviの開始からの経過時間を測定する単調増加~clockの下で定義され~MUST。 ◎ The value of the timing attributes MUST monotonically increase to ensure timing attributes are not skewed by adjustments to the system clock while fetching the resource. The difference between any two chronologically recorded timing attributes MUST never be negative. For all resources, including subdocument resources, the user agent MUST record the system clock at the beginning of the root document navigation and define subsequent timing attributes in terms of a monotonic clock measuring time elapsed from the beginning of the navigation.