blog

【WordPress高速化①】表示を止める”邪魔なCSS”を解消する｜レンダリングブロック対策

表示開始を止めてしまうCSSの見つけ方と解消法を、自社サイトの実例で解説します。

レンダリングブロックCSSとは何か：なぜ表示速度を下げるのか

WordPressサイトの表示速度を改善しようとPageSpeed InsightsやLighthouseで計測すると、「レンダリングブロックリソースを排除してください」という警告が高頻度で登場します。特にCSSファイルが原因のケースは多く、適切に対処すればFCP（First Contentful Paint）やLCP（Largest Contentful Paint）を数十ミリ秒〜数百ミリ秒単位で短縮できます。

この記事について

本記事は、自社サイト crystal-method.com（WordPress運用） で実際に表示速度を改善した一次データに基づきます（第三者CDN(unpkg)のCSSを自前ホスト化し、モバイルの初回描画(FCP)を 640ms→596ms に短縮。Google Chrome + Puppeteer／モバイル相当スロットル・5回中央値）。
発行：クリスタルメソッド株式会社（代表取締役 河合 継）　｜　運営会社　｜　編集方針

本記事では、レンダリングブロックCSSが発生するメカニズムを仕組みから理解し、WordPressで実践できる具体的な解消手順を網羅的に解説します。当サイト（クリスタルメソッド）での実測データも交えながら、「本数を減らす」「サードパーティ接続を断つ」という2軸で整理します。

レンダリングブロックCSSの仕組み

ブラウザはHTMLを上から順にパースし、DOMツリーを構築します。<link rel="stylesheet">タグに到達すると、CSSファイルを取得してCSSOMを完成させるまでレンダリングを完全に停止します。これがレンダリングブロックです。

理由はシンプルで、CSSOMとDOMが揃わないとブラウザはレンダーツリーを生成できず、どの要素を画面に描画すべきかが決まらないからです。CSSが1バイトでも届いていなければ、白紙の画面がユーザーに見え続けます。

HTMLパース開始
→
CSSリンク検出
レンダリング停止
→
CSS取得・解析
（ネットワーク往復）
→
CSSOM完成
レンダリング再開
→
FCP達成

問題が深刻になる要因は主に3つです。

  • CSSファイルの本数が多い：プラグインやテーマが追加するCSSが積み重なり、ブラウザが順次取得を待つ
  • サードパーティドメインからの読み込み：DNS解決・TCP接続・TLSハンドシェイクが新たに発生する
  • ファイルサイズが大きい：未使用CSSを含む肥大化したファイルはダウンロードに時間がかかる

サードパーティCDNが引き起こす隠れたボトルネック：実測データ

「CSSの本数を減らす」だけでなく、「どこから取得するか」も描画速度に直結します。当サイトでの実例を紹介します。

CSSリセットとして広く使われるress.min.cssを、unpkg（サードパーティCDN）から読み込んでいた環境で計測したところ、モバイルのFCPが640msを記録していました。原因を調査すると、unpkgは44バイトのリダイレクトレスポンスを返し、本体のCSSを再取得するために2往復のネットワーク通信が発生していることが判明しました。

取得方法 ネットワーク往復 モバイルFCP 主な課題
unpkg（外部CDN）から読み込み 2往復（リダイレクト含む） 640ms DNS・TLS・リダイレクトのオーバーヘッド
自前ホスト化（自サーバー配信） 1往復 596ms（−44ms） なし（同一オリジンで完結）

ress.min.cssを自サーバーに配置して配信先を自前ホストに変更しただけで、FCPが44ms短縮（640ms→596ms）されました。この経験から得た結論は明確です。レンダリングブロックCSSの改善は「本数を減らすこと」と「サードパーティ接続を断つこと」の2点が核心です。

WordPressでレンダリングブロックCSSを解消する5つの手法

手法1：不要なCSSの読み込みを無効化する

最も根本的な対策です。使っていないプラグインのCSS、テーマのブロックスタイル、絵文字用CSS（wp-emoji-release.min.css）などは、表示に不要なページでは読み込まないことが最善です。

WordPressではwp_dequeue_style()関数を使ってCSSの読み込みを無効化できます。たとえば、絵文字スタイルを全ページで無効にするには以下のコードをfunctions.phpに追記します。

// 絵文字関連スクリプト・スタイルを無効化
function disable_emoji_styles() {
    remove_action('wp_head', 'print_emoji_detection_script', 7);
    remove_action('wp_print_styles', 'print_emoji_styles');
}
add_action('init', 'disable_emoji_styles');

同様に、Contact Form 7などのプラグインCSSを問い合わせページ以外で無効化するには、条件分岐タグ（is_page()など）と組み合わせてwp_dequeue_style('contact-form-7')を実装します。

手法2：CSSをインライン化（クリティカルCSSの抽出）

ファーストビューの描画に必要な最小限のCSS（クリティカルCSS）を<style>タグとしてHTMLの<head>内に直接埋め込む手法です。外部CSSファイルへのネットワーク往復をゼロにできるため、FCPを大幅に改善できます。

残りの非クリティカルCSSは後述の遅延読み込みで処理します。クリティカルCSSの抽出には以下のツールが活用できます。

  • Critical（npmパッケージ）：ビルドプロセスに組み込む場合
  • Penthouse：URLを指定してクリティカルCSSを自動抽出
  • LiteSpeed Cache / WP Rocket：WordPressプラグインとして自動化可能

注意点として、クリティカルCSSはページ単位で異なることが多く、トップページ・投稿ページ・カテゴリページなどで分けて生成・管理するのが理想です。

手法3：非クリティカルCSSの遅延読み込み（preload + onload）

ファーストビューに不要なCSSファイルは、レンダリングをブロックしない形で読み込む技法があります。rel="preload"とonload属性を組み合わせた記述が標準的です。

<!-- 非ブロッキングでCSSを読み込む -->
<link rel="preload" href="/wp-content/themes/your-theme/style.css"
      as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript>
  <link rel="stylesheet" href="/wp-content/themes/your-theme/style.css">
</noscript>

rel="preload"はファイルを事前にダウンロードしますが、適用はしません。onloadでrel="stylesheet"に切り替えることでレンダリングブロックを回避します。JavaScriptが無効な環境への<noscript>フォールバックも必ず記述してください。

WordPressでこの変換を自動化するには、WP Rocketの「CSS遅延読み込み」機能やLiteSpeed Cacheの「CSS非同期」オプションが利用できます。

手法4：サードパーティCSSの自前ホスト化

Google Fonts、FontAwesome、Bootstrap、CSSリセット（normalize.css、ress.css）など、外部CDNから読み込んでいるCSSは、可能な限り自サーバーへ移行することを推奨します。理由は冒頭の実測データが示すとおりで、サードパーティへの接続にはDNS解決・TCPハンドシェイク・TLSネゴシエーションが追加されるためです。

❌ サードパーティCDN読み込み
  1. DNSルックアップ（外部ドメイン）
  2. TCPコネクション確立
  3. TLSハンドシェイク
  4. リダイレクト（CDNによっては発生）
  5. CSS本体の取得
✅ 自前ホスト化
  1. DNSルックアップ（不要）
  2. TCPコネクション確立（既存接続を再利用）
  3. TLSハンドシェイク（不要）
  4. リダイレクト（不要）
  5. CSS本体の取得のみ

Google Fontsの自前ホスト化にはgoogle-webfonts-helper（ウェブサービス）が便利で、使用フォントのwoffファイル一式をダウンロードしてサーバーに配置できます。WordPressプラグインのOMGF（Optimize My Google Fonts）を使うと、設定画面からGoogle Fontsをローカルに自動取得・配信切り替えまで行えます。

手順の概要（手動）

  1. 使用しているCSSファイルのURLをソースコードやLighthouseレポートで特定する
  2. ファイルをダウンロードし、/wp-content/themes/your-theme/css/などに配置する
  3. functions.phpで既存の読み込みをwp_dequeue_style()で無効化し、wp_enqueue_style()で自前URLを登録する
  4. Lighthouseで再計測し、サードパーティへの接続が消えていることを確認する

手法5：CSSの結合・最小化（Minify）

複数のCSSファイルを1ファイルに結合する「結合（Concatenation）」と、コメントや空白を除去する「最小化（Minify）」は、リクエスト数削減とファイルサイズ圧縮に有効です。ただし、HTTP/2環境ではヘッダー圧縮・多重化により複数ファイルのオーバーヘッドが小さいため、結合の優先度は以前ほど高くありません。それでも、無効化・遅延読み込みと組み合わせることで確実に効果があります。

WordPressで利用できる主なプラグインをまとめます。

プラグイン名 CSS Minify CSS結合 遅延読み込み クリティカルCSS 料金
WP Rocket ✅ ✅ ✅ ✅（自動生成） 有料（$59〜/年）
LiteSpeed Cache ✅ ✅ ✅ ✅（CCSS） 無料
Autoptimize ✅ ✅ △（手動設定） ❌（別途必要） 無料
W3 Total Cache ✅ ✅ △ ❌ 無料（Pro版あり）

media属性とprint CSSの扱い

CSSのブロッキングはデフォルトですべてのCSSに適用されますが、media属性を使うことで特定の条件に限定した読み込みが可能です。たとえば印刷用CSSを以下のように記述するとレンダリングをブロックしません。

<link rel="stylesheet" href="print.css" media="print">

media="print"はスクリーン表示時には非ブロッキングとなるため、印刷スタイルや条件分岐のあるCSSは積極的にmedia属性で限定すべきです。ただし、media="all"（デフォルト）やmedia="screen"は通常のブロッキング動作のままです。

WordPressのwp_enqueue_style()でmediaを指定する場合は、第5引数にmedia属性値を渡せます。

wp_enqueue_style(
    'my-print-style',
    get_template_directory_uri() . '/css/print.css',
    array(),
    '1.0',
    'print' // media属性
);

preconnectでサードパーティ接続のオーバーヘッドを削減する

サードパーティCSSを自前ホスト化できない場合の次善策として、<link rel="preconnect">があります。DNS解決・TCPハンドシェイク・TLSネゴシエーションをHTML解析の早い段階で先行実行し、CSSファイルが実際に要求されたときの接続コストをゼロにします。

<!-- Google Fontsの例 -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

ただし、preconnectは接続確立の高速化であり、ブロッキング自体を解消するものではありません。根本解決は自前ホスト化です。preconnectは移行の過渡期や、どうしても外部依存が残るケースの補助的手法として位置づけてください。

なお、preconnect先が多すぎるとブラウザのネットワークリソースを奪う副作用があります。実際に接続するドメインに絞って指定することが重要です。

未使用CSSの削除（PurgeCSS / テーマの最適化）

ファイルの本数や接続先を整理しても、CSSファイル自体が巨大であればダウンロード時間は長くなります。特にBootstrapやTailwind CSSなど大規模フレームワークを使っているWordPressテーマでは、実際にページで使用するセレクタがごく一部であることがよくあります。

未使用CSSを自動削除するツールとしてPurgeCSSが広く使われています。WordPressとの統合にはビルドツール（webpack、Vite、Laravel Mix）経由での利用が一般的です。また、WP RocketにはRUCSSS（Remove Unused CSS on Safe Mode）という機能があり、ページを安全に解析して未使用CSSを除去できます。

注意点として、JavaScriptで動的に付与されるクラス名はPurgeCSSが検出できず、誤って削除されることがあります。safelistオプションで動的クラスを保護する設定が必要です。

// PurgeCSS設定例（purgecss.config.js）
module.exports = {
  content: ['./wp-content/themes/your-theme/**/*.php'],
  css: ['./wp-content/themes/your-theme/style.css'],
  safelist: [
    /^is-/, /^has-/, /^wp-block-/, 'active', 'open'
  ]
};

改善効果の確認方法

対策を実施したら必ず計測し、効果を数値で確認します。主な計測手段を整理します。

ツール 確認できること 特徴
PageSpeed Insights FCP・LCP・レンダリングブロックリソース一覧 実際のフィールドデータ（CrUX）も参照可能
Chrome DevTools（Performanceタブ） CSS取得タイミング・ブロッキング時間の可視化 ウォーターフォールチャートで詳細確認
WebPageTest サードパーティ接続・ウォーターフォール詳細 接続先ドメインごとのタイミングが可視化される
Lighthouse CLI CI/CDパイプラインでの自動計測 デプロイごとにスコア変化を追える

計測は必ずモバイル・デスクトップ両方で行い、変更前後の数値を記録して比較することが重要です。特にモバイルはネットワーク帯域・CPU性能がデスクトップより制約されるため、CSSブロッキングの影響がより顕著に出ます。

レンダリングブロック解消前後のCSSウォーターフォール比較イメージ
レンダリングブロック解消前後のCSSウォーターフォール比較イメージ

対策の優先順位と実施ロードマップ

レンダリングブロックCSSの解消策は複数ありますが、すべてを一度に実施する必要はありません。効果の高さと実施コストのバランスから、以下の優先順位で進めることを推奨します。

優先1
不要なCSSを無効化（wp_dequeue_style）：コストゼロで即効果。まずLighthouseで読み込まれているCSSを全列挙し、不要なものを特定する。

優先2
サードパーティCSSを自前ホスト化：特にGoogle Fonts・CDN配信のリセットCSSは移行コストが低く効果が大きい。

優先3
非クリティカルCSSを遅延読み込み（preload + onload）：プラグインで自動化するか、手動でlink属性を変更する。

優先4
クリティカルCSSのインライン化：効果は最大だが、生成・管理コストがかかる。ツールやプラグインを活用する。

優先5
未使用CSSの削除（PurgeCSS / RUCSS）：ファイルサイズ削減で転送時間を短縮。動的クラスのsafelist設定を忘れずに。

よくある失敗パターンと注意事項

  • CSS結合でWordPressのブロックエディタが崩れる：Gutenbergのブロックスタイルは動的に生成されるため、無秩序に結合すると表示が壊れることがあります。プラグインの「問題のあるCSSを除外」設定を活用してください。
  • 遅延読み込みで初期描画にスタイル未適用のチラつき（FOUC）が発生する：クリティカルCSSのカバー範囲が不十分なときに起きます。ファーストビューの要素を網羅するようクリティカルCSSを見直します。
  • preconnectを過剰に設定してかえって遅くなる：接続確立にもリソースが必要です。実際にブロッキングが問題になっているドメインに絞って指定してください。
  • キャッシュプラグイン同士の競合：WP RocketとAutoptimizeなど複数の最適化プラグインを併用すると、CSS処理が二重になり予期せぬ挙動が起きます。基本的に1つのキャッシュ・最適化プラグインに絞ることを推奨します。
  • 自前ホスト化後にCSSの更新を忘れる：自前ホスト化したCSSはサードパーティ側が更新されても自動更新されません。バグ修正やセキュリティパッチが必要なケースでは定期的な確認が必要です（ress.cssのような安定版であればリスクは低い）。

まとめ

レンダリングブロックCSSはWordPressの表示速度低下の主要因のひとつですが、解消の方向性は明確です。不要なCSSを読み込まない・本数を減らす・サードパーティ接続を断つ・必要なCSSは非ブロッキングで届けるの4点が柱です。

当サイトでの実測では、ress.min.cssをunpkgから自前ホストへ切り替えるだけでモバイルFCPが44ms改善しました。ツールやプラグインを使えばコーディングなしでも多くの対策が実施できますが、まずPageSpeed Insightsで現状を把握し、優先度の高い対策から一つずつ実施して効果を確認するアプローチが確実です。

Google CoreWebVitals（特にFCP・LCP）は検索順位にも影響するため、レンダリングブロックCSSの解消はSEO改善としても重要な取り組みです。定期的に計測し、新たに追加されるプラグインやテーマのCSSが問題化していないかを継続的に監視することをお勧めします。

関連記事

AIブログ購読

　
クリスタルメソッドがお届けする
AIブログの更新通知を受け取る

Study about AI

AIについて学ぶ

  • Claude Code 公式ドキュメント完全読解ガイド｜導入判断から運用まで

    Claude Code 公式ドキュメント完全読解ガイド｜導入判断から運用まで

    監修 河合 継（クリスタルメソッド株式会社 代表取締役） AI・ディープラーニングに関する特許16件の発明者。国立がん研究センターとの共同研究や、テレビ番組での...

  • Claude Code ベストプラクティス完全解説｜実装現場で使える設計指針2026

    Claude Code ベストプラクティス完全解説｜実装現場で使える設計指針2026

    監修 河合 継（クリスタルメソッド株式会社 代表取締役） AI・ディープラーニングに関する特許16件の発明者。国立がん研究センターとの共同研究や、テレビ番組での...

  • Claude Code 自動化の実装ガイド――設計・事例・セキュリティを徹底解説

    Claude Code 自動化の実装ガイド――設計・事例・セキュリティを徹底解説

    監修 河合 継（クリスタルメソッド株式会社 代表取締役） AI・ディープラーニングに関する特許16件の発明者。国立がん研究センターとの共同研究や、テレビ番組での...

View more

AIで、業務の生産性を変革しませんか？

無料デモ・資料請求は1分で完了。お気軽にお問い合わせください。

無料デモを試す お問い合わせ