server-timing-ja.html

<!DOCTYPE html><html lang="ja"><head><meta charset="utf-8">
<title>Server Timing（日本語訳）</title>

<link rel="stylesheet" href="common.css" type="text/css">
<link rel="stylesheet" href="common-w3c.css" type="text/css">

<script src="common0.js" ></script>
<script src="common1.js" async></script>

<script>

Util.ready = function(){
	const source_data = {
		generate: expand
	};
	Util.switchWordsInit(source_data);
}

function expand(){
	const class_map = this.class_map;
	const tag_map = this.tag_map;
	const link_map = this.link_map;

	return this.html.replace(
		/%[\w\-~一-鿆あ-ん]+|`(.+?)([$@!\^])(\w*)/g,
		create_html
	);

	function create_html(match, key, indicator, klass){

if(!key) {//%
	return `<var>${match.slice(1)}</var>`;
}

let text = key;
let href = '';

switch(klass){
case 'r':
	text = `[${key}]`;
	href = `#bib-${key.toLowerCase()}`;
	break;
case 'l':
	text = `"<code class="literal">${text}</code>"`;
	break;
case 'm':
	const n = text.indexOf('(');
	if(n > 0){
		key = text.slice(0, n);
		text = key + text.slice(n).replace(/\w+/g, '<var>$&</var>');
	}
	break;
case 'U':
	text = `U+${text}`;
	break;
case 'smb':
	text = `(<span class="char-symbol">${text}</span>)`;
	break;
case 'en':
	return `<span lang="en">${key}</span>`;
	break;
}

let tag = tag_map[klass];
if(tag) {
	let classname = class_map[klass];
	classname = classname ? ` class="${classname}"` : '';
	text = `<${tag}${classname}>${text}</${tag}>`;
}

if(indicator !== '^'){
	href = link_map[ klass ? `${klass}.${key}` : key ] || href;
	if(!href){
		console.log(match); // check error
		return match;
	}

	switch(indicator){
	case '$':
		text = `<a href="${href}">${text}</a>`;
		break;
	case '@':
		text = `<dfn id="${href.slice(1)}">${text}</dfn>`;
		break;
	default:
		console.log(match);
		return match;
	}
}

return text;

	}
}

</script>

<script type="text/plain" id="_source_data">

●●options

spec_date:2023-04-11
trans_update:2024-04-18
source_checked:220424
page_state_key:TIMING
original_url:https://www.w3.org/TR/server-timing/
	https://w3c.github.io/server-timing/
	abbr_url:SERVER-TIMING
spec_status:WD
ref_id_prefix:bib-
ref_id_lowercase:true
	conformance:w3c
copyright:2023,permissive
trans_1st_pub:2019-05-01

●●class_map
h:header
e:element
a:attr
P:production
v:value
U:code-point
cn:cp-name

●●tag_map
I:code
m:code
c:code
h:code
P:code
v:code

●●original_id_map

●●mdn_urls
dfn-server-timing-header-field:HTTP/Headers/Server-Timing

dom-performanceservertiming:API/PerformanceServerTiming

●●link_map

	●IDL
Exposed:~WEBIDLjs#Exposed
Default:~WEBIDLjs#Default

DOMString:~WEBIDL#idl-DOMString
DOMHighResTimeStamp:~HRTIME#dom-domhighrestimestamp
c.DOMHighResTimeStamp:~HRTIME#dom-domhighrestimestamp

object:~WEBIDL#idl-object

I.PerformanceResourceTiming:~RESOURCE-TIMING#dom-performanceresourcetiming
I.PerformanceNavigationTiming:~NAV-TIMING#dom-performancenavigationtiming
I.PerformanceServerTiming:#dom-performanceservertiming

m.serverTiming:#dom-performanceresourcetiming-servertiming
m.description:#dom-performanceservertiming-description
m.duration:#dom-performanceservertiming-duration
m.name:#dom-performanceservertiming-name
m.toJSON:#dom-performanceservertiming-tojson

m.getEntriesByType:~TIMELINE#dom-performance-getentriesbytype
m.performance:~HRTIME#dom-windoworworkerglobalscope-performance
m.startTime:~TIMELINE#dom-performanceentry-starttime

	●protocol

	~RFCx/rfc7230 → ~HTTPinfra

h.Server-Timing:#dfn-server-timing-header-field
h.Timing-Allow-Origin:~RESOURCE-TIMING#dfn-timing-allow-origin

P.OWS:~HTTPinfra#p.OWS
P.token:~HTTPinfra#p.token
P.quoted-string:~HTTPinfra#p.quoted-string

P.Server-Timing:#_p.Server-Timing
P.metric-name:#_p.metric-name
P.server-timing-metric:#_p.server-timing-metric
P.server-timing-param:#_p.server-timing-param
P.server-timing-param-name:#_p.server-timing-param-name
P.server-timing-param-value:#_p.server-timing-param-value

	●用語

計量~名:#dfn-metric-name
~parameter群:#dfn-params
~server計時~headerを構文解析する:#dfn-parse-a-server-timing-header-field

	§#privacy-and-security

	●外部

位置~変数:~INFRA#string-position-variable
符号位置~並びを収集する:~INFRA#collect-a-sequence-of-code-points
前後の~ASCII空白~列を剥ぐ:~INFRA#strip-leading-and-trailing-ascii-whitespace
~ASCII空白を読飛ばす:~INFRA#skip-ascii-whitespace
有順序~map:~INFRA#ordered-map
~list:~INFRA#list
付加する:~INFRA#list-append

既定の~toJSON手続き:~WEBIDLjs#default-tojson-steps

~HTTP引用符付き文字列を収集する:~FETCH#collect-an-http-quoted-string
fT.~server計時~header群:~FETCH#fetch-timing-info-server-timing-headers

浮動小数点数として構文解析する:~HTMLcms#rules-for-parsing-floating-point-number-values
同一-生成元:~ORIGIN#same-origin

所要時間:~HRTIME#dfn-duration
pT.計時~報:~RESOURCE-TIMING#dfn-timing-info
~trailer~field:~HTTPinfra#trailer-field

媒介者:~HTTPinfra#intermediary

●●words_table1


●●words_table

	●network／HTTP

	端点から端点まで:end-to-end
CDN:
provider::::プロバイダ
datacenter:data center:::データセンター
	datacenter:datacenter
component::::コンポーネント
beacon:
検索:lookup::~
	header:header field
trailer::::トレイラ
	~trailer~header:trailer field
	要請から応答までを巡る:request-response cycle

負荷分散器:load balancer::~::ロードバランサ
過負荷:overload::~::オーバーロード

	経由を変える:reroute
	経由-:routed through
	経由上の:routing
	^en:edge node

	●計時
運用上の:operationalな:~
計量:metric::~
時計:clock::~
費した:spendした:費やした
	かかった:took／taken
	~~時間:how long
合計:total:~
節目:milestone:~
mill::::ミリ
	~mill秒数:milliseconds

	より速く:making 〜 faster
	測定-法:measuring

	●構文
略称:abbreviation:~
内包-:include:~

	●保安
認証-:authenticate::~

	●DOM ／ IDL／データ構造
toJSON:

属性化:attribution::~

	●環境

	●処理一般
overhead::::オーバーヘッド
bottleneck::::ボトルネック
	妥当でない:invalid
合成-:synthesize::~
段階:stage:~
	-:called
浮動小数点数:floating-point number::~
読飛ばす:skipする:読み飛ばす
剥ぐ:stripする:~
引用符付き:quoted:~
生の:raw:~

	~parameter群:params
	~parameter:param
	%~parameter群:params
	%~entry群:entries
	%計量:metric
	%~parameter名:paramName
	%~parameter値:paramValue
	%生の~parameter値:rawParamValue

	●仕様
余計:extraneous:~
内情:insight:~
恒久的:permanent:~
素早く:quickに:~
表面化-:surface:~
答える:answerする:~
診断-:diagnose::~
問い:question:~
license:
保って:keepして:~

	アリでない:impossible
	実用的でない:impractical
	になり得る:potentially
	今日:today
	難しく:hard
	~~意図的に:purposely
	〜が指定した:-specified
	でないならば:exclude
	要する:requireする
	すなわち、:mean
	選ぶ:choose
	示して:illustrate
	-:kept

	●未分類
集成-:aggregate::~
	~sw:Service Worker
	この仕様:Server Timing
template:
database::::データベース
広告-:advertise::~
分析:analysis:~
解析:analytics:~
	短く:short
entryList

	もの:instance
	可視に:visibility
	可視でない:no visibility
	住まう:live
	Server-Timing^h:server-timing
	指して:pointing
	合致-:equal

	●指示語

	同じ:individual
	個:distinct
	残りはすべて:All subsequent occurrences
	その次の:next
	複数回:multiple times
	複数の:one or more multiple
	複数個:more than once
	〜以外に〜ない:only
	どこへ:whom
	各種:different
	その他諸々:and more
	~~部分:fraction
	6:six
	-:and nothing at all to all others


●●ref_normative

[fetch]
    ＜Fetch Standard＞. Anne van Kesteren.  WHATWG. Living Standard. URL: https://fetch.spec.whatwg.org/
[hr-time]
    ＜High Resolution Time＞. Yoav Weiss.  W3C. 22 March 2023. W3C Working Draft. URL: https://www.w3.org/TR/hr-time-3/
[html]
    ＜HTML Standard＞. Anne van Kesteren; Domenic Denicola; Ian Hickson; Philip Jägenstedt; Simon Pieters.  WHATWG. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[infra]
    ＜Infra Standard＞. Anne van Kesteren; Domenic Denicola.  WHATWG. Living Standard. URL: https://infra.spec.whatwg.org/
[RESOURCE-TIMING]
    ＜Resource Timing＞. Yoav Weiss; Noam Rosenthal.  W3C. 4 October 2022. W3C Candidate Recommendation. URL: https://www.w3.org/TR/resource-timing-2/
[RFC2119]
    ＜Key words for use in RFCs to Indicate Requirement Levels＞. S. Bradner.  IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC3864]
    ＜Registration Procedures for Message Header Fields＞. G. Klyne; M. Nottingham; J. Mogul.  IETF. September 2004. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc3864
[RFC5234]
    ＜Augmented BNF for Syntax Specifications: ABNF＞. D. Crocker, Ed.; P. Overell.  IETF. January 2008. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc5234
[RFC7230]
    ＜Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing＞. R. Fielding, Ed.; J. Reschke, Ed..  IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7230.html
[RFC8174]
    ＜Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words＞. B. Leiba.  IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[WEBIDL]
    ＜Web IDL Standard＞. Edgar Chen; Timothy Gu.  WHATWG. Living Standard. URL: https://webidl.spec.whatwg.org/
    

●●ref_informative

[NAVIGATION-TIMING]
    ＜Navigation Timing＞. Zhiheng Wang.  W3C. 17 December 2012. W3C Recommendation. URL: https://www.w3.org/TR/navigation-timing/
[PERFORMANCE-TIMELINE-2]
    ＜Performance Timeline＞. Nicolas Pena Moreno.  W3C. 15 November 2022. W3C Candidate Recommendation. URL: https://www.w3.org/TR/performance-timeline/
[RFC6797]
    ＜HTTP Strict Transport Security (HSTS)＞. J. Hodges; C. Jackson; A. Barth.  IETF. November 2012. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc6797


●●trans_metadata
<p>
~THIS_PAGEは、~W3Cにより作業草案として公開された
<a href="~SPEC_URL">Server Timing</a>
を日本語に翻訳したものです。
~PUB
</p>

●●spec_metadata

最新公表バージョン
	https://www.w3.org/TR/server-timing/
公表履歴
	https://www.w3.org/standards/history/server-timing/
編集者草案
	https://w3c.github.io/server-timing/
commit 履歴
	https://github.com/w3c/server-timing/commits/
編集
	<a href="mailto:cvazac@gmail.com">Charles Vazac</a> (Akamai)
	<a href="https://www.igvita.com/">Ilya Grigorik</a> (Google)
フィードバック
	<a href="https://github.com/w3c/server-timing/">GitHub w3c/server-timing</a> (<a href="https://github.com/w3c/server-timing/pulls/">pull requests</a>, <a href="https://github.com/w3c/server-timing/issues/new/choose">new issue</a>, <a href="https://github.com/w3c/server-timing/issues/">open issues</a>)
	<a href="https://lists.w3.org/Archives/Public/public-web-perf/">public-web-perf@w3.org</a>
実装
	<a href="http://w3c-test.org/server-timing/">Test Suite</a>
	<a href="https://github.com/web-platform-tests/wpt/tree/master/server-timing">Test Suite repository</a>
公表者
	<a href="https://www.w3.org/groups/wg/webperf">Web Performance WG</a>
ブラウザサポート
	https://caniuse.com/server-timing

</script>

</head>
<body>

<header>
	<hgroup>
<h1>サーバの計時 — Server Timing</h1>
	</hgroup>
</header>

<div id="MAIN" hidden>
	<section id="abstract">
◎要約

<p>
この仕様は、
~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.
</p>

	</section>
	<section id="sotd">
◎位置付け

<p>
この節では、
公表~時点における…
【以下、この節の内容は，~SOTD-W3Cに移譲。】
</p>

	</section>

<main id="MAIN0">

	<section id="introduction">
<h2 title="Introduction">1. 序論</h2>

◎非規範的

<p>
~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.
</p>

<p>
この仕様は、
次を導入する：
◎
This specification introduces＼
</p>
<ul>
	<li>
`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,＼
</li>
	<li>
`PerformanceServerTiming$I ~interface
— ~appが自身の送達を最適化するために，これらの計量を［
収集して, 処理して, 動作する
］ことを可能化する。
◎
and a JavaScript interface to enable applications to collect, process, and act on these metrics to optimize application delivery.
</li>
</ul>

	</section>
	<section id="conformance">
<h2 title="Conformance">2. 適合性</h2>

<p class="trans-note">【
この節の内容は
<a href="~W3Ccommon#conformance">~W3C日本語訳 共通~page</a>
に移譲。
】</p>

	</section>
	<section id="the-server-timing-header-field">
<h2 title="The Server-Timing Header Field">3. `Server-Timing^h ~header</h2>

<p>
`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:
</p>

<pre class="bnf">
`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
</pre>

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

<p>
応答には、
同じ `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.
</p>

<p>
~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.
</p>

<p>
この~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.
</p>

<p>
多義性を避けるため、
`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.
</p>

<p>
~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.
</p>

<div >
<p>
この仕様は、
`server-timing-param$P 用の `server-timing-param-name$P として，次を確立する
— いずれも任意選択~である：
</p>
<ul>
	<li>
`dur^l
（所要時間）
⇒
対応する `server-timing-param-value$P は、
`duration$m に公開される。
</li>
	<li>
`desc^l
（記述）
⇒
対応する `server-timing-param-value$P は、
`description$m に公開される。
</li>
</ul>
◎
This specification establishes the server-timing-params for server-timing-param-names "dur" for duration and "desc" for description, both optional.
</div>

<div class="note">
<p>
注記：
◎
Note
</p>
<ul>
	<li>
~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.
</li>
	<li>
［
~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.
</li>
	<li>
~serverや関連な各`媒介者$は、
どの計量をいつ~UAに通信するかについて，全部的な制御を有する。
例えば，一部の計量への~accessは、
~privacyや~securityの理由に因り制約され得る
— <a href="#privacy-and-security">§ ~privacyと~security</a>
を見よ。
◎
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.
</li>
</ul>
</div>

<div class="algo">
<p>
`~server計時~headerを構文解析する@
~algoは、
所与の
( 文字列 %~field )
に対し：
◎
To parse a server-timing header field given a string field:
</p>
<ol>
	<li>
%位置 ~LET %~field 内の始端を指している`位置~変数$
◎
Let position be a position variable, initially pointing at the start of field.
</li>
	<li>
%名前 ~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.
</li>
	<li>
%名前 ~SET `前後の~ASCII空白~列を剥ぐ$( %名前 )
◎
Strip leading and trailing ASCII whitespace from name.
</li>
	<li>
~IF［
%名前 ~EQ 空~文字列
］
⇒
~RET ~NULL
◎
If name is an empty string, return null.
</li>
	<li>
%計量 ~LET 新たな `PerformanceServerTiming$I ~obj
◎
Let metric be a new PerformanceServerTiming＼
</li>
	<li>
%計量 の`計量~名$ ~SET %名前
◎
whose metric name is name.
</li>
	<li>
%~parameter群 ~LET 新たな`有順序~map$
◎
Let params be an empty ordered map.
</li>
	<li>
<p>
~WHILE［
%位置↗ ~NEQ ε
］：
◎
While position is not at the end of field:
</p>
		<ol>
			<li>
%位置 ~INCBY 1
◎
Advance position by 1.
</li>
			<li>
%~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.
</li>
			<li>
%~parameter名 ~SET `前後の~ASCII空白~列を剥ぐ$( %~parameter名 )
◎
Strip leading and trailing ASCII whitespace from paramName.
</li>
			<li>
~IF［
%~parameter名 ~EQ 空~文字列
］~OR［
%~parameter群[ %~parameter名 ] ~NEQ ε
］
⇒
~CONTINUE
◎
If paramName is an empty string or params[paramName] exists, continue.
</li>
			<li>
%位置 ~INCBY 1
◎
Advance position by 1.
</li>
			<li>
%~parameter値 ~LET 空~文字列
◎
Let paramValue be an empty string.
</li>
			<li>
%~field 内の %位置 から`~ASCII空白を読飛ばす$
◎
Skip ASCII whitespace within field given position.
</li>
			<li>
<p>
~IF［
%位置↗ ~EQ `0022^U `"^smb
］：
◎
If the code point at position within field is U+0022 ("), then:
</p>
				<ol>
					<li>
%~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.
</li>
					<li>
%~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.
</li>
				</ol>
			</li>
			<li>
<p>
~ELSE：
◎
Otherwise:
</p>
				<ol>
					<li>
%生の~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.
</li>
					<li>
%~parameter値 ~LET `前後の~ASCII空白~列を剥ぐ$( %生の~parameter値 )
◎
Let paramValue be the result of stripping rawParamValue.
</li>
				</ol>
			</li>
		</ol>
	</li>
	<li>
%計量 の`~parameter群$ ~SET %~parameter群
◎
Set metric's params to params.
</li>
	<li>
~RET %計量
◎
Return metric.
</li>
</ol>
</div>

	</section>
	<section id="the-performanceservertiming-interface">
<h2 title="The PerformanceServerTiming Interface">4. `PerformanceServerTiming^I ~interface</h2>

<pre class="idl">
[`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();
};
</pre>

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

<div class="algo">
<p id="name-attribute">
`name@m
取得子~手続きは
⇒
~RET コレの`計量~名$
◎
4.1 name attribute
◎
The name getter steps are to return this's metric name.
</p>
</div>

<div class="algo">
<p id="duration-attribute">
`duration@m
取得子~手続きは：
◎
4.2 duration attribute
◎
The duration getter steps are to do the following:
</p>
<ol>
	<li>
%dur ~LET コレの`~parameter群$[ `dur^l ]
◎
↓</li>
	<li>
~IF［
%dur ~EQ ε
］
⇒
~RET 0
◎
If this's params["dur"] does not exist, return 0.
</li>
	<li>
%所要時間 ~SET `浮動小数点数として構文解析する$( %dur )
◎
Let dur be the result of parsing this's params["dur"] using the rules for parsing floating-point number values.
</li>
	<li>
~IF［
%所要時間 ~EQ `失敗^i
］
⇒
~RET 0
◎
If dur is an error, return 0;＼
</li>
	<li>
~RET %所要時間
◎
Otherwise return dur.
</li>
</ol>

<p class="note">注記：
`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.
</p>
</div>

<div class="algo">
<p id="description-attribute">
`description@m
取得子~手続きは：
</p>
<ol>
	<li>
%desc ~LET コレの`~parameter群$[ `desc^l ]
◎
↓</li>
	<li>
~IF［
%desc ~EQ ε
］
⇒
~RET 空~文字列
◎
If this's params["dur"] does not exist, return 0.
</li>
	<li>
~RET %desc
◎
Otherwise return dur.
</li>
</ol>
◎
4.3 description attribute
◎
The description getter steps are to return this's params["desc"] if it exists, otherwise the empty string.
</div>

<p>
各 `PerformanceServerTiming$I には、
次に挙げるものが結付けられる：
◎
↓</p>
<ul>
	<li>
`計量~名@
⇒
文字列
— 初期~時は空~文字列とする。
◎
A PerformanceServerTiming has an associated string metric name, initially set to the empty string.
</li>
	<li>
`~parameter群@
⇒
`有順序~map$
— 初期~時は空とする。
◎
A PerformanceServerTiming has an associated ordered map params, initially empty.
</li>
</ul>

	</section>
	<section id="extension-to-the-performanceresourcetiming-interface">
<h2 title="Extension to the PerformanceResourceTiming interface">5. `PerformanceResourceTiming^I ~interfaceに対する拡張</h2>

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

<pre class="idl">
[Exposed=(Window,Worker)]
partial interface `PerformanceResourceTiming$I {
  readonly attribute FrozenArray&lt;`PerformanceServerTiming$I&gt; `serverTiming$m;
};
</pre>

<div class="algo">
<p id="servertiming-attribute">
`serverTiming@m
取得子~手続きは：
◎
5.1 serverTiming attribute
◎
The serverTiming getter steps are the following:
</p>
<ol>
	<li>
%~entry群 ~LET 新たな`~list$
◎
Let entries be a new list.
</li>
	<li>
<p>
コレの`計時~報$pTの`~server計時~header群$fTを成す
~EACH( %~field )
に対し：
◎
For each field in this's timing info's server-timing headers:
</p>
		<ol>
			<li>
%計量 ~LET `~server計時~headerを構文解析する$( %~field )
◎
Let metric be the result of parsing field.
</li>
			<li>
~IF［
%計量 ~NEQ ~NULL
］
⇒
%~entry群 に %計量 を`付加する$
◎
If metric is not null, append metric to entries.
</li>
		</ol>
	</li>
	<li>
~RET %~entry群
◎
Return entries.
</li>
</ol>
</div>

	</section>
	<section id="privacy-and-security">
<h2 title="Privacy and Security">6. ~privacyと~security</h2>

◎非規範的

<p>
この仕様に定義した~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.
</p>

<p>
`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.
</p>

	</section>
	<section id="iana-considerations">
<h2 title="IANA Considerations">7. ~IANA考慮点</h2>

<p>
恒久的~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
</p>

<div id="server-timing-header-field">
<ul>
	<li>
~header名
⇒
`Server-Timing^h
</li>
	<li>
適用-可能な~protocol
⇒
http
</li>
	<li>
位置付け
⇒
標準
</li>
	<li>
著作者／変更~制御者
⇒
<abbr title="World Wide Web Consortium">W3C</abbr>
</li>
	<li>
仕様~文書
⇒
この仕様
（ `Server-Timing$h ~headerを見よ）
</li>
</ul>

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

	</section>
	<section id="examples">
<h2 title="A. Examples">A. 例</h2>

◎非規範的

<div class="example">

<pre class="lang-http">
&gt; GET /resource HTTP/1.1
&gt; Host: example.com

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

</div>

<table class="parameters">
<thead>
<tr><th>名前
<th>所要時間（ `dur^P ）
<th>記述（ `desc^P ）
<tbody>

<tr><td>`miss^v
<td><td>

<tr><td>`db^v
<td>`53^v
<td>

<tr><td>`app^v
<td>`47.2^v
<td>

<tr><td>`customView^v
<td>
<td>

<tr><td>`dc^v
<td>
<td>`atl^l

<tr><td>`cache^v
<td>`23.2^v
<td>`Cache Read^l

<tr><td>`total^v
<td>`123.4^v
<td>
<td>
</table>

<p>
上の~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:
</p>

<ol>
	<li>
~cacheに当たらなかった（ `miss^v ）。
◎
There was a cache miss.
</li>
	<li>
当の要請は
`atl^l ~datacenter（ `dc^v ）を経由した。
◎
The request was routed through the "atl" datacenter ("dc").
</li>
	<li>
~database（ `db^v ）にかかった~~時間は 53ms 。
◎
The database ("db") time was 53 ms.
</li>
	<li>
~cacheを読取るのに 23.2ms にかかった。
◎
A cache read took 23.2 ms.
</li>
	<li>
~app~server（ `app^v ） は
`customView^v ~template（または関数）を処理するのに 47.2ms かかった。
◎
The application server ("app") took 47.2ms to process "customView" template or function.
</li>
	<li>
~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.
</li>
</ol>

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

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

</div>

	</section>
	<section id="use-cases">
<h2 title="B. Use cases">B. 利用事例</h2>

◎非規範的

		<section id="server-timing-in-developer-tools">
<h3 title="B.1 Server timing in developer tools">B.1. 開発者~toolにおける~server計時</h3>

<p>
~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.
</p>

<p>
今日では、
~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.
</p>

<p>
この仕様は、
標準な仕組みを定義する。
それは、
~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.
</p>

		</section>
		<section id="server-timing-for-automated-analytics">
<h3 title="B.2 Server timing for automated analytics">B.2. 自動化された解析~用の~server計時</h3>

<p>
~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.
</p>

		</section>
		<section id="measuring-request-routing-performance">
<h3 title="B.3 Measuring request routing performance">B.3. 要請の経由上の処理能の測定-法</h3>

<p>
この仕様は、
生成元~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.
</p>

<p>
例えば，ある~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.
</p>

<p>
同様に，~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.
</p>

		</section>
	</section>
	<section id="acknowledgments">
<h2 title="C. Acknowledgments">謝辞</h2>

◎非規範的

<p>
この文書は、
次に挙げる仕様からの~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.
</p>
	</section>
</main></div>