Lighthouseスコア100への道②：体感速度が爆速に！プリロード（preload）徹底活用術
Webサイトの表示速度は、ユーザーがページを開いてから「意味のあるコンテンツ」がどれだけ速く表示されるかで決まります。この「意味のあるコンテンツ」の表示を司るのが、クリティカルレンダリングパスです。
シリーズ「Lighthouseスコア100への道」の第2弾となる今回は、このクリティカルレンダリングパスを最適化し、Lighthouseのスコアを飛躍させる強力な武器、「リソースのプリロード（preload）」について、その仕組みから具体的な活用法までを掘り下げて解説します。
なぜページの表示は遅れるのか？レンダリングの仕組み
ブラウザがページを表示するまでには、以下のようなプロセスを経ています。
- サーバーからHTMLファイルを受け取る。
- HTMLを上から順に解析し、DOM（Document Object Model）ツリーを構築する。
- 解析の途中で<link rel=”stylesheet”>や<script>タグを見つけると、CSSやJavaScriptファイルのリクエストを開始する。
- CSSのダウンロードと解析が終わると、CSSOM（CSS Object Model）ツリーを構築する。
- DOMとCSSOMが揃って初めて、レンダリングツリーが構築され、画面への描画が開始される。
ここでのボトルネックは、ステップ3でCSSやJavaScriptを見つけるまで、それらのダウンロードを開始できない点です。特に、ページの見た目を決めるCSSや、ページの骨格を組み立てる重要なJavaScriptは、1秒でも早くダウンロードを始めたい「クリティカルリソース」です。これらの読み込みが遅れると、画面が真っ白な時間が長引いたり、レイアウトが崩れた状態で表示されたりして、ユーザー体験を損ないます。
救世主 rel=”preload” とは？
そこで登場するのが<link rel=”preload”>です。
これは、HTMLの<head>内に記述することで、ブラウザに対して「このリソースは、このページの表示に後で必ず必要になるから、他のことをしている間に、高い優先度でダウンロードだけ先に済ませておいて！」と伝えるための指示です。
preloadを使うと、ブラウザはHTMLの解析を続けながら、並行して指定されたリソースのダウンロードを開始します。これにより、実際にそのリソースが必要になったときには、既にダウンロードが完了しているか、かなり進んでいる状態になり、待ち時間を大幅に短縮できるのです。
基本的な構文は以下の通りです。
<link rel="preload" href="path/to/resource" as="resource-type">- href: リソースのパスを指定します。
- as: 非常に重要な属性です。 リソースの種類（style, script, font, imageなど）を明示します。これを正しく指定することで、ブラウザはリソースに対して適切な優先順位付けやセキュリティポリシーを適用できます。
何を、どのようにプリロードするべきか？
preloadは強力ですが、無闇に使うと逆効果になることもあります。ここでは、Lighthouseスコア改善に直結する効果的な使い方を3つ紹介します。
1. レンダリングをブロックするCSSのプリロード
通常、CSSはレンダリングをブロックします。これを回避する一般的な手法として、「クリティカルCSS（ページの初期表示に必要な最小限のCSS）をHTMLにインラインで埋め込み、残りのメインCSSは非同期で読み込む」という方法があります。
この非同期読み込みの際にpreloadが真価を発揮します。
<head>
<link rel="preload" href="style.css" as="style">
<style>
/* body { background: #eee; } ...など最小限のスタイル */
</style>
<link rel="stylesheet" href="style.css" media="print" onload="this.media='all'">
</head>このコードは、まずpreloadでstyle.cssのダウンロードを最優先で開始させます。同時に、media=”print”というトリックを使って、ブラウザに「これは印刷用のCSSだから、画面表示はブロックしないでね」と思わせておき、ダウンロード完了後（onloadイベント）にmedia=”all”に切り替えてスタイルを適用します。
これにより、「レンダリングを妨げるリソースの除外」というLighthouseの指摘に対応できます。
2. Webフォントのプリロード
第1回の記事で解説したWebフォントも、プリロードの絶好の対象です。CSSファイルが読み込まれて、その中の@font-faceが解析されてからフォントのダウンロードが始まる、という遅延を解消できます。
<head>
<link rel="preload" href="/fonts/noto-sans-jp.woff2" as="font" type="font/woff2" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Noto+Sans+JP&display=swap" rel="stylesheet">
</head>as=”font”とcrossorigin属性を忘れずに指定するのがポイントです。display=swapと組み合わせることで、代替フォントが表示される時間（FOUT）をさらに短縮し、よりスムーズな表示を実現できます。
3. LCP（Largest Contentful Paint）画像のプリロード
Lighthouseの重要な指標であるLCPは、「ビューポート内で最も大きなコンテンツが表示されるまでの時間」です。多くの場合、これはページのメインビジュアル（ヒーローイメージ）になります。
このLCPになりうる画像をプリロードすることで、LCPスコアを劇的に改善できます。
<head>
<link rel="preload" as="image" href="hero-image.webp">
</head>
<body>
<img src="hero-image.webp" alt="素晴らしいヒーローイメージ">
</body>ブラウザが<img>タグにたどり着くずっと前からダウンロードを開始できるため、画像の表示が格段に速くなります。
プリロードの注意点：「諸刃の剣」であることを忘れずに
preloadは万能薬ではありません。使い方を誤ると、パフォーマンスを悪化させる可能性があります。
- 何でもプリロードしないこと： preloadはブラウザに「最優先で！」とお願いする強力な指示です。本当にクリティカルなリソースだけに絞りましょう。不要なものまでプリロードすると、本当に重要なリソースの帯域を奪ってしまい、かえって表示が遅くなります。
- プリロードしたリソースは必ず使用すること： preloadで指定したにもかかわらず、そのページで結局使われなかった場合、無駄なダウンロードが発生したことになります。Chromeのデベロッパーツールは、このような場合にコンソールで警告を出してくれます。
- 二重ダウンロードに注意： preloadはあくまでダウンロードを先行させるだけです。実際にリソースを適用するには、別途<link rel=”stylesheet”>や<script>タグなどが必要です。
まとめ
プリロードは、ブラウザの動作を先読みしてリソースの読み込みを最適化する、非常に強力なパフォーマンス改善手法です。
- CSSのプリロードでレンダリングブロックを防ぐ
- WebフォントのプリロードでFOUTを短縮する
- LCP画像のプリロードでコアウェブバイタルのスコアを向上させる
これらのテクニックを正しく使えば、ユーザーの体感速度は劇的に向上し、Lighthouseスコア100がぐっと近づくはずです。
次回は、パフォーマンスチューニングの基本に立ち返り、「JS/CSSの圧縮と、次世代画像フォーマットWebP」について解説します。お楽しみに！
