【動作確認済み環境】
・WordPress：6.5
・PHP：8.2
・確認日：2026年2月
・テーマ：Twenty Twenty-Four
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。

最近のWeb制作の現場で、「フルサイト編集（FSE）でサイトを構築してほしいけれど、表示速度が落ちないか心配」というご相談をよくいただきます。ブロックエディターでサイト全体を柔軟に編集できるFSEですが、初期設定のまま運用すると不要なCSSやJavaScriptが読み込まれ、パフォーマンスに影響が出ることがあります。そこで本記事では、実際の制作案件で実践しているFSE環境の構築と表示速度の高速化を両立する具体的な設計手順をシェアします。この記事をお読みいただくことで、実務で使えるブロックテーマのパフォーマンス改善と運用方法がわかります。

■ この記事でわかること
・FSE（フルサイト編集）と高速化を両立する基本設計の考え方
・ブロックテーマ特有のパフォーマンス低下を防ぐ改善ポイント
・表示速度を維持したままFSE環境を構築する具体的な手順
・開発時のキャッシュ処理とデータベース最適化の注意点
・長期的な保守を見据えたテーマの運用方針と判断基準

1. 2026年のWordPress環境でフルサイト編集と高速化を両立するための基本設計

1. WordPress環境でフルサイト編集と高速化を両立するための基本設計

【動作確認済み環境】
・WordPress：6.4
・PHP：8.1
・確認日：2024年4月
・テーマ：Twenty Twenty-Four
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。

実際の案件でも、フルサイト編集（FSE：ブロックエディターでサイト全体を編集できるWordPressの新機能）を活用する機会が増えてきました。ただ、FSEテーマを導入しただけでは「ページの表示速度が思ったより上がらない」「Core Web Vitalsのスコアが伸び悩む」という声もよく耳にします。

この記事では、FSEの柔軟性を活かしつつ、表示速度の最適化も両立するための基本設計について、実務の現場で実践しているアプローチをシェアします。

■ この記事でわかること
・FSE環境における表示速度低下の主な原因
・テーマ設計段階で組み込むべき高速化の考え方
・ブロックの読み込みを最適化する判断基準

FSEテーマの最大の利点は、PHPのテンプレートファイルではなく、HTMLベースのブロックマークアップでサイト構造を定義できる点です。しかし、これが逆に高速化のネックになることがあります。

ブロックエディターで多数の複雑なブロックを配置すると、出力されるDOM（HTMLの要素）が深くなり、ブラウザのレンダリングに負荷がかかります。さらに、各ブロックが独自のCSSやJavaScriptを読み込むため、リクエスト数が増加しがちです。

実案件でFSEテーマを設計する際、まずは「テーマ側でグローバルに制御する部分」と「エディター側で個別に設定する部分」を明確に切り分けるようにしています。theme.jsonを活用してタイポグラフィやカラーパレット、余白のルールを一元管理することで、各ブロックにインラインスタイルが大量に出力されるのを防ぎます。

以前、FSEテーマの導入案件で、クライアントがエディター上で自由にデザインを調整できるようにと、すべての設定を開放したことがありました。結果として、ページごとに異なるインラインCSSが大量に生成され、CSSのパース（読み込みと解析）に時間がかかり、表示速度が著しく低下してしまいました。それ以降、theme.jsonでの制約と解放のバランスをシビアに見極めるようにしています。

また、画像の扱いも重要です。WordPressの標準機能で遅延読み込み（Lazy Load）は実装されていますが、ファーストビューに入る画像（LCP要素）まで遅延読み込みされてしまうと、逆にスコアが悪化します。

// functions.php に記述
// ファーストビューのLCP画像にはLazy Loadを適用しない
add_filter( 'wp_omit_loading_attr_threshold', function( $omit_threshold ) {
// 最初の1枚の画像は遅延読み込みから除外する
return 1;
} );

このコードは、ページ上部にある重要な画像がすぐに読み込まれるようにするためのものです。シンプルな設定ですが、これだけでLCP（Largest Contentful Paint：最大コンテンツの描画時間）の改善が見込めます。

高速化は「後からプラグインを追加して解決する」のではなく、構築の初期段階でのテーマ設計（theme.jsonの活用とDOMの最適化）が鍵を握ります。迷ったときは、「そのブロックや設定が、本当にページを開いた瞬間に必要か」を基準に判断してみてください。

Web制作やWordPressのカスタマイズ、保守運用に関するご相談はお気軽にeBIZクリエイトまでお問い合わせください。

2. 実案件の経験から見えたブロックテーマにおけるパフォーマンス改善のポイント

FSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）を活用したブロックテーマの構築は、従来のクラシックテーマとは異なるパフォーマンスチューニングが求められます。

以前、大規模なコーポレートサイトをブロックテーマで構築した際、初期表示の速度が想定より伸び悩むという課題に直面しました。調査を進めると、ページ内で全く使用していないコアブロックのCSSやJavaScriptが、全ページで一括して読み込まれていることが原因でした。ブロックテーマは柔軟性が高い反面、初期状態では不要なリソースまで読み込んでしまう傾向があります。

この問題を解決するため、実務の現場でデフォルトとして設定しているのが、ブロックアセットの個別読み込みです。以下のコードをテーマのfunctions.php（テーマの機能を追加・カスタマイズするファイル）に追記することで、そのページで実際に使用されているブロックのCSSのみが読み込まれるようになります。

// functions.php に記述
// ブロックごとのCSSを個別に読み込み、不要なリソースのロードを防ぐ
add_filter( 'should_load_separate_core_block_assets', '__return_true' );

この記述を追加する理由は、ブラウザへのリクエスト数を減らし、レンダリングブロックを解消するためです。WordPressの内部仕様として、クラシックテーマの時代は一つの巨大なスタイルシートを読み込むのが主流でしたが、ブロックテーマではコンポーネントごとにスタイルを分割して管理する設計思想にシフトしています。そのため、このフィルターフック（データを加工・変換する仕組み）を活用し、必要なアセットだけを都度インラインで出力する方が、長期的な保守性やGoogleのCore Web Vitals対策としても理にかなっています。

ただし、すべてのプロジェクトでこの設定が適しているわけではありません。以下の表で判断基準を整理しました。

また、theme.jsonを活用して不要なカラーパレットやタイポグラフィの設定を制限することも、フロントエンドの出力コードをクリーンに保つために有効です。エディター上でユーザーが選べる選択肢を絞ることは、結果として不要なインラインスタイルの生成を防ぎ、サイト全体の軽量化に直面して貢献します。

迷ったときは、まず開発環境で上記のフィルターフックを適用し、ブラウザのデベロッパーツールでネットワークタブを確認してみてください。読み込まれるCSSのファイルサイズが大きく削減されていることを実感できるはずです。正解は一つではないため、サイトの規模や運用体制に合わせて適切なアプローチを選択することが大切です。

3. ページの表示速度を落とさずにFSE環境を構築する具体的な設定手順

FSE（フルサイト編集：ブロックエディターでサイト全体を編集できる機能）を導入すると、直感的なサイト管理が可能になる反面、初期設定のままではWordPress本体が持つデフォルトのCSSや不要なブロックスクリプトが大量に読み込まれ、表示速度が低下する原因になります。

実際の案件でも、FSE対応の自作テーマへ移行した際に「PageSpeed Insightsのスコアが下がった」というご相談をいただくことが少なくありません。ここでは、表示速度を犠牲にせずにFSE環境を構築するため、実務で実際に導入している設定手順をシェアします。

theme.jsonによる不要なインラインスタイルの制御

FSEテーマの心臓部となるのが `theme.json` です。このファイルで設定を適切に行うことで、不要なCSSの出力を防ぐことができます。

/<strong> theme.json の設定例 </strong>/
{
"version": 2,
"settings": {
"color": {
"custom": false, /<strong> ユーザーによるカスタムカラーパレットを無効化 </strong>/
"customGradient": false /<strong> カスタムグラデーションを無効化 </strong>/
},
"typography": {
"customFontSize": false, /<strong> カスタムフォントサイズを無効化 </strong>/
"dropCap": false /<strong> ドロップキャップ（先頭の1文字を大きくする装飾）を無効化 </strong>/
},
"spacing": {
"margin": true,
"padding": true,
"blockGap": true
}
}
}

この設定を行う理由は、運用者がエディター上で自由に色やサイズを変更できるようにしておくと、ページごとに固有のインラインCSSが生成され、コードの肥大化を招くためです。あらかじめテーマ側で用意したプリセットのみを使用させることで、デザインの統一性を保ちながらHTMLのデータ量を削減できます。

不要なデフォルトブロックパターンの無効化

WordPressは標準で多くのブロックパターンを持っていますが、実務の案件ではオリジナルのデザインを使用することが大半です。これらの不要なパターンがバックグラウンドで読み込まれるのを防ぐため、テーマの機能を追加・カスタマイズするファイルである `functions.php` に以下のコードを記述します。

<?php
/
 functions.php に記述します。
 WordPressの初期化タイミング（initフック）で実行されます。
/
function remove_core_block_patterns() {
// コアのブロックパターンをすべて無効化
remove_theme_support( 'core-block-patterns' );
}
// 処理を割り込ませるアクションフックの登録
add_action( 'init', 'remove_core_block_patterns' );

以前、パフォーマンスチューニングの案件でボトルネックを調査した際、使用していないデフォルトパターンの読み込みがサーバーの応答速度にわずかながら影響を与えていたことがありました。それ以降、うちの制作環境ではこの記述をデフォルトの設定として採用しています。

この設定の使い分け基準

FSE環境の構築は、機能をどこまで解放し、どこを制限するかのバランスが重要になります。長期的な保守性や表示速度を考慮すると、運用方針に合わせて不要な機能をあらかじめ削ぎ落としておく設計が推奨されます。必ず検証環境でお試しいただき、プロジェクトの目的に合った設定を取り入れてみてください。

4. 開発環境の構築時に注意しておきたいキャッシュ処理とデータベースの最適化

【動作確認済み環境】
・WordPress：6.4
・PHP：8.2
・確認日：最新バージョンリリース時
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。

開発環境でテーマやプラグインのカスタマイズを行っている際、CSSやPHPの変更が画面に反映されず、ブラウザの更新ボタンを何度も押した経験はありませんか。FSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）環境では、内部的なキャッシュが強力に働くため、開発中のキャッシュ制御とデータベースの整理がより重要になります。この記事では、開発をスムーズに進めるための具体的な設定方法と判断基準をシェアします。

・開発環境での適切なキャッシュ無効化の方法がわかります
・肥大化しやすいリビジョンの制御方法がわかります
・本番環境への移行を見据えた設定の判断基準がわかります

wp-config.phpを活用したキャッシュとリビジョンの制御

開発環境の構築時、多くの制約を取り払って作業を効率化するために、WordPressの基本設定ファイルであるwp-config.phpに以下のコードを追加します。

// wp-config.phpに記述します。
// ※「/<strong> 編集が必要なのはここまでです </strong>/」という行より上に記述してください。

// WP_CACHEをfalseに設定し、WordPress本体のオブジェクトキャッシュを無効化します
define( 'WP_CACHE', false );

// リビジョン（記事の変更履歴）の保存回数を制限します（ここでは3回に設定）
define( 'WP_POST_REVISIONS', 3 );

// 自動保存の間隔をデフォルトの60秒から300秒（5分）に延長します
define( 'AUTOSAVE_INTERVAL', 300 );

なぜこの設定が必要なのか

この書き方が推奨される理由は、データベースの肥大化を防ぎ、開発中の動作確認を正確に行うためです。FSE環境では、テンプレートパーツやパターンの変更がデータベースに頻繁に保存されます。WordPressはデフォルトで無制限にリビジョン（変更履歴）を保存するため、開発を続けているとデータベースの容量が圧迫され、サイト全体のパフォーマンス低下を引き起こす原因になります。

また、オブジェクトキャッシュが有効な状態だと、コードを書き換えてもメモリ上の古いデータが読み込まれてしまい、「コードは合っているのに画面が変わらない」という事態が発生します。内部でこう動いているからこそ、開発段階ではキャッシュを切り、リビジョンを制限することが有効です。

実案件での失敗談と解決策

正直に言うと、以前は開発環境でもリビジョンを無制限のまま作業していました。eBIZクリエイト株式会社で担当した大規模なメディアサイトの構築案件で、数千件のダミー記事とカスタムブロックを繰り返しテストしていたところ、データベースのサイズが急激に膨れ上がり、ローカル環境の動作が著しく重くなるという問題に当たりました。

その時の解決策が、上記のリビジョン制限と自動保存間隔の調整です。このトラブルが起きてから、開発環境立ち上げ時のデフォルト設定として組み込むように変えました。

よくある間違いと注意点

やりがちですが、開発が終わって本番環境へ移行する際、このwp-config.phpの設定をそのままアップロードしてしまうのは避けたほうがよいケースがあります。本番環境では、ある程度のリビジョンが残っていないと、誤って記事を上書きしてしまった際に復旧できなくなります。代替案として、本番環境ではリビジョン数を10回程度に緩和するなど、運用に合わせた調整が必要です。

向いているケース・向いていないケースまとめ

迷ったときは、「今はコードを書くフェーズか、コンテンツを運用するフェーズか」を基準に考えると整理しやすいです。開発フェーズではパフォーマンスと確認の確実性を優先し、運用フェーズでは安全性を優先して設定を切り替えることで、無用なトラブルを防ぐことができます。Web制作のご相談はお気軽にeBIZクリエイトまでお問い合わせください。

5. 長期的な保守を見据えたテーマの運用方針と今後の方向性について

WordPressのテーマ開発において、FSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）を採用するか、従来のクラシックテーマを維持するかは、運用保守の観点から非常に大きな判断となります。

実案件でFSEを導入して運用を続けていると、クライアント側でサイトの構造自体を意図せず変更してしまうリスクに直面することがあります。従来のクラシックテーマであれば、PHPファイルでレイアウトが固定されているため、デザインが大きく崩れる心配は少なかったのですが、FSEではヘッダーやフッターも含めてブラウザ上から編集できてしまうためです。

そのため、実務では「どこまでをクライアントが編集可能にするか」という権限設定（theme.jsonでの制御）が保守運用の鍵を握ります。すべての解放を前提とするのではなく、不要なブロックやカラーパレット、タイポグラフィの設定をあらかじめ制限しておくことで、運用中のデザイン崩れやパフォーマンス低下を防ぐことができます。

また、WordPress本体のメジャーアップデートに伴うブロックの仕様変更への対応も、今後の保守計画に組み込んでおく必要があります。

長期的な視点で考えると、WordPress本体は完全にFSEを中心としたブロックベースの設計へとシフトしています。保守性を高めるためには、この流れに逆らって独自のページビルダーや複雑なPHPのカスタマイズに依存するよりも、WordPressのコア機能に寄り添ったシンプルな構築を心がけることが、将来的な技術的負債を減らすことにつながります。

迷ったときは、初期構築時の自由度よりも「数年後に誰がどのようにメンテナンスをするのか」を軸に考えてみてください。運用体制に合わせた適切な権限管理と、公式の仕様に準拠したシンプルなテーマ設計が、結果として最も安定した保守運用を実現します。

Web制作や保守運用に関する具体的な設計でお困りの際は、お気軽にeBIZクリエイトまでご相談ください。貴社の運用体制に合わせた最適な方針をご提案いたします。