2026年のWordPress高速化とFSE移行で押さえるべき重要設定
【動作確認済み環境】
・WordPress：6.4以上（FSE：フルサイト編集対応環境）
・PHP：8.1 / 8.2
・確認日：2024年11月
※検証環境はエックスサーバー（KUSANAGI技術導入環境）およびNginx環境です。
※サーバー環境や使用するブロックテーマによって動作が異なる場合があります。必ずテスト環境で検証の上、本番環境へ適用してください。
「FSE（フルサイト編集）に移行したら、以前よりもページの表示速度が落ちてしまった」
「ブロックエディターの利便性は魅力的だけれど、表示速度の維持と両立する方法がわからない」
実務の現場で、このような壁に突き当たったことはありませんか？
2026年に向けて、WordPressの制作現場ではFSE（ブロックエディターでサイト全体を編集できる機能）への移行がさらに本格化しています。しかし、従来のクラシックテーマと同じ感覚で構築を進めると、不要なアセットの読み込みやデータベースの肥大化により、想定外の速度低下を招くケースが少なくありません。
表示速度の低下は、ユーザーの離脱を招くだけでなく、SEO（検索エンジン最適化）やコンバージョン率にも直接影響を与える重大な課題です。
この記事では、10年以上の実務経験を持つ現役Web制作者の視点から、FSE移行にともなう速度低下の具体的な原因と、それを解消するための実践的なアプローチをシェアします。
FSE移行時に表示速度が低下する構造的な原因と、その解決手順
サーバーキャッシュとWordPressを効率的に連携させるための最適設定
不要な CSS や JS を読み込ませないアセット管理の実践方法
実務で効果を発揮する最新の画像フォーマット選定と遅延読み込みの実装手順
長期的な安定稼働を支えるデータベースのクリーンアップ方法
1. FSE移行時に表示速度が低下する原因と解決手順
【動作確認済み環境】
・WordPress：6.4
・PHP：8.1
・確認日：2024年3月
・テーマ：Twenty Twenty-Four（FSEテーマ）
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。
FSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）に対応したテーマへ移行した際、「期待していたほど表示速度が上がらない」「移行前よりページが重くなった」という壁にぶつかることがあります。ブロックテーマは従来のクラシックテーマに比べて構造がシンプルな分、適切な設定を行わないと無駄なアセット（CSSやJavaScript）の読み込みが発生しやすい傾向があります。
この記事では、FSE移行に際して表示速度が低下する具体的な原因と、それを解消するための実践的な手順をシェアします。
この記事でわかること
・FSE移行後に表示速度が低下する主な原因
・不要なブロックCSSを読み込ませないための最適化コード
・FSEテーマにおける表示速度改善の具体的な手順
・クラシックテーマとの構造的な違いによるパフォーマンスへの影響
FSE移行で速度が低下する3つの原因
FSEに移行すると、多くの場合においてHTML構造はシンプルになります。しかし、パフォーマンス低下を引き起こす要因は以下の3点に集約されます。
1. グローバルスタイルによるインラインCSSの肥大化
FSEでは「theme.json」という設定ファイルを元に、サイト全体のスタイルを一括管理します。これにより、ページ内で使用していないブロックのスタイル（CSS）まで、大量のインラインCSSとしてHTMLヘッダー内に出力されてしまうことがあります。
2. クラシックテーマ用の互換性スクリプトの残存
移行時に古いプラグインや以前のコードが残っていると、不要なJavaScriptや古いCSSが裏側で動き続け、ブラウザのレンダリング（画面描画）を妨げます。
3. Webフォントや重い静的ファイルの読み込み
FSEテーマの初期状態では、特定の外部フォントや大きな画像ファイルがテーマ側から呼び出されていることがあります。
速度低下を防ぐための具体的な解決手順
これらを解決するために、まずは不要なブロックCSSの分割読み込みを有効化します。
WordPressには、ページ内で実際に使われているブロックのCSSのみを読み込む機能が標準で備わっています。functions.php（テーマの機能を追加・カスタマイズするファイル）に以下のコードを追加し、この機能を強制的に有効化します。
使用しているブロックのCSSのみを個別に読み込む設定
wp_enqueue_scripts アクションフックに割り込ませて実行します。
function ebiz_optimize_block_styles() {
// ページ内で使われているブロックのCSSのみを出力する
add_filter( ‘should_load_separate_core_block_assets’, ‘__return_true’ );
}
add_action( ‘wp_enqueue_scripts’, ‘ebiz_optimize_block_styles’, 1 );
このフィルターフック（データを加工・変換する仕組み）を動かすことで、ヘッダーに一括出力されていた膨大なCSSが、必要な分だけ分割して読み込まれるようになり、初期表示の軽量化が期待できます。
なぜこの設定が必要なのか
デフォルトのWordPressは、古い環境との互換性を保つために、全ブロックのスタイルシートを1つの大きなファイルとして読み込もうとします。しかし、実務のWeb制作においては、すべてのページで全種類のブロックを使うわけではありません。
不必要なコードをブラウザにダウンロードさせないことは、モバイル環境など細い回線での表示速度に直接影響します。テーマ側の設定（theme.json）だけでなく、システム側からアセットの読み込みを制御することが、FSEにおける速度最適化のポイントです。
実案件での失敗談から学んだ選択
以前、制作したコーポレートサイトをクラシックテーマからFSEテーマへリニューアルした際、ページスピードのスコアが急激に悪化するというトラブルに直面しました。
調査したところ、デザインの自由度を高めるために細かくブロックを組み合わせた結果、HTMLソースのヘッダー部分が数千行に及ぶスタイル定義で埋め尽くされていました。上記で紹介した「個別読み込み（should_load_separate_core_block_assets）」を記述したことでインラインCSSの量が4分の1に削減され、表示速度を元の水準以上にまで引き上げることができました。この経験から、FSE移行時には必ずアセットの最適化コードをセットで組み込むようにしています。
FSE移行における速度チューニングの注意点
ただし、すべてのサイトでこの個別読み込みが適しているとは限りません。一部の古いプラグインが独自に出力するブロックでは、スタイルが適用されずに表示が崩れる原因になることがあります。そのため、導入後は必ず主要なページのレイアウトが崩れていないか確認が必要です。
また、テーマ内で使用するフォント（Webフォントなど）がローカルサーバーから正しく配信されているか、外部通信（DNSルックアップ）が発生していないかもあわせてチェックしてください。
向いているケース・向いていないケースまとめ
| 項目 | 向いているケース | 向いていないケース |
| ブロックCSSの個別読み込み | ページ数や使用ブロックが整理されているサイト | 古いサードパーティ製プラグインを多用しているサイト |
| theme.jsonによるスタイル集約 | デザインシステムが明確に定義されている新規制作 | 自由奔放なカスタムCSSが多数残っている既存移行サイト |
将来的な保守性とFSEの方向性
WordPressのコア開発は、FSEとブロックエディターのパフォーマンス改善に注力しています。今後リリースされるアップデートでも、ブロックアセットの読み込み最適化はさらに進むと予想されます。
現段階からシステム側に依存しすぎない「theme.json」をベースにした軽量なスタイリングを徹底しておくことは、将来的なメジャーアップデートの際にも表示崩れを起こしにくく、安定した表示速度を維持するための選択肢となります。
まとめ・判断基準の整理
FSEへの移行で速度低下を避けるための手順は以下の通りです。
1. まずテーマ内の不要なフォントやアセットの読み込み設定を見直す
2. functions.phpに個別読み込みのコードを追加して検証環境で確認する
3. 表示崩れがないか確認し、プラグインのCSSとの干渉をチェックする
FSEは適切にチューニングを施せば、極めて軽量なサイト設計が可能です。サイトの現状に合わせて、一つずつボトルネックを解消していきましょう。
Web制作やWordPressの移行、表示速度の改善に関する細かな調整でお悩みの際は、どうぞお気軽にeBIZクリエイトまでご相談ください。
2. サーバーキャッシュとWordPressコア機能を連携させるための最適設定
【動作確認済み環境】
・WordPress：6.7
・PHP：8.2
・確認日：2025年11月
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。
Webサイトの表示速度を突き詰める際、サーバー側のキャッシュ機能は非常に強力な味方になります。しかし、WordPressのコア機能（標準で備わっているシステム全体）との連携設定を誤ると、更新した内容が画面に反映されなかったり、動的な処理が意図しない挙動を示したりするトラブルを招くことがあります。
特にフルサイト編集（FSE：ブロックエディターでサイト全体を編集できるWordPressの機能）を導入している環境では、テンプレートの修正やスタイルの変更が即座に反映されないといった現象が起きやすくなります。これを防ぐためには、サーバーキャッシュの仕組みとWordPressのシステムを正しく紐付ける設計が必要です。
1. プラグインやサーバー設定によるキャッシュのパージ（一括削除）連携
記事の投稿時やテーマの更新時に、サーバー側のキャッシュを自動でクリア（パージ）する設定を行います。以下は、代表的なWebサーバーであるNginx（エンジンエックス）のファストcgiキャッシュを利用している場合に、functions.php（テーマの機能を追加・カスタマイズするファイル）へ記述する連携コードの一例です。
記事保存時にサーバーキャッシュをクリアするトリガー
アクションフック（特定のタイミングで処理を実行する仕組み）である
‘save_post’ を利用して、記事が更新されたタイミングで独自のキャッシュクリア処理を実行します。function custom_flush_server_cache( $post_id ) {
// 自動保存やリビジョンの場合は処理をスキップ
if ( defined( ‘DOING_AUTOSAVE’ ) && DOING_AUTOSAVE ) {
return;
}// ここに利用しているサーバーのキャッシュクリアAPI呼び出しや、特定のコマンド実行処理を記述します。
// 例：cURL等を用いてサーバーのキャッシュ削除エンドポイントを叩く
}
add_action( ‘save_post’, ‘custom_flush_server_cache’ );
2. キャッシュから除外すべき動的ページの整理
すべてのページを一律でキャッシュしてしまうと、ユーザーごとに表示を変えたいマイページや、お問い合わせフォームの送信完了画面などで不具合が生じます。
以下のページや要素は、サーバー設定（.htaccessやNginx設定ファイル）において必ずキャッシュ除外（バイパス）の登録を行ってください。
WordPress管理画面（`/wp-admin/` 配下）
ログインページ（`wp-login.php`）
プレビュー画面（URLパラメータに `preview=true` が含まれるもの）
セッション管理が必要なページ（ECサイトのカートページや問い合わせフォーム等）
なぜキャッシュの連携設計が必要なのか
サーバーキャッシュはWordPress（PHP）を実行することなく、あらかじめ生成されたHTMLを直接ユーザーに返すため、表示速度を圧倒的に速くすることができます。しかし、WordPress側で「コンテンツが更新された」というイベントを検知してサーバー側に伝えない限り、古いHTMLが残り続けてしまいます。
システム同士が互いの状態を理解できるように連動させておくことが、表示速度の向上と運用のしやすさを両立させるために不可欠なのです。
実案件での経験から：動的処理の落とし穴
以前、コーポレートサイトの構築案件で、表示速度を限界まで高めるためにサーバーのページキャッシュを強力に効かせたことがありました。その際、新着情報の出し分け処理がうまく動かず、古い情報が数時間にわたって表示され続ける問題が発生しました。
この経験から、ただキャッシュを有効にするだけでなく、WordPressの更新フックと連動させて「必要なときに、必要な場所のキャッシュだけを確実に消去する」仕組みを標準パッケージとして導入するようになりました。
向いているケース・向いていないケースまとめ
| 項目 | 向いているケース | 向いていないケース |
| サーバーキャッシュの連携設定 | アクセス数が多く、表示速度の改善が急務である大規模なメディアサイトやコーポレートサイト | 会員ごとに表示内容が細かく変わるマイページ中心のSNS型サイトや、頻繁にシステム開発が入る検証環境 |
3. プラグインへの依存を減らしテーマの軽量化を実現するアセット管理の方法
【動作確認済み環境】
・WordPress：6.4
・PHP：8.1
・確認日：2024年11月
・テーマ：WordPressデフォルトテーマ（Block Theme）
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。
「デザインは完成したけれど、ページの読み込み速度がどうしても改善しない」と悩んだ経験はありませんか。特にフルサイト編集（FSE：ブロックエディターでサイト全体を編集できるWordPressの機能）へ移行する際、これまでのクラシックテーマと同じ感覚でプラグインを追加していくと、ソースコードが肥大化して表示速度に悪影響を与えることがあります。
この記事を読むと、以下のことがわかるようになります。
・FSE移行時における不要なアセット（CSSやJavaScript）の発生原因
・プラグインに頼らずに特定のページだけでアセットを読み込ませるコードの書き方
・テーマ全体の軽量化を図るための判断基準
なぜFSE移行でアセット管理が重要になるのか
従来のクラシックテーマでは、必要な関数やスクリプトを「wp_enqueue_script」などのフック（WordPressの処理に割り込んで独自の処理を追加する仕組み）を使い、自分でコントロールしながら読み込ませることが一般的でした。
しかし、FSE（フルサイト編集）やブロックエディターの導入以降、WordPressはエディターの利便性を高めるために、デフォルトで多くのスタイルシートやスクリプトを出力するようになっています。さらに、特定の機能を実現するためにプラグインを導入すると、そのプラグインが使用されていないページにまで、一律で大量のCSSやJavaScriptが読み込まれてしまう現象が起こります。
サイト全体のパフォーマンスを高めるためには、不要なページでの読み込みを徹底的にカットする「アセットの出し分け」が必要不可欠です。
特定のページのみでアセットを読み込む具体的な実装コード
実務でよく使われる、不要なCSSやJavaScriptの読み込みを停止させ、必要なページ（例：お問い合わせページなど）のみで読み込ませるためのコード例を紹介します。
以下のコードは、テーマの機能をカスタマイズするファイルである「functions.php」に記述します。
特定のページ以外で不要なプラグインのアセット読み込みを停止する
function ebiz_optimize_assets_loading() {
// 例: お問い合わせページ（スラッグが ‘contact’）以外では、特定のCSS・JSを読み込まない
if ( ! is_page( ‘contact’ ) ) {
// 停止したいCSSのハンドル名を指定してデキュー（読み込み解除）する
wp_dequeue_style( ‘contact-form-7’ );// 停止したいJavaScriptのハンドル名を指定してデキューする
wp_dequeue_script( ‘contact-form-7’ );
}
}
// wp_enqueue_scripts アクションフックに、優先順位を遅くして（99など）登録する
add_action( ‘wp_enqueue_scripts’, ‘ebiz_optimize_assets_loading’, 99 );
このコードでは、「is_page」という条件分岐タグを使い、お問い合わせページ以外のときに、不要なスタイルやスクリプトをキューから取り除く処理（デキュー）を行っています。フックの実行タイミング（優先順位）を「99」と遅めに設定しているのは、プラグイン側がアセットを登録した後に、確実に解除処理を割り込ませるためです。
内部仕様とこの方法が推奨される理由
WordPressの「wp_enqueue_style」や「wp_enqueue_script」によって登録されたアセットは、グローバル変数である「$wp_styles」や「$wp_scripts」に一時的に保持されます。
アクションフック（特定のタイミングで処理を実行する仕組み）の「wp_enqueue_scripts」が実行される際、登録された順番にHTMLのヘッダーやフッターへ出力されていきます。そのため、出力処理が走る直前のタイミングで「wp_dequeue_style」を実行し、キュー（出力待ちリスト）から該当するハンドル名を取り除くのが最も安全かつ確実な方法です。
ファイルを物理的に削除したり、プラグイン自体を停止したりするわけではないため、システムの整合性を保ったままフロントエンドの軽量化を実現できます。
実案件における判断の経緯
以前、多機能なフォームプラグインや複雑なスライダープラグインを多数導入しているコーポレートサイトの表示速度改善を担当しました。当初は、ページの表示速度を改善する目的の「最適化プラグイン」を重ねて導入することで解決を図ろうとしましたが、プラグイン同士が競合を起こし、レイアウトが崩れるトラブルが発生しました。
そこで、安易に最適化用のプラグインを増やすのではなく、不要なページでアセットを読み込ませないシンプルなコードを「functions.php」へ直接記述する運用に切り替えました。結果として、サイト全体の読み込み容量を大幅に削減でき、保守性も向上しました。
よくある間違い・ハマりポイント
よくある失敗として、デキュー（読み込み解除）を実行するアクションフックの優先順位をデフォルト（10）のままにしてしまうケースが挙げられます。
プラグイン側が優先順位「20」などの遅いタイミングでアセットを登録している場合、こちらが「10」のタイミングで解除しようとしても、まだ登録されていないため解除処理がスルーされてしまいます。そのため、フックの第3引数には「99」や「999」といった大きな数値を指定し、必ず「他のすべての登録が終わった後に解除を実行する」ように設計してください。
向いているケース・向いていないケースまとめ
アセット管理をコードで実装する方法には、以下のような適性があります。
| 項目 | 向いているケース | 向いていないケース |
| 手法の適性 | 特定のページ（お問い合わせなど）だけで重いプラグインを使用している場合 | サイト内のほぼすべてのページで共通の機能（スライダーなど）を使用している場合 |
| 運用の適性 | 制作会社やコーダーが保守を継続して行える環境 | クライアント自身が頻繁にプラグインを新規追加・変更する環境 |
保守性と将来性の考察
WordPressのコア（本体）開発は、ブロックごとに必要なアセットのみを自動で読み込む仕組み（ブロックアセットのオンデマンド読み込み）の最適化を継続的に進めています。
しかし、サードパーティ製のプラグインがこの新しい仕組みに完全対応するまでには時間がかかることが多く、依然として不要なアセットが全体で読み込まれてしまうのが現状です。過渡期においては、テーマ側で出力をコントロールする今回のようなアセット管理の手法を持っておくことが、長期的な表示速度の維持につながります。
まとめと判断基準の整理
プラグインの依存度を下げ、テーマを軽量に保つための判断基準は以下の通りです。
1. プラグインの全ページ読み込みを疑う：開発ツール（デベロッパーツール）などで、不要なCSS/JSが全ページで読み込まれていないか確認する。
2. コードによる部分制御を行う：特定ページでのみ使う機能は、最適化プラグインを増やす前に、条件分岐コード（デキュー）で解決を試みる。
3. 運用の手間と天秤にかける：ページの数や仕様変更の頻度が多い場合は、運用の負担にならない範囲で実装の範囲を決定する。
表示速度の向上は、ユーザーの利便性を高めるだけでなく、検索エンジンからの評価にも直結する重要な要素です。まずは現状のソースコードを確認し、不要な読み込みが発生していないかチェックすることから始めてみてはいかがでしょうか。
Webサイトの表示速度改善や、クラシックテーマからFSE（フルサイト編集）への移行に伴うカスタマイズで技術的な課題がございましたら、地方密着型のデジタルパートナーであるeBIZクリエイト株式会社へお気軽にご相談ください。Web制作から保守・運用まで、実務経験に基づいた最適な解決策をご提案いたします。
4. 表示速度を維持するために実務で取り入れたい画像フォーマット選定と遅延読み込みの実装
【動作確認済み環境】
・WordPress：6.4
・PHP：8.1
・確認日：2024年11月
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。
Webサイトの表示速度を左右する大きな要因の一つが画像ファイルです。リッチなデザインを維持しながら表示速度を高速に保つためには、適切な画像フォーマットの選定と、ブラウザの仕組みを活かした遅延読み込みの設定が欠かせません。実務の現場で実際に導入している具体的な手法をご紹介します。
次世代画像フォーマット「WebP」と「AVIF」の使い分け
現在のWeb制作において、従来のJPEGやPNGに代わり、WebP（ウェッピー：画質を保ったまま圧縮率を高めた画像フォーマット）やAVIF（エーブイアイエフ：WebPよりさらに圧縮率が高い次世代フォーマット）の採用が進んでいます。
実務における使い分けの判断基準は以下の通りです。
基本の書き出し： 写真などの画像は、まず「WebP」での書き出しを標準とします。画質とファイルサイズのバランスが良く、現在の主要なブラウザで広くサポートされています。
さらなる軽量化： グラデーションが多い複雑な写真や、色数の多いアイキャッチ画像などには「AVIF」を検討します。WebPよりもさらにファイルサイズを削減できますが、古いブラウザ環境では表示できない場合があるため、表示の確認が必要です。
イラストや透過画像： 背景を透過させたいイラストなどは、PNGからWebPの透過設定（ロスレス圧縮）に切り替えることで、ファイルサイズを大幅に削減できます。
ブラウザ標準の遅延読み込み「loading=”lazy”」を活かす実装方法
画像の遅延読み込みは、画面に表示されていない画像を後から読み込むことで、初回の表示速度を向上させる技術です。以前はJavaScriptのライブラリを使用することが一般的でしたが、現在はブラウザが標準でサポートしている「loading=”lazy”（ローディング・レイジー）」属性を使用するのがスマートな設計です。
WordPressでは、標準機能としてメディアライブラリから挿入した画像に自動で `loading=”lazy”` が付与されます。しかし、テーマのテンプレートファイルに直接コーディングした画像には手動で付与する必要があります。
テンプレートファイルへの記述例
テーマのテンプレートファイル（`single.php` や `page.php` など）に直接画像を記述する場合は、以下のように属性を追加します。<img
src=””
alt=”サービス紹介のイメージ画像”
width=”800″
height=”450″
loading=”lazy”
/>
記述のポイント
widthとheightの明記： 画像の縦横幅（アスペクト比）を必ず記述してください。これを怠ると、画像読み込み時に表示領域のサイズが急に変わり、レイアウトが崩れる現象（累積レイアウトシフト：CLS）が発生し、ユーザー体験を損ねてしまいます。
ファーストビュー画像における「遅延読み込みの除外」という落とし穴
遅延読み込みを実装する上で、非常によくある失敗が「ページ上部のヘッダー画像やメインビジュアル（ファーストビュー画像）にも `loading=”lazy”` を設定してしまうこと」です。
画面を開いた瞬間に最初に見えるべき画像に遅延読み込みを設定してしまうと、ブラウザが画像を描画するタイミングがワンテンポ遅れ、かえって表示速度の指標（LCP：最大視覚コンテンツの表示時間）が悪化してしまいます。
実務では、最初の画面に表示されるメイン画像には `loading=”lazy”` を付与せず、代わりに「`fetchpriority=”high”`（フェッチプライオリティ・ハイ：読み込み優先度を高める属性）」を付与する設計を取り入れています。
メイン画像に最適な記述例
<img
src=””
alt=”企業のメインビジュアル”
width=”1200″
height=”675″
fetchpriority=”high”
/ loading=”lazy” はあえて記述しません /
/>
なぜこの実装方法を推奨するのか
WordPressの内部システムやモダンブラウザは、HTMLの構造を解析してリソースの読み込み順を自動で最適化しています。JavaScriptライブラリに依存した古い遅延読み込み処理は、スクリプトの実行負荷がかかるため、現在のブラウザ仕様においては不要なオーバーヘッド（余分な処理負荷）になるケースが増えています。
ブラウザ標準の `loading=”lazy”` と `fetchpriority=”high”` を適切に使い分けることで、余計なコードを記述せず、ブラウザ本来の高速なレンダリング（描画）機能を活かすことができます。これが、長期にわたってメンテナンスしやすいクリーンなコード作りに繋がります。
実案件での判断：以前の失敗から学んだこと
以前、あるコーポレートサイトの制作において、サイト全体のすべての画像に対して一律で遅延読み込みのJavaScriptを適用していたことがありました。一見すると表示スピードが上がったように見えましたが、モバイル実機で検証した際、ページ上部のメイン画像が一瞬遅れて不自然に表示されるという現象が発生しました。
この経験から、ただ「すべて遅延読み込みすれば良い」という考えを改め、表示位置（ファーストビューか、スクロール先か）によって属性を明確に使い分ける実装手法へと切り替えました。これにより、表示速度の数値が改善するだけでなく、ユーザーにとって視覚的にストレスのない表示が可能になりました。
画像最適化手法の選択基準
プロジェクトの特性に応じて、最適な画像処理のアプローチを選択する必要があります。
| 項目 | 向いているケース | 向いていないケース |
| ブラウザ標準機能（WebP + lazy） | シンプルなコーディングで、運用時の手間や読み込み速度のバランスを重視したい場合 | 非常に古いブラウザ環境（サポート切れのIEなど）への対応が厳密に求められる場合 |
| 画像最適化プラグインの活用 | クライアントが自身でJPEGやPNG画像を大量にアップロードする運用のWebサイト | すべてのコーディングとアセット管理を制作者側で厳密にコントロールしたい場合 |
長期的な保守性と表示速度の維持に向けて
WordPressは、フルサイト編集（FSE）をはじめとするブロックテーマへの移行が進んでおり、表示されるHTMLソースコードの最適化がシステム側でも日々行われています。
テーマ開発においては、独自の複雑なスクリプトを導入するよりも、Web標準に準拠したシンプルなHTML属性を適切に指定していくアプローチが、WordPressの将来のアップデートとも競合しにくく、最も安全な選択肢となります。
Webサイトの表示速度改善や、WordPressのブロックテーマ移行に伴う設計の見直しでお困りの際は、お気軽にeBIZクリエイトまでご相談ください。貴社の運用体制に合わせた最適な構築プランをご提案いたします。
5. データベースの肥大化を防ぎ長期的な安定稼働を支えるメンテナンス手法
【動作確認済み環境】
・WordPress：6.4.3
・PHP：8.1.22
・確認日：2024年4月
・テーマ：ブロックテーマ（デフォルトテーマなど）
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。
「サイトを公開した当初は軽快に動いていたのに、徐々に管理画面の動きが重くなってきた」という経験はありませんか。実は、WordPressのデータベースは日々の運用の中で少しずつ不要なデータが蓄積され、パフォーマンスに影響を与える原因になります。
この記事では、データベースの肥大化を防ぎ、サイトの安定稼働を長期的に維持するための具体的なメンテナンス手法を解説します。
この記事でわかること
・データベースが肥大化する主な原因と仕組みがわかります。
・不要なデータを安全に削除し、蓄積を防ぐ具体的な設定方法がわかります。
・長期的なサイト運用におけるメンテナンスの判断基準がわかります。
不要なリビジョンや一時データを適切に管理する
WordPressのパフォーマンスを保つために最初に見直したいのが、投稿のリビジョン（編集履歴）と、一時的なデータを保存するトランジエントデータです。これらは放っておくとデータベースの容量を圧迫し、クエリ（データベースへの命令）の処理速度を低下させる要因になります。
特に記事の更新頻度が高いサイトや、多くの自動処理を行うプラグインを導入している環境では、データベースのテーブルが気付かないうちに肥大化しているケースが少なくありません。
wp-config.phpで行うリビジョン制限の実務設定
実務の案件では、データベースのクリーンアップを行うだけでなく、そもそも不要なデータが溜まりすぎない仕組みを作っておくことが求められます。最も手軽で効果的なのが、`wp-config.php`（WordPressの基本設定ファイル）に変数を追加し、保存されるリビジョンの最大数を制限する方法です。
以下は、保存するリビジョン数を「最大5個」に制限するコードです。
// リビジョンの最大保存数を5個に制限する（wp-config.phpの「編集が必要なのはここまでです」より上に記述）
define(‘WP_POST_REVISIONS’, 5);// 自動保存の間隔を180秒（3分）に変更する（デフォルトは60秒）
define(‘AUTOSAVE_INTERVAL’, 180);
リビジョンを完全に無効化（`false`に設定）することも可能ですが、万が一の執筆トラブルの際に過去の版に戻せなくなるリスクが生じます。実務においては、過去3〜5世代程度を保持する設定にしておくのが、利便性とパフォーマンスのバランスが取れた現実的な判断です。
なぜデータベースの整理が高速化につながるのか
WordPressは、ページを表示するたびにデータベースへアクセスし、必要な情報を取得しています。データベースのテーブル（特に投稿データを格納する`wp_posts`や、各種設定を保存する`wp_options`）のレコード数が膨大になると、検索処理に時間がかかるようになります。
内部的な仕様として、インデックスが適切に効いていないテーブル構造や、不要になったプラグインのゴミデータが残っていると、データベースのメモリ消費量が増加します。定期的に「最適化（OPTIMIZE）」という処理を行うことで、データの並び順を整理し、無駄な空き容量を詰めてパフォーマンスを回復させることができます。
実案件での失敗から学んだ設定の定番化
以前、数千本の記事を移行したオウンドメディアの構築案件で、管理画面の読み込みに10秒以上かかるという問題に直面したことがあります。調査したところ、1記事あたり100世代以上のリビジョンが蓄積されており、総レコード数が数十万件に達していました。
この時、一括で古いリビジョンをクリーンアップし、上記のリビジョン制限コードを導入したことで、管理画面の表示速度は劇的に改善されました。以降、私たちが手掛ける案件では、初期構築時に必ずこの設定を組み込むことをデフォルトにしています。
メンテナンス時の注意点とハマりやすいポイント
データベースのクリーンアップを行う際は、必ず事前に「データベース全体のバックアップ」を取得してください。万が一、必要なデータを巻き込んで削除してしまった場合、元に戻すことができなくなります。
また、アンインストールしたプラグインが残していった古い設定データ（`wp_options`テーブル内の不要なレコード）を手動で削除する際は、どのレコードがどのプラグインに関連しているかを慎重に見極める必要があります。動作に必要なデータを誤って消去すると、サイト全体が真っ白になるなどの致命的なエラーを引き起こす可能性があるため注意が必要です。
向いているケース・向いていないケースまとめ
| 項目 | 向いているケース | 向いていないケース |
| リビジョン制限の導入 | 記事の更新頻度が高く、複数人でサイトを運用している場合 | 記事の執筆プロセスで、何世代も前の履歴に頻繁に戻る必要がある場合 |
| 定期的なクリーンアップ | 過去に多くのプラグインをインストール・削除した経験がある場合 | データベースのバックアップ体制が整っておらず、復旧手段がない場合 |
保守性と将来性を見据えたデータベース設計
WordPressはブロックエディターへの移行やフルサイト編集（FSE）の普及に伴い、ポストメタデータ（記事に紐づく詳細情報）の活用頻度がさらに高まっています。これはデータベースへのアクセス回数が増加傾向にあることを意味します。
将来にわたってサイトの表示速度を維持するためには、サーバーのスペックを上げるだけでなく、データベース自体を常に「軽量でクリーンな状態」に保つ設計思想が不可欠です。
まとめ：長期稼働を支えるメンテナンスの判断基準
データベースの肥大化を防ぐための対策は、以下の手順で進めるのがスムーズです。
1. 事前準備：必ずデータベース全体のバックアップを取得する。
2. 予防設定：`wp-config.php`にリビジョン制限（3〜5個推奨）の記述を追加する。
3. 現状把握：不要なトランジエントデータや古いリビジョンがどれだけ溜まっているかを確認する。
4. クリーンアップ：安全な方法で不要データを削除し、テーブルの最適化を実行する。
適切なメンテナンスを行うことで、数年が経過してもストレスのない、高速で安定したウェブサイトを維持することができます。
Webサイトの高速化やデータベースの最適化、安全なサイトの保守運用に関するご相談がございましたら、福島県郡山市のeBIZクリエイト株式会社までお気軽にお問い合わせください。お客様の状況に合わせた最適な運用方法をご提案いたします。