このページは Cloud Translation API によって翻訳されました。

重要なアセットをプリロードして読み込み速度を改善する

Houssein Djirdeh

Jeremy Wagner

Milica Mihajlija

ウェブページを開くと、ブラウザはサーバーに HTML ドキュメントをリクエストし、そのコンテンツを解析し、参照されているリソースに対して個別のリクエストを送信します。デベロッパーは、ページに必要なすべてのリソースと、その中で最も重要なリソースをすでに把握しています。この知識を使用して、重要なリソースを事前にリクエストし、読み込みプロセスを高速化できます。この記事では、<link rel="preload"> を使用してこれを実現する方法について説明します。

プリロードの仕組み

プリロードは、通常はブラウザによって遅れて検出されるリソースに最適です。

Chrome DevTools の [Network] パネルのスクリーンショット。 — この例では、Pacifico フォントは `@font-face` ルールを使用してスタイルシートで定義されています。ブラウザは、スタイルシートのダウンロードと解析が完了した後にのみ、フォントファイルを読み込みます。

特定のリソースをプリロードすると、そのリソースが現在のページにとって重要であると確信しているため、ブラウザがリソースを検出するよりも早くフェッチすることをブラウザに指示します。

プリロードを適用した後の Chrome DevTools の [Network] パネルのスクリーンショット。 — この例では、Pacifico フォントがプリロードされているため、ダウンロードはスタイルシートと同時に行われます。

クリティカルリクエストチェーンは、ブラウザによって優先され、フェッチされるリソースの順序を表します。Lighthouse では、このチェーンの 3 番目のレベルにあるアセットは遅く検出されたアセットとして識別されます。主要なリクエストをプリロードする監査を使用して、プリロードするリソースを特定できます。

Lighthouse のプリロードキーリクエストの監査。

リソースをプリロードするには、rel="preload" を含む <link> タグを HTML ドキュメントのヘッドに追加します。

<link rel="preload" as="script" href="critical.js">

ブラウザはプリロードされたリソースをキャッシュに保存し、必要に応じてすぐに使用できるようにします。（スクリプトの実行やスタイルシートの適用は行いません）。

リソースヒント（preconnect や prefetch など）は、ブラウザの判断で実行されます。一方、preload はブラウザに必須です。最新のブラウザはすでにリソースの優先付けがかなり優れています。そのため、preload は控えめに使用し、最も重要なリソースのみをプリロードすることが重要です。

未使用のプリロードは、load イベントの約 3 秒後に Chrome のコンソールに警告をトリガーします。

未使用のプリロードリソースに関する Chrome DevTools Console の警告。

注: preload は、すべての最新ブラウザでサポートされています。

対応ブラウザ

ソース

ユースケース

CSS で定義されたリソースのプリロード

@font-face ルールで定義されたフォントや CSS ファイルで定義された背景画像は、ブラウザがそれらの CSS ファイルをダウンロードして解析するまで検出されません。これらのリソースをプリロードすると、CSS ファイルのダウンロード前にフェッチされます。

CSS ファイルのプリロード

重要な CSS アプローチを使用している場合は、CSS を 2 つの部分に分割します。スクロールせずに見える範囲のコンテンツのレンダリングに必要なクリティカル CSS は、ドキュメントの <head> にインライン化され、重要でない CSS は通常 JavaScript で遅延読み込みされます。重要でない CSS を読み込む前に JavaScript の実行を待つと、ユーザーがスクロールしたときにレンダリングが遅れる可能性があるため、<link rel="preload"> を使用してダウンロードを早めに開始することをおすすめします。

JavaScript ファイルのプリロード

ブラウザはプリロードされたファイルを実行しないため、プリロードは取得と実行を分離するのに役立ち、Time to Interactive などの指標を改善できます。プリロードは、JavaScript バンドルを分割し、重要なチャンクのみをプリロードする場合に最適です。

rel=preload を実装する方法

preload を実装する最も簡単な方法は、ドキュメントの <head> に <link> タグを追加することです。

<head>
  <link rel="preload" as="script" href="critical.js">
</head>

as 属性を指定すると、ブラウザはプリフェッチされたリソースの優先度をそのタイプに応じて設定し、適切なヘッダーを設定し、リソースがキャッシュにすでに存在するかどうかを判断できます。この属性の有効な値は、script、style、font、image、その他です。

注意: as 属性を省略するか、無効な値を指定すると、XHR リクエストと同じになります。ブラウザは取得する内容を認識できないため、正しい優先度を決定できません。また、スクリプトなどのリソースが 2 回取得されることもあります。

フォントなどの一部のリソースは、匿名モードで読み込まれます。そのような場合は、crossorigin 属性を preload に設定する必要があります。

<link rel="preload" href="ComicSans.woff2" as="font" type="font/woff2" crossorigin>

注意: crossorigin 属性なしでプリロードされたフォントは、2 回フェッチされます。

<link> 要素には、リンクされたリソースの MIME タイプを含む type 属性も使用できます。ブラウザは type 属性の値を使用して、ファイル形式がサポートされている場合にのみリソースをプリロードします。ブラウザが指定されたリソースタイプをサポートしていない場合、<link rel="preload"> は無視されます。

Link HTTP ヘッダーを使用して、任意のタイプのリソースをプリロードすることもできます。

Link: </css/style.css>; rel="preload"; as="style"

HTTP ヘッダーで preload を指定すると、ブラウザがドキュメントを解析して検出する必要がなくなるため、場合によってはパフォーマンスがわずかに向上します。

webpack による JavaScript モジュールのプリロード

アプリケーションのビルドファイルを作成するモジュールバンドルを使用している場合は、プリロードタグの挿入をサポートしているかどうかを確認する必要があります。webpack バージョン 4.6.0 以降では、import() 内でマジックコメントを使用してプリロードがサポートされています。

import(_/* webpackPreload: true */_ "CriticalChunk")

古いバージョンの webpack を使用している場合は、preload-webpack-plugin などのサードパーティプラグインを使用します。

プリロードが Core Web Vitals に与える影響

プリロードは、読み込み速度に影響する強力なパフォーマンス最適化です。こうした最適化により、サイトの Core Web Vitals が変化する可能性があるため、注意が必要です。

Largest Contentful Paint（LCP）

フォントと画像の場合、画像ノードとテキストノードの両方が LCP の候補になるため、プリロードは Largest Contentful Paint（LCP）に大きな効果をもたらします。ウェブフォントを使用してレンダリングされるヘッダー画像や長いテキストは、適切に配置されたプリロードヒントによって大幅に改善できます。これらの重要なコンテンツをユーザーに迅速に提供できる機会がある場合は、プリロードヒントを使用する必要があります。

ただし、プリロードやその他の最適化については注意が必要です。特に、リソースを過剰にプリロードしないでください。優先度を付けるリソースが多すぎると、実際にはどれも優先されません。過剰なプリロードヒントの影響は、帯域幅の競合がより顕著になる低速ネットワークで特に悪影響を及ぼします。

代わりに、適切に配置されたプリロードが効果を発揮するとわかっている、価値の高いリソースに重点を置きます。フォントをプリロードする際は、WOFF 2.0 形式でフォントを配信して、リソースの読み込み時間をできるだけ短くしてください。WOFF 2.0 は優れたブラウザサポートがあるため、WOFF 1.0 や TrueType（TTF）などの古い形式を使用すると、LCP 候補がテキストノードである場合に LCP が遅延します。

LCP と JavaScript については、ブラウザのプリロードスキャナが正しく機能するように、サーバーから完全なマークアップを送信する必要があります。マークアップのレンダリングに JavaScript に完全に依存し、サーバーレンダリングされた HTML を送信できないエクスペリエンスを提供している場合は、ブラウザのプリロードスキャナが対応できない部分に介入して、JavaScript の読み込みと実行が完了したときにのみ検出可能なリソースをプリロードすることをおすすめします。

Cumulative Layout Shift（CLS）

累積レイアウトシフト（CLS）は、ウェブフォントに関する特に重要な指標です。CLS は、font-display CSS プロパティを使用してフォント読み込み方法を管理するウェブフォントと密接に関連しています。ウェブフォント関連のレイアウトシフトを最小限に抑えるには、次の戦略を検討してください。

font-display にデフォルトの block 値を使用してフォントをプリロードします。これは微妙なバランスです。フォールバックなしでフォントの表示をブロックすることは、ユーザーエクスペリエンスの問題と見なされる可能性があります。一方、font-display: block; でフォントを読み込むと、ウェブフォント関連のレイアウトのずれが解消されます。一方で、ウェブフォントがユーザーエクスペリエンスに不可欠な場合は、できるだけ早く読み込みを完了する必要があります。プリロードと font-display: block; を組み合わせることは、妥協案として許容できるかもしれません。
font-display に fallback 値を使用してフォントをプリロードします。fallback は、ブロック期間が非常に短い点で、swap と block の妥協点です。
プリロードなしで font-display に optional 値を使用します。ウェブフォントがユーザーエクスペリエンスに不可欠ではないものの、ページのテキストの大部分のレンダリングに使用されている場合は、optional 値の使用を検討してください。不利な状況では、optional はフォールバックフォントでページテキストを表示し、次のナビゲーション用にフォントをバックグラウンドで読み込みます。このような条件下では、システムフォントがすぐにレンダリングされ、その後のページ読み込みではレイアウトシフトなしでフォントがすぐに読み込まれるため、CLS が改善されます。

CLS は、ウェブフォントに関して最適化が難しい指標です。いつものようにラボでテストを行いますが、フォント読み込み戦略によって CLS が改善されたか悪化したかは、フィールドデータを信頼して判断してください。

Interaction to Next Paint（INP）

Interaction to Next Paint は、ユーザー入力に対する応答性を測定する指標です。ウェブ上のインタラクティビティの大部分は JavaScript によって駆動されるため、重要なインタラクションを可能にする JavaScript をプリロードすると、ページの INP を低く抑えることができます。ただし、起動時に JavaScript を読み込みすぎると、リソースの競合により帯域幅が圧迫され、意図しない悪影響が生じる可能性があります。

また、コード分割の方法にも注意が必要です。Code Splitting は、起動時に読み込まれる JavaScript の量を減らすための優れた最適化手法ですが、インタラクションの開始時に読み込まれる JavaScript に依存している場合、インタラクションの遅延が発生する可能性があります。この問題を補正するには、ユーザーの意図を調べ、インタラクションが発生する前に、必要な JavaScript チャンクのプリロードを挿入する必要があります。たとえば、フォーム内のいずれかのフィールドにフォーカスが当たったときに、フォームの内容の検証に必要な JavaScript をプリロードできます。

まとめ

ページの速度を改善するには、ブラウザで遅れて検出される重要なリソースをプリロードします。すべてをプリロードするのは逆効果になるため、preload は控えめに使用し、実際の影響を測定してください。