サイト高速化テクニックの一つとして挙げられるpreload。
しかし正しい役割と使い方はあまり知られていないような気がします。
……みたいな感じで。
実際のところ、8割方当たりとはいえます。
しかし原理を知らずに使うと遅くなることもあり、決して万能な魔法の呪文というわけでもありません。
preloadをよく用いられるのがWebフォントとMV。
この2つを例として、preloadの機能と使い方について記してみます。
preloadとは何か
まず、preloadとはなんでしょう？
preloadとは？：
ページの表示に早い段階で必要になるリソースを、ブラウザに「重要だから先に見つけて」と伝えて取得を前倒しにするための指定。
「重要なリソースを先に見つけさせる」のがポイントです。
Webフォントと画像における指定は次のように書きます。
Webフォント。
<link rel="preload" href="/path/to/font.woff2" as="font" type="font/woff2" crossorigin>
画像。
<link rel="preload" as="image" href="/images/mv.webp">
preloadで高速化を図れる原理
では、preloadを指定すれば、どうして（場合によっては）速くなるのでしょう？
その原理について説明します。
かつてのPagespeed Insights（PSI）には「クリティカルなリクエストの深さの最小化」という項目がありました。
クリティカル リクエスト チェーンは、クリティカル レンダリング パス（CRP）の最適化技術のコンセプトの 1 つです。 CRP を考慮してリソースに優先度を設定し、読み込む順序を指定すると、ブラウザでより早くページが読み込まれるようになります。
なんのこっちゃ？と思われるかもしれません。
かつての私もそうでした。
クリティカルレンダリングパス；ページがブラウザに表示されるまでの重要な処理の流れ。
雑に言えば「ファーストビューが表示されるまでの手順」くらいの理解で構いません
MVの方が直観的に理解しやすいでしょう。
ファーストビューにはMVの画像ファイルが必要なのにすぐには見つからない構造になっている（具体的には後述します）。
この場合、表示しようとしても画像ファイルがないのですから、見つかるまで表示が遅れます。
ここで「先に見つけろ！」と命じておけば、表示すべきタイミングですぐさま画像を表示できるという原理です。
preloadで高速化を図れるケースと邪魔になるケース
つまりpreloadで高速化を図れるのは、次のケースです。
一方で、通常のフローで重要なリソースをすんなり見つけてくれる場合ですと、あまり効果がありません。
さらに、次の場合は邪魔にすらなります。
回線や同時接続を圧迫し、本当に先に読み込ませたいリソースの邪魔になることもあります。
先述した通りpreloadは魔法の呪文ではありません。
それどころか魔法の呪文と思い込んで乱用すると、かえって遅くなるおそれすらあるということです。
preloadは次の点を見極めて使うのが望ましいと考えます
- そのリソースが本当に重要か
- 通常の読み込みフローでは発見が遅れやすいか
この考えを前提とした場合、preload が効果を発揮しやすい代表例がWebフォントとMV画像となります。
Webフォントで考える
Webフォントは、見た目には文字を表示するための重要リソースですが、ブラウザがその本体ファイルを見つけるまでには段階があります。
まず①CSSを読み、②CSSの中の @font-face を解析し、③ようやく、woff2などのフォントファイルにたどり着きます。
CSS側では次のように書かれます。
@font-face {
font-family: 'hogefont';
src: url('/fonts/hogefont.woff2') format('woff2'),
url('/fonts/hogefont.woff') format('woff'),
url('/fonts/hogefont.ttf') format('truetype');
}
ブラウザはCSSを読むまでフォントファイル（＝重要なリソース）の存在を把握できません。
先述したとおり、フォントの取得開始が後ろにずれやすくなります。
そこでフォントファイルをpreloadすることによって、CSSの解析を待たずに「このフォントは重要だ」と見つけさせるわけです。
ここで御注意いただきたいこと。
preload＝Webフォントの高速化のセオリーというわけでもありません
例えばFontAwesomeの場合、表示するアイコンが少ないのならSVGでインライン化した方が速いです。
（レンダリングブロックを生まないので）
サイト高速化という軸で考えるのであればWebフォントの性質に応じて使い分けてください。
もう一つ。
ファーストビューでFontAwesomeのアイコンを使っていないなら、必ずしもpreloadを使う必要はありません。
表示を急ぐ必要がないからです。
MV画像で考える
img要素のケースとCSSで指定しているケースで切り分ける
MV画像については、次のケースで切り分けて考える必要があります。
- img要素としてのMV画像
- CSSの背景画像としてのMV画像
まず、img要素のMV画像について。
<img src="/images/mv.webp" alt="">
この場合、ブラウザは比較的早くその画像を見つけることができます。
そのためpreloadを指定する必要は下がります。
つまり、
img要素のMV画像の場合は「MVだから必ず preload」と必ずしも言えない。
この点は見落としがちなので押さえておきましょう
一方、CSSの背景画像としてのMV画像について。
<div class="mv"></div>
.mv {
background-image: url("/images/mv.webp");
}
この場合、ブラウザはHTMLを読んだだけでは画像URLを把握できません。
先述したケースで、まずCSSを見つけ、読み込み、解析して、そこで初めて背景画像の存在を知ります。
つまり、CSS背景画像のMVは、重要であるにもかかわらず発見が遅れやすい。
こういうときはpreloadを指定する価値が高くなります。
クリティカルCSSをインライン化しているケースも考える
ただし、CSSのbackground-imageならpreloadというほど単純でもありません。
なぜ？
MVに必要なCSSをクリティカルCSSとしてインライン化しているなら、外部CSSの読み込み待ちが発生しないからです
たとえば次のインライン化がされていた場合、
<style>
.mv {
background-image: url("/images/mv.webp");
}
</style>
ブラウザはHTML解析中にその背景画像URLを把握できます。
この場合、外部CSS依存の背景画像よりは発見の遅れが小さくなるわけです。
とはいえ、img要素と比べた場合。
背景画像はHTML上の主役画像として明示しにくいですし、制御もしづらい面があります。
LCP改善が必要なケースでは、やっぱりpreload を検討する余地があったりします。
どっちなんだよ！
どっちかで考える問題じゃないんです。
設計で考えるんです。
背景画像MVについては初期段階でどれだけ早く発見される設計になっているか。
それ次第でpreloadをするかしないかが変わってきます。
fetchpriority=”high”との違い
MV画像で推奨される設定がこちら。
fetchpriority="high"
PSIでも推奨されます。
fetchpriority=”high”とpreloadは、両者ともアバウトに「先読み」と呼ばれたりします。
そのため区別が曖昧な方もいるかもしれません。
両者の違いは次の通りです。
preloadとfetchpriority=”high”の違い：
preload→ リソースの存在を早く知らせる（＝発見の前倒し）
fetchpriority=”high”→ 見つかったリソースの優先度を高くする（優先度の調整）
この違いを押さえておくと、MVにおける使い分けを判断しやすくなります。
img のLCP画像なら、HTML上で早く見つかるので、まずは fetchpriority=”high” の方が素直です。
CSS背景画像のように発見自体が遅れやすいケースでは、preload の意味が大きくなります。
制作実務におけるpreloadの考え方
実務的には次のように考えるといいかもです
Webフォント
Webフォントはファーストビューにおける重要なリソースです。
しかも本体ファイルの発見が後段になりやすいので、一般的にはpreloadを使った方がいいでしょう。
先述した通り、SVGを用いればFontAwesomeについてはフォントファイルの読み込みが不要となります。
しかしSVGには記述が長くなることから①HTMLが若干重くなる②保守性に欠ける、という欠点があります。
制作会社によっては運用保守まで見据えてサイトを作る必要があります。
その点まで踏まえると、SVGは必ずしも正義というわけでもありません。
MV画像
ここまでの考え方をざっくりまとめると、以下の通りとなります。
img のMV画像の場合、通常の実装やfetchpriorityを見直す。preload は必須ではない。
CSS背景画像のMVの場合、発見が遅れやすいためpreloadを検討する。
もっとも制作実務ですと、MV画像には基本的にfetchpriority=”high”をつけます。
そして、レイアウトの組みやすさなどの利点から、MVはCSSの背景画像として設定するケースが多い。
結果として両者を併用することが多くなります。
インライン化していればpreloadは必須とまで言えないのですが。
WebフォントのSVG以上に、CSSのインライン化は運用保守面でデメリットがあります。
当サイトのように速度を極限までつきつめる個人サイトならともかくですが。
コーポレートサイトですとCSSファイルを分けて制作するのが多くなるでしょう。
「preloadとfetchpriority=”high”は両方つけるのが正義」と短絡的に言いたくはありませんけれども
実務においては、そのくらいに捉えてしまって大丈夫と思います（ただし職場の制作方針によります）。
まとめ
preloadはサイト高速化の定番テクニックとして扱われがちです。
実際、制作現場では“とりあえず有効そうな施策”として受け止められている場面もあるでしょう。
ただ、本来、「どういうケースにpreloadが向くのか」は制作環境次第と言えます。
セオリー扱いして構わない制作環境が多いから結果的にそうなっているだけ。
そうでない場合もあることは、頭の片隅に入れておくと役立つこともあるかもしれません
VPSは、もう「黒い画面」だけじゃない。
「VPSは難しそう」と諦めていませんか？ ConoHaのKUSANAGIなら、ブラウザ上の管理画面（KUSANAGI Manager）で、ドメイン設定からSSL発行まで直感的に操作可能です。
コマンド操作なしで世界最速級の環境を構築できる、今の時代の初心者にとっての最適解。私が長年愛用している理由がここにあります。
※当サイト経由で新規申し込みいただくと、特典として1000円分のクーポンをもらえます。