Server Timing（日本語訳）

1. 序論

~web~appの処理能~特性を正確aに測定することは、 ~web~appをより速くするための重要な側面を成す。 `NAVIGATION-TIMING$r, `RESOURCE-TIMING$r は、文書とその資源に対する要請の詳細な計時~情報を供する — それは、［要請が起動された時刻から，接続を折衝して応答を受信するまで］の様々な節目を含む。しかしながら、 ~UAは，要請の計時~dataは観測できても、要請から応答までを巡るある種の段階 — 例：要請はどこを経由し，~server上のどこで時間を費したか, 等々 — については，その内情 — ［どれだけ／なぜ］時間がかかったか — を知り得ない。 ◎ Accurately measuring performance characteristics of web applications is an important aspect of making web applications faster. [NAVIGATION-TIMING] and [RESOURCE-TIMING] provide detailed request timing information for the document and its resources, which include time when the request was initiated, and various milestones to negotiate the connection and receive the response. However, while the user agent can observe the timing data of the request it has no insight into how or why certain stages of the request-response cycle have taken as much time as they have - e.g., how the request was routed, where the time was spent on the server, and so on.

この仕様は、次を導入する： ◎ This specification introduces＼

`Server-Timing$h ~header【！PerformanceServerTiming interface】 — ~serverが要請から応答までを巡る処理能~計量を~UAへ通信することを可能化する。 ◎ PerformanceServerTiming interface, which enables the server to communicate performance metrics about the request-response cycle to the user agent,＼
`PerformanceServerTiming$I ~interface — ~appが自身の送達を最適化するために，これらの計量を［収集して, 処理して, 動作する］ことを可能化する。 ◎ and a JavaScript interface to enable applications to collect, process, and act on these metrics to optimize application delivery.

2. 適合性

【この節の内容は ~W3C日本語訳共通~page に移譲。】

3. `Server-Timing^h ~header

`Server-Timing@h ~headerが、要請から応答までを巡る 1 個~以上の［計量, 記述］を通信するために利用される。この~header用の~ABNF `RFC5234$r 構文は、次に従う： ◎ The Server-Timing header field is used to communicate one or more metrics and descriptions for the given request-response cycle. The ABNF (Augmented Backus-Naur Form) [RFC5234] syntax for the Server-Timing header field is as follows:

`Server-Timing@P
	= #`server-timing-metric$P
`server-timing-metric@P
	= `metric-name$P *( `OWS^P ";" `OWS^P `server-timing-param$P )
`metric-name@P
	= `token^P
`server-timing-param@P
	= `server-timing-param-name$P `OWS^P "=" `OWS^P `server-timing-param-value$P
`server-timing-param-name@P
	= `token^P
`server-timing-param-value@P
	= `token^P
	/ `quoted-string^P

`#^P, `*^P, `OWS$P, `token$P, `quoted-string$P の定義は `RFC7230$r を見よ。 ◎ See [RFC7230] for definitions of #, *, OWS, token, and quoted-string.

応答には、同じ `metric-name$P を伴う複数個の `server-timing-metric$P ~entryを伴わせてもヨイ。 ~UAは、そのような~entryすべてを処理して~APIに公開するモノトスル。 ◎ A response MAY have multiple server-timing-metric entries with the same metric-name, and the user agent MUST process and expose all such entries.

~UAは、供された各~計量をどの順序で表面化してもヨイ — すなわち，~HTTP~header内の計量どうしの順序は有意でない。 ◎ The user agent MAY surface provided metrics in any order - i.e. the order of metrics in the HTTP header field is not significant.

この~headerは、将来の~parameterを許容するため，拡張-可能な構文で定義される。 ~UAは、応答の `Server-Timing^h ~header内の特定0の `server-timing-param-name$P を認識しないならば、 ~errorを通達する代わりに，それらの~tokenを無視して処理を継続するモノトスル。 ◎ This header field is defined with an extensible syntax to allow for future parameters. A user agent that does not recognize particular server-timing-param-name in the Server-Timing header field of a response MUST ignore those tokens and continue processing instead of signaling an error.

多義性を避けるため、 `server-timing-metric$P の中に同じ `server-timing-param-name$P を伴う `server-timing-param$P が複数回~現れるベキでない。そのような各 `server-timing-param$P に対しては、最初に現れるものに限り考慮して，残りはすべて無視するモノトスル — ［最初のそれが不完全, または妥当でない］としても、また，［残りのそれらに対し~errorを通達する］ことも［ `server-timing-metric$P の処理を改める］こともなく。これ以外に、 `server-timing-metric$P の中の~parameterどうしの順序が有意と見なされる事例はない。 ◎ To avoid any possible ambiguity, individual server-timing-param-names SHOULD NOT appear multiple times within a server-timing-metric. If any server-timing-param-name is specified more than once, only the first instance is to be considered, even if the server-timing-param is incomplete or invalid. All subsequent occurrences MUST be ignored without signaling an error or otherwise altering the processing of the server-timing-metric. This is the only case in which the ordering of parameters within a server-timing-metric is considered to be significant.

~UAは、 `Server-Timing$P 内のどの［ `metric-name$P ／ `server-timing-param-name$P ／ `server-timing-param-value$P ］にも含まれない，余計な文字は無視するモノトスル。 ◎ User agents MUST ignore extraneous characters found after a server-timing-param-value but before the next server-timing-param and before the end of the current server-timing-metric. ◎ User agents MUST ignore extraneous characters found after a metric-name but before the first server-timing-param and before the next server-timing-metric.

この仕様は、 `server-timing-param$P 用の `server-timing-param-name$P として，次を確立する — いずれも任意選択~である：

`dur^l （所要時間） ⇒ 対応する `server-timing-param-value$P は、 `duration$m に公開される。
`desc^l （記述） ⇒ 対応する `server-timing-param-value$P は、 `description$m に公開される。

◎ This specification establishes the server-timing-params for server-timing-param-names "dur" for duration and "desc" for description, both optional.

注記： ◎ Note

~HTTP~overheadを最小限にするため、名前【 `metric-name$P ／ `server-timing-param-name$P 】や記述には，アリな限り短いものを供するべきである — ［略称を利用する／任意選択なものはアリな所では省略する］など。 ◎ To minimize the HTTP overhead the provided names and descriptions should be kept as short as possible - e.g. use abbreviations and omit optional values where possible.
［ ~client, ~server, `媒介者$たち］どうしで時計の同期法は保証できないので、 ~clientの時列線~上に有意義な `startTime^m を対応付けることはアリでない。その理由から、【他の計時~仕様にはある】 `startTime$m の属性化は，この仕様からは~~意図的に省略されている。開発者は，複数の~entryの間に関係性を確立したいと求めるなら、計量の名前【 `metric-name$P 】や, その記述を介して~custom~dataを通信することにより，それを行える。 ◎ Because there can be no guarantee of clock synchronization between client, server, and intermediaries, it is impossible to map a meaningful startTime onto the clients timeline. For that reason, any startTime attribution is purposely omitted from this specification. If the developers want to establish a relationship between multiple entries, they can do so by communicating custom data via metric names and/or descriptions.
~serverや関連な各`媒介者$は、どの計量をいつ~UAに通信するかについて，全部的な制御を有する。例えば，一部の計量への~accessは、 ~privacyや~securityの理由に因り制約され得る — § ~privacyと~security を見よ。 ◎ The server and/or any relevant intermediaries are in full control of which metrics are communicated to the user agent and when. For example, access to some metrics may be restricted due to privacy or security reasons - see § Privacy and Security section.

`~server計時~headerを構文解析する@ ときは、所与の ( 文字列 %~field ) に対し： ◎ To parse a server-timing header field given a string field:

%位置 ~LET %~field 内の始端を指している`位置~変数$ ◎ Let position be a position variable, initially pointing at the start of field.
%名前 ~LET %~field 内の %位置から `003B^U `;^smb 以外の`符号位置~並びを収集する$ ◎ Let name be the result of collecting a sequence of code points from field that are not equal to U+003B (;), given position.
%名前 ~SET `前後の~ASCII空白~列を剥ぐ$( %名前 ) ◎ Strip leading and trailing ASCII whitespace from name.
~IF［ %名前 ~EQ 空~文字列］ ⇒ ~RET ~NULL ◎ If name is an empty string, return null.
%計量 ~LET 新たな `PerformanceServerTiming$I ~obj ◎ Let metric be a new PerformanceServerTiming＼
%計量の`計量~名$ ~SET %名前 ◎ whose metric name is name.
%~parameter群 ~LET 新たな`有順序~map$ ◎ Let params be an empty ordered map.
~WHILE［ %位置↗ ~NEQ ε ］： ◎ While position is not at the end of field:
1. %位置 ~INCBY 1 ◎ Advance position by 1.
2. %~parameter名 ~LET %~field 内の %位置から `003D^U `=^smb 以外の`符号位置~並びを収集する$ ◎ Let paramName be the result of collecting a sequence of code points from field that are not equal to U+003D (=), given position.
3. %~parameter名 ~SET `前後の~ASCII空白~列を剥ぐ$( %~parameter名 ) ◎ Strip leading and trailing ASCII whitespace from paramName.
4. ~IF［ %~parameter名 ~EQ 空~文字列］~OR［ %~parameter群[ %~parameter名 ] ~NEQ ε ］ ⇒ ~CONTINUE ◎ If paramName is an empty string or params[paramName] exists, continue.
5. %位置 ~INCBY 1 ◎ Advance position by 1.
6. %~parameter値 ~LET 空~文字列 ◎ Let paramValue be an empty string.
7. %~field 内の %位置から`~ASCII空白を読飛ばす$ ◎ Skip ASCII whitespace within field given position.
8. ~IF［ %位置↗ ~EQ `0022^U `"^smb ］： ◎ If the code point at position within field is U+0022 ("), then:
  1. %~parameter値 ~SET `~HTTP引用符付き文字列を収集する$( %~field, %位置, `値を抽出する^i ) ◎ Set paramValue to the result of collecting an HTTP quoted string from field given position with the extract-value flag set.
  2. %~field 内の %位置から `003B^U `;^smb 以外の`符号位置~並びを収集する$ ◎ Collect a sequence of code points from field that are not equal to U+003B (;), given position. The result is not used.
9. ~ELSE： ◎ Otherwise:
  1. %生の~parameter値 ~LET %~field 内の %位置から `003B^U `;^smb 以外の`符号位置~並びを収集する$ ◎ Let rawParamValue be the result of collecting a sequence of code points from field that are not equal to U+003B (;), given position.
  2. %~parameter値 ~LET `前後の~ASCII空白~列を剥ぐ$( %生の~parameter値 ) ◎ Let paramValue be the result of stripping rawParamValue.
%計量の`~parameter群$ ~SET %~parameter群 ◎ Set metric's params to params.
~RET %計量 ◎ Return metric.

4. `PerformanceServerTiming^I ~interface

[`Exposed$=(Window,Worker)]
interface `PerformanceServerTiming@I {
  readonly attribute `DOMString$ `name$m;
  readonly attribute `DOMHighResTimeStamp$ `duration$m;
  readonly attribute `DOMString$ `description$m;
  [`Default$] `object$ `toJSON$m();
};

`toJSON@m 演算は、 `既定の~toJSON手続き$ `WEBIDL$r を走らす。 ◎ When toJSON is called, run [WEBIDL]'s default toJSON steps.

`name@m 取得子~手続きは ⇒ ~RET コレの`計量~名$ ◎ 4.1 name attribute ◎ The name getter steps are to return this's metric name.

`duration@m 取得子~手続きは： ◎ 4.2 duration attribute ◎ The duration getter steps are to do the following:

%dur ~LET コレの`~parameter群$[ `dur^l ] ◎ ↓
~IF［ %dur ~EQ ε ］ ⇒ ~RET 0 ◎ If this's params["dur"] does not exist, return 0.
%所要時間 ~SET `浮動小数点数として構文解析する$( %dur ) ◎ Let dur be the result of parsing this's params["dur"] using the rules for parsing floating-point number values.
~IF［ %所要時間 ~EQ `失敗^i ］ ⇒ ~RET 0 ◎ If dur is an error, return 0;＼
~RET %所要時間 ◎ Otherwise return dur.

注記： `duration$m は `DOMHighResTimeStamp$c であり，通例的には`所要時間$を~mill秒数で表現する。これは，実施においては【~serverに対し】施行-可能でないので、 `duration$m が表現する時間は，どの単位にもなり得るが、 `所要時間$を~mill秒数で表現することが推奨される。 ◎ Note Since duration is a DOMHighResTimeStamp, it usually represents a duration in milliseconds. Since this is not enforcable in practice, duration can represent any unit of time, and having it represent a duration in milliseconds is a recommendation.

`description@m 取得子~手続きは：

%desc ~LET コレの`~parameter群$[ `desc^l ] ◎ ↓
~IF［ %desc ~EQ ε ］ ⇒ ~RET 空~文字列 ◎ If this's params["dur"] does not exist, return 0.
~RET %desc ◎ Otherwise return dur.

◎ 4.3 description attribute ◎ The description getter steps are to return this's params["desc"] if it exists, otherwise the empty string.

各 `PerformanceServerTiming$I には、次に挙げるものが結付けられる： ◎ ↓

`計量~名@ ⇒ 文字列 — 初期~時は空~文字列とする。 ◎ A PerformanceServerTiming has an associated string metric name, initially set to the empty string.
`~parameter群@ ⇒ `有順序~map$ — 初期~時は空とする。 ◎ A PerformanceServerTiming has an associated ordered map params, initially empty.

5. `PerformanceResourceTiming^I ~interfaceに対する拡張

この仕様は、 `PerformanceResourceTiming$I ~interface `RESOURCE-TIMING$r を部分的に拡張する。 ◎ The PerformanceResourceTiming interface, which this specification partially extends, is defined in [RESOURCE-TIMING].

[Exposed=(Window,Worker)]
partial interface `PerformanceResourceTiming$I {
  readonly attribute FrozenArray<`PerformanceServerTiming$I> `serverTiming$m;
};

`serverTiming@m 取得子~手続きは： ◎ 5.1 serverTiming attribute ◎ The serverTiming getter steps are the following:

%~entry群 ~LET 新たな`~list$ ◎ Let entries be a new list.
コレの`計時~報$pTの`~server計時~header群$fTを成す ~EACH( %~field ) に対し： ◎ For each field in this's timing info's server-timing headers:
1. %計量 ~LET `~server計時~headerを構文解析する$( %~field ) ◎ Let metric be the result of parsing field.
2. ~IF［ %計量 ~NEQ ~NULL ］ ⇒ %~entry群に %計量を`付加する$ ◎ If metric is not null, append metric to entries.
~RET %~entry群 ◎ Return entries.

6. ~privacyと~security

◎非規範的

この仕様に定義した~interfaceは、敏感になり得る［ ~app／基盤］情報を，~server計時~計量を広告する資源を内包するどの~web~pageにも公開する。この理由から、 `PerformanceServerTiming$I ~interfaceへの~accessは，既定では`同一-生成元$施策により制約される。資源~providerは、［ `Timing-Allow-Origin$h ~HTTP応答~header `RESOURCE-TIMING$r を追加して， ~server計量への~accessが許容され得る~domainを指定する］ことにより，［ ~server計時~情報が可用になることを明示的に許容できる］が、その場合でも，~UAは、 `同一-生成元$の制約を保ってもヨイ。 ◎ The interfaces defined in this specification expose potentially sensitive application and infrastructure information to any web page that has included a resource that advertises server timing metrics. For this reason the access to PerformanceServerTiming interface is restricted by the same origin policy by default. Resource providers can explicitly allow server timing information to be available by adding the Timing-Allow-Origin HTTP response header, as defined in [RESOURCE-TIMING], that specifies the domains that may be allowed to access the server metrics, but the user agent MAY keep the same origin policy restriction.

`Timing-Allow-Origin^h ~headerの利用に加えて，~serverは、関連な~logicを利用して，どの計量を［いつ／どこへ］返すかを制御することもできる。例えば、正しく認証した利用者に限り，ある種の計量を供するなど。 ◎ In addition to using the Timing-Allow-Origin HTTP response header, the server can also use relevant logic to control which metrics are returned, when, and to whom - e.g. the server may only provide certain metrics to correctly authenticated users and nothing at all to all others.

7. ~IANA考慮点

恒久的~message~header~registryは、次の登録により更新されるべきである `RFC3864$r ： ◎ The permanent message header field registry should be updated with the following registrations ([RFC3864]): ◎ 7.1. Server-Timing Header Field

~header名 ⇒ `Server-Timing^h
適用-可能な~protocol ⇒ http
位置付け ⇒ 標準
著作者／変更~制御者 ⇒ W3C
仕様~文書 ⇒ この仕様（ `Server-Timing$h ~headerを見よ）

◎ Header field name • Server-Timing Applicable protocol • http Status • standard Author/Change controller • W3C Specification document • This specification (See Server-Timing Header Field)

A. 例

◎非規範的

> GET /resource HTTP/1.1
> Host: example.com

< HTTP/1.1 200 OK
< Server-Timing: miss, db;dur=53, app;dur=47.2
< Server-Timing: customView, dc;desc=atl
< Server-Timing: cache;desc="Cache Read";dur=23.2
< Trailer: Server-Timing
< (... snip response body ...)
< Server-Timing: total;dur=123.4

名前	所要時間（ `dur^P ）	記述（ `desc^P ）
`miss^v
`db^v	`53^v
`app^v	`47.2^v
`customView^v
`dc^v		`atl^l
`cache^v	`23.2^v	`Cache Read^l
`total^v	`123.4^v

上の~headerは、 6 個の計量を通信している — それは、 ~serverが~UAに向けて~dataを通信するためにアリな仕方~すべてを示している：計量~名【 `metric-name$P 】のみ, 値を伴う計量, 値と記述を伴う計量, 記述を伴う計量。例えば，上の各~計量は、 `example.com/resource.jpg^c への~fetchに対し，次を指示しているであろう： ◎ The above header fields communicate six distinct metrics that illustrate all the possible ways for the server to communicate data to the user agent: metric name only, metric with value, metric with value and description, and metric with description. For example, the above metrics may indicate that for example.com/resource.jpg fetch:

~cacheに当たらなかった（ `miss^v ）。 ◎ There was a cache miss.
当の要請は `atl^l ~datacenter（ `dc^v ）を経由した。 ◎ The request was routed through the "atl" datacenter ("dc").
~database（ `db^v ）にかかった~~時間は 53ms 。 ◎ The database ("db") time was 53 ms.
~cacheを読取るのに 23.2ms にかかった。 ◎ A cache read took 23.2 ms.
~app~server（ `app^v ）は `customView^v ~template（または関数）を処理するのに 47.2ms かかった。 ◎ The application server ("app") took 47.2ms to process "customView" template or function.
~server上での要請から応答までにかかった合計~時間は 123.4ms であった。それは、応答の終端に記録され，`~trailer~field$を介して送達された。 ◎ The total time for the request-response cycle on the server was 123.4ms, which is recorded at the end of the response and delivered via a trailer field.

~appは、供された~JS~interfaceを介して，供された各~計量を収集して, 処理して, 動作できる： ◎ The application can collect, process, and act on the provided metrics via the provided JavaScript interface:

/* 
`serverTiming$m を成す各~entryは、［
`navigation^l ／ `resource^l
］~entry上に住まう。
◎
serverTiming entries can live on 'navigation' and 'resource' entries
 */
for (const %entryType of ['navigation', 'resource']) {
  for (const {name: %url, %serverTiming} of `performance$m.`getEntriesByType(entryType)$m ) {
    /* 
`serverTiming^m 配列~上で反復する
◎
iterate over the serverTiming array
 */
    for (const {%name, %duration, %description} of %serverTiming) {
      /* 
“低速”なものだけ~careする
◎
we only care about "slow" ones
 */
      if (%duration > 200) {
        console.info('低速な~server計時~entry =',
          JSON.stringify({%url, %entryType, %name, %duration, %description}, null, 2))
      }
    }
  }
}

B. 利用事例

◎非規範的

B.1. 開発者~toolにおける~server計時

~serverの処理~時間は、要請の合計~時間を成す有意な~~部分を成し得る。例えば，動的【に生成される】応答は、［ ~database~query, ~cache検索, ~API~call, 関連な~dataを処理して応答を具現化するためにかけた時間, 等々］を要することもある。静的な応答であっても、同様に［ ~serverの過負荷, 低速な~cache, その他の理由］に因り遅延し得る。 ◎ Server processing time can be a significant fraction of the total request time. For example, a dynamic response may require one or more database queries, cache lookups, API calls, time to process relevant data and render the response, and so on. Similarly, even a static response can be delayed due to overloaded servers, slow caches, or other reasons.

今日では、 ~UAに備わる開発者~toolは，［要請はいつ起動されたか］も［応答の最初, 最後の~byteはいつ受信されたか］も示すことが可能である。しかしながら，~server上の［どこで／どれだけ］時間を費したかは、可視でない。すなわち、開発者にとっては，［処理能~bottleneckは~server上にあるのか，そうならばどの~componentにあるのか］を素早く診断-可能でない。今日、開発者がこの問いに答えるには，各種~技法の利用を要する — ［ ~server~logを検査する／（アリなら）応答の中に処理能~dataを埋込む／外部~toolを利用する］, 等々。これは、処理能~bottleneckを識別して診断するのを難しくし，多くの事例では実用的でない。 ◎ Today, the user agent developer tools are able to show when the request was initiated, and when the first and last bytes of the response were received. However, there is no visibility into where or how the time was spent on the server, which means that the developer is unable to quickly diagnose if there is a performance bottleneck on the server, and if so, in which component. Today, to answer this question, the developer is required to use different techniques: check the server logs, embed performance data within the response (if possible), use external tools, and so on. This makes identifying and diagnosing performance bottlenecks hard, and in many cases impractical.

この仕様は、標準な仕組みを定義する。それは、 ~serverが［関連な処理能~計量を~clientに向けて通信する］ことを可能化し，［それらを開発者~tool内に直に表面化する］ことを~clientに許容する — 例：要請には、 ~serverが送信した計量で注釈できる — 応答を生成している間の［どこで／どれだけ］時間を費したかの内情を供するために。 ◎ Server Timing defines a standard mechanism that enables the server to communicate relevant performance metrics to the client and allows the client to surface them directly in the developer tools - e.g. the requests can be annotated with server sent metrics to provide insight into where or how the time was spent while generating the response.

B.2. 自動化された解析~用の~server計時

~serverが送信した処理能~計量を開発者~tool内に表面化することに加えて、標準な~JS~interfaceは，［運用上の／処理能の］分析~用に，これらの計量を自動的に［収集して, 処理して, ~beaconして, 集成する］ことを解析~toolに可能化する。 ◎ In addition to surfacing server sent performance metrics in the developer tools, a standard JavaScript interface enables analytics tools to automatically collect, process, beacon, and aggregate these metrics for operational and performance analysis.

B.3. 要請の経由上の処理能の測定-法

この仕様は、生成元~serverが［要請を処理している間に［どこで／どれだけ］時間を費したか］について処理能~計量を通信することを可能化する。しかしながら、当の要請, 対する応答は，複数の~proxyを経由することもある（例：~cache~server, 負荷分散器, 等々） — 各~proxyは、自前の遅延を導入し得るので，［どこで／どれだけ］時間を費したかについて処理能~計量を供したいと求めることもあろう。 ◎ Server Timing enables origin servers to communicate performance metrics about where or how time is spent while processing the request. However, the same request and response may also be routed through one or more multiple proxies (e.g. cache servers, load balancers, and so on), each of which may introduce own delays and may want to provide performance metrics into where or how the time is spent.

例えば，ある~CDN `edge node^en 【背後にある~networkを代表する，論理的な~network端点】は、［どの~datacenterが利用されたか／資源は~cache内に可用であったか／ ~cacheや生成元~serverから応答を検索取得するのにかかった~~時間］を報告したいと求めることもあろう。更に，他の~proxyも同じ処理-を繰返すこともあろう — その結果、［要請が，どこを経由し, どこで時間を費したか］について，端点から端点まで全部的に可視にし得る。 ◎ For example, a CDN edge node may want to report which data center was being used, if the resource was available in cache, and how long it took to retrieve the response from cache or from the origin server. Further, the same process may be repeated by other proxies, thus allowing full end-to-end visibility into how the request was routed and where the time was spent.

同様に，~swが作動中であるとき、 ~navi要請や資源~要請の一部またはすべてが，それを経由することもある。作動中な~swは、実質的に，［要請の経由を変える／ ~cacheされた応答を~serveする／応答を合成する／その他諸々］が可能な局所的な~proxyである。この仕様は、要請がどう処理されたかについて~custom処理能~計量を報告することを，~swに可能化する — ［要請は~serverから~fetchされたか局所~cacheから~serveされたか／関連な各種~処理の所要時間］, 等々。 ◎ Similarly, when a Service Worker is active, some or all of the navigation and resource requests may be routed through it. Effectively, an active Service Worker is a local proxy that is able to reroute requests, serve cached responses, synthesize responses, and more. As a result, Server Timing enables Service Worker to report custom performance metrics about how the request was processed: whether it was fetched from a server or served from local cache, duration of relevant the processing steps, and so on.

謝辞

◎非規範的

この文書は、次に挙げる仕様からの~textを，それらの~licenseから許可される下で再利用している ⇒＃ `NAVIGATION-TIMING$r, `RESOURCE-TIMING$r, `PERFORMANCE-TIMELINE-2$r, `RFC6797$r ◎ This document reuses text from the [NAVIGATION-TIMING], [RESOURCE-TIMING], [PERFORMANCE-TIMELINE-2], and [RFC6797] specifications as permitted by the licenses of those specifications.

◎要約

この仕様は、 ~serverが［要請から応答までを巡る処理能~計量を~UAに向けて通信する］ことを可能化する。また、 ~appが自身の送達を最適化するために，これらの計量を［収集して, 処理して, 動作する］ことを可能化するための，~JS~interfaceを標準~化する。 ◎ This specification enables a server to communicate performance metrics about the request-response cycle to the user agent. It also standardizes a JavaScript interface to enable applications to collect, process, and act on these metrics to optimize application delivery.