「使用していないCSSの削減」原因特定から改善方法を解説

2026年1月21日

PageSpeed Insightsで「使用していないCSSの削減」と出たものの、何を消せばよいか分からず放置していませんか？

未使用CSSは転送量だけでなく、解析・適用処理も増やし初期表示を遅らせます。

本記事では、DevToolsのカバレッジなどを使って“原因のCSS”を特定し、削除・分割・遅延読み込み（クリティカルCSS）まで、表示崩れを避けながら改善する手順を解説します。

使用していないCSSの削減とは？

「使用していないCSSの削減」とは、ページで実際に使われていないCSSルール（セレクタやプロパティ）を、削除・分割・遅延読み込みなどで配信量を減らし、表示速度を改善する最適化です。

未使用CSSが多いと、ブラウザは不要なCSSまでダウンロードして解析・適用候補として処理するため、初期表示が遅くなりやすく、PageSpeed Insightsで「使用していない CSS の削減」として指摘されます。

PageSpeed InsightsでURLを分析すると「パフォーマンスの問題を診断する＞インサイト」の箇所に表示されます。

上記画像の赤枠部分で削減余地のあるサイズが表示されます。

青枠の部分は削減ができる可能性のあるファイルです。

黄色枠はそのファイルの転送サイズと推定の削減サイズが記載されています。

スタイルシートから使用していないルールを削除して、スクロールせずに見える範囲のコンテンツで使用されていない CSS の読み込みを遅らせると、ネットワークの通信量を減らすことができます。

と言った記載があり、主に使用されていないCSSの削減と、ファーストビュー以外のCSSファイルの読み込みタイミングを遅らせるような改善策が求められます。

未使用CSSがあると表示が遅くなる理由

未使用CSSがあると表示が遅くなる主因は、不要なCSSまでダウンロード→解析（パース）→CSSOM生成→描画（レンダリング）に関わる処理が増えるためです。

CSSはページ表示に必須のリソースになりやすく、ファイルが大きいほど通信時間が伸び、ブラウザ側も大量のセレクタ照合を行うため初期表示が重くなります。

さらに、実際には使わないルールでも「読んで評価する」コストは発生し、結果として表示開始が遅延します。

PageSpeed Insightsで「使用していない CSS の削減」を推奨するのは、こうした転送量と処理負荷のムダを減らして表示速度を改善できるからです。

「未使用」と判定される代表パターン

主に未使用と判断される原因は下記となります。

共通CSSの肥大化
テーマ・プラグインによるCSS追加
フレームワーク導入

これらが典型な例です。

共通CSSは「全ページで読み込む」前提のため、ページごとに使わないコンポーネントの装飾まで抱え込みやすく、未使用判定が増えます。

テーマやプラグインは機能単位でCSSを同梱し、実際にその機能を使っていないページでも読み込まれてしまいがちです。

さらにBootstrap等のフレームワークは汎用クラスを大量に含むため、使っているのは一部でも残りは未使用として計測されやすくなります。

結果としてCSSが増え、評価上「未使用」が目立ちます。

PageSpeed Insightsの指摘は“ページ単位の観測”である点に注意

PageSpeed Insightsの評価は、そのURLを読み込んだ瞬間の“ページ単位の観測”である点に注意が必要です。

たとえば、別ページで使う共通コンポーネント用CSS、モーダル・アコーディオンなど操作後に適用されるCSS、特定幅のメディアクエリ、JSで後付けされるclass向けCSSは、計測時点では発火せず未使用扱いになりやすいです。

つまり「サイト全体で不要」とは限らず、まず対象ページの表示条件（初期表示・画面幅・操作有無）を揃えて評価し、ページ別に分割・遅延読み込みを検討するのが改善の近道です。

使用していないCSSを探す方法

まず簡単にざっくり確認する場合は、PageSpeed Insightsで確認するのが簡単です。

PageSpeed InsightsにURLを入れて「使用していないCSSの削減」の項目を確認します。

どこのファイルが対象となっているかをここでチェックしておきます。（青枠部分）

また、各ファイルどのくらい削減できそうかも確認しておくといいでしょう。（黄色枠部分）

詳しくみたい場合は DevTools「カバレッジ」

詳しく確認したい場合は、DevToolsの「カバレッジ」で確認を行います。

①確認したいページでDevToolsを開き「カバレッジ」を開きます。

上記画像を参考に赤枠の部分でカバレッジを探し選択します。

黄色枠の部分を確認し「使用していないバイト」が大きいファイルは使用していない部分が大きいことを示します。

「使用状況の可視化」で赤くなっている部分が使用しいていない割合を示しているので、赤い部分が多いほど使用率は低いことになります。

更に対象のファイルをクリックすると、上部にファイルの中身も確認ができるようになります。

上記画像の黄色い枠にある赤い部分は使用していないソースとなっていることがわかります。

詳しくみたい場合は、DevToolsでここまで確認することができます。

「使用していないCSSの削減」の改善手順

上記で「使用していないCSS」を探す方法を紹介しました。

ここからは対象となるCSSを削減する手順を紹介しますが、まずは下記を覚えておきましょう。

基本的に削減する方法は、削除、分割、遅延の３パターンとなります。

対応する場合は、削除なのか、分割なのか、遅延なのかを判断してから着手していきます。

下記で詳しく説明していきます。

削除する場合のケースと方法

削除する場合は「そのページだけで未使用」ではなく「サイト全体でも不要」なCSSに絞ります。

特に

他のページで使用されているソースではないか？
操作をした後に使用されるようなソースではないか？

などを入念にチェック・確認します。

具体的に、まずDevToolsのカバレッジで未使用箇所を洗い出します。

対象CSSが

退役したclass/HTMLの名残
置き換え済みコンポーネント
使っていないプラグイン/機能の同梱CSS
フレームワークの未使用ユーティリティ

のどれか判定します。

削除方法は、該当セレクタを検索して参照箇所が無いことを確認し、ページ種別（記事/固定/一覧）や主要UI操作（モーダル等）も含め再計測します。

問題なければCSSから削除し、PRで段階リリース＋監視（レイアウト崩れ）を行います。

ミス防止のためにも、一気に全て削除してしまうのではなく段階的に削除して実際の動作を確認しながら進めるのがおすすめです。

分割する場合のケースと方法

分割するのは「全体で不要とは言えないが、当該ページの初期表示では使われないCSS」が多い場合です。

分割を推奨ケース例

共通CSSに全ページ分のコンポーネントが入っている
記事・LPなどページ種別で見た目が大きく違う
モーダル/タブ等“操作後に必要”なCSSが多いケース

手順として、まずはDevToolsのカバレッジでページ初期表示の未使用を確認します。

共通（ベース）とページ種別/機能別（例：記事・フォーム・管理バー等）にCSSファイルを分け、必要なページだけで読み込ませます。

上記画像はあくまで例ですが黄色枠になっている部分はファーストビュー表示時点では使用されていないCSSと判断できます。

これがモーダルなど、操作時に必要なCSSだった場合は、別のCSSファイルに分けましょう。

ということになります。

さらに操作後に必要な分は遅延読み込みにし、再計測で未使用率と表示崩れを確認します。

なおカバレッジは未使用箇所の可視化に使えます。

遅延する場合のケースと方法

遅延（defer）に向くのは「全体では必要だが初期表示（Above the Fold）では不要」なCSSが多いケースです。

遅延を推奨ケース例

モーダル/アコーディオン内部など
下層までスクロールしないと出ないUI

まずカバレッジで初期表示に必要な“内部CSS”を抽出して<style>でheadにインライン化します。

例ですが上記の画像の場合は青枠の#headerのCSSがページのヘッダーで使用されています。

こういったソースを内部CSSとして、HTMLのheadに直接入力していきます。

（こちらは例なので、#header以外にも使用されているCSSを探して追加する必要があります）

残りはrel="preload"を活用し非同期で後読みします。

また、読み込みを遅らせてOKなCSSはbodyに入れることで、レンダリングブロックも防ぐことができます。

ソースのイメージ例です。

<head>
  <!-- 1) 初期表示に必要な最小CSS（クリティカルCSS）をインライン -->
  <style>
    body{margin:0;font-family:system-ui,-apple-system,"Segoe UI",sans-serif}
    header{padding:16px;border-bottom:1px solid #eee}
    main{padding:16px}
  </style>
</head>

<body>
  <!-- 2) 残りのCSSはbodyでpreload→読み込み後にstylesheet化 -->
  <link rel="preload" href="/assets/app.css" as="style"
        onload="this.onload=null;this.rel='stylesheet'">
  <noscript><link rel="stylesheet" href="/assets/app.css"></noscript>
</body>

こちら参考に設定してみましょう。

参考記事：rel="preload"とは・レンダリングブロック

【WordPress編】「使用していないCSSの削減」の対処法

WordPressでは「テーマ＋プラグイン＋エディタ」がCSSを共通読込しがちです。

他のCMSとは違い、プラグインなどの影響で使用してないCSSが増える要因になることが多くあります。

WordPressでよくある「使用していないCSSの削減」の原因

WordPressでよくある原因をまとめると下記のようなものが挙げられます。

全ページ共通のCSSを一括で読み込んでいる（ヘッダー/フッター/ウィジェット/各種ブロック等）
プラグインが機能別CSSを同梱し、該当機能を使わないページでも読み込まれている（フォーム、目次、スライダー等）
カスタムCSS/子テーマの追記が積み重なり、退役したclassや上書きの名残が残る
複数の最適化系プラグインで「結合・圧縮・最適化」が重なる

特にプラグインが増えれば増えるほど、要因になる可能性は高くなります。

WordPressでの対処法

それぞれ対処法をご紹介します。

使用していないプラグインをオフにする

使っていないプラグインは、CSS/JSを無駄に読み込む原因になりやすいため、まず停止→問題なければ削除が基本です。

管理画面［プラグイン］で不要なものを「停止」し、表示崩れ・機能（フォーム/決済/会員等）を主要ページで確認します。

問題がなければ「削除」まで行い、キャッシュ系プラグイン/CDNを使っている場合はキャッシュを削除して再計測。

これだけで「未使用CSS」指摘が減ることがあります。

【難易度高め】削除・分割・遅延を行う

上記で解説している方法を用いて、CSSの削除、分割、遅延の作業を行います。

ただ、プラグインのファイルやテーマのファイルをいじることになるため、制作担当の方やエンジニアの方と相談しながら進めましょう。

他人の作った把握できてないソースをいじることでリスクもあるため注意しながら進めてみてください。

改善効果の確認方法

改善できたかは、同条件で再計測→差分確認で判断します。

PageSpeed InsightsとDevToolsのどちらでも確認はできます。

PageSpeed Insightsの場合

まずは、修正する前の情報を確認しておきましょう。

PageSpeed Insightsの場合は、下記画像の赤枠部分、黄色枠部分の数値を確認しておくようにしてください。

赤枠の「推定される削減サイズ」の数値の変化でページ全体のCSSが削減できたかを確認します。

黄色枠の「転送サイズ・削減サイズ」でファイル別に削減ができているかの確認ができます。

DevToolsの場合

DevToolsの場合も修正前の数値を確認しておくようにしてください。

特に下記画像の「使用していないバイト」の部分のバイト数と割合の部分をチェックしておきましょう。

ここのバイト数や割合が減っていれば削減できている状態となります。

よくある質問

「未使用CSSを削除」してもSEO順位は上がる？

未使用CSSの削除は、直接的にSEO順位を上げる要因ではありません。

しかし、ページの読み込み速度が改善されることで、Googleのコアウェブバイタル（LCP、FID、CLS）のスコアが向上します。

間接的な効果として、ページ速度向上によるユーザー体験の改善が、滞在時間やコンバージョン率の向上につながります。

カバレッジで100% unusedと出るのに実際は使っている

DevToolsのカバレッジツールは、ページ読み込み時点での使用状況のみを判定するため、動的に追加されるクラスやJavaScriptで制御される要素のCSSは「未使用」と判定されます。

例えば、モーダルウィンドウ、ハンバーガーメニュー、タブ切り替えなど、ユーザー操作後に表示される要素のスタイルは誤検知されやすいです。

対策として、実際に削除する前に、該当のCSSセレクタを全ページで検索し、JavaScriptでの動的クラス付与がないか確認しましょう。

また、テスト環境で削除後の動作確認を十分に行い、各種インタラクション要素が正常に表示されるかチェックすることが重要です。

どこまでやればいい？

優先順位は「大きなファイルサイズのCSS」と「全ページ共通で読み込まれるCSS」から着手すべきです。

具体的には、100KB以上のCSSファイルや、BootstrapやFoundationなどのフレームワークで未使用の大部分を削減することが効果的です。

改善の目安として、First Contentful Paint（FCP）が1.8秒以下、Largest Contentful Paint（LCP）が2.5秒以下を目指しましょう。

完璧を求めて全ての未使用CSSを削除する必要はなく、パフォーマンススコアが80点以上、実際のユーザー体験で遅延を感じないレベルであれば十分です。

メンテナンスコストとのバランスを考慮することが重要です。

記事を書いた人

井上寛生

LandingHub 執行役員 / 事業責任者 / 技術責任者

大学院では情報工学を専攻し、修了後に株式会社TeNへ新卒入社。当時は社内唯一のエンジニアながら、開発部門をゼロから立ち上げ、採用・育成を一手に担い、全員が未経験からスタートした精鋭エンジニアチームを組成。2021 年にはWEBサイト高速化プラットフォーム「LandingHub」を立ち上げ、プロダクトオーナー兼事業責任者として企画・開発・グロースを牽引。現在は執行役員として、会社の技術戦略と事業成長の双方をリードしている。

コラム一覧に戻る