Preload — 事前読み込み

3.1. 処理

`資源を得る$ `適切な時機@ は，次に挙げられる： ◎ The appropriate times to obtain the resource are:

• ~UAが `RFC5988$r を~supportしている場合には、`文書$を作成してから， `Link$h ~headerを介して指定される`~preload~link$を処理するとき。 ◎ When the user agent that supports [RFC5988] creates a Document and processes Link headers that contain a preload link.
• `~preload~link$を与える `link$e 要素が`文書の中へ挿入された$とき。 ◎ When the preload link's link element is inserted into a document.
• `link$e 要素が`文書~木~内$にある下で，要素~上に`~preload~link$が作成されたとき。 ◎ When the preload link is created on a link element that is already in a document tree.

• `~preload~link$を与える `link$e 要素が`文書~木~内$にある下で： ◎ ↓

  • 要素の `href$a 属性が変更されたとき。 ◎ When the href attribute of the link element of a preload link that is already in a document tree is changed.
  • 要素の `crossorigin$a 属性が［ 設定-／変更-／除去- ］されたとき。 ◎ When the crossorigin attribute of the link element of a preload link that is already in a document tree is set, changed, or removed.
  • 要素の `as$a 属性が［ 以前に得られた外部~資源への`要請の行先$ ］に合致しない値に［ 設定-／変更- ］されたとき。 ◎ When the as attribute of the link element of a preload link that is already in a document tree is set or changed to a value that does not or no longer matches the request destination of the previous obtained external resource, if any.
  • 要素は `as$a 属性を有していて, その値は［ ~supportされない`要請の行先$ ］を指定していたことに因り，まだ資源を得ていない下で、 `as$a 属性が［ 設定-／変更-／除去- ］されたとき。 ◎ When the as attribute of the link element of a preload link that is already in a document tree but was previously not obtained due to the as attribute specifying an unsupported request destination is set, removed, or changed.
  • 要素は `type$a 属性を有していて, その値は［ `要請の行先$用として［ `構文解析できる~MIME型$でないもの ／ `~supportされない~MIME型$ ］を指定していたことに因り，まだ資源を得ていない下で、 `type$a 属性が［ 設定-／変更-／除去- ］されたとき。 ◎ When the type attribute of the link element of a preload link that is already in a document tree but was previously not obtained due to the type attribute not specifying a parsable MIME type or specifying an unsupported MIME type for the request destination is set, removed, or changed.
  • 要素は `media$a 属性を有していて, その値は［ `妥当な媒体~query~list$でない ／ `環境に合致して$いない ］ことに因り，まだ資源を得ていない下で、 `media$a 属性が［ 設定-／変更-／除去- ］されたとき。 ◎ When the media attribute of the link element of a preload link that is already in a document tree but was not previously obtained due the media attribute's value being not a valid media query list or one that does not match the environment is set, removed, or changed.

~UAは、`~preload~link$を与える `link$e 要素の `href$a 属性が［ 変更- ／ 除去- ／ 空~文字列に設定- ］されたときは、現在の要請を中止するベキである。 ◎ The user agent SHOULD abort the current request if the href attribute of the link element of a preload link is changed, removed, or its value is set to an empty string.

~UAは、上に挙げた時機に， `link$e 要素に与えられた`資源を得る$ことが要求される。 ◎ At these times, the user agent must obtain the resource given by the link element.

`~preload~link$要素に与えられた資源を得ることにより，要素の`~node文書$の`~load~eventを遅延する$ことは、ないモノトスル。 ◎ Obtaining the resource given by a preload link element MUST NOT delay the load event of the element's node document.

`~preload資源が得られた@ なら、~UAは~fetch~group 【~fetch~group？】 の応答~cacheに要請を追加する必要がある。 ◎ Once a preload resource has been obtained, the user agent must add request to fetch group's response cache.

注記： `Link$h ~HTTP応答~headerは、どの型の`要請の行先$に対しても，処理されるべきである。 ◎ Link HTTP response header should be processed for all types of request destination.

注記： `media$a 属性の値が`環境に合致して$いないときは、資源は~preloadされないことになる。 ◎ When the media attribute's value does not match the environment, the resource will not be preloaded.

~UAは、現在の頁~文脈に対し，資源を自動的に［ 実行-／適用- ］しないモノトスル。 ◎ The user agent MUST NOT automatically execute or apply the resource against the current page context.

注記： 例えば，~JS資源が`~preload~link$を介して~fetchされ，対する応答が `no-cache$dir 指令を包含する場合、~fetchされた応答は，~UAにより維持され、後に（ 例えば `script$e ~tagその他の手段を介して）合致する同じ~navi要請で~fetchされたとき，即時に可用にされる。 これにより、［ ~preload~linkを介して起動される初期~資源~fetchから，同じ資源を要請している後の~fetchまで ］の間，~UAは［ 不必要な再検証 ／ 重複~download ］を被らないことが確保される。 ◎ For example, if a JavaScript resource is fetched via a preload link and the response contains a no-cache directive, the fetched response is retained by the user agent and is made immediately available when fetched with a matching same navigation request at a later time - e.g. via a script tag or other means. This ensures that the user agent does not incur an unnecessary revalidation, or a duplicate download, between the initial resource fetch initiated via the preload link and a later fetch requesting the same resource.

3.2. `as^a 属性

注記： `as$a 内容~属性（および `as$m ~IDL属性）は、 `HTML$r が定義する。 この属性は、次を保証するために必要とされる： 正しい優先度付け, 要請との照合, 正しい `CSP3$r ~policyの適用, 適切な `Accept$h 要請~headerを設定すること。 ◎ [HTML] defines the as content and IDL attributes. The attribute is necessary to guarantee correct prioritization, request matching, application of the correct [CSP3] policy, and setting of the appropriate Accept request header.

資源が `Link$h ~header `RFC5988$r を介して宣言されている場合、 `as$a 属性に~~相当するものは、［ `as^c ~link拡張~target属性 ］を介して定義される（ `RFC5988$r, 5.4 節）。 ◎ When the resource is declared via the Link header field ([RFC5988]), the resource's as attribute is defined via the as link-extension target attribute. ([RFC5988] section 5.4)

3.3. ~server~push（ HTTP/2 ）

~HTTP/2 `RFC7540$r においては、~serverは，~clientに向けて応答を先取的に送信すること（ “~push” ）が許容される。 ~pushされてきた応答は、意味論的には 次に等価になる： ~serverがある要請に応答し、~UAは — ~preloadされた応答と同様に — それを維持し、その応答は，~appにより起動された要請に合致したとき ~appにより実行される。 そのようなわけで，~app視点からは、［ ~preloadによる応答を消費すること, ~server~pushによる応答を消費すること ］の間に相違はない。 ◎ HTTP/2 ([RFC7540]) allows a server to pre-emptively send ("push") responses to the client. A pushed response is semantically equivalent to a server responding to a request and, similar to a preloaded response, is retained by the user agent and executed by the application when matched with a request initiated by the application. As such, from an application perspective, there is no difference between consuming a preload or a server push response.

~serverは、~appにより定義された`~preload~link$に対し，それが~serverが 権限を有する 資源を指すならば、~server~pushを起動してヨイ。 そのような~server~pushにより、宣言された`~preload~link$資源~用の ~clientから~server向けの要請による往来は，排せるようになる。 ［ `Link$h ~header `RFC5988$r を介して宣言された資源に対しては，~server~pushを利用しない ］ことが欲される場合、開発者は 任意選択で， `nopush^c ~target属性 （ `RFC5988$r 5.4 節）を介して任意選択で外す~signalを~server向けに供してヨイ。 例えば： ◎ The server MAY initiate server push for preload link resources defined by the application for which it is authoritative. Initiating server push eliminates the request roundtrip between client and server for the declared preload link resource. Optionally, if the use of server push is not desired for a resource declared via the Link header field ([RFC5988]), the developer MAY provide an opt-out signal to the server via the nopush target attribute ([RFC5988] section 5.4). For example:

Link: </app/style.css>; rel=preload; as=style; nopush
Link: </app/script.js>; rel=preload; as=script

A.1. 必須の資源の早期~fetch

ほとんどの~UAは、~main文書の構文解析器が~scriptに因り阻まれている間に，~preload構文解析器を利用して資源の早期~fetchを起動する。 しかしながら，~preload構文解析器は、~JSは実行せず、概して，~CSSの構文解析-に限り浅く遂行する。 このことは、［ ~JSや~CSSの中で指定される資源 ］に対する~fetchは、関連する文書の構文解析器が資源~宣言を処理できるようになるまで，遅延されることを意味する。 ◎ Preload parsers are used by most user agents to initiate early resource fetches while the main document parser is blocked due to a blocking script. However, the preload parsers do not execute JavaScript, and typically only perform a shallow parse of CSS, which means that the fetch of resources specified within JavaScript and CSS is delayed until the relevant document parser is able to process the resource declaration.

~JS／~CSS の中で指定されるほとんどの資源~宣言は、投機的な構文解析器からは実質的に “見えなくなる” ため，処理能上の代償を被る。 ~appは、これに取組むため，［ 頁~処理能を改善するために，~UAが早期に~fetchする必要がある資源 ］を，`~preload~link$を利用して宣言的に指定できる： ◎ In effect, most resources declarations specified within JavaScript and CSS are "hidden" from the speculative parsers and incur a performance penalty. To address this, the application can use a preload link to declaratively specify which resources the user agent must fetch early to improve page performance:

<link rel="preload" href="/assets/font.woff2" as="font" type="font/woff2">
<link rel="preload" href="/style/other.css" as="style">
<link rel="preload" href="//example.com/resource" as="fetch" crossorigin>
<link rel="preload" href="https://fonts.example.com/font.woff2" as="font" crossorigin type="font/woff2">

上の~markupは、 4 個の資源 — ~font資源, ~stylesheet, 別の生成元からの未知の資源~型, 別の生成元からの~font資源 — それぞれに対し，~fetchを起動する。 各~fetchは、適切な要請~headerと優先度で初期化され、未知の型は `XMLHttpRequest$I による要請で起動される~fetchと等価になる。 更には、これらの要請が構文解析器や `load^et ~eventを阻むことはない。 ◎ Above markup initiates four resource fetches: a font resource, a stylesheet, an unknown resource type from another origin, and a font resource from another origin. Each fetch is initialized with appropriate request headers and priority - the unknown type is equivalent to a fetch initiated XMLHttpRequest request. Further, these requests do not block the parser or the load event.

注記： `crossorigin$a 属性が伴われた~fontや画像など，~CORSが可能化された資源~用の~preload~linkは、資源が適正に利用されるようにするためには， `crossorigin$a 属性も有している必要がある。 ◎ Preload links for CORS enabled resources, such as fonts or images with a crossorigin attribute, must also include a crossorigin attribute, in order for the resource to be properly used.

A.2. 早期~fetchと~appにより定義される実行

~appは、 1 つ以上の資源の早期~fetchを起動する`~preload~link$を利用できることに加え、各~応答がいつ, どう文書に適用されるべきかを与える~custom~logicを供せる。 ~appは次を行える： ◎ The preload link can be used by the application to initiate early fetch of one or more resources, as well as to provide custom logic for when and how each response should be applied to the document. The application may:

• 各~資源を可用になり次第~即時に適用することに決める。 ◎ Decide to immediately apply each resource as it becomes available.
• 各~資源が，~appに特有の何らかの順序で適用されることを確保する。 ◎ Ensure that resources are applied in some application specific order.
• 恣意的な［ 資源または~app ］による判定基準に基づいて、資源を条件付きで適用する。 ◎ Apply resources conditionally based on arbitrary resource or application criteria.
• ~appによる条件が満たされるまで，資源の適用を先送りする。 ◎ Defer resource application until some application condition is met.

`~preload~link$は、低次かつ内容型に非依存な~primitiveを提供する。 それは、~appが — 資源~読込みが遅延される代償を被ることなく — 資源の読込み, 実行それぞれに~customな挙動を築けるようにする。 ◎ The preload link provides a low-level and content-type agnostic primitive that enables applications to build custom resource loading and execution behaviors without incurring the penalty of delayed resource loading.

例えば`~preload~link$は、~appが［ 今日では `script$e 要素にしか可用でない［ `async$a ／ `defer$a ］の様な意味論 ］を，どの内容型にも提供することを可能化する： 可用になり次第，即時に資源を適用することは、 `async$a の機能性を提供する。 一方で，何らかの順序付け~logicを追加することは、 `defer$a 機能性を可能化する。 更には，この挙動は、いくつかの内容型が混在していても定義できる — ~appは、各~資源がいつ, どう適用されるかについて全部的な制御を有する。 ◎ For example, preload link enables the application to provide async and defer like semantics, which are only available on script elements today, but for any content-type: applying the resource immediately after it is available provides async functionality, whereas adding some ordering logic enables defer functionality. Further, this behavior can be defined across a mix of content-types - the application is in full control over when and how each resource is applied.

<script>
  function preloadFinished(e) { ... }
  function preloadError(e)  { ... }
</script>
<!-- 
`load^et ／ `error^et ~eventを~listenする
◎
listen for load and error events
 -->
<link rel="preload" href="app.js" as="script" onload="preloadFinished()" onerror="preloadError()">

資源の~fetchingを その実行から切り離すことにより、`~preload~link$は，将来まで耐え得るような［ 処理能が~~重要な~appが，自身に特有の資源~読込み策を築く ］ための~primitiveを提供する。 ◎ By decoupling resource fetching from execution, the preload link provides a future-proof primitive for building performant application specific resource loading strategies.

A.3. 開発者／ ~server／~proxyにより起動される~fetching

開発者は、`~preload~link$を指定でき，また ~app~server／最適化~proxy（例えば~CDN）も，自動的に`~preload~link$を生成できる。 ◎ The preload link can be specified by the developer, or be automatically generated by the application server or an optimization proxy (e.g. a CDN).

Link: <https://example.com/font.woff2>; rel=preload; as=font; type="font/woff2"
Link: <https://example.com/app/script.js>; rel=preload; as=script
Link: <https://example.com/logo-hires.jpg>; rel=preload; as=image
Link: <https://fonts.example.com/font.woff2>; rel=preload; as=font; crossorigin; type="font/woff2"

<link rel="preload" href="//example.com/widget.html" as="document">

<script>
var %資源 = document.createElement("link");
%資源.rel = "preload";
%資源.as = "document";
%資源.href = "/other/widget.html";
document.head.appendChild(%資源);
</script>

• ~appは、次を許容するような~preload~linkを指定できる： ◎ The application can specify preload links, allowing:

  • ~UAが必須の資源に対する早期~fetchを起動する。 ◎ The user agent to initiate early fetch of critical resources.
  • 最適化~proxyが、必須の資源を事前に~fetchして，自身の~cacheの中に置く — それにより、生成元から資源を検索取得する際の遅延を，抑制する／排する。 ◎ The optimization proxy to fetch the critical resources and place them into its cache ahead of time, thus reducing or eliminating the latency of retrieving resources from origin.

• 最適化~proxyは、~appに利するために~preload~linkを指定できる： ◎ The optimization proxy can specify preload links on behalf of the application:

  • ~proxyは、過去の要請~patternに基づいて 必須の資源を観測-／推定して，関連する~preload~linkの生成を自動化でき、それにより頁~処理能は改善される。 ◎ The proxy can observe and infer critical resources based on past request patterns, allowing it to automate generation of relevant preload links to improve page performance.

  • ~proxyは、生成元からの応答が阻まれている間に，推定した~preload~linkを~UAに送達できる — ~UAは、結付けられている必須の資源に対し，早期に~fetchし始めることが可能になる。 ◎ The proxy can deliver inferred preload links to the user agent while it is blocked on the response from the origin, allowing the user agent to begin early fetch of associated critical resources.

    • 既存の最適化~proxyの多くは、 “早めに流し込む（ early flush ）” 策を実装する — そこでは、~proxyが生成元からの応答により阻まれている間，結付けられている必須の資源への参照-が，~UAに自動的に送達される。 今日では、これは概して，結付けられている必須の資源~用の［ `XMLHttpRequest$I, `image^e, `object^e ］要請を包含するような `head$e を文書~内に偽造することにより行われる。 しかしながら，実施においては、これらの実装は不安定で，投機的に起動される要請と, 文書~構文解析器によるそれとで優先度付けが競合することが多い上に、要請の文脈~情報が欠落していることに因る結果，遅延される／二重~downloadになることもある。 `~preload~link$は、宣言的~fetch~primitiveを提供することにより，これらの問題, および ~HTTP `Link$h ~headerとの相互運用性に取組む — それは~URL, 資源の文脈の両者とやりとりする。 ◎ Many existing optimization proxies implement "early flush" strategies where references to associated critical resources are automatically delivered to the user agent while the proxy is blocked on the response from the origin. Today, this is typically done by creating a fake document head that contains XMLHttpRequest, image, and object requests for the associated critical resources. However, in practice, these implementations are brittle and often result in prioritization conflicts with requests initiated by speculative and document parsers, or worse, result in delayed or double downloads due to missing request context information. The preload link addresses these problems by providing a declarative fetch primitive, and interoperability with the HTTP Link header, that communicates both the URL and the context of the resource.