blog

【WordPress高速化②】未使用CSSを消すだけで軽くなる|PurgeCSS実践と落とし穴

使っていないCSSを削るだけで表示は軽くなります。PurgeCSSの手順とやりがちな失敗を実例で解説します。

未使用CSSを削除すると表示速度が劇的に改善する理由

WordPressサイトの表示速度改善を調べていると、必ずといっていいほど「未使用CSSの削除」が登場します。しかし「CSSを削除して本当に大丈夫なの?」「どのツールを使えばいいの?」と迷っている方も多いはずです。

この記事について

本記事は、自社サイト crystal-method.com(WordPress運用) で実際に表示速度を改善した一次データに基づきます(モバイルLCP 8,144ms→1,700ms を実測。Google Chrome + Puppeteer/モバイル相当スロットル・5回中央値)。
発行:クリスタルメソッド株式会社(代表取締役 河合 継) | 運営会社 | 編集方針

実際に弊社がTailwind CSSのCDN版(約250KB)にPurgeCSSを適用したところ、CSSファイルのサイズが19KBまで圧縮(約92%削減)されました。Google PageSpeed InsightsのLCPスコアも大幅に改善し、未使用CSSの削除がいかに効果的かを身をもって体験しています。

この記事では、未使用CSSが表示速度に与える影響のメカニズムから、WordPress上での具体的な削除方法、そして「消してはいけないCSSを誤って削除してしまう」罠の回避策まで、実践ベースで詳しく解説します。

未使用CSSがサイト表示速度を遅くする仕組み

未使用CSSを削除すると表示速度が改善する理由は、ブラウザのレンダリングプロセスに深く関係しています。CSSはHTMLと異なり、レンダーブロッキングリソースとして扱われます。つまりブラウザはCSSファイルを完全にダウンロード・パースし終えるまで、画面への描画(レンダリング)を一切開始しません。

ブラウザのレンダリングプロセスとCSSの関係
HTMLパース
CSSダウンロード
&パース
(ここでブロック)
レンダーツリー
構築
画面描画
(ペイント)

CSSファイルが大きいほど「ブロック時間」が長くなり、FCP・LCPが悪化する

未使用CSSが表示速度を悪化させる具体的な経路は以下の3点です。

  • ダウンロード時間の増加:ファイルサイズが大きいほど転送に時間がかかり、レンダリング開始が遅れる
  • パース時間の増加:ブラウザはCSSを1行ずつ解析するため、不要なルールが多いほどCPU処理時間が増える
  • CSSOM構築の肥大化:使われないセレクタもすべてメモリ上のCSSOMツリーに展開されるため、メモリ消費が増加する

Google PageSpeed Insightsの監査項目「使用されていないCSSの削除」は、このレンダーブロッキング時間に直接影響します。Lighthouseの計測では、未使用CSSの削除によるFCP(First Contentful Paint)の改善が平均0.3〜0.7秒、LCP改善は最大1秒以上になるケースも報告されています。

あなたのサイトの未使用CSSを計測する方法

削除作業を始める前に、現状を正確に把握することが重要です。闇雲に作業を始めると「何が改善したのか」が分からなくなります。

Chrome DevToolsのCoverageパネルで可視化する

最もシンプルで正確な計測方法はChrome DevToolsのCoverageパネルです。実際のブラウザ動作を記録するため、JavaScriptで動的に付与されるクラスも捕捉できます。

  1. Chromeでサイトを開き、F12でDevToolsを起動
  2. 右上のメニュー(⋮)→「More tools」→「Coverage」を選択
  3. 「Start instrumenting coverage and reload page」ボタン(録画アイコン)をクリック
  4. ページが読み込まれたら、サイト内のリンクをクリックしてインタラクションを一通り実施
  5. カバレッジ一覧でCSSファイルの「Unused Bytes」と「Usage visualization」(赤いバー)を確認

ここで赤いバーが長いほど未使用CSSの割合が高いファイルです。未使用率が70%を超えている場合は、削除による改善効果が大きいと判断できます。

Google PageSpeed Insightsで現状スコアを記録する

作業前後の比較のために、PageSpeed Insightsでモバイル・デスクトップ両方のスコアを記録しておきます。特に「使用されていないCSSの削除」の節約可能バイト数と推定節約時間を控えておくと、作業後の改善幅が明確になります。

WordPressで未使用CSSを削除する3つのアプローチ

実際の削除方法は、使用しているテーマや開発環境によって最適な手段が異なります。以下の3アプローチを状況に応じて選択してください。

アプローチ 向いている状況 難易度 削減効果
①プラグイン(Asset CleanUp等) コードを書けない/テーマに触れたくない 中〜高
②PurgeCSS(ビルドツール組み込み) フレームワーク系CSS(Tailwind等)を使用 非常に高
③Critical CSS+非同期読み込み LCP・FCPを最優先で改善したい 中〜高 高(初期表示に特化)

アプローチ①:プラグインで不要CSSを読み込まないようにする

WordPressでは、プラグインやテーマが全ページで一括してCSSを読み込むため、そのページで使われていないCSSが大量に含まれます。Asset CleanUp: Page Speed Booster(または同等の「Perfmatters」など)を使うと、ページ単位でCSSファイルの読み込みをオン・オフできます。

  1. Asset CleanUpをインストール・有効化する
  2. WordPressの各ページ編集画面下部に表示される「Asset CleanUp」セクションを開く
  3. DevToolsのCoverageで未使用と確認したCSSファイルのチェックを外し「Unload on this page」に設定
  4. フロントエンドで表示を確認し、レイアウト崩れがないか目視チェック
  5. PageSpeed Insightsで再計測し、改善を確認する

この方法の利点はファイル自体を削除しないため、元に戻すのが容易であることです。ただし、未使用のルールを削除するのではなく「読み込まない」という制御なので、ファイル自体が肥大化しているケースには次のアプローチが必要です。

アプローチ②:PurgeCSSでCSSファイルそのものを最適化する

TailwindやBootstrapのようなユーティリティファーストCSSフレームワーク、または自社制作のCSSが肥大化している場合は、PurgeCSSがもっとも強力な解決策です。冒頭で触れた弊社の事例(250KB→19KB)もこのアプローチによるものです。

PurgeCSSはHTMLファイルやJavaScriptファイルをスキャンして「実際に使われているCSSクラス名・セレクタ」を抽出し、それ以外のルールを削除します。

PurgeCSSの基本的な設定例(webpack / PostCSS環境)
// postcss.config.js
const purgecss = require('@fullhuman/postcss-purgecss');

module.exports = {
  plugins: [
    purgecss({
      content: [
        './src/**/*.html',
        './src/**/*.js',
        './src/**/*.php',   // WordPressテーマのPHPファイル
      ],
      defaultExtractor: content =>
        content.match(/[\w-/:]+(?<!:)/g) || [],
      safelist: [
        /^wp-/,          // WordPress標準クラスを保護
        /^woocommerce/,  // WooCommerceクラスを保護(使用時)
        /^is-/,
        /^has-/,
      ],
    }),
  ],
};

Tailwind CSSのバージョン3以降はJITモード(Just-In-Time)が標準となり、ビルド時に使用クラスのみを生成する仕組みが内包されています。CDN経由での利用を本番環境に使っている場合は、必ずビルドプロセスを導入してください。

アプローチ③:Critical CSSの抽出と非同期読み込み

ファーストビューに必要なCSSのみをインラインで埋め込み、残りのCSSを非同期で読み込む手法です。LCPとFCPの改善に直接効きます。

  1. Critical CSS抽出:critical(npm)やPenthouseを使い、ファーストビューに必要なCSSだけを抽出する
  2. インライン埋め込み:抽出したCSSを<style>タグとして<head>内に直接記述(2〜8KB程度が目安)
  3. 残りのCSSを遅延読み込み:<link rel="preload" as="style" onload="this.onload=null;this.rel='stylesheet'">パターンで非同期化

WordPressではAutoptimizeプラグインがCritical CSS生成・インライン化・非同期読み込みを一括で担える実績のある選択肢です。ただし設定が複雑なため、ステージング環境での検証を強く推奨します。

PurgeCSSの「罠」と誤削除を防ぐ方法

PurgeCSSは強力な反面、設定を誤ると動的に付与されるクラス名を「未使用」と判定して削除してしまうという代表的な罠があります。弊社でもこの罠を一度経験しており、本番環境で特定のホバーエフェクトが消えるという問題が発生しました。

動的クラス名が消える問題

JavaScriptでelement.classList.add('is-active')のようにクラスを動的に付与している場合、そのクラス名はHTML・PHPファイル内に静的には存在しません。PurgeCSSのデフォルト設定では「使われていない」と判断されて削除されます。

具体的に削除されやすいケース:

  • モーダル表示時に付与されるis-openmodal-visibleなどのクラス
  • スクロールイベントで付与されるfixedsticky-activeなど
  • WordPressのメニュー展開時のsub-menu-openなど
  • WooCommerce、Contact Form 7、Yoastなどのプラグインが動的に使うクラス
  • Gutenbergブロックエディタが付与するwp-block-*系クラス

safelistで保護する(最重要の対策)

safelist設定に削除したくないクラスのパターンを正規表現で指定することが最も確実な対策です。

safelist: [
  // 文字列で完全一致指定
  'is-active',
  'is-open',
  'modal-visible',

  // 正規表現でパターン指定(推奨)
  /^wp-/,
  /^wc-/,         // WooCommerce
  /^fluentform/, // FluentForms
  /^is-/,
  /^has-/,
  /^active/,

  // deep: trueでネストしたセレクタも保護
  { pattern: /^slick-/, deep: true, greedy: false },
]

extractor(抽出器)のカスタマイズ

PurgeCSSのデフォルト抽出器は[\w-]+パターンでクラス名をスキャンしますが、Tailwindのsm:text-lghover:bg-blue-500のようなコロン・スラッシュを含むユーティリティクラスは検出できません。Tailwind公式のPurge設定例が提供する[\w-/:]+(?<!:)の正規表現を使うことで、これらのクラスも正しく検出されます。

また、JavaScriptでテンプレートリテラルを使って動的にクラス名を構築している場合(例:`bg-${color}-500`)、PurgeCSSはそのクラスを検出できません。この場合はクラス名を文字列として静的に記述するか、safelistに追加するかのどちらかで対処します。

本番適用前の確認フロー

PurgeCSS適用の安全な確認フロー
Step 1
ステージング環境で
PurgeCSS適用

Step 2
全ページ・全インタラクションを
目視チェック

Step 3
CSSファイルサイズと
PageSpeedスコア計測

Step 4
問題なければ
本番へデプロイ

フレームワーク別の未使用CSS削除戦略

Tailwind CSS

Tailwind v3以降はJITモードが標準で、tailwind.config.jscontent配列に対象ファイルのパスを指定するだけで自動的に未使用クラスが除去されます。WordPressテーマで使う場合は./src/**/*.php./src/**/*.jsを含めてください。CDN経由での利用は開発・プロトタイプ用途に限定し、本番では必ずビルドプロセスを経由させることが鉄則です。

Bootstrap

BootstrapはSCSSソースを使いカスタムビルドする方法と、PurgeCSSを後処理で適用する方法の2択です。Bootstrapのコンポーネントを少数しか使っていない場合は、必要なコンポーネントのSCSSのみをインポートするカスタムビルドの方が確実です。モーダル・カルーセルなど使っていないJSコンポーネントに依存するCSSは、ビルド時に除外できます。

テーマ付属CSS(Twenty Twenty-FourなどWordPress標準テーマ)

ブロックテーマのCSS(style.cssglobal-styles-inline-css等)は、WordPressのブロックエディタがページ内のブロック構成に応じて動的に判断して出力します。WordPress 6.1以降では「ブロックに必要なスタイルのみ動的に読み込む」という仕組み(Block Style Variations & Per-Block Stylesheets)が改善され続けています。クラシックテーマの場合は、子テーマのfunctions.phpで親テーマの不要なCSSスタイルシートのデキュー(wp_dequeue_style)を検討してください。

未使用CSS削除と合わせて行うべき最適化

未使用CSSの削除は表示速度改善の重要な一手ですが、単体で行うよりも関連する最適化と組み合わせることで相乗効果が得られます。

最適化手法 CSSとの関連 推奨ツール(WordPress)
CSSミニファイ コメント・空白削除でさらに縮小 Autoptimize、LiteSpeed Cache
Gzip/Brotli圧縮 転送サイズをさらに60〜80%削減 サーバー設定(.htaccess / nginx.conf)
レンダーブロッキングJS削減 CSSと同様にレンダリングをブロック WP Rocket、Autoptimize
ブラウザキャッシュ設定 最適化済みCSSを再ダウンロードさせない W3 Total Cache、LiteSpeed Cache
未使用JavaScriptの削除 JSもレンダーブロッキングになりうる Asset CleanUp、Perfmatters
CSSの構造を抽象的に表したクリーンなコードドキュメントのイメージ
CSSの構造を抽象的に表したクリーンなコードドキュメントのイメージ

よくある疑問と注意点

「CSSを削除したらスマートフォンでレイアウトが崩れた」

レスポンシブ対応のメディアクエリが削除された可能性があります。PurgeCSSは@mediaクエリ内のルールも削除対象にするため、DevToolsのCoverageでデスクトップ幅のみで測定してPurgeCSSを適用すると、モバイル用のスタイルが丸ごと消えることがあります。Coverage測定時はモバイルエミュレーションも有効にして記録するか、複数解像度で繰り返しインタラクションを実施してから適用してください。

「WordPressのプラグインを更新したらCSSが壊れた」

プラグイン更新でクラス名が変わったり、新しいクラスが追加されたりすると、事前にPurgeCSSで削除済みのクラスが復活できず表示が崩れます。PurgeCSSを使う場合はCI/CDパイプラインに組み込み、コンテンツ更新やプラグイン更新のたびに再ビルドする仕組みを作ることが重要です。一度設定して終わりではなく、継続的なメンテナンスが必要な点を念頭に置いてください。

「プラグイン方式(Asset CleanUp等)はページ数が多いと設定が大変」

ページ数が多いサイトでは「テンプレート単位で設定」(投稿一覧、シングル投稿、固定ページなど)ができるプラグインが有効です。Asset CleanUpはPostタイプ単位やテンプレートファイル単位での一括設定に対応しています。またPerfmattersも同様の機能を持ち、軽量な設計で人気があります。

実際の改善数値と作業の優先順位

弊社での実経験をもとに、CSS削除による改善効果の目安をまとめます。

状況 削減前 削減後 主な改善指標
Tailwind CDN使用(弊社実例) 250KB 19KB(92%削減) FCP・LCP大幅改善
Bootstrap全体読み込み ~190KB 20〜50KB程度 レンダーブロック時間削減
WP標準テーマ+複数プラグイン 合計150〜300KB 50〜100KB程度 TBT・TTI改善

作業の優先順位としては、まず「未使用CSSの割合が70%以上」かつ「ファイルサイズが100KB以上」のCSSファイルから手をつけるのが費用対効果の高いアプローチです。DevToolsのCoverageパネルで確認し、赤いバーが長いファイルを優先してください。

ブラウザでページが高速に表示されるようになった状態を表すミニマリストなイラスト
ブラウザでページが高速に表示されるようになった状態を表すミニマリストなイラスト

まとめ

未使用CSSの削除は、WordPressサイトの表示速度改善において確実に効果が出る施策です。ポイントを整理します。

  • CSSはレンダーブロッキングリソースであり、ファイルサイズを削減するとFCP・LCPが直接改善する
  • まずChrome DevToolsのCoverageパネルで未使用率を計測し、優先順位を決める
  • WordPressでの削除手段はプラグイン(Asset CleanUp等)・PurgeCSS・Critical CSSの3アプローチがあり、状況に応じて選択する
  • PurgeCSSは非常に効果的(弊社実績250KB→19KB)だが、動的クラス名の誤削除という罠に注意し、safelistを適切に設定する
  • Tailwind CSS v3以降はJITモードで自動対応済みだが、本番環境でCDN版を使うのは厳禁
  • 本番適用前にかならずステージング環境で全ページ・全インタラクションを目視確認する
  • CSSミニファイ、Gzip/Brotli圧縮、ブラウザキャッシュと組み合わせることで相乗効果が得られる

表示速度は検索順位にも直結する重要な要素です。一度正しく設定すれば長期的に効果が持続する未使用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