1. 依存関係
【 この節の内容(他の仕様に定義される用語)の和訳は、省略する。 また、 `RFC5988$r を参照する~linkは,その後継~versionである `RFC8288^r への参照に置換している。 】
2. 序論
多くの~appは、資源がいつ[ ~fetchされ, 処理され, 文書に適用されるか ]に関する,木目細かな制御を要求する。 例えば,資源~競合を抑制して初期~読込nの処理能を改善するため、~appは,一部の資源の読込ngと処理を先送りすることもある。 この挙動は、概して,資源~fetchingを[ ~appにより定義される,資源~読込ng用の~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になるような事例もある — 例えば、依存関係の管理, 条件付き読込ng, 順序付け保証, 等々。 現在、処理能上の代償なしには,この挙動を果たせない。 ◎ 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が実行されるときに限られ、たいていの~pageでは それを阻んでいる~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が遅延される代償 ]を被ることなく — 資源の[ 読込ng, 実行 ]それぞれに対し~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:
<!DOCTYPE html> <html> <head> <meta charset="UTF-8"> <!-- 宣言的な~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を起動する一方で、~supportしない~browserは,それを無視して~~従来どおり資源を~fetchすることになる。 他の場合、~appは — 資源を~preloadする~fetchに依拠したいと意図するならば — この特能を検出する,この検査 を実行すれば,~supportの有無を検証yできる。 ◎ 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になる。 開発者は、資源~競合を最小限にするか, 読込n処理能を最適化するかに則って,それぞれを利用するべきである。 ◎ 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 often low-priority fetch for a resource that might be used by a subsequent navigation; `preload` is a mandatory 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. 処理
`~link先の資源を~fetchして処理する$ `適切な時機@ は,次に挙げられる: ◎ The appropriate times to fetch and process the linked 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 要素が`文書~tree内$にある下で,要素~上に`~preload~link$が作成されたとき。 ◎ When the preload link is created on a link element that is already in a document tree.
-
`~preload~link$を与える `link$e 要素が`文書~tree内$にある下で: ◎ ↓
- 要素の `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 要素に与えられた`~link先の資源を~fetchして処理する$モノトスル。 ◎ At these times, the user agent must fetch and process the linked 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は 応答を — それが`~network~error$であっても — ~preload~cacheに追加するモノトスル。 ◎ Once a preload resource has been processed, the user agent must add the response to the preload cache. The user agent must also add responses that are network errors to the preload cache.
注記: ~preload~cacheに`~network~error$を追加することは、重要になる — ~preload要請の結果が~errorになった場合に、後で~network越しに~error含みの応答を要請し直さないよう。 これにはまた、~securityの含意もある。 開発者が、~preload要請に対し下位資源の`完全性~metadata$を指定しつつ,後続する資源~要請には指定しなかった事例を考える。 ~preload要請が`下位資源に対する完全性の検証y$に失敗して破棄された場合、後続する資源~要請が~fetchされ,~networkからの悪意的になり得る応答を — その完全性を検証yすることなく — 消費することになる。 `SRI$r ◎ It is important that network errors be added to the preload cache so that if a preload request results in an error, the erroneous response isn't re-requested from the network later. This also has security implications; consider the case where a developer specifies subresource integrity metadata on a preload request, but not the following resource request. If the preload request fails subresource integrity verification and is discarded, the resource request will fetch and consume a potentially-malicious response from the network without verifying its integrity [SRI].
注記: すべての~browser実装は、~HTTP~cacheに加えて,何~levelかの追加的な~cacheを供する。 それは、~HTTP~cacheより前に~liveになることもあれば(例: ~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. 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](https://github.com/whatwg/fetch/issues/354).
~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は、現在の~page文脈に対し,資源を自動的に[ 実行-/適用- ]しないモノトスル。 ◎ 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, 適切な `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)を介して定義される。 【 `as^c などの個々の拡張~属性は、その仕様には定義されない。】 ◎ 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する指令( 2 列目)と,それを消費するもの( 1 列目)の例: ◎ 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
[ ~HTTP2 `RFC7540$r / ~HTTP3 ]においては、~serverは,~clientに向けて応答を先取的に送信すること( “~push” )が許容される。 ~pushされてきた応答は、意味論的には 次に等価になる: ~serverがある要請に応答し、~UAは — ~preloadされた応答と同様に — それを維持し、その応答は,~appにより起動された要請に合致したとき ~appにより実行される。 そのようなわけで,~app視点からは、[ ~preloadによる応答を消費すること, ~server~pushによる応答を消費すること ]の間に相違はない。 ◎ HTTP/2 ([RFC7540]) and HTTP/3 allow 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)を介して~opt-outする通達を~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
この例の各 `Link^h は、~server~push能力を有する~serverに,次を指示する: ◎ The above example indicates to a Server Push capable server that\
- `/app/style.css^c は、~pushしないべきである(例:生成元は、~cache内にすでにあることを指示する追加的な情報を有していると見られる)。 ◎ /app/style.css should not be pushed (e.g. the origin may have additional information indicating that it may already be in cache),\
- `/app/script.js^c は、~server~pushの候補として考慮されるべきである。 ◎ while /app/script.js should be considered as a candidate for server push.
`~preload~link$用に~server~pushを起動することは、任意選択の最適化である — 例えば~serverは、次に該当する場合には,そのような~pushを省略するかもしれない: ◎ Initiating server push for a preload link is an optional optimization. For example, the server might omit initiating push\
- ~clientの~cache内に可用な応答があると予見されるとき。 ~clientは、当の資源が欠落しているときには,[ `preload^v 指令, 関連な~cacheの検査 ]を処理して,~server向け要請を起動することになる。 ◎ 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.\
- 可用な~server資源その他の判定基準などの運用上の懸念があるとき。 ◎ Alternatively, the server might omit initiating push due to operational concerns, such as available server resources or other criteria.\
最後に,~server~pushの利用は、折衝される[ ~HTTP2 / ~HTTP3 ]接続~設定群の~subjectになる: ~clientは、~server~pushの利用を制限したり, 全く不能化することもある。 したがって~appは,~server~pushの可用性/利用には依拠できない。 ◎ Finally, the use of server push is subject to negotiated HTTP/2 or HTTP/3 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 日本語訳 共通~page に移譲。 】
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は、これに取組むため,[ ~page処理能を改善するために,~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:
<!DOCTYPE html> <html> <head> <meta charset="UTF-8"> <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.
注記: ~preload~linkを文書の~HTML~source内の先頭近くで宣言することはイミを成すが、`文字~符号化法~宣言$より前には置かないこと — 符号化法は、もっと早く~~現れる必要がある。 ◎ Even though it makes sense to declare preload links early in the HTML source of the document, do not put them before the character encoding declaration, which needs to be seen even earlier.
A.2. 早期~fetchと~appにより定義される実行
~appは、各~資源に対し早期~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が — 資源~読込ngが遅延される代償を被ることなく — 資源の読込ng, 実行それぞれに~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.
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<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が,自身に特有な資源~読込ng策を築く ]ための~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"
<!DOCTYPE html> <html> <head> <meta charset="UTF-8"> <link rel="preload" href="//example.com/widget.html" as="document">
<!DOCTYPE html> <html> <head> <meta charset="UTF-8"> <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の生成を自動化でき、それにより~page処理能は改善される。 ◎ 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の文脈における処理において — 具現化を阻むことなく — 早期に読込まれるべきであることを~~指示する。 ◎ 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.
- 応答は、実行されないし,その`内容$を検索取得するような~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施策を施行できるようになる。 `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 による関連な各種~施策を指定することが奨励される — ~browserが~preload要請を起動するときにそれらを施行できるよう。 加えて, `Link$h ~HTTP応答~headerを介して `preload$dir 指令が供された場合、関連な施策も ~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.