1. 依存関係
【 この節の内容の和訳は、省略する。 原文の用語には, W3C による~HTML `HTML52$r を参照しているものもあるが、この訳では WHATWG による~HTML `HTML$r を参照することにする。 】
2. 序論
多くの~appは、資源がいつ~fetchされ, 処理され, 文書に適用されるかに関する,木目細かな制御を要求する。 例えば,資源~競合を抑制して初期~loadの処理能を改善するため、~appは,一部の資源の読込みと処理を先送りすることもある。 この挙動は、概して,資源~fetchingを[ ~appにより定義される,資源~読込み用の~custom~logic ]の中へ移動することにより達成される — すなわち,資源~fetchは、特定0の~app条件が満たされたとき[ 注入された要素/ `XMLHttpRequest$I ]を介して起動される。 ◎ Many applications require fine-grained control over when resources are fetched, processed, and applied to the document. For example, the loading and processing of some resources may be deferred by the application to reduce resource contention and improve performance of the initial load. This behavior is typically achieved by moving resource fetching into custom resource loading logic defined by the application - i.e. resource fetches are initiated via injected elements, or via XMLHttpRequest, when particular application conditions are met.
しかしながら,一部の資源に対しては、可能な限り早くに~fetchする必要はあるが,その処理や実行~logicは ~appに特有の要件の~subjectになるような事例もある — 例えば、依存関係の管理, 条件付き読込み, 順序付け保証, 等々。 現在、処理能上の代償なしには,この挙動を果たせない。 ◎ However, there are also cases where some resources need to be fetched as early as possible, but their processing and execution logic is subject to application-specific requirements - e.g. dependency management, conditional loading, ordering guarantees, and so on. Currently, it is not possible to deliver this behavior without a performance penalty.
- 既存の要素のいずれか(例: `img$e, `script$e, `link$e )を介して資源を宣言した場合,資源の~fetchingと実行はひとまとめにされる。 その一方で,~appには、~fetchはしつつ,資源の実行は何らかの条件が満たされるまで遅延するよう求められることもある。 ◎ Declaring a resource via one of the existing elements (e.g. img, script, link) couples resource fetching and execution. Whereas, an application may want to fetch, but delay execution of the resource until some condition is met.
- 上の挙動を避けるために,資源を `XMLHttpRequest$I を用いて~fetchすることにした場合、資源~宣言は,~UAの~DOMと~preload構文解析器からは見えなくなるので,重い 処理能上の代償を被る。 そのような資源~fetchが~~起動されるのは,関連する~JSが実行されるときに限られ、たいていの頁では それを阻んでいる~scriptが多量にあるため、有意な遅延-がもたらされ,~appの処理能に影響する。 ◎ Fetching resources with XMLHttpRequest to avoid above behavior incurs a serious performance penalty by hiding resource declarations from the user agent's DOM and preload parsers. The resource fetches are only dispatched when the relevant JavaScript is executed, which due to abundance of blocking scripts on most pages introduces significant delays and affects application performance.
`link$e 要素~上の `preload$v ~keywordは、上の利用事例 — 早期~fetchを起動すること, および~fetchingを資源の実行から分離すること — に取組むような,低次かつ宣言的な~fetch~primitiveを供する。 そうすることで、~appが — [ ~UAから資源が見えなくなることで,資源~fetchingが遅延される代償 ]を被ることなく — 資源の読込み, 実行それぞれに対する~customな挙動を築けるようにする。 ◎ The preload keyword on link elements provides a declarative fetch primitive that addresses the above use case of initiating an early fetch and separating fetching from resource execution. As such, preload keyword serves as a low-level primitive that enables applications to build custom resource loading and execution behaviors without hiding resources from the user agent and incurring delayed resource fetching penalties.
`preload$v ~keywordを利用すれば、~appは ,例えば~CSS資源に対する[ 早期, 高~優先度, 具現化を阻まない ]~fetchを起動でき、より適切な時機に~CSSを適用できる: ◎ For example, the application can use the preload keyword to initiate early, high-priority, and non-render-blocking fetch of a CSS resource that can then be applied by the application at appropriate time:
<!-- 宣言的な~markupを介して,~stylesheet資源を~preloadする ◎ preload stylesheet resource via declarative markup --> <link rel="preload" href="/styles/other.css" as="style"> <!-- または、~JSを介して,~stylesheet資源を~preloadする ◎ or, preload stylesheet resource via JavaScript --> <script> var %資源 = document.createElement("link"); %資源.rel = "preload"; %資源.as = "style"; %資源.href = "styles/other.css"; document.head.appendChild(%資源); </script>
Link: <https://example.com/other/styles.css>; rel=preload; as=style
上に例示したように,資源は[ 宣言的な~markup / `Link$h ~HTTP~header `RFC5988$r / ~scheduleされた~JS ]を介して指定できる。 `preload$v をどこで, どう利用できるかについて,より実践的な例は、利用事例節を見よ。 ◎ As above examples illustrate, the resource can be specified via declarative markup, Link HTTP header ([RFC5988]), or scheduled via JavaScript. See use cases section for more hands-on examples of how and where preload can be used.
3. ~link型 `preload^v
`preload@v ~keywordは、 `link$e 要素に利用でき, `~preload~link@ — 資源とその~fetch~propを宣言するために利用される`外部~資源~link$ — を作成する。 ◎ The preload keyword may be used with link elements. This keyword creates an external resource link (preload link) that is used to declare a resource and its fetch properties.
注記: `preload$v ~keywordが早期の~fetchを起動する最適化として利用された場合、特色機能を検出する追加の検査は必要とされない — ~preloadを~supportする~browserは、無視することなく早期の~fetchを起動して,以前のように資源を~fetchすることになる。 他の場合 — ~appは,資源を~preloadする~fetchに依拠したいと意図する場合 — この 特色機能を検出する検査 を実行すれば,~supportされているか検証0できる。 ◎ If the preload keyword is used as an optimization to initiate earlier fetch then no additional feature detection checks are necessary: browsers that support preload will initiate earlier fetch, and those that do not will ignore it and fetch the resource as previously. Otherwise, if the application intends to rely on preload to fetch the resource, then it can execute a feature detection check to verify that it is supported.
注記: `prefetch$v , `preload$v ともに資源と その~fetch~propを宣言するが、~UAが資源がいつ, どう~fetchするかにおいて相違する。 `prefetch$v は、後続の~naviにより利用されるであろう資源~用の,低~優先度, 任意選択の~fetchになる。 他方, `preload$v は、現在の~naviに必要とされる資源~用の,高~優先度, 義務的な~fetchになる。 開発者は、資源~競合を最小化するか, ~load処理能を最適化するかに則って,それぞれを利用するべきである。 ◎ Both prefetch and preload declare a resource and its fetch properties, but differ in how and when the resource is fetched by the user agent: prefetch is an optional and low-priority fetch for a resource that might be used by a subsequent navigation; preload is a mandatory and high-priority fetch for a resource that is necessary for the current navigation. Developers should use each one accordingly to minimize resource contention and optimize load performance.
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 属性が[ 変更- / 除去- / 空~文字列に設定- ]されたときは、現在の要請を中止する~SHOULDである。 ◎ 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を遅延-$しては~MUST_NOT。 ◎ 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.
注記: すべての~browser実装は、~HTTP~cacheに加えて,何~levelかの追加の~cacheを供する。 それは、~HTTP~cacheより前に~liveになることもあれば(例: HTTP/2 ~serverにより~pushされる応答は、概して,~client要請が発行されるまで ~HTTP~cacheには~commitされない)、~HTTP~cacheより後に~liveになることもある(例: 処理-中の~memory~cache)。 今日では、これらの~cacheは定義されておらず, Fetch ~APIにて定義される必要がある( 関係する論点 を見よ)。 ◎ In addition to the HTTP cache, all browser implementations provide one or more levels of additional caches, which sometimes live before the HTTP cache (e.g. HTTP/2 server push responses are typically not committed to HTTP cache until a client request is made), and after the HTTP cache (e.g. in-process memory caches). These caches are not defined today and need to be defined in Fetch API— see related discussion.
~preloadされた応答は、概念的には,~HTTP~cacheに~commitされるべきである — それは、~clientにより起動され,~memory~cache内にも可用になり,少なくとも~fetch~groupの存続期間に~~現れて以降は再~利用できるので。 ◎ Conceptually, a preloaded response ought to be committed to the HTTP cache, as it is initiated by the client, and also be available in the memory cache and be re-usable at least once within the lifetime of a fetch group.
注記: `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は、現在の頁~文脈に対し,資源を自動的に[ 実行-/適用- ]しては~MUST_NOT。 ◎ 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)
資源を~preloadする指令(右列)と,それを消費するもの(左列)の例: ◎ Example directives to preload a resource that will be consumed by...
消費者◎ consumer | `preload^v 指令◎ Preload directive |
---|---|
`audio$e 要素 | `<link rel=preload as=audio href=...>^c |
`video$e 要素 | `<link rel=preload as=video href=...>^c |
`track$e 要素 | `<link rel=preload as=track href=...>^c |
`script$e 要素 / `Worker$I の `importScripts()$m | `<link rel=preload as=script href=...>^c |
`<link rel=stylesheet>^c / ~CSS `import$at 規則 | `<link rel=preload as=style href=...>^c |
~CSS `font-face$at 規則 | `<link rel=preload as=font href=...>^c |
`img$e 要素 / `picture$e 要素 / `srcset$a 属性 / `imageset^c 【?】 | `<link rel=preload as=image href=...>^c |
~SVG `image$e 要素 / 各種~CSS `*-image^css | `<link rel=preload as=image href=...>^c |
`XMLHttpRequest$I / `fetch()$m | `<link rel=preload as=fetch crossorigin href=...>^c |
`Worker$I / `SharedWorker$I | `<link rel=preload as=worker href=...>^c |
`embed$e 要素 | `<link rel=preload as=embed href=...>^c |
`object$e 要素 | `<link rel=preload as=object href=...>^c |
`iframe$e 要素 / `frame$e 要素 | `<link rel=preload as=document href=...>^c |
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を起動して~MAY。 そのような~server~pushにより、宣言された`~preload~link$資源~用の ~clientから~server向けの要請による往来は,排せるようになる。 [ `Link$h ~header `RFC5988$r を介して宣言された資源に対しては,~server~pushを利用しない ]ことが欲される場合、開発者は 任意選択で, `nopush^c ~target属性 ( `RFC5988$r 5.4 節)を介して任意選択で外す~signalを~server向けに供して~MAY。 例えば: ◎ 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
この例の各 `Link^h は、 HTTP/2 ~push能力を備えている~serverに,順に次を指示する:
- `/app/style.css^c は、~pushしないべきである(例:生成元は、~cache内にすでにあることを指示する追加の情報を有していると見られる)。
- `/app/script.js^c は、~server~pushの候補として考慮されるべきである。
`~preload~link$用に~server~pushを起動することは、任意選択の最適化である — 例えば~serverは、次に該当する場合には,そのような~pushを省略するかもしれない:
- ~clientの~cache内に応答は可用であると予見されるとき。 ~clientは、当の資源が欠落しているときには,[ `preload^v 指令, 関連する~cacheの検査 ]を処理して,~server向け要請を起動することになる。
- 可用な~server資源その他の判定基準などの運用上の懸念があるとき。
最後に,~server~pushの利用は、折衝される ~HTTP/2 接続~設定群の~subjectになる: ~clientは、~server~pushの利用を制限したり, 全く不能化することもある。 したがって~appは,~server~pushの可用性/利用には依拠できない。
◎ Initiating server push for a preload link is an optional optimization. For example, the server might omit initiating push if it believes that the response is available in the client's cache: the client will process the preload directive, check the relevant caches, and initiate the request to the server if the resource is missing. Alternatively, the server might omit initiating push due to operational concerns, such as available server resources or other criteria. Finally, the use of server push is subject to negotiated HTTP/2 connection settings: the client may limit or outright disable the use of server push. Applications cannot rely on the availability and use of server push.6. 適合性
この仕様が適合性を課す対象は、~UAのみである。 ◎ There is only one class of product that can claim conformance to this specification: a user agent.
【 この節の他の内容は W3C 日本語訳 共通ページ に委譲 】
A. 利用事例
~INFORMATIVEA.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.
B. ~IANA考慮点
以下に挙げる各種~link関係~型は、 `RFC5988$r, 6.2.1 節にしたがって,~IANAにより登録された: ◎ The link relation type below has been registered by IANA per Section 6.2.1 of [RFC5988]:
- 関係~名
- `preload@dir
- 記述
- 資源は、~linkの文脈における処理において — 具現化を阻むことなく — 早期に~loadされるべきであることを~~指示する。 ◎ Refers to a resource that should be loaded early in the processing of the link's context, without blocking rendering.
- 参照
- この仕様。 ◎ W3C Preload Specification (https://www.w3.org/TR/preload/)
- 注記
- 追加の~target属性は、~linkの詳細な~fetch~propを確立する。 ◎ Additional target attributes establish the detailed fetch properties of the link.
C. ~privacyと~security
~INFORMATIVE~preloadは、 資源の早期~fetchを起動する宣言的な~fetch~primitiveであり、 ~fetchingを資源の実行から分離する。 その効果は、概念的には,~scriptによる資源の~fetchを起動するのに類似するが、追加の拘束と便益もある: ◎ Preload is a declarative fetch primitive that initiates early fetch of resources and separates fetching from resource execution. In effect, it is conceptually similar to initiating a scripted fetch for a resource, but with additional constraints and benefits:
- 資源~宣言は、~HTTP~header/~HTML~markupを介して可視になる。 ~UAは、~JS実行により阻まれずに,~fetchをより早期に起動できるようになる。 ◎ The resource declaration is visible via HTTP headers or HTML markup, which allows the user agent to initiate the fetch earlier, and without blocking on JavaScript execution.
- 応答は、実行されないし,その~payloadを検索取得するような~callbackはない。 応答は、~preloadされた応答に合致する,別の~fetchを起動することにより検索取得され,実行される( `script^e / ~DOM要素 , 等々を介して)。 ◎ The response is not executed and there is no callback to retrieve its payload. The response is retrieved and executed by initiating another fetch (via script, DOM element, etc) that matches the preloaded response.
- 開発者は、 `as$a 属性を介して,応答を消費することになる~target文脈を指定できる。 ~UAは、~preload~fetchを起動するときに、関連する~CSP~policyを施行できるようになる。 `as$a が省略された場合の ~preloadに対する既定の~security/~privacy処理は、 `fetch()$m を~callするときと同じになる — すなわち、 `connect-src$dir 指令の~subjectになる。 ◎ The developer can specify the target context that will consume the response via as attribute, which allows the user agent to enforce the relevant CSP policies when initiating the preload fetch. If as is omitted, preload defaults to same security and privacy processing as a call to fetch() - i.e. subject to connect-src.
~site作者には、必要とされる予防策をとり、 `CSP3$r, `MIXED-CONTENT$r, `REFERRER-POLICY$r による関連する各種~policyを指定することが奨励される — ~browserが~preload要請を起動するときにそれらを施行できるよう。 加えて, `Link$h ~HTTP応答~headerを介して `preload$dir 指令が提供された場合、関連する~policyも ~HTTP応答~headerとして送達されるべきである — 例: ~CSPに対しては処理の複雑化を見よ。 ◎ The site authors are encouraged to take the necessary precautions and specify the relevant [CSP3], [MIXED-CONTENT], and [REFERRER-POLICY] rules, such that the browser can enforce them when initiating the preload request. Additionally, if preload directives are provided via the Link HTTP response header, then the relevant policies should also be delivered as an HTTP response header - e.g. see Processing Complications for CSP.
D. 謝辞
~INFORMATIVEThis document reuses text from the [HTML] specification, edited by Ian Hickson, as permitted by the license of that specification.