blog
AIブログ
【WordPress高速化③】最初の表示を速くするクリティカルCSS入門
最初の画面に必要なCSSだけ先に読ませるクリティカルCSSで、体感速度を上げる方法を解説します。
この記事について
本記事は、自社サイト crystal-method.com(WordPress運用) で実際に表示速度を改善した一次データに基づきます(クリティカルCSSのインライン化+外部CSS非同期で、モバイルの初回描画(FCP)を 596ms→404ms に短縮。Google Chrome + Puppeteer/モバイル相当スロットル・5回中央値)。
発行:クリスタルメソッド株式会社(代表取締役 河合 継) | 運営会社 | 編集方針
クリティカルCSSとは何か、WordPressで重要な理由
クリティカルCSS(Critical CSS)とは、ページを開いたとき最初に画面に表示される領域(ファーストビュー/Above the fold)をレンダリングするために必要な最小限のCSSです。通常のWordPressサイトは外部CSSファイルをHTMLの<head>内で読み込みますが、ブラウザはCSSの取得・解析が終わるまでレンダリングを止める(レンダーブロッキング)という仕様があります。これがLCP・FCPを押し上げる主な原因の一つです。
クリティカルCSSをインライン展開することで、ブラウザは外部CSSファイルを待たずにファーストビューを描画でき、体感速度が大きく改善します。当社の実測では、外部CSSから使用分だけ8KBを抽出してインライン化し、残りを非同期(preload)で読み込む構成に変更したところ、モバイルFCPが596ms→404msへ32%短縮しました(Slow 4G+CPU4倍スロットリング、5回測定の中央値)。
本記事ではWordPressにおけるクリティカルCSSの仕組みから、手動・プラグインを使った具体的な実装手順、FOUC(スタイルなし表示のちらつき)の検証と回避策、そして運用時の保守まで網羅的に解説します。
レンダーブロッキングCSSが遅い理由を理解する
まずブラウザがページを表示するまでの流れを確認します。レンダーブロッキングの発生箇所を把握することが、クリティカルCSS対策の前提です。
⚠ ここで停止
外部CSSファイルが複数あれば、それぞれのネットワーク往復分だけ表示が遅れます。WordPressはテーマのメインCSS(style.css)、プラグインのCSS、ブロックエディタのCSS等を重ねて読み込むため、ファイル合計が100〜300KBを超えることも珍しくありません。
Core Web Vitalsの観点では、FCPとLCPがレンダーブロッキングに直接影響します。GoogleはPageSpeed InsightsやLighthouseで「レンダーブロッキング リソースの除外」として指摘してきます。クリティカルCSSはこの指摘に対する最も根本的な解決策の一つです。
クリティカルCSSの基本的な仕組み
クリティカルCSSの実装は大きく3ステップで構成されます。
- ファーストビューに必要なCSSを抽出する:ツールやスクリプトが「特定のビューポートサイズでHTMLをレンダリングしたとき、表示される要素に適用されるCSSルール」を自動または手動で選別する。
- 抽出したCSSをHTMLの
<head>内に<style>タグでインライン展開する:ブラウザは外部リクエストを発生させずに即座にCSSを解析できる。 - 元の外部CSSを非同期で読み込む:
<link rel="preload">を使いファーストビューの描画を邪魔せずに全CSSを遅延読み込みする。
| 方式 | レンダーブロック | FCP/LCPへの影響 | 実装難易度 |
|---|---|---|---|
従来(外部CSS <link>) |
あり | 大きい | なし(デフォルト) |
| クリティカルCSS インライン化+preload | 解消 | 大幅改善 | 中〜高 |
| CSS全体をインライン化 | 解消 | やや改善(HTMLが肥大化) | 低 |
media="print" ハック |
解消 | 改善(JavaScriptが必要) | 低〜中 |
CSS全体のインライン化はブラウザキャッシュが効かず、HTMLが肥大化するためページが2回目以降も遅くなります。クリティカルCSS(ファーストビュー分のみ)を8KB前後に絞り込み、残りはpreloadで非同期取得するのが現実的なバランスです。
クリティカルCSSの抽出方法:ツール比較
抽出には自動ツールを使うのが現実的です。主要な選択肢を整理します。
| ツール名 | 形式 | 特徴 | 向いている用途 |
|---|---|---|---|
| Critical(npm) | CLIツール | Puppeteerベース。複数ビューポート対応。精度が高い | 開発環境でビルド時に組み込む |
| Penthouse(npm) | CLIツール | Puppeteerベース。Gulpとの連携が容易 | Gulpワークフローがある環境 |
| criticalcss.com(オンライン) | Web UI | URLを入力するだけで抽出できる。無料枠あり | 手動確認・小規模サイト |
| WP Rocket | WordPressプラグイン(有料) | 設定画面からワンクリック。ページ別に自動生成 | 技術知識が少ないサイト運営者 |
| Autoptimize + criticalcss.com API | WordPress無料プラグイン+外部API | 無料で実装可能。設定は少し複雑 | コストを抑えたい場合 |
| LiteSpeed Cache | WordPressプラグイン(無料) | CSS最適化機能内にクリティカルCSS生成を内蔵 | LiteSpeedサーバー環境 |
WordPressへの実装手順(手動編)
プラグインを使わず手動で実装する場合の手順です。テーマのfunctions.phpを編集できる開発者向けの方法ですが、仕組みを理解するうえでも重要です。
ステップ1:クリティカルCSSを抽出する
npmが使える環境であれば、以下のコマンドでCriticalパッケージをインストールして実行します。
npm install -g critical
critical https://example.com \
--base ./output/ \
--width 1300 \
--height 900 \
--width 375 \
--height 812 \
--inline \
--extract
--widthと--heightでデスクトップとモバイルのビューポートを両方指定することが重要です。モバイルのファーストビューはデスクトップと異なるため、片方だけだとFOUCが起きます。--extractオプションを付けると、インライン化されたCSSを元のファイルから除去しダウンロードサイズを削減します。
ステップ2:抽出したCSSをWordPressにインライン挿入する
抽出したCSSをwp-content/themes/your-theme/critical.css等として保存し、functions.phpに以下を追加します。
function my_inline_critical_css() {
$critical_css_path = get_template_directory() . '/critical.css';
if ( file_exists( $critical_css_path ) ) {
$critical_css = file_get_contents( $critical_css_path );
echo '<style id="critical-css">' . $critical_css . '</style>';
}
}
add_action( 'wp_head', 'my_inline_critical_css', 1 );
優先度を1(最小値)にすることで、他のCSSより先頭に出力されます。
ステップ3:元の外部CSSをpreloadで非同期化する
テーマのstyle.cssなど主要なCSSをレンダーブロッキングなしで読み込みます。
function my_deferred_css( $html, $handle, $href, $media ) {
if ( is_admin() ) return $html;
// クリティカルCSSで代替済みのハンドルのみ対象にする
$handles_to_defer = array( 'my-theme-style', 'some-plugin-style' );
if ( in_array( $handle, $handles_to_defer ) ) {
$html = '<link rel="preload" href="' . $href . '" as="style" ';
$html .= 'onload="this.onload=null;this.rel=\'stylesheet\'">';
$html .= '<noscript><link rel="stylesheet" href="' . $href . '"></noscript>';
}
return $html;
}
add_filter( 'style_loader_tag', 'my_deferred_css', 10, 4 );
$handles_to_deferにはWordPressがwp_enqueue_style()で登録したハンドル名を指定します。すべてのCSSをまとめて遅延させるのではなく、クリティカルCSSで代替できることを確認したハンドルだけを対象にするのが安全です。
ステップ4:JavaScriptが無効な環境への対応
onload属性はJavaScriptを使うため、JSが無効なブラウザでは全CSSが当たらなくなります。上記コードの<noscript>タグがその対策です。必ず含めてください。
WordPressへの実装手順(プラグイン編)
プラグインを使う場合、以下の2パターンが代表的です。
WP Rocketを使う場合
WP Rocketは有料(年間約$59〜)ですが、クリティカルCSS生成からpreload設定まで管理画面から完結します。
- WP Rocketをインストール・有効化する
- 管理画面の「ファイルの最適化」タブを開く
- 「CSSの最適化」セクションで「クリティカルCSSの生成」を有効化する
- 「クリティカルCSSの生成」ボタンをクリックし、自動生成を実行する
- 生成が完了したら、PageSpeed Insightsで効果を確認する
WP Rocketはページテンプレートごとに個別のクリティカルCSSを生成するため、トップページ・固定ページ・投稿・カテゴリーページで最適化が分かれます。
Autoptimize + criticalcss.com APIを使う場合
- Autoptimizeプラグインをインストール・有効化する
- criticalcss.comでアカウントを作成してAPIキーを取得する
- Autoptimizeの設定画面「クリティカルCSS」タブを開く
- APIキーを入力し、対象URLを追加して「保存」する
- バックグラウンドでクリティカルCSSが生成・適用される
FOUC(スタイルなし表示)の検証と回避策
クリティカルCSS実装後に最も注意すべき問題がFOUC(Flash of Unstyled Content)です。ファーストビューのスタイルが抜け落ちた状態で一瞬表示されるちらつき現象で、ユーザー体験を著しく損ないます。
FOUCの検証手順
当社では以下の手順でFOUCの発生有無を確認しています。
- ブラウザのDevToolsを開き、「ネットワーク」タブで「スロットリング:Slow 4G」を選択する
- 外部CSSファイルのリクエストをブロックする(Chrome DevToolsの「ネットワーク条件」→「リクエストのブロック」で対象CSSのURLを指定)
- ページをリロードし、ファーストビューのスタイルが正常に描画されるか目視確認する
- ヘッダー・ナビゲーション・ヒーロー画像エリアのレイアウトが崩れていなければ、クリティカルCSSが正しく機能している
外部CSSをブロックしたときにファーストビューの上部が正常に描画されれば合格です。逆に崩れる場合は、抽出したクリティカルCSSにそのスタイルが含まれていないため、抽出のビューポートサイズや対象URLを見直す必要があります。
FOUCが起きやすいパターンと対策
- フォント関連のスタイルが抜ける:Google FontsなどのWebフォントCSS(
@font-face)は別途処理されるため、クリティカルCSS内にもフォールバックフォントのスタイルを含める - JavaScriptで動的に挿入されるクラスのスタイルが抜ける:スクロールで動くアニメーションクラス等はツールが検出できないため、手動で追記する
- ビューポート指定が不十分:デスクトップのみ抽出してモバイルでFOUCが起きるケース。複数ビューポートを必ず指定する
- デザイン変更後の陳腐化:後述の保守問題を参照

preloadによる非同期CSSの読み込み詳細
クリティカルCSS実装の核心である<link rel="preload">の仕組みと注意点を整理します。
| 属性 | 値 | 役割 |
|---|---|---|
rel |
preload |
レンダーブロックなしで優先的に取得開始 |
as |
style |
ファイルの種別をブラウザに伝える(キャッシュ優先度に影響) |
onload |
this.rel='stylesheet' |
取得完了後にスタイルシートとして適用 |
media(オプション) |
print→all |
「printハック」と呼ばれる別の非同期化手法。onloadの代替 |
ブラウザ互換性について、rel="preload"はChrome・Firefox・Edgeで広くサポートされています。Safariは以前サポートが不安定でしたが、Safari 15.4以降で対応しており2026年現在は問題ありません。念のため<noscript>フォールバックを常に含めてください。
preloadの使いすぎに注意
preloadは「優先取得」の指示です。過剰に指定するとネットワーク帯域の争奪が起き、逆に重要リソース(LCP画像など)の取得が遅れます。CSSのpreloadはクリティカルCSSで代替した外部CSSのみに絞り、フォントやLCP画像のpreloadとの優先順位バランスも考慮してください。
ページ種別ごとのクリティカルCSS管理
WordPressはトップページ・投稿・固定ページ・アーカイブ等でHTMLの構造が異なります。ファーストビューの要素も変わるため、理想的にはページテンプレート別にクリティカルCSSを用意します。
| ページ種別 | 判定条件(WordPress関数) | 優先度 |
|---|---|---|
| トップページ | is_front_page() |
最高(流入数が多い) |
| 投稿(ブログ記事) | is_single() |
高(SEO流入の主体) |
| 固定ページ | is_page() |
中〜高(LP等は高) |
| カテゴリー・アーカイブ | is_archive() |
中 |
手動実装の場合は、functions.php内でこれらの条件分岐を使い、読み込むcritical.cssファイルを切り替えます。プラグインを使う場合はWP Rocket等が自動で行います。
クリティカルCSSの保守と再生成のタイミング
クリティカルCSSは一度設定すれば終わりではありません。サイトのデザインが変わるたびに再生成が必要です。再生成を怠ると古いクリティカルCSSが残り、ファーストビューに存在しないクラスや変更されたレイアウトのスタイルがインライン化されたまま残ります。特に問題なのが逆方向のFOUCです。クリティカルCSSが外部CSSより先に適用されるため、「クリティカルCSS→旧デザイン、外部CSS→新デザイン」という状態になり、ページ表示の瞬間に旧デザインが一瞬見えてしまいます。
再生成が必要なタイミング
- テーマのメジャーアップデート(レイアウト変更が伴うもの)
- ヘッダー・ナビゲーション・ヒーローエリアなどファーストビューのデザイン変更
- 新しいページテンプレートの追加
- フォントやカラーパレットの変更
- 主要なプラグイン(ページビルダー等)のアップデート後
再生成の自動化
WP Rocketはテーマ切り替え時やWooCommerceの商品ページ変更時に自動でクリティカルCSSを再生成するフックが用意されています。手動実装の場合は、CIパイプラインやGitHub ActionsでCritical CLIを実行し、生成されたcritical.cssをサーバーにデプロイするワークフローを組むと保守負荷を下げられます。
クリティカルCSS実装後の効果測定と注意点
実装効果を正確に測定するためのポイントを整理します。
測定環境を統一する
PageSpeed InsightsやLighthouseはネットワーク状況や測定タイミングによって数値がブレます。当社ではSlow 4G+CPU4倍スロットリング、5回測定の中央値を基準にしています。1〜2回の測定で判断せず、同一条件で複数回測定してください。
確認すべき指標
- FCP(First Contentful Paint):クリティカルCSSの効果が最もダイレクトに現れる指標
- LCP(Largest Contentful Paint):FCPが改善することでLCPも連動して改善することが多い
- Lighthouse「レンダーブロッキング リソースの除外」スコア:対象CSSが除外リストから消えているか確認
- CLS(Cumulative Layout Shift):クリティカルCSSが不完全だとFOUCでCLSが悪化する場合がある
ハイドレーション問題:SPAやブロックテーマの場合
Next.js on WordPress(ヘッドレス構成)やフルサイト編集(FSE)テーマを使う場合、クリティカルCSSの適用タイミングがJavaScriptのハイドレーションと干渉することがあります。FSEテーマではブロックテーマのCSSがblock-stylesとして別管理されているため、通常のクリティカルCSS抽出ツールが見落とすケースがあります。この場合は実際にビルドされたHTMLをスクレイピングしてから抽出するか、プラグインのFSE対応版を利用してください。

クリティカルCSSとその他の高速化施策との組み合わせ
クリティカルCSSはWordPressの表示速度改善の一部です。単独でも効果はありますが、他の施策と組み合わせると相乗効果が出ます。
| 施策 | クリティカルCSSとの関係 | 主な改善指標 |
|---|---|---|
| 使用していないCSSの削除(PurgeCSS等) | 事前に全CSSを削減→クリティカルCSSの抽出精度が上がる | FCP・LCP・転送量 |
| LCP画像のpreload | クリティカルCSSでファーストビューを確保した後、画像を最優先で取得 | LCP |
| Webフォントのdisplay:swap | フォント読み込み中もフォールバックフォントで表示→FCP改善に寄与 | FCP・CLS |
| CSSの圧縮・結合(minify) | クリティカルCSSのインラインサイズを小さく保つ前提として有効 | 転送量・TBT |
| サーバーサイドキャッシュ | TTFB削減→クリティカルCSSが早く届く | TTFB・FCP |
特に使用していないCSSの削除とクリティカルCSSの組み合わせは相性が良いです。テーマのCSSをPurgeCSSやUnCSSで事前にスリム化しておくと、クリティカルCSSとして抽出すべき量が減り、インライン化によるHTMLの肥大化を抑えられます。
よくある失敗と対処法
- 管理画面が崩れる:
is_admin()の条件分岐なしにpreloadを適用すると、WordPress管理画面のCSSまで遅延されてしまいます。必ずif ( is_admin() ) return $html;で除外してください。 - WooCommerceのカートページが崩れる:カート・チェックアウトページはJavaScriptで動的に変わる部分が多く、クリティカルCSSとの相性が悪い場合があります。これらのページはpreloadの対象から除外するか、個別にクリティカルCSSを生成します。
- キャッシュプラグインと二重適用になる:WP RocketとAutoptimize等を同時に使うと、クリティカルCSS処理が重複する場合があります。どちらか一方の機能を無効化してください。
- ステージング環境のURLで抽出してしまう:クリティカルCSS抽出ツールはCSSのURLも含めて書き出すため、ステージングのURLが混入するとCSSが404になります。本番URLで抽出するか、抽出後にURLを置換してください。
まとめ
クリティカルCSSはWordPressの表示速度改善において、レンダーブロッキングを根本から解消する有効な手段です。実装の要点を整理します。
- ファーストビューに必要なCSSのみを抽出し(目安は8KB前後)、
<head>内に<style>タグでインライン展開する - 元の外部CSSは
<link rel="preload">で非同期化し、<noscript>フォールバックを必ず追加する - FOUC検証は外部CSSをDevToolsでブロックし、ファーストビューが正常描画されるか目視で確認する
- デスクトップとモバイルの両ビューポートで抽出し、片方だけのFOUCを防ぐ
- デザイン変更のたびにクリティカルCSSを再生成する運用ルールを設ける
- 効果測定は同一条件(スロットリング・複数回測定の中央値)で行い、FCP・LCP・CLSを総合的に確認する
当社の実測では、この対応だけでモバイルFCPを32%短縮できました。プラグインを使えば実装のハードルは下がりますが、仕組みを理解していないと保守で躓きます。本記事の手動手順を参考に、クリティカルCSSがどのように動くかを把握したうえで、運用しやすい方法を選択してください。
関連記事
- wordpress 表示速度 改善とは(総合ガイド)
- core web vitals lcp 改善
- wordpress 画像 webp 遅延読み込み
- 未使用css 削除 表示速度
- wordpress gtm 遅延 読み込み
Study about AI
AIについて学ぶ
-
【WordPress高速化①】表示を止める”邪魔なCSS”を解消する|レンダリングブロック対策
表示開始を止めてしまうCSSの見つけ方と解消法を、自社サイトの実例で解説します。 この記事について 本記事は、自社サイト crystal-method.com(...
-
【WordPress高速化⑧】次のページを先読みして体感速度を上げる|リンクプリフェッチ
次に見られそうなページを先読みし、クリック後の表示を体感ゼロ秒に近づける手法を解説します。 この記事について 本記事は、自社サイト crystal-method...
-
【WordPress高速化③】最初の表示を速くするクリティカルCSS入門
最初の画面に必要なCSSだけ先に読ませるクリティカルCSSで、体感速度を上げる方法を解説します。 この記事について 本記事は、自社サイト crystal-met...