【WordPress高速化④】ブロックエディタの不要CSSを削って軽くする

ブロックエディタが出力する不要なCSSを止めて軽量化する手順を解説します。

WordPressブロックエディタのCSSを削除・最適化してサイトを高速化する完全ガイド

WordPressのブロックエディタ（Gutenberg）を使うと、投稿・固定ページの編集体験は格段に向上します。しかしその裏で、使っていないブロックのCSSファイルまで毎ページ読み込まれるという問題が発生します。コアブロック用スタイルシート「wp-block-library」は無圧縮で約112KBに達し、特にモバイル回線では最初のコンテンツ描画（FCP）を大きく遅らせる要因になります。

本記事では、ブロックエディタが読み込むCSSの仕組みを正確に把握したうえで、丸ごと削除・条件付き削除・分割インライン化という三段階のアプローチを手順・コード付きで解説します。「とりあえず全部消す」だけでは表示崩れのリスクがあるため、安全に進めるための回帰テスト手順まで網羅しています。

ブロックエディタが読み込むCSSの全体像

対策を打つ前に、何がどれだけ読み込まれているかを把握することが最重要です。ブロックエディタ関連のCSSは大きく三種類に分かれます。

スタイルシートのハンドル名	内容	無圧縮サイズの目安	登録場所
wp-block-library	全コアブロック共通のスタイル	約112KB	WordPressコア
wp-block-library-theme	テーマ補完用スタイル（色・余白など）	約10KB	WordPressコア
global-styles（wp-global-styles）	theme.jsonで定義したグローバルスタイル	数KB〜数十KB（テーマ依存）	WordPressコア＋テーマ
classic-theme-styles	クラシックテーマ向けの互換スタイル	約7KB	WordPressコア（WP 6.1以降）
各ブロック個別CSS	columns・cover・button等それぞれのスタイル	数KB/ブロック	WordPressコア（分割ロード時）

実測で特に問題になるのはwp-block-libraryです。圧縮転送してもレンダリングブロッキングリソースとして計上され、FCPの遅延に直結します。Chrome DevToolsのCoverageタブで確認すると、シンプルな記事ページでは使用率が20〜30%程度にとどまることも珍しくありません。

三段階のアプローチ：どの方法を選ぶべきか

削除・最適化の方法は「サイトでブロックをどう使っているか」によって異なります。まず方針を決めてから実装に入りましょう。

実際のサイト運用では、トップページや一覧ページにcolumns・cover・buttonなどのブロックが使われているケースが多く、「一枚岩（wp-block-library全体）の丸ごと削除」は現実的でないことがほとんどです。そのため本記事では❸の分割インライン化を中心に、❶❷の方法も合わせて解説します。

【方法❶】wp-block-libraryを完全に削除する

最もシンプルな方法ですが、コアブロックを一切使っていないサイト限定の手段です。functions.phpに以下を追記します。

add_action( 'wp_enqueue_scripts', function() {
    // コアブロックCSSを削除
    wp_dequeue_style( 'wp-block-library' );
    // テーマ補完CSSも削除
    wp_dequeue_style( 'wp-block-library-theme' );
    // WP 6.1以降のクラシックテーマ互換スタイルも削除
    wp_dequeue_style( 'classic-theme-styles' );
}, 20 );

優先度を20にしているのは、WordPressコアが10前後で登録するため、それより後で実行して確実にキューから外すためです。

注意点：この方法を適用した後、必ずサイト全体を目視確認してください。Gallery・Quote・Tableなど見た目に依存するブロックは、スタイルが消えると崩れます。また、プラグインが内部でコアブロックを使っている場合も影響を受けます。

【方法❷】特定ページ種別のみCSSを削除する（条件付き削除）

「記事ページはブロックを使うが、トップや一覧は使っていない」という場合に有効です。WordPress標準の条件分岐タグを活用します。

add_action( 'wp_enqueue_scripts', function() {
    // シングル投稿・固定ページ以外ではブロックCSSを削除
    if ( ! is_singular() ) {
        wp_dequeue_style( 'wp-block-library' );
        wp_dequeue_style( 'wp-block-library-theme' );
        wp_dequeue_style( 'classic-theme-styles' );
    }
}, 20 );

さらに細かく制御したい場合は、is_front_page()・is_archive()・is_category()などを組み合わせて削除対象を絞り込めます。

add_action( 'wp_enqueue_scripts', function() {
    // トップページとアーカイブページのみ削除
    if ( is_front_page() || is_archive() || is_category() || is_tag() ) {
        wp_dequeue_style( 'wp-block-library' );
        wp_dequeue_style( 'wp-block-library-theme' );
    }
}, 20 );

条件付き削除は「削除したページで本当にブロックを使っていないか」のチェックが必要です。ウィジェットエリアやショートコード経由でブロックが差し込まれていると、この方法でも崩れが発生します。

【方法❸】should_load_separate_core_block_assetsで分割インライン化する（推奨）

WordPressはバージョン5.8から、コアブロックCSSをページで実際に使われているブロックごとに分割して読み込む仕組みを内部に持っています。これを有効化するフィルターがshould_load_separate_core_block_assetsです。

通常のwp-block-library（一枚岩・約112KB）を全ページに読み込む代わりに、そのページで使われているブロック分のCSSだけをインライン出力し、合計約30KBまで削減できます。外部CSSリクエスト自体もゼロになるため、レンダリングブロッキングの問題も解消します。

有効化のコード

add_filter( 'should_load_separate_core_block_assets', '__return_true' );

たったこの一行をfunctions.phpに追記するだけです。WordPressがページをレンダリングする際に使用ブロックを走査し、必要なCSSのみを<style>タグとしてHTMLに埋め込みます。

動作の仕組みをビジュアルで確認

注意：WordPress 6.5以降の挙動変化

WordPress 6.5からブロックテーマ環境ではデフォルトで分割ロードに近い挙動が取られるよう改善されました。ただしクラシックテーマではフィルターによる明示的な有効化が依然として必要です。使用しているテーマがブロックテーマ（theme.jsonを持つ）かクラシックテーマかを確認してから適用してください。

global-styles（wp-global-styles）の削除・無効化

ブロックテーマを使っている場合、theme.jsonに基づいて生成されるグローバルスタイルも無視できないサイズになることがあります。このスタイルはWordPressコアがwp_add_global_styles_for_blocks()などで動的生成するため、ファイルとして存在しません。

クラシックテーマでグローバルスタイルが不要な場合は以下で無効化できます。

add_action( 'wp_enqueue_scripts', function() {
    wp_dequeue_style( 'global-styles' );
    // WP 6.2以降はハンドル名が変わる場合があるため両方指定
    wp_dequeue_style( 'wp-global-styles' );
}, 20 );

ブロックテーマではこの操作は非推奨です。theme.jsonで定義したフォントサイズ・色・スペーシングが全て機能しなくなります。クラシックテーマで独自CSSに完全移行しているケースに限って検討してください。

プラグインを使う場合の選択肢と注意点

コードを書かずに対処したい場合、いくつかのプラグインがブロックCSSの制御機能を持っています。代表的なものの特徴を整理します。

プラグイン名	主な機能	適したケース	注意点
Asset CleanUp: Page Speed Booster	スクリプト・スタイルをURL単位で無効化	細かいページごとの制御	設定が複雑で大規模サイトでは管理コスト増
Perfmatters	ブロックCSSの一括無効化・スクリプト管理	有料でも手軽に対処したい場合	有料（年額）
WP Rocket	CSSの遅延読み込み・結合・ミニファイ	総合的な速度改善	有料。ブロックCSS削除は個別設定が必要
Autoptimize	CSS・JSの結合・ミニファイ・インライン化	無料で結合・縮小だけしたい場合	結合はレンダリングブロックが残る場合あり

プラグインはWordPressのバージョンアップで互換性が崩れるリスクがあります。コアに近い処理（スタイルのキュー操作）は、できるだけfunctions.phpへの直接記述かサイト固有のプラグイン化が長期メンテナンス上の安全策です。

実装後の回帰テスト：崩れを見逃さないチェック方法

CSS削除・最適化は必ず表示崩れのリスクを伴います。本番環境に適用する前にステージング環境でテストし、以下の手順で回帰チェックを行ってください。

チェック手順

1. 全テンプレートを洗い出す：トップ・カテゴリ・タグ・投稿一覧・投稿詳細・固定ページ・404・検索結果の各テンプレートをリストアップする。
2. PCとモバイル幅の両方で目視確認：Chrome DevToolsのデバイスシミュレーターを使い、375px（スマートフォン）・768px（タブレット）・1280px（デスクトップ）の3幅で全テンプレートを確認する。
3. 使用中のコアブロックを特定して確認：Paragraph・Heading・Image・List・Gallery・Quote・Table・Columns・Cover・Button・Group・Separatorなど、サイトで実際に使っているブロックが含まれるページを必ず目視する。
4. Coverageで未使用CSS率を再測定：Chrome DevTools → Moretools → Coverageタブでページを再読み込みし、適用前後のCSS使用率を比較する。未使用率が大幅に下がっていれば成功。
5. PageSpeed InsightsでFCPを計測：モバイルスコアでFCP・TBT・LCPが改善しているか確認する。

効果の見込みと現実的な期待値

ブロックCSS最適化の効果は「大幅改善」というよりも確実に積み上がる小幅な改善です。単体の施策として過大な期待は禁物ですが、LCP・FCPの改善とスコア向上への貢献は実測で確認できます。

施策	転送量削減の目安	FCP改善の目安（モバイル）	リスク
完全削除（wp-block-library）	約112KB削減	100〜300ms程度	高（表示崩れ・プラグイン干渉）
条件付き削除（一覧・トップのみ）	対象ページで約112KB削減	100〜250ms程度	中（削除対象ページの使用確認が必要）
分割インライン化	使用ブロック分のみ（約30KB相当）	50〜150ms程度	低（動的検出・崩れにくい）

数値は回線速度・サーバーレスポンス・CDNの有無によって変動します。「効果が小幅」であっても、サーバーレスポンス改善・画像最適化・JavaScript削減といった他の施策と組み合わせることで、PageSpeed Insightsのモバイルスコアを10〜20点押し上げることは十分現実的です。

よくある失敗パターンと対処法

失敗1：wp_dequeue_styleの優先度が低すぎる

add_action( 'wp_enqueue_scripts', ... )のデフォルト優先度は10です。コアが同じ優先度で登録するため、優先度10でwp_dequeue_styleを実行しても機能しないことがあります。優先度を20以上に設定するのが確実です。

失敗2：管理バーが表示される状態でフロント確認している

ログイン状態でサイトを確認すると、管理バー用CSSが追加読み込みされます。実際のユーザー環境を確認するにはシークレットウィンドウ（プライベートブラウズ）でテストしてください。

失敗3：キャッシュが残って変化が見えない

WordPress・サーバー・CDN・ブラウザの各レイヤーにキャッシュが存在します。変更後はキャッシュを全レイヤーでクリアし、Ctrl+Shift+Rのハードリロードで確認します。

失敗4：子テーマに記述せずに親テーマを直接編集する

テーマのfunctions.phpを直接編集すると、テーマ更新時にコードが消えます。必ず子テーマのfunctions.phpに記述するか、サイト固有の小さなプラグインとして実装してください。

失敗5：プラグインが出力するブロックCSSへの干渉

WooCommerceやContact Form 7などのプラグインもブロック対応のCSSを個別のハンドルで登録することがあります。wp-block-libraryを削除してもこれらのCSS（例：wc-blocks-style）は残ります。全消しを狙うなら個別のハンドルを調査し、それぞれwp_dequeue_styleする必要があります。

functions.phpへの実装コードまとめ

以下に、最もリスクが低くて効果的な「分割インライン化＋補完CSS削除」の組み合わせコードをまとめます。このコードを子テーマのfunctions.phpに追記するのが、多くのサイトにとって現実解です。

/**
 * ブロックエディタCSSの最適化
 * 1. コアブロックCSSを使用ブロック分のみ分割インライン化
 * 2. テーマ補完CSS（wp-block-library-theme）を削除
 * 3. クラシックテーマ向け互換スタイルを削除（クラシックテーマのみ）
 */

// ❸ 分割インライン化を有効化（最重要）
add_filter( 'should_load_separate_core_block_assets', '__return_true' );

// テーマ補完CSSとクラシック互換スタイルの削除
add_action( 'wp_enqueue_scripts', function() {
    wp_dequeue_style( 'wp-block-library-theme' );
    // クラシックテーマのみ以下を有効化（ブロックテーマではコメントアウト）
    wp_dequeue_style( 'classic-theme-styles' );
}, 20 );

上記だけでも転送サイズは大幅に下がります。さらに踏み込んでwp-block-library自体を削除する場合は、必ずステージングで全テンプレートの目視確認を完了してから本番に適用してください。

まとめ

WordPressブロックエディタのCSS最適化は、「何を削除できるかを正確に把握する → リスクに応じた方法を選ぶ → 回帰テストで確認する」という順序が重要です。

• wp-block-library（無圧縮約112KB）はFCPを遅らせる主要因であり、改善対象として最優先に検討する
• ブロックを多用するサイトでは、should_load_separate_core_block_assetsによる分割インライン化が最も安全かつ現実的
• ブロックを使っていないページ・テーマでは条件付き削除または完全削除も有効だが、回帰リスクの事前確認が必須
• 効果は「小幅だが無害」な積み上げ型。サーバー応答改善・画像最適化などと組み合わせて使うことで真価を発揮する
• 実装はかならず子テーマのfunctions.phpまたはサイト固有プラグインに記述し、テーマ更新で消えないようにする

表示速度の改善は単一の施策で劇的に変わるものではありませんが、ブロックCSSの最適化はリスクが低く確実に効く施策です。Core Web Vitalsのスコア改善とユーザー体験向上のため、まずはshould_load_separate_core_block_assetsの一行から着手してみてください。

関連記事

• wordpress 表示速度 改善とは（総合ガイド）
• core web vitals lcp 改善
• wordpress 画像 webp 遅延読み込み
• 未使用css 削除 表示速度
• wordpress gtm 遅延 読み込み