言語

Critical CSS（クリティカルCSS）

Critical CSSを抽出してインライン化し、残りを遅延する方法を解説します。ファーストペイント、LCP、CSP、キャッシュ、テンプレート状態、レイアウトシフト、保守上のトレードオフを扱います。

初回公開：2026年7月3日 · 最終更新：2026年8月11日 · Advanced
言語
AI執筆者：AI v2

Critical CSSはファーストビューの描画に必要なCSSを抽出して<head>へインライン化し、残りを非同期で遅延する手法です。CSSは既定でレンダリングをブロックしますが、ファーストビューは端末や状態で変わります。Googleは高度で任意と説明しており、インラインCSSのキャッシュ喪失、CSP、テンプレート変更、競合を測定する必要があります。SEOへの影響は直接のランキング要因ではなく、実際にLCPやページ体験が改善した場合の間接効果です。

要点 — Critical CSSでは、ファーストビュー用スタイルを抽出して<head>へインライン化し、残りを非同期で遅延します（rel="preload"とonloadの切り替え、<noscript>のフォールバック、またはloadCSS）。CSSが既定でレンダリングをブロックするため成立する手法です。正確さの軸は、Googleがこれを標準的な助言ではなく、高度で任意の手法としていることです。“Most sites should be able to achieve all of our recommended performance targets without implementing this technique.” (翻訳)「ほとんどのサイトは、この手法を実装しなくても推奨されるすべてのパフォーマンス目標を達成できるはずです。」インライン容量は小さく保ちます。インラインCSSはページ間でキャッシュされず、テンプレート変更で分割が壊れ、遅延処理が競合してFOUCやCLSを起こすことがあります。まず診断し、 JavaScriptやサーバー応答ではなくCSSが実際のボトルネックかを確認してください。CSPのstyle-srcがインライン<style>を拒否する場合があり、“unused at capture” (翻訳)「計測時に未使用」と*“safe to defer”* (翻訳)「遅延して安全」は同義ではありません。また、インライン化だけではフォント読み込みのタイミングは解決しません。SEO効果はCore Web Vitals／LCPを介した間接的なものです。Bing固有の助言はありません。

Critical CSSの実像

解決対象はレンダリングをブロックするCSSです。Googleのweb.devは次のように明記しています。 “By default, CSS is treated as a render-blocking resource, which means that the browser won’t render any processed content until the CSSOM is constructed” (翻訳)「既定ではCSSはレンダリングをブロックするリソースとして扱われるため、CSSOMが構築されるまでブラウザーは処理済みコンテンツを描画しません。」 出典 これが手法の存在理由です。ブラウザーはスタイルが揃うまで描画を待つため、CSSの遅延は初回描画の遅延になります。基礎となる処理全体はクリティカルレンダリングパスのハブと、関連するレンダリングをブロックするリソースを参照してください。

Critical CSSはCSSを2つに分けて対処します。web.devの定義は、“Critical CSS is a technique that extracts the CSS for above-the-fold content in order to render content to the user as fast as possible.” (翻訳)「Critical CSSは、ファーストビューのコンテンツに必要なCSSを抽出し、できるだけ速く利用者へ表示する手法です。」と説明しています。仕組みについても、“Inlining extracted styles in the <head> of the HTML document eliminates the need to make an additional request to fetch these styles. The remainder of the CSS can be loaded asynchronously” (翻訳) 「抽出したスタイルをHTML文書のheadへインライン化すれば追加リクエストが不要になり、残りのCSSは非同期で読み込めます」としています。

Evidence for this claim Critical CSS extracts and inlines above-the-fold styles so the remaining CSS can load asynchronously. Scope: web.dev definition and implementation outline for critical CSS. Confidence: high · Verified: web.dev: Extract critical CSS

web.devが明言し、多くの二次資料が見落としている点として、普遍的なファーストビューの高さは存在しません。端末サイズ、向き、ブラウザーUI、ズーム、ページ状態（開いたメニュー、読み込み済みのパーソナライズ、エラー状態）によって「クリティカル」に含めるものが変わります。固定のピクセル境界ではなく、選択した初期ビューポートと状態に対する判断として扱い、デスクトップのスクリーンショット1枚ではなく実際のブレークポイントと状態で検証します。

作業は次の順序で2つあります。

  1. インライン化： ファーストビューに最低限必要なCSSを<head>へ置き、初回描画前の追加往復をなくします。
  2. 遅延： 残りのスタイルシートを非同期で読み込み、初回描画をブロックさせません。

これは私がページ体験に関する講演で示してきた分け方と同じです。ページ体験の次の展開（SMX Next 2021）では、CSS作業を早期／クリティカル経路（未使用CSSの削除 → CSSの圧縮 → Critical CSSのインライン化）と、後期／遅延経路（非クリティカルCSSの遅延）に分けました。web.devと同じ構造を、私の考える実行順に並べたものです。

実装方法

ステップ1 — Critical CSSをインライン化する。 Lighthouseは、初回描画に必要なクリティカルスタイルをHTMLページのheadにある<style>ブロック内へインライン化するよう案内しています。同じ資料で参照されるGoogleの容量目安は、ファーストビューのコンテンツを圧縮後14 KB未満に保つことです。最初のネットワーク往復に収めるためですが、これは普遍的な仕様ではなく、2019年時点の通信上の指針として扱ってください。現在普及しているHTTP/2とHTTP/3では初回往復の計算が変わります。Google文書に残る数値ではあるものの、厳密に調整する場合は14 KBを絶対視せず、現在のプロトコルとサーバー挙動で検証します。

ステップ2 — 残りを遅延する。 web.devが非クリティカルCSSの遅延で推奨するのは、onloadで切り替えるpreloadと<noscript>のフォールバックを組み合わせる方法です。

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

本番環境では、切り替えを自作するより、この挙動を内包して各ブラウザーで機能するloadCSSなどのCSS遅延関数を使うことをweb.devは勧めています。JavaScriptで遅延する場合、非クリティカルCSSの読み込み開始をJavaScriptの実行まで待つと、利用者がスクロールした際の描画が遅れることがあるため、preloadでダウンロードを早く開始します。

ツール。 Critical CSSを手作業で抽出することは多くありません。Googleの参照実装はAddy Osmaniによるcritical npmパッケージで、“a tool that extracts, minifies and inlines above-the-fold CSS.” (翻訳)「ファーストビューのCSSを抽出、圧縮、インライン化するツール」です。代替にはPenthouse、CriticalCSS、WordPressやShopify向けのSaaS／プラグイン生成ツールがあります。必要な規則を自分で特定する場合、GoogleはChrome DevToolsのCoverageタブで非クリティカルなCSSとJSを識別するよう案内しています。

WP RocketやAutoptimizeなどのプラグイン／生成ツールを使う場合、ベンダーのUI手順やスコアの前後比較をプラットフォーム全体の保証と見なさないでください。製品バージョンと特定サイトの結果が混在し、差分が独立に再現されていないことがあります。本番採用前に現行文書とバージョンを確認し、手作業の実装と同じテスト行列、つまりコールド／再訪読み込み、実際のブレークポイント・テーマ・状態、運用中ならCSPポリシーで検証します。

Critical CSSはレンダリングをブロックするCSSへの対策の一つにすぎません。ほかにも、media属性でスタイルシートの適用範囲を限定して描画をブロックさせない方法や、配信するCSS自体を減らす方法があります。web.devのレンダリングブロック記事はインライン化よりmedia属性を中心に説明しており、Googleにも文書ごとに複数の公式な処方があります。

Googleの実際の位置付け（正確さの軸）

競合記事の多くが埋もれさせているものの、ここがこのページを書いた最大の理由です。GoogleはCritical CSSを標準的な助言として提示していません。codelabはリスクを明記しています。“This codelab describes an advanced performance technique that can improve performance, but can also lead to bugs if not implemented properly” (翻訳)「このcodelabはパフォーマンスを改善し得る高度な手法を説明しますが、正しく実装しないとバグを生む可能性もあります。」 出典さらに複数の文書で、“Most sites should be able to achieve all of our recommended performance targets without implementing this technique” (翻訳)「ほとんどのサイトは、この手法を実装せずに推奨されるすべてのパフォーマンス目標を達成できるはずです。」 出典と述べています。

Evidence for this claim web.dev presents critical CSS as an advanced technique that can cause bugs and says most sites can meet performance targets without it. Scope: web.dev codelab guidance; not a universal recommendation. Confidence: high · Verified: web.dev: Extract and inline critical CSS

利点にも注意点があります。web.devは、インライン化するとブラウザーが後続ページで再利用するためのCSSキャッシュを作れなくなるため、控えめに使うべきだと説明しています。過剰な優先付けについても、if everything is prioritized then nothing is. (翻訳)「すべてを優先すれば、何も優先されていないのと同じです。」と警告しています。インライン化しすぎると、速く届けたいHTMLそのものが肥大化します。

正確に表現するなら、Critical CSSは文書化された実在の強力な手法である一方、Googleが大半のサイトには目標達成のために不要だとする、高度で任意の最終手段です。その前提で扱ってください。

実際のトレードオフ

独立系のパフォーマンス技術者は特に強く注意を促しており、その内容はGoogle自身の但し書きとも一致します。

再訪時のキャッシュ喪失。 DebugBearのMatt Zeunertは、“critical CSS can’t be re-used between different page loads on your website. So subsequent page views can actually be slower than they would be without critical CSS” (翻訳)「Critical CSSはサイト内の別ページ読み込みで再利用できないため、後続ページはCritical CSSがない場合より遅くなることがあります。」 出典と明言しています。通常の外部スタイルシートは一度キャッシュされて全ページで再利用されますが、インラインCSSはHTMLレスポンスごとに再ダウンロードされます。

保守と回帰のリスク。 Harry Robertsの反対意見として有名な記事は、“retrofitting Critical CSS is difficult and error prone” (翻訳)「既存サイトへCritical CSSを後付けするのは難しく、誤りが起きやすい」 出典と警告しています。CSSをボトルネックと特定した後も、“you need to keep it that way… One wrong decision can undo everything.” (翻訳)「その状態を維持しなければならず、判断を一つ誤るだけですべてが台無しになり得ます。」自動的な再検証はなく、テンプレートやデザインの変更で分割が静かに壊れる可能性があります。

遅延処理の競合。 Robertsはpreload／onloadの切り替えがタイミング次第で逆効果になるとも指摘します。“if it takes 1s to parse your <head> and 0.5s to asynchronously fetch your non-Critical CSS, then the CSS will be turned back into a synchronous file 0.5s before you were ready to go anyway” (翻訳)「headの解析に1秒、非クリティカルCSSの非同期取得に0.5秒かかるなら、準備が整う0.5秒前にCSSは結局同期ファイルへ戻されます。」非クリティカルCSSの到着が遅ければ、未スタイル表示やレイアウトシフトも起こり得ます。

そもそも最大のボトルネックではないことが多い。 Robertsの中心的な主張は、“Critical CSS only helps if CSS is your biggest render-blocking bottleneck, and quite often, it isn’t” (翻訳)「Critical CSSが役立つのはCSSが最大のレンダリングブロッカーである場合だけで、実際にはそうでないことがよくあります。」 出典というものです。DebugBearも、“if you still have render-blocking JavaScript code, inlining CSS is unlikely to help” (翻訳)「レンダリングをブロックするJavaScriptが残っているなら、CSSのインライン化はほぼ役立ちません。」 出典と説明し、“often it’s not the most impactful optimization.” (翻訳)「最も効果の大きい最適化ではないことが多い」としています。

本番環境の落とし穴：CSP、状態、フォント

簡単なデモでは見えず、本番運用で問題になる失敗要因がさらに3つあります。

CSPがインライン<style>を完全にブロックすることがある。 Content-Security-Policyのstyle-srcは、nonceや一致するハッシュなどで明示的に許可されていないインライン<style>をブロックします。MDNは違反条件とnonce／hashの仕組みを説明しています。コンソールエラーを消すためにunsafe-inlineへ逃げるとサイト全体のポリシーが弱くなります。抽出ツールへnonce／hash生成を組み込み、公開後にブラウザーコンソールで違反を確認してください。

「計測時に未使用」は「遅延して安全」と同じではない。 Coverageタブが示すのは、1回の記録中に実行されたCSSです。安全な分割では、カスケード順序に加え、レスポンシブのブレークポイント、テーマ差分、パーソナライズ、フォーカス状態、開いたメニュー／モーダル、エラー状態に必要な規則を維持しなければなりません。Robertsも、どのビューポートと、どの未表示・未操作要素（ドロップダウンやフライアウト）を抽出対象に含めるのかという同じ問題を提起しています。

フォント問題は解決せず、描画処理が増えることもある。 要素スタイルをインライン化しても、Webフォントが早く発見されることや文字が時間どおりに表示されることは保証されません。フォントの発見、preload、font-display、フォールバック指標はCritical CSSとは別の依存関係です。また、インラインの部分スタイルに続いて大きなスタイルシートを適用すると、スタイル再計算、レイアウト、描画が増える場合があります。取得遅延の削減が総描画処理の削減を意味するとは限らないため、ネットワークウォーターフォール以外も測定します。

本当に必要かを診断する方法

以上を踏まえ、「Critical CSSを追加する」から始めず、「CSSが描画のボトルネックであることを確認する」から始めてください。さらに、次の4つのゲートをすべて満たす必要があります。

1. CSSが推測ではなく、実証されたブロッカーである。

  • PageSpeed Insights／Lighthouseレポートを開きます。Lighthouse 13以降、旧「Eliminate render-blocking resources」監査はRender-blocking requestsインサイトへ移動しました。旧監査名を使う記事は古くなっています。
  • Chrome DevToolsのCoverageタブで、初回描画時に未使用のCSSとJSの量を確認します。
  • 原因を分けます。ボトルネックがレンダリングをブロックするJavaScriptや遅い**サーバー応答（TTFB）**なら、CSSのインライン化では直りません。

2. 実際に安定した抽出範囲を作れる。 デスクトップのスクリーンショット1枚ではなく、実際のブレークポイント、テーマ、パーソナライズ、操作状態を網羅する必要があります。

3. 再訪コストとCSPコストを許容できる。 インラインCSSはキャッシュされないため、一般的なセッションの深さと比較します。CSPのstyle-srcを運用している場合は、公開後ではなく事前にnonce／hash生成をパイプラインへ組み込みます。

4. 実際に保守できる。 テンプレートやデザインの変更ごとに再生成し、コールド／再訪読み込み、対応する全ルート・ビューポート・状態を含むテスト行列を再実行します。公開後に一度目視するだけでは不十分です。

4つのゲートをすべて満たすなら、Critical CSSは保守コストに見合う可能性があります。一つでも満たさないなら、未使用CSSの削除、圧縮、mediaによる非クリティカルスタイルシートの限定といった、より低コストな修正を優先します。

2026年時点の注意点

現在進行中の注意点として、Google文書がCSS遅延用に推奨する<link rel="preload" as="style">パターンが、Lighthouse／PSIの更新後に再びレンダリングブロック扱いされたという未解決報告があります。GitHub issue #17031では、Lighthouse 13.0.1で緑だったpreload済みCSSが13.3.0でレンダリングブロックと判定された経緯が記録されています。執筆時点でGoogleの公開解決はないため進行中の問題として扱います。正しく遅延したCSSをPSIが警告しても監査側が誤っている可能性があるため、実装が壊れたと決め付けずレポートを批判的に読んでください。

Critical CSSはSEOに役立つか

効果は間接的で、小さいものです。次の2点を分けます。

  • CSSは直接のランキングシグナルではない。 GoogleのMartin SplittはCSSクラス名について、“I don’t think we care because the CSS class names are just that.” (翻訳)「CSSクラス名は単なる名前なので、Googleが気にしているとは思いません。」と述べています。クラス名に限った発言ですが、CSSの選択自体がランキング入力として読まれるという広い誤解を否定します。
  • 速度はCore Web Vitalsを介した小さなシグナルである。 Critical CSSは初回描画を改善し、それがGoogleのページ体験シグナルに使われるCore Web Vitals指標のLCPを改善する可能性があります。SEOとのつながりは手法への加点ではなく、描画の高速化だけです。

したがってCritical CSSのSEO上の価値は、そのサイトでLCPをどれだけ改善するかに等しく、Googleやパフォーマンス専門家が指摘するように、販売ツールが示唆するほど大きくないことがよくあります。

Bingについて

Bing固有の助言はありません。Googleには複数のweb.devページとcodelabがありますが、Critical CSSを扱うBing／Microsoft専用文書は確認できませんでした。Bingの一般的なページ体験の助言（高速に保ち、重要なコンテンツへ到達可能にする）は適用されますが、web.devのCritical CSS codelabに相当するものはありません。Bing固有の推奨があるという主張には根拠がありません。

このページの位置付け

このページはクリティカルレンダリングパスのハブ配下にあり、Critical CSSはその経路を短縮する手法の一つです。レンダリングをブロックするリソースの実践的な関連ページでもあります。効果が出る場合は、Largest Contentful Paint（LCP）、First Contentful Paint（FCP）、より広いCore Web Vitalsに現れます。全体像はWebパフォーマンスのクラスターを参照してください。

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.