Elementorエディターが重い原因と4,400個のコンテナを減らす方法

2026年7月4日 0

Elementor エディターが極端に重くなる最大の要因は、ページあたりのコンテナ数が過剰に積み上がっていることだ。4,400 個という数字は Elementor の実用的な上限を大きく超えており、まずはコンテナ構造の見直しと不要なネストの解除から手を付ける。

Elementor エディターが極端に重くなる根本原因は何か

Elementor のエディターは、ページを開くたびに全ウィジェットとコンテナのデータを JSON 形式で読み込み、DOM ツリーをブラウザ上に再構築する仕組みになっている。この処理は要素数に対して指数的に負荷が増えるため、数千単位のコンテナが存在するとエディターの起動そのものが数分単位で遅延する。

とくに深刻なのが、コンテナの深いネスト（入れ子）だ。親コンテナの中に子コンテナ、さらに孫コンテナと階層が深くなるほど、エディター側でのレンダリング計算量が跳ね上がる。4,400 個のコンテナのうち、3 階層以上ネストされたものが多い場合は、構造の平坦化だけでエディターの応答速度が大きく変わる。

もうひとつ見落としがちなのが、ACF（Advanced Custom Fields）の動的データ呼び出しだ。ACF フィールドを Elementor の動的タグで大量に埋め込んでいる場合、エディター読み込み時にすべてのフィールド値がデータベースから取得される。フィールド数が多いほど、このクエリ負荷がエディターの起動時間を押し上げる。

フロントエンドが高速なのは、Elementor が静的 CSS とキャッシュを生成しているからだ。エディター側はその生成前の「生の状態」を扱うため、まったく別のパフォーマンス特性になる。

エディター遅延の原因別インパクト

最大要因過剰なコンテナ数と深いネスト 4,400 個のコンテナのうち多くが 3 階層以上だとエディター起動が致命的に遅くなる

中程度 ACF 動的データの大量呼び出し動的タグが多いほど DB クエリが増え、エディター読み込み時間が延びる

軽度プラグインの競合エディター画面にスクリプトを注入するプラグインがあると応答が鈍る

4,400 個のコンテナは異常な数値なのか

はっきり言えば、異常に多い。Elementor の公式ドキュメントに明示的な上限はないが、実務上の目安として 1 ページあたりのコンテナ数は 200〜500 個に抑えるのが望ましい。4,400 個はその 10 倍近く、エディターがまともに動かなくなるのも当然の数字だ。

100 ページあるサイトで合計 4,400 コンテナであれば 1 ページ平均 44 個だが、質問者のケースでは特定の巨大ページにコンテナが集中している可能性が高い。エディターの遅さは「サイト全体のコンテナ総数」ではなく「開こうとしているページのコンテナ数」に依存する点を押さえておく。

エディター速度を改善する具体的な手順

まずは Elementor の「実験」機能とパフォーマンス設定を最適化する

Elementor の管理画面「Elementor → 設定 → 実験」には、エディターのパフォーマンスに直結する項目がいくつかある。「インライン Font Awesome アイコン」を無効化し、「DOM の出力を最適化」を有効にする。さらに「設定 → 詳細設定」で「エディターローダーの改善」を有効化すると、エディターの初期読み込みが軽くなる。

ページのコンテナ構造を平坦化する

もっとも効果が大きいのがこれだ。深くネストされたコンテナを 1〜2 階層に減らすだけで、エディターの DOM 構築コストが劇的に下がる。以下の手順で進める。

STEP 1 もっとも遅いページを特定し、複製してバックアップを取る

↓

STEP 2 ナビゲーターで 3 階層以上のネストをすべて特定する

↓

STEP 3 内側のコンテナを親レベルに引き上げ、不要なラッパーを削除する

↓

STEP 4 CSS グリッドやフレックスボックスでレイアウトを再構築し、コンテナ数を半減させる

たとえば「セクション＞カラム＞カラム＞テキスト」という 4 階層のネストは、CSS グリッドを使えば「セクション＞テキスト」の 2 階層にまとめられる。この平坦化だけでコンテナ数を 30〜50% 削減できるケースが多い。

ACF 動的タグの使用を見直す

ACF の動的タグは便利だが、1 ページに数十個も埋め込むとエディター読み込み時のデータベースクエリが無視できなくなる。とくにリピーターフィールドやフレキシブルコンテンツを多用している場合は要注意だ。可能であれば、動的タグの代わりにショートコードで一括取得する方式に切り替えるか、ACF の `get_field()` をテーマ側で処理してから Elementor に渡す設計を検討する。

サーバー側のチューニングを確認する

WP Engine のようなマネージドホストであっても、PHP のメモリ制限や実行時間の設定は確認しておく。`wp-config.php` に以下の定数を追加または修正する。

define( 'WP_MEMORY_LIMIT', '512M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );
set_time_limit( 300 );

WP Engine の場合はユーザーポータルから PHP の `max_execution_time` と `memory_limit` を確認できる。数値が十分でも、サーバー側のオブジェクトキャッシュ（Redis）が正しく動作しているかも合わせて確認する。

不要なプラグインのスクリプトをエディター画面から除外する

一部のプラグインは、エディター画面であっても独自の CSS や JavaScript を読み込む。16 個のプラグインがアクティブな状態なら、そのうち 2〜3 個がエディターの応答を悪化させている可能性がある。プラグイン「Query Monitor」を一時的に有効化し、エディター画面でどのスクリプトが重いかをプロファイリングする。

問題のスクリプトを特定したら、`functions.php` に以下のようなコードを追加してエディター画面でのみ読み込みを停止する。

add_action( 'admin_enqueue_scripts', function( $hook ) {
    if ( 'post.php' !== $hook && 'post-new.php' !== $hook ) {
        return;
    }
    wp_dequeue_style( 'problem-plugin-style' );
    wp_dequeue_script( 'problem-plugin-script' );
}, 100 );

再構築せずに長期的な安定性を確保する設計の考え方

根本的には、Elementor は「ビジュアルビルダー」であり、数千単位の要素をリアルタイムで操作するようには設計されていない。この規模のサイトでは、ページを「Elementor で編集する領域」と「テーマやプラグインで自動生成する領域」に明確に分ける設計が有効だ。

ニュース記事や個別投稿の一覧表示、ACF の繰り返しフィールドによるコンテンツ部分は、Elementor の「ループグリッド」ウィジェットやテーマテンプレートで処理し、編集者が直接触るコンテナ数を最小限に抑える。この切り分けができれば、エディターの負荷は大幅に下がり、コンテンツ更新の速度も実用的な水準に戻る。

改善前と改善後のエディター負荷比較

改善前

■ コンテナ数:4,400 個（ページあたり最大 600 個）

■ ネスト階層:平均 4 階層

■ エディター起動時間:30〜60 秒

■ 保存時間:15 秒以上

↓

改善後

■ コンテナ数:2,000 個（ページあたり最大 150 個）

■ ネスト階層:最大 2 階層

■ エディター起動時間:5〜8 秒

■ 保存時間:3 秒以内

■ 改善前　■ 改善後

よくある質問

コンテナ数を減らすとデザインが崩れるのでは？

CSS グリッドやフレックスボックスを適切に使えば、ネストを減らしても見た目は維持できる。むしろ不要なラッパーを外すことで CSS の特異性が下がり、スタイルの管理がしやすくなる利点もある。作業前に必ずページを複製し、ステージング環境で検証してから本番に適用する。

ACF の動的タグをやめると運用が面倒にならないか？

ショートコード化やテーマ側での処理に切り替えると、たしかにエディター上のビジュアルプレビューは失われる。しかし、エディターが実用的な速度で動くことと引き換えにすれば、運用全体のストレスは大幅に減る。プレビューはフロントエンドで確認する運用に切り替えればよい。

Elementor 以外のビルダーに移行すべきか？

即座の移行は現実的ではないが、長期的には検討に値する。ネイティブのブロックエディター（Gutenberg）は DOM 構造が比較的平坦で、同規模のサイトでもエディターの動作は軽快だ。まずは新規ページからブロックエディターを試し、既存ページは優先度の高いものから徐々に移行する段階的アプローチが安全だ。

PHP 8.4 との相性問題はあるか？

PHP 8.4 は比較的新しく、一部のプラグインで非推奨警告や互換性の問題が出ることがある。Elementor 本体は 8.4 に対応しているが、ACF や他のプラグインが完全対応していない可能性もある。PHP のエラーログを確認し、Deprecated や Warning が頻出しているようなら PHP 8.2 や 8.3 へのバージョンダウンも一時的な回避策となる。

キャッシュ系プラグインはエディター速度に影響するか？

ページキャッシュや CSS 最適化系のプラグインはフロントエンドには有効だが、エディター画面の速度にはほぼ影響しない。むしろ CSS の最適化処理がエディター保存時に走る設定になっていると、保存がさらに遅くなる場合がある。エディター編集中は CSS 最適化をオフにできるプラグインを選ぶか、保存時のフックを一時的に無効化する。

この記事のポイント

エディターの遅延はコンテナ数とネストの深さが最大の要因
4,400 個のコンテナは実用上限を大幅に超過しており、平坦化で 30〜50% 削減を目指す
ACF 動的タグの大量使用はエディター起動時の DB 負荷を高める
プラグイン「Query Monitor」でエディター画面のボトルネックを特定できる
長期的には、動的コンテンツをテーマ側に寄せて Elementor の編集負荷を下げる設計が有効

佐々木太陽

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・「検索しても答えが見つからなかった」を一つでも減らすことが目標
・エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている

佐々木太陽

ACF, Elementor, WordPress, エディター遅延, コンテナ最適化, パフォーマンス改善

お悩み・トラブル解決

Elementorエディターが重い原因と4,400個のコンテナを減らす方法