link rel = "preload"はどのくらい正確に機能しますか？

Question

クロムの新しいバージョンが<link rel="preload">のサポートを追加しました。彼らは、元のドキュメントへの参照で多くの情報を投稿しています。誰かがそれがどのように働くかについての簡単な説明と、rel="preload"のない場合との違いを教えてください。

Answer 1

最も基本的なフォームではrel="preload"を持つlinkを優先順位に設定します。プリフェッチとは異なり、ブラウザはそれが良いかどうかを判断できます。プリロードすると、強制的にブラウザが強制的に実行されます。

=== より詳細な外観： ===

はここで、多くのアプリケーションが処理、資源が フェッチされたときに細かく制御する必要がW3C

からの抜粋です文書に適用されます。例えば、 の一部のリソースのロードおよび処理は、リソースの競合を減らし、最初の負荷を のパフォーマンスを向上させるために、 アプリケーションによって遅延される可能性があります。この動作は、通常、 リソースフェッチを アプリケーションで定義されたカスタムリソースロードロジックに移動することによって実現されます。つまり、特定のアプリケーション 条件が満たされたときに、注入された 要素を介してリソースフェッチが開始されるか、XMLHttpRequestによって開始されます。

しかし、いくつかのリソースをできるだけ早くフェッチする必要がある場合もありますが、その処理および実行ロジックはアプリケーション固有の要件に従います（例： ）。依存関係 管理、条件付きロード、注文保証などが含まれます。 現在のところ、この動作は、 のパフォーマンスペナルティなしでは実現できません。

既存の要素（img、 スクリプト、リンクなど）を使用してリソースを宣言すると、リソースの取得と実行が結合されます。一方、 アプリケーションはフェッチしたいかもしれませんが、何らかの条件が満たされるまでリソース の実行を遅らせます。 XMLHttpRequestを使用してリソースを にフェッチすると、上記の動作が回避され、ユーザーエージェントのDOMおよびプリロードパーサーから リソース宣言が隠されるため、パフォーマンスが大幅に低下します。 リソースフェッチは、関連するJavaScript が実行されたときにのみ送出されます。ほとんどのページでブロッキングスクリプトが多いため、 にはかなりの遅延があり、アプリケーションのパフォーマンスに影響します。リンク要素の preloadキーワードは、 フェッチを早期に開始し、フェッチをリソース実行から分離する上記の使用例に対処する宣言的フェッチ プリミティブを提供します。したがって、 preloadキーワードは、 アプリケーションがユーザエージェントからのリソースを隠すことなく、アプリケーションのカスタムリソースロードおよび実行動作を構築できる低レベルのプリミティブとして機能し、遅れて のリソースフェッチペナルティが発生します。

例えば、アプリケーションが優先度の高い、早期 を開始するためにプリロードキーワードを使用することができ、非レンダリングブロックは、適切な時にアプリケーションによって適用することができるCSSリソース のフェッチ：

<!-- preload stylesheet resource via declarative markup --> 
<link rel="preload" href="/styles/other.css" as="style"> 
<!-- or, preload stylesheet resource via JavaScript --> 
<script> 
var res = document.createElement("link"); 
res.rel = "preload"; 
res.as = "style"; 
res.href = "styles/other.css"; 
document.head.appendChild(res); 
</script> 

ここでは、W3Cの実際の綿密な外観です：https://w3c.github.io/preload/

しかし、あなたはブラウザのサポートとしてそれを使用する予定がある場合、私は慎重になりますが、その偉大ではない、グローバルbroswerのサポートは、0.18％です。

ここで完全なリストです：http://caniuse.com/#search=preload