preload

プリロード

目次

• 使用するタイミング
• 使用しないタイミング
• 手順
• 詳細
• ソース

プリロード（<link rel="preload">）は、重要なリソース（検出が遅れる可能性があるもの）を早めにリクエストできるブラウザーの最適化です。主要なリソースの読み込み順序を手動で調整することに抵抗がなければ、読み込みパフォーマンスやCore Web Vitalsの指標に良い影響を与えられます。ただし、プリロードは万能ではなく、トレードオフを理解しておく必要があります。

使用するタイミング

• 読み込み処理の後半で重要なリソース（フォント、スクリプト、画像）が検出される場合に使用します
• Time To Interactive（TTI）と Largest Contentful Paint（LCP）の改善に役立ちます

使用しないタイミング

• 重要ではないリソースの場合 — アセットをプリロードしすぎると、初回レンダリングで実際に重要なリソースの読み込みが遅れます
• ブラウザーのプリロードスキャナーによってリソースがすでに早期に検出されている場合（例：<head>内のインライン<script>タグ）
• 過剰に使用すると、未使用のプリロード済みリソースに関するブラウザーの警告が表示され、帯域幅が無駄になっていることが示される場合

手順

• 現在のページですぐに必要なリソースには<link rel="preload">を使用します
• リソースをプリロードしすぎてFirst Contentful Paintが遅れないように注意します
• as属性を使用してリソースの種類（script、style、font、image）を指定します
• フォントなど、CORSを使用して取得するリソースでは、プリロードにcrossoriginを設定し、後続のリクエストモードと一致させます
• 初回レンダリングから約1秒以内に表示する必要があるリソースのみをプリロードします

詳細

<link rel="preload" href="emoji-picker.js" as="script">
...
</head>
<body>
  ...
  <script src="stickers.js" defer></script>
  <script src="video-sharing.js" defer></script>
  <script src="emoji-picker.js" defer></script>

Time To InteractiveやFirst Input Delayなどの指標を最適化する場合、インタラクティブ性に必要なJavaScriptバンドル（またはチャンク）の読み込みにプリロードが役立ちます。ただし、プリロードを使用する際は十分な注意が必要です。インタラクティブ性を向上させる代わりに、First Contentful PaintやLargest Contentful Paintに必要なヒーロー画像やフォントなどのリソースの読み込みを遅らせないようにしてください。

ファーストパーティのJavaScriptの読み込みを最適化する場合は、これらのリソースを早期に検出できるよう、ドキュメントの<head>と<body>のどちらに<script defer>を配置するか検討することもできます。

シングルページアプリでのプリロード

プリフェッチは、近いうちにリクエストされる可能性のあるリソースをキャッシュする優れた方法ですが、すぐに使用する必要があるリソースはプリロードできます。たとえば、初回レンダリングで使われる特定のフォントや、ユーザーがすぐに目にする画像などです。

EmojiPicker コンポーネントを初回レンダリング時にすぐ表示する必要があるとします。メインバンドルには含めないものの、並行して読み込む必要があります。_プリフェッチ_と同様に、マジックコメントを追加して、このモジュールをプリロードするよう Webpack に知らせることができます。

const EmojiPicker = import(/* webpackPreload: true */ "./EmojiPicker");

Webpack 4.6.0+ では、インポートに /* webpackPreload: true */ を追加することでリソースをプリロードできます。古いバージョンの webpack でプリロードを機能させるには、webpack の設定に preload-webpack-plugin を追加する必要があります。

アプリケーションをビルドすると、EmojiPicker がプリロードされることを確認できます。

 Asset                             Size       Chunks                          Chunk Names
    emoji-picker.bundle.js         1.49 KiB   emoji-picker [emitted]          emoji-picker
    vendors~emoji-picker.bundle.js 171 KiB    vendors~emoji-picker [emitted]  vendors~emoji-picker
    main.bundle.js                 1.34 MiB   main  [emitted]                 main

Entrypoint main = main.bundle.js
(preload: vendors~emoji-picker.bundle.js emoji-picker.bundle.js)

実際の出力は、ドキュメントの head 内にある rel="preload" を指定した link タグとして確認できます。

<link rel="preload" href="emoji-picker.bundle.js" as="script" />
<link rel="preload" href="vendors~emoji-picker.bundle.js" as="script" />

プリロードされた EmojiPicker は、初回バンドルと並行して読み込まれます。ブラウザーが、リソースをプリフェッチするのに十分なインターネット接続と帯域幅があるかどうかを判断する余地がある「プリフェッチ」とは異なり、プリロードされたリソースは条件にかかわらずプリロードされます。

初回レンダリング後に EmojiPicker が読み込まれるのを待たなくても、リソースをすぐに利用できるようになります。より適切な順序でアセットを読み込むため、ユーザーのデバイスやインターネット接続によっては、初回の読み込み時間が大幅に長くなる場合があります。初回レンダリングから約 1 秒後までに表示する必要があるリソースのみをプリロードしてください。

プリロード＋async ハック

ブラウザーにスクリプトを高優先度でダウンロードさせつつ、スクリプトを待つ間にパーサーをブロックさせたくない場合は、以下のプリロード＋async ハックを利用できます。この場合、プリロードによってほかのリソースの読み込みが遅れることがありますが、これは開発者が判断する必要のあるトレードオフです。

<link rel="preload" href="emoji-picker.js" as="script">
<script src="emoji-picker.js" async>

フォントのプリロードでは crossorigin を指定する必要があります

フォントは、同一オリジンでセルフホストされている場合でも、CORS リソースとして取得されます。そのため、プリロードのリクエストと最終的な @font-face のリクエストで同じフェッチモードを使用する必要があります。そうしないと、プリロードを再利用できません。

crossorigin を指定せずにフォントをプリロードすると、通常、ブラウザーは no-cors でプリロードリクエストを行い、その後 CSS がフォントを検出した際に、別途 cors リクエストを行います。同じファイルを二重に取得することになり、帯域幅が無駄になります。

避けるべき例：

<link rel="preload" href="/fonts/inter-roman.woff2" as="font" type="font/woff2">

推奨例：

<link
  rel="preload"
  href="/fonts/inter-roman.woff2"
  as="font"
  type="font/woff2"
  crossorigin
>

また、@font-face が同じリソースを参照していることを確認してください。

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-roman.woff2") format("woff2");
  font-display: swap;
}

このルールはより広く適用されます。最終的にリソースを使用する側が CORS の仕組みでそのリソースを取得する場合、プリロードでも同じモードを指定してください。

Chrome 95 以降でのプリロード

Chrome 95 以降では、プリロードのキューを追い越す動作に対する修正により、この機能をより広く使う際の安全性が多少高まりました。Chrome の Pat Meenan が示すプリロードに関する新しい推奨事項は次のとおりです。

• HTTP ヘッダーに記述すると、ほかのすべてより優先されます。
• 一般に、Medium 以上の優先度のプリロードはパーサーが到達した順に読み込まれるため、HTML の先頭にプリロードを配置する際は注意してください。
• フォントのプリロードは、head の終わりか body の始めに配置するのが最適と思われます。
• インポートのプリロードは、インポートを必要とするスクリプトタグの後に配置してください（実際のスクリプトが先に読み込まれて解析されるようにします）。
• 画像のプリロードは優先度が低いため、async スクリプトや、ほかの低優先度・最低優先度のタグとの相対的な順序を考慮して配置してください。

まとめ

繰り返しになりますが、preload は必要な場合にのみ使用し、本番環境での効果を測定してください。画像の preload をドキュメント内でより早い位置に置くと、ブラウザーが画像を発見しやすくなり、ほかのリソースとの読み込み順序にも影響を与えられます。誤って使用すると、画像の preload によって First Contentful Paint が遅れることがあります（例：CSS、フォント）。これは望ましいこととは逆です。また、このような優先順位の変更を効果的に行うには、サーバーがリクエストを適切に優先することも必要です。

スクリプトを実行せずに取得する必要がある場合にも、<link rel="preload">が役立つことがあります。

web.dev のさまざまな記事では、Preload を使って次のことを行う方法を紹介しています。

• インタラクティブ性に必要な主要スクリプトを preload する
• Largest Contentful Paint の画像を preload する
• レイアウトシフトを防ぎながらフォントを読み込む

ソース

• patterns.dev/vanilla/preload