レンダリングの「ボトルネック」を先回りして潰す：`rel=”preload”` 実践ガイド
Webサイトのパフォーマンスチューニングにおいて、多くのエンジニアが「画像圧縮」や「JSのバンドルサイズ削減」に血眼になります。もちろんそれらも重要ですが、ブラウザの「読み込みの優先順位」を最適化するだけで、体感速度は劇的に変わります。
今日は、ブラウザの先読みエンジンの鼻先を出し抜く手法、`link rel=”preload”` について深掘りします。
—
ブラウザの読み込み順序に「待った」をかける
ブラウザのパーサーは非常に優秀です。しかし、どれほど優秀でも「HTMLの深い場所にあるCSSが、実はページのメインビジュアルを決めるフォントを呼び出している」といった、複雑な依存関係の深層までは予測できません。
通常、ブラウザはHTMLをパースしながら「あ、ここにJSがあるな」「CSSがあるな」と発見するたびにリクエストを飛ばします。しかし、重要なリソースが発見されるのが遅れると、ブラウザは「暇な時間（アイドルタイム）」を無駄にしてしまいます。
`rel=”preload”` は、そんなブラウザに対して「お前がこれから探しに行くはずのそのファイル、今すぐダウンロードしておけ」と先回りして指示を出すための命令です。
—
なぜ `preload` が現場で必須なのか
特にフォントファイルや、Critical CSS（ページ表示に不可欠なスタイル）を読み込む際、preloadを指定していないと、ブラウザは「HTMLの解析→CSSの読み込み→CSSのパース→フォントの発見→フォントのダウンロード」という長い旅路を辿ります。
この結果、ユーザーの画面には「文字化けしたような空白」が一瞬表示される（FOIT: Flash of Invisible Text）ことになります。これを防ぐために、ブラウザに「最優先でこれを持ってこい」と指示するのが `preload` の役割です。
—
実践：現場でそのまま使えるコード例
以下は、WebフォントとメインのJSを早期読み込みさせるための、実務レベルの記述例です。これを `
` 内の、なるべく上部（titleタグの直下あたり）に配置してください。
—
守るべき「3つの鉄則」
現場で `preload` を導入する際、必ず頭に入れておいてほしい注意点があります。
1. `crossorigin` を忘れない（フォントの罠）
フォントファイルをプリロードする際は、`crossorigin` 属性が必須です。たとえ同じドメイン内であっても、ブラウザはフォントをCORS（Cross-Origin Resource Sharing）で取得するため、この指定がないと「プリロード用のリクエスト」と「CSSが発火させた実際のリクエスト」の2回ダウンロードが発生してしまいます。これでは逆効果です。
2. `as` 属性は正確に
ブラウザは `as` 属性を見て、リクエストの優先順位（Priority）を決定します。ここを間違えると、ブラウザが適切な優先度を割り当てられず、せっかくの先読みが無駄になります。`style`, `script`, `font`, `image` など、適切な型を明示しましょう。
3. 「何でもかんでも」は禁物
「とりあえず全部プリロードしておけば速くなるだろう」というのは初心者が陥る罠です。プリロードしすぎると、本当に必要なリソースの帯域を圧迫し、ネットワークの輻輳を招きます。
「今、画面に見えているもの」、あるいは「次に必ず使うもの」だけを厳選して指定してください。
—
まとめ：賢いエンジニアは「優先度」をコントロールする
`rel=”preload”` は、ブラウザの本来の挙動をハックする強力なツールです。しかし、魔法の杖ではありません。
まずは Chrome DevTools の「Network」タブを開き、フォントやJSが「どのタイミングで読み込まれているか（Waterfall）」を確認してください。もし、重要度が高いリソースが「Late（遅い）」タイミングで落ちてきているなら、それが `preload` の出番です。
パフォーマンスチューニングは、細かな積み重ねの果てにあります。明日から、読み込みの「順序」という観点でサイトを見直してみてください。きっと、これまで見えなかったボトルネックが見えてくるはずですよ。
コメント