スタイルシートのプリロードが意味をなす(なさない)ケース

CSSのプリロードが通常役に立たない理由と、それが機能する唯一のケース

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-03-07

スタイルシートのプリロードが意味をなす(なさない)ケース

プリロードされたスタイルシートや、それにまつわる多くの誤った情報を定期的に目にする。リソースのプリロードは、ダウンロードがスケジュールされるタイミングを変更するものである。しかしほとんどの場合、スタイルシートのプリロードは役に立たない。それが機能するケースと機能しないケースを5つの事例で示す。

最終査読者: Arjen Karel、2026年3月

スタイルシートのプリロードのアイデア

スタイルシートはレンダリングブロック・リソースである。スタイルシートのダウンロード中、ブラウザによってページはレンダリングされず、訪問者には空白の画面だけが表示される。

スタイルシートのダウンロードにかかる時間を最小限に抑えるため、開発者はプリロードに頼ることがある。プリロードは、HTML内でリソースが発見される前にフェッチするようブラウザに指示し、より早く準備を整える。これは、rel="preload"属性を持つ<link>タグを使用して行われる。

2025 Web Almanacによると、レンダリングブロック・リソースの監査に合格したデスクトップページはわずか13%である。プリロードは解決策ではない。不要なレンダリングブロック・リソースを排除し、重要でないスタイルシートを遅延させることが解決策である。

ケース1: 宣言の直前でのスタイルシートのプリロード

開発者は熱心さのあまり、実際のCSS宣言の直前にHTML内でプリロードすることでCSSの影響を最小限に抑えようとすることがある。これは次のようになる:

<link rel="preload" as="style" href="style.css">
<link rel="stylesheet" href="style.css">

これはまったく意味をなさないものであり、よくてもページの速度を低下させない程度である。ブラウザには組み込みのプリロードスキャナーがあり、メインパーサーが到達する前にダウンロードするリソースをHTMLからスキャンする。スタイルシートの<link>がすでに<head>内にある場合、プリロードスキャナーはそれを即座に見つける。同じURLに対してrel="preload"のヒントを追加することは、ブラウザがすでに持っている情報を提供することになる。単に不要な行を1行追加しただけである。

3つのプリロードされたスタイルシート

3つの通常のスタイルシート

ケース2: リンクヘッダーを使用したスタイルシートのプリロード

このアイデアは興味深い。Linkサーバーヘッダーを使用してスタイルシートをプリロードできる。これは次のようになる:

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

このアイデアは、HTMLの解析を開始する前にスタイルシートをキューに入れるようブラウザに指示することである。これを考えついた開発者の思考プロセスは素晴らしい。しかし現実には、得られるメリットはごくわずかである。ほんの数マイクロ秒の話である。結果は非常に期待外れだが、このアイデアは実際に機能するものへとつながっていく。

ケース3: スタイルシートへの103 Early Hints

これは実際にCore Web Vitalsの結果を向上させる唯一のアイデアである。スタイルシートに対するアーリーヒントの送信は、First Contentful PaintLargest Contentful Paintのような指標を改善する。

103 Early Hintヘッダーは、実際のHTMLレスポンスのに送信される。つまり、HTMLのダウンロード中に、ブラウザはスタイルシートのダウンロードを並行して開始できる。最も理想的なシナリオは、HTMLのダウンロードが完了するまでにスタイルシートのダウンロードも完了していることである。これらのスタイルシートによるレンダリングブロック時間はゼロになる。これは低速なネットワークで起こり得るし、実際に起こる。高速なネットワークではその効果は目立ちにくいが、それでも103 Early Hintsを使用する方がほとんどのケースで高速である。

103 Early Hintのレスポンスは、プリロードリンクヘッダーとほぼ同じように見える。103 Early Hintsを使用するには、ウェブサーバーまたはCDNを構成する必要がある。

HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style

Cloudflareなどの一部のCDNでは、リンクプリロードヘッダー(ケース2で説明)を設定するだけで103 Early Hintをトリガーできる。実装とブラウザのサポートに関する完全なガイドについては、103 Early Hints:サーバーのシンクタイム中に重要なリソースをプリロードするを参照してほしい。

CoreDashによって監視されているサイト全体で、メインのスタイルシートに103 Early Hintsを使用しているページは、Early Hintsを使用していないページと比較して、75パーセンタイルでFCPが120ミリ秒速くなっている。この改善は、サーバーのシンクタイムとネットワークレイテンシの重複が大きくなるモバイル接続で最も顕著である。

ケース4: 非同期CSSを実現するためのスタイルシートのプリロード

CSSをレンダリングブロックしないようにするための有名なテクニックは、スタイルシートをプリロードし、ロードされたらそれをページに追加することである。アイデアはシンプルで、次のようになる:

<link
   rel="preload"
   href="style.css"
   as="style"
   onload="this.onload=null;this.rel='stylesheet'"
>

これは通常のプリロードコード<link rel="preload" as="style" href="style.css">に基づいており、リンクを最終的な形式である<link rel="stylesheet" href="style.css">に変更するonloadイベントリスナーonload="this.onload=null;this.rel='stylesheet'"を追加する。

これもまた理にかなったアイデアである。スタイルシートがレンダリングブロックしない場合、ブラウザはスタイルシートを待たずにページの解析とレンダリングを継続できる。ただし、注意が必要である!

  • 可視ビューポート内のCSSを非同期にしないこと。 これはおそらくCumulative Layout Shiftを引き起こし、貧弱なユーザー体験につながるだろう。
  • トレードオフを考慮すること。 非同期CSSは、ページの様々な部分の再レンダリングを引き起こす可能性が高い。これはInteraction to Next Paintのような指標に影響を与える。

よりシンプルな現代の代替案は、通常のスタイルシートリンクでfetchpriority="low"を使用することである:<link rel="stylesheet" href="style.css" fetchpriority="low">。これにより、JavaScriptのハックなしにダウンロードの優先順位を下げるようブラウザに指示する。ほとんどのユースケースにおいて、onloadのトリックよりもこちらを推奨する。

ケース5: スタイルシートのプレキャッシュ

まれに、後続のページビューのためにキャッシュファイルを事前に温めようとする気の利いたソリューションを見かける。そうしたソリューションが作られる熱意は称賛するが、これは決して行わないでほしい。

アイデアはシンプルだ。ホームページ上で、必要であれば他のページのためのスタイルをあらかじめキャッシュしておくことができる。例えば製品ページだ。ページロード後のどこかの時点で、スタイルシートをプリロードしてブラウザのキャッシュに追加する。

function preloadStylesheet(url) {
    var link = document.createElement('link');
    link.rel = 'preload';
    link.href = url;
    link.as = 'style';
    document.head.appendChild(link);
}

window.addEventListener('load', function () {
    preloadStylesheet('cart.css');
    preloadStylesheet('shop.css');
});

一見すると、これはそこまで悪くないように見える。どの製品ページでもcart.cssとshop.cssが利用可能になり、レンダリングをブロックしなくなる。これを行うべきではない理由がいくつかある:

  1. より良い方法がある。例えば、Speculation Rulesを用いた投機的プリレンダリングやサービスワーカーの使用などである。
  2. おそらくリソースを浪費することになり、トレードオフの価値はないだろう。もしリソースのプリロードが簡単であれば、ブラウザはよりうまくやっていたはずだ。
  3. このようなソリューションは保守が難しく、将来のどこかの時点で問題を引き起こす可能性が高い。
  4. いくつかだけでなく、すべてのスタイルシートをプリロードする必要がある。すべてのスタイルシートはレンダリングをブロックし並行してダウンロードされるため、たった1つのスタイルシートが複数のスタイルシートと同じ影響を与える可能性があるからだ。

CSSパフォーマンスに実際に効果があること

プリロードのヒントに手を伸ばす代わりに、以下のリソースの優先順位付けの基本に焦点を当てるべきである:

  • 未使用および冗長なCSSを削除する。ファイルが小さいほどダウンロードは速くなる。これがほとんどのサイトにとって最大の成果である。
  • サーバーまたはCDNが対応している場合は、重要なスタイルシートに103 Early Hintsを使用する。

我々のReal User Monitoringデータにおいて、冗長なCSSを削除し103 Early Hintsを使用しているサイトは、一貫して75パーセンタイルでLCPに合格している。根本原因(CSSが多すぎる、読み込みが遅すぎる)に対処せず、単にスタイルシートをプリロードするだけのサイトが意味のある改善を見せることは稀である。

About the author

Arjen Karel is a web performance consultant and the creator of CoreDash, a Real User Monitoring platform that tracks Core Web Vitals data across hundreds of sites. He also built the Core Web Vitals Visualizer Chrome extension. He has helped clients achieve passing Core Web Vitals scores on over 925,000 mobile URLs.

納品するのはレポートではなくコードです。

1〜2スプリント、チームに入ります。監視も整備するので、私が抜けてもメトリクスは緑のままです。

メッセージをどうぞ
スタイルシートのプリロードが意味をなす(なさない)ケースCore Web Vitals スタイルシートのプリロードが意味をなす(なさない)ケース