Elementor対カスタムテーマ：本当のコスト

Elementorとカスタムテーマの議論は、たいてい好みの問題として、ときには部族的な帰属意識の問題として戦わされます。実際にはそのどちらでもありません。これはコストの問題であり、その形は予測できます。ページビルダーはコストを構築の段階からサイトの運用寿命のほうへ移動させるのです。その取引が得かどうかは、ほとんど誰も卓上に出さない二つの数字で決まります。サイトが何ページあるか、そしてそのページがどれくらいの頻度で変わるかです。

議論が決着しないのは、双方が逸話から語るからです。ビルダーは遅いと誰かが言い、別の誰かが緑色のLighthouseスコアを投稿し、それで何も定まりません。パフォーマンスは実在するコストですが、それはもっと長い請求書の一行にすぎません。同じ請求書には、ライセンスの更新、プラグイン構成、編集作業の処理量、アクセシビリティの改修、そして最後に自分のコンテンツを取り出し直すための費用も並んでいます。

Elementorは悪いツールではありません。ある広い層のサイトにとっては正解であり、誠実な比較ならまずそう述べるべきです。有益な問いはビルダーが良いか悪いかではなく、どこで採算が合わなくなるかです。そしてその境界線は、騒がしい議論が示唆するよりもずっと鮮明です。

Elementorとオーダーメイドのテーマ、実際に安く済むのはどちらでしょうか。 Elementorは構築が安く、運用が高くつきます。オーダーメイドのテーマはその逆です。分岐点はおおよそ、少数の繰り返しレイアウトから作られたページが25ページを超え、すでに開発者の工数に費用を払っており、憧れではなく満たさなければならないパフォーマンスまたはアクセシビリティの基準があるあたりに位置します。その線より下ではビルダーが総コストでたいてい勝ちます。上では、構築で浮いた分が2年から3年のうちに使い切られます。

ページビルダーが出力に対して実際に行っていること

ビルダーは遅いと断言しても役に立ちません。遅くない場合もあるからです。安定しているのは仕組みのほうで、そこには三つの部分があります。それぞれは確実性ではなく傾向であり、だからこそスクリーンショットの応酬では何も決着しないのです。

ドキュメントの深さ

ビジュアルビルダーはレイアウトをコンテナとして表現しなければならず、コンテナは要素です。セクションがカラムを抱え、カラムがウィジェットを抱え、ウィジェットは自前のラッパーとその中身を抱えます。手書きのマークアップなら二つか三つの要素で表現できる設計を、ビルダーは六つか七つ吐き出します。

その深さは無料ではありません。スタイルの再計算、レイアウト、ペイントはいずれも、ブラウザが歩かなければならないノードの数と、それに一致するセレクタの複雑さに応じて増えていきます。GoogleのDOMサイズとインタラクティブ性に関するガイダンスは実用的な目安を示しています。Lighthouseは800ノードを超えると警告を出し始め、1,400ノードを超えるページを過大とみなします。ビルダーのページは日常的に1,400を超え、複数のスライダーとメガメニューを備えた長いページは三千から四千に届くこともあります。

このコストは二度支払われます。一度目は最初のレンダリングで、二度目はツリーを変更するすべての操作でです。アコーディオンを開いたりリストを絞り込んだりするたびに、ブラウザは同じ作業をやり直すことになるからです。

ページごとに生成されるスタイルシート

Elementor自身のCSSレンダリング性能についての技術記事は、二つの出力モードを率直に説明しています。CSSはドキュメント内の<style>タグに書き出されるか、ページとともに読み込まれるファイルに書き出されるかのどちらかです。ファイル出力は静的で、ページが変更されたときにだけ再生成されます。

どちらのモードにも見落としやすいコストがあります。スタイルはサイト全体で共有されるのではなくページごとに生成されるため、訪問者がトップページからサービスページへ移動すると、キャッシュ済みのものを再利用するのではなく新しいスタイルシートをダウンロードします。内部埋め込みの場合、CSSはリクエストのたびにHTMLの内側を一緒に運ばれ、ドキュメントを膨らませ、キャッシュを完全に無効にします。

手作りのテーマはこれを逆にします。スタイルシートは一つ、キャッシュは一度、どこでも再利用され、訪問者が開く二ページ目のCSSコストはほとんどゼロです。

レイアウトが確定する前に走るスクリプト

ウィジェットはそれぞれ自前のJavaScriptを抱えています。スライダー、タブ、アコーディオン、カウンター、ポップアップ、フォームはどれもハンドラを登録し、そのいくつかは最終的な寸法を実行時に決めます。スクリプトが走り終わるまでコンテンツの位置が分からないとき、ブラウザは一つのレイアウトを描いてから別のレイアウトを描き直します。

これが典型的なレイアウトシフトのパターンで、寸法の指定がないメディアや遅れて読み込まれるウェブフォントと重なってさらに悪化します。どれも直せないものではありませんが、修正はウィジェットごとで、ページを編集するたびにやり直さなければならず、しかもページを編集する人はたいてい修正を施した人ではありません。

Core Web Vitals、そしてビルダーが実際に悪化させる指標

まず指標の一式を正しく押さえてください。ビルダーをめぐる論評の多くが、もはや存在しない指標について今も議論しているからです。Core Web Vitalsは三つあり、Googleの定義は良好な体験のしきい値を正確に示しています。Largest Contentful Paintはページの読み込みが始まってから2.5秒以内に発生すべきであり、Interaction to Next Paintは200ミリ秒以下、Cumulative Layout Shiftは0.1以下であるべきです。三つとも、ページ読み込みの75パーセンタイルで、モバイルとデスクトップを分けて評価されます。

First Input Delayはもうありません。Interaction to Next Paintが2024年3月12日に安定したCore Web Vitalとしてこれを置き換えており、その変更はここで意味を持ちます。FIDは最初の操作が処理されるまでの遅延だけを測っていたため、重いページを実際より良く見せていました。INPは入力から次に描画されるフレームまでの経路全体を、ページ上の複数の操作にわたって測り、最悪に近い値を採ります。

なぜINPが最後まで抵抗する指標なのか

Largest Contentful Paintは主に配信の問題です。より良いホスティング、CDN、適切なサイズに圧縮された画像、先読みしたヒーロー画像、レンダリングを妨げるリソースの削減で、ビルダー製サイトの多くはビルダー自体に手を触れずに2.5秒を切れます。

Cumulative Layout Shiftは規律の問題です。メディアに寸法を指定し、あとから差し込まれるものの場所をあらかじめ確保し、ページを再流動させないようにフォントを読み込めば、0.1には届きます。

Interaction to Next Paintは構造の問題です。これは応答できるようになるまでにメインスレッドがこなさなければならない作業量を測っており、深いマークアップとウィジェットスクリプトの積み重ねはまさにその作業です。キャッシュで回り込むことはできず、速いサーバーも助けになりません。Elementorのページと無駄のないオーダーメイドのテーマがもっとも大きく分かれるのがこの指標であり、簡単な最適化を終えたあとも分かれたままなのもこの指標です。当社のWordPressパフォーマンス監査ガイドでは、この三つの問題を稼働中のサイトで切り分ける手順を解説しています。

本当に改善された点

ここで公平であることは礼儀ではなく正確さの問題です。Elementorに向けられた批判の多くが、2019年当時のElementorに向けられたものだからです。

Elementorは現在、WordPressプラグインディレクトリでバージョン4.2.4として配布されており、WordPress 6.8以上とPHP 7.4以上を必要とし、1千万件を超える有効インストールを報告しています。エディターV4は、Elementorがアトミック要素と呼ぶものを中心に要素アーキテクチャを作り直し、CSSファーストの手法を採り、同社自身の言葉を借りれば「レガシーなDOM肥大化のオーバーヘッド」を伴いません。Elementorは、Atomic Editorが4.0以降のすべての新規サイトで既定の体験になると述べています。

見出しよりも重要な留保が二つあります。第一に、既存のサイトは更新しただけではそれを手に入れられません。Elementorは、4.0への更新が現在稼働しているサイトに影響しないこと、新機能は手動で有効化することを明示しており、2022年に作られたサイトは誰かが作り直すまで2022年の出力を保ち続けます。第二に、移行の途中ではV3とV4の要素が同じページ上に共存するため、部分的に移行されたページは両方のアーキテクチャと両方のオーバーヘッドを抱えます。

この改善は本物であり、前向きなものとして受け取ってください。それは新しいElementorサイトが何になれるかを変えます。あなたの既存のサイトが今どうであるかを変えるわけではありません。

ロックインの仕組みを、正しく述べる

これはビルダーに対する最強の反論でありながら、ほとんどいつも下手に述べられます。よくある版、つまり壊れたショートコードだらけの画面が残るという話は、実際に起きることとは少し違い、簡単に退けられてしまいます。正確な版のほうがもっと悪い話です。

Elementorのデータ構造ドキュメントは、あなたのページがどこにあるかを正確に述べています。エディターはページのデータとレイアウトをJSON形式でWordPressの投稿メタデータとしてwp_postmetaテーブルに保存し、ドキュメントはそれがWordPressの管理画面には表示されないプライベートなカスタムフィールドとして格納されると注記しています。あなたのレイアウト、スタイリング、そして本文の多くは、Elementorだけが読めるシリアライズされた構造の中にあります。

これをWordPressコアと比べてみてください。ブロックエディターはブロックをpost_contentにシリアライズし、HTMLコメントの区切りを伴うHTMLとして保存し、属性はコメント内のJSONリテラルとして運びます。コアが掲げる狙いは、読める状態を保ち、WordPressのコンテンツに触れる他のすべてと互換であり続ける単一の情報源です。ブロックエディターを剥がしても、コンテンツフィールドには有効なHTMLが残ります。

違いはそれがすべてです。一方のシステムはあなたのコンテンツを、WordPressが常にコンテンツを置いてきた場所に保ちます。もう一方はその隣にあるプライベートなフィールドに置きます。

これが三年後のリニューアルに何を意味するか

Elementorを停止しても、ページは優雅に劣化してはくれません。WordPressはpost_contentを描画しますが、ビルダーのページではそれはたいてい空か断片なので、ページは素朴になるのではなく真っ白になります。何も削除されてはいませんが、何も表示されません。

実務的には、これはリニューアルを二つのプロジェクトに変えます。あなたはテーマを切り替えるのではなく、コンテンツ移行を走らせることになります。ページごとにレンダリング済みのHTMLを抽出するか、投稿メタからJSONを取り出して解析し、そのうえで新しいシステムでレイアウトを作り直すのです。移行として予算を組めば扱えます。リニューアルの途中でこれに気づけば、スケジュールを吹き飛ばすのはこれです。同じ規律がCMS移行にも当てはまり、結果を決める作業は何かを止める前に行われます。

Elementorを擁護する誠実な主張

ビルダーが妥協ではなく正しい技術的判断になるサイトの層が実在し、しかもそれは大きな層です。

10ページから20ページのパンフレット型サイト。社内に開発者がおらず、雇うつもりもない。見出しを変え、写真を差し替え、今日の午後にランディングページを公開したいマーケティング担当者がいて、チケットもブランチもデプロイも通したくない。オーダーメイドの構築には本当に手が届かない予算で、代わりに来るのはより良いサイトではなく、より悪いサイトか、サイトがないという状態である。

この条件のもとでは、ビルダーは開発者への依存をサブスクリプションに変換します。そしてそれはたいてい良い取引です。組織の誰も更新できないサイトは、マーケティングチームが完全に自分のものとして扱えるやや重いサイトよりも、資産として劣ります。オーダーメイドの道の失敗の形は遅さではなく、あらゆる変更が外部の誰かを必要とするせいでサイトが古びていくことです。

もう一つ誠実な主張があります。最初の売上までの速さです。三か月ではなく三週間で信用に足るサイトを公開できることには、どのCore Web Vitalsの数値も捉えられない価値があり、新しい事業にとってその価値はここまで論じたすべてよりも大きいことがしばしばあります。

Elementorとカスタムテーマを分ける判断基準

一般論ではなく、あなた自身のサイトに当てはめられる基準をここに示します。次の六つを採点し、三つ以上当てはまるところを、ビルダーが節約する以上のコストを生み始める点として扱ってください。

ページ数とテンプレート数の対比。 八種類に満たない異なるレイアウトから作られたページが25ページを超えるなら、あなたは繰り返しに対して料金を払っています。テーマはその繰り返しを一度だけ表現し、ビルダーは25か所で保守させます。

編集作業の処理量。 週に数件を超える内容変更が、複数の担当者によって行われるなら、編集体験よりもツールとレビュー手順のほうが重要になります。

すでに存在するデザインシステム。 Figmaに本物のトークン一式があるなら、テーマはそれを一度符号化して強制できます。ビルダーは何も強制できません。どのページもすべてを上書きできてしまうからです。

多言語のコンテンツ。 言語が増えるたびに保守すべきビルダーの構造が倍加し、翻訳プラグインはpost_contentの外に置かれたレイアウトとの相性がよくありません。

契約上のパフォーマンス予算。 Core Web Vitalsが入札条件、SLA、または顧客との合意に現れるなら、期待する数値ではなく自分で制御できる下限が必要です。

アクセシビリティ上の義務。 下で扱いますが、これは単独でも決定打になることが少なくありません。

どれも当てはまらないなら、ビルダーを使い、浮いた分をコンテンツに使ってください。四つ以上当てはまるなら、オーダーメイドのテーマは贅沢ではなく、サイトの生涯を通して安いほうの選択肢です。

多くの比較が飛ばす中間の道

第三の選択肢があります。それはオーダーメイドのテーマでも第三者製のビルダーでもありません。WordPressコアは2022年1月の5.9以降フルサイト編集を提供しており、サイトエディターは今や製品の成熟した一部です。

重要な制約はWordPressサイトエディターのドキュメントにそっけなく書かれています。サイトエディターはブロックテーマをインストールして有効化したときにだけ利用できます。有効なブロックテーマがあれば、編集者はアイデンティティ、スタイル、ページ、ナビゲーション、パターン、テンプレートを扱えるようになり、WordPress 6.3以降はその中からページを管理し編集できます。グローバルスタイル、タイポグラフィ、カラーパレット、レイアウトはテーマのtheme.jsonで一度設定され、サイト全体に適用されます。

これが解決するのはビルダーの本当の価値のほとんどです。マーケティングはページを変え、ヘッダーを編集し、サイトの見た目を変え、デプロイなしで公開できます。そのうえで手に入るのは、ビルダーが与えてくれないものです。コンテンツはpost_contentにあり、デザインシステムは開発者が定義し、第三者へのライセンス料はなく、サイトエディターのエクスポートはテンプレートとスタイルを含むテーマのzipを生成します。

解決しないのは規律の問題です。緩いtheme.jsonと第三者製ブロックプラグインの山を抱えたブロックテーマは、ビルダーの問題をコアの内側で再現します。ロックインも含めてです。それらのブロックはプラグインが去るときにあなたのページを去るからです。またきちんと立ち上げるには依然として開発者が必要で、既存のElementorサイトをそこへ移すのはやはりコンテンツ移行です。

アクセシビリティ、ビルダーが静かに失敗する場所

これは誰もデモで見せない失敗の形であり、遅いページではなく法的な問題に変わるほうの失敗です。

見出しの順序が意味ではなくレイアウトに従う。 編集者はH2が大きすぎて見えたからH3を選び、そこで文書のアウトラインは内容を説明しなくなります。それがWCAG 2.2の達成基準1.3.1「情報及び関係性」のレベルAであり、その上に2.4.6「見出し及びラベル」のレベルAAが重なります。ビルダーの中にそれを防ぐものはありません。見出しの操作がスタイリングの操作だからです。

コントラストの初期値。 1.4.3「コントラスト（最低限）」のレベルAAは、通常のテキストに少なくとも4.5:1、大きなテキストに3:1の比率を求め、1.4.11「非テキストのコントラスト」は、インターフェース部品と図形について隣接する色に対して少なくとも3:1を求めます。白地に薄い灰色の本文、色を敷いたセクションの上の淡いアイコンは、私たちが見つけるビルダー製サイトで最も多い二つの不適合であり、どちらもデモで見栄えのしたテンプレートからそのまま来ています。

入れ子のコンテナ内でのフォーカス順序。 2.4.3「フォーカス順序」のレベルAは、フォーカス可能な部品が意味と操作可能性を保つ順序でフォーカスを受け取ることを求め、2.4.7「フォーカスの可視化」のレベルAAは見えるフォーカス表示を求めます。深く入れ子になったコンテナ、絶対配置のオーバーレイ、ポップアップはこの両方を日常的に壊し、ビルダー向けテーマは見た目が乱れるという理由で既定のフォーカスの輪郭を取り除いていることがよくあります。

英国ではこれは大きな組織群にとって任意ではありません。GOV.UKのガイダンスは、公共部門の団体が2018年の公共部門機関（ウェブサイト及びモバイルアプリケーション）（第2号）アクセシビリティ規則のもとでWCAG 2.2のレベルAAを満たし、アクセシビリティ声明を公開しなければならないと明示しています。その要求は、供給者向け質問票を通じて民間部門の調達にもますます広がっています。生成されたマークアップの改修は、自分で書いたマークアップの修正より明らかに難しい作業です。

それぞれの道が実際にかかる費用

自分で確かめられるライセンスの行

まずライセンス料金から。この節で当社のものではない唯一の数字だからです。ElementorはGBPで直接価格を公表しているので、換算は一切ありません。Elementorの価格ページを2026年9月2日に読んだ時点で、年間プランはEssentialのGBP 48、Advanced SoloのGBP 72、AdvancedのGBP 84を経て、ExpertのGBP 168まで並んでいます。新しいバンドル階層はElementor OneがGBP 144、One AgencyがGBP 348です。

以下のその他の数字は当社が提示する価格帯であり、公表された数字ではありません。またECサイトの構築ではなく、英国の中小規模の事業サイトを前提としています。

構築費、運用費、そして最後に来るリニューアル

表は要約にすぎないので、散文として読んでください。ビルダー製サイトは構築費が三倍以上安く、運用費が最も高くつきます。年間の数字がElementorのライセンス料に加えて、ほぼ必ず付いてくる有料アドオン、その周りで育つプラグイン構成、そして決して終わらない定期的なパフォーマンス作業を抱えるからです。

比較が決着するのはリニューアルの列です。ビルダー製サイトの作り直しは、テーマで作ったサイトの作り直しより高くつきます。理由は上で述べたとおりで、作り直す前にコンテンツを取り出さなければならないからです。五年を通して見ると、GBP 4,000のビルダー製サイトとGBP 20,000のオーダーメイドのサイトは、どちらの当事者が予想するよりも近い位置に着地し、どちらが勝つかは好みではなくページ数と編集頻度で決まります。当社のウェブサイト費用の内訳はより大きな構築でこれらの価格帯がどう動くかを扱い、ウェブサイト開発サービスのページはオーダーメイドの構築に何が含まれるかを示しています。

すでにビルダーの上にいて、そこから出たい場合

移行は順序を正しく組めば扱えますし、間違えれば苦痛になります。

計画よりも先に棚卸しから始めてください。投稿メタを検索して、どのページが実際にビルダーのデータを抱えているかを調べます。ほとんどのサイトでそれは予想よりはるかに少なく、ブログ記事はたいていすでに素のコンテンツです。そのうえで仕分けをします。作り直す、変換する、削除するの三つです。ほとんどのサイトは、一年間誰も訪れておらず、移行の費用を払う価値もないページの長い裾を抱えています。

作り直す前に取り出してください。生き残るページを一つずつレンダリングしてHTMLを保管するか、投稿メタからJSONを解析して取り出し、プラグインから独立した形でコンテンツを手元に置きます。手作業で作り直すつもりのページについてもこれを行ってください。プラグインが去ったあと、それがあなたの唯一の写しになるからです。

URLは変えないでください。作り直しは住所を変える理由になりませんし、変わった住所はすべて、その具体的な対応先へのリダイレクトを必要とします。

そのうえで作業をページごとに進め、最後の一ページが離れるまでElementorはインストールしたままにし、Interaction to Next Paintを実験室のスコアではなく実際のフィールドデータで前後に測ってください。速いノートパソコンでの実験室のスコアは、問題など初めからなかったと告げてくるからです。

ここに落ち着く

この選択は思想の問題ではありません。ビルダーは、小さくて変化の遅い、開発者のいないサイトにとって正当な答えであり、開発者が認めたがるよりずっと多くの場合に正しい答えです。それが正しい答えでなくなるのは、ページ数、テンプレートの再利用、編集作業の処理量、あるいは厳しいパフォーマンスやアクセシビリティの要件が絵の中に入ってきたときです。その点を過ぎてなおビルダーに留まるコストは、年間ライセンス料として、改修として、そして最後に移行として、静かに支払われます。

Mecanikはその両方を作ります。経済的に理にかなう顧客にはビルダー製サイトを運用し、理にかなわなくなればそれを置き換えます。置き換え先はたいてい、完全なオーダーメイドの構築ではなくコア上のブロックテーマです。自分のサイトが線のどちら側にあるのかについて率直な答えが欲しければ、ウェブサイト開発とWordPress開発のページに私たちの見積もり方を示していますし、WordPress開発者を雇うときに聞くべきことのガイドは、私たちを含め、話す相手をどう試すかを扱っています。

よくある質問

ElementorはSEOに悪いのでしょうか？ いいえ。Elementorはインデックスを妨げませんし、よく作られたElementorのページは他のページと同じように順位が付きます。検索に対する圧力は間接的で、Core Web Vitals、主にInteraction to Next Paintに現れます。深い生成マークアップとウィジェットのスクリプトが、メインスレッドにより多くの仕事を与えるからです。Vitalsは多くの入力のうちの一つにすぎないので、内容の優れた遅いビルダーのページは、内容の劣る速いページに今でも勝ちます。

Elementorを停止するとページはどうなりますか？ レイアウトが消えます。Elementorはページ構造をpost_contentではなくwp_postmetaテーブルのプライベートなカスタムフィールドにJSONとして保持するため、プラグインを停止するとWordPressはpost_contentの中身を描画することになり、ビルダーのページではそれはたいてい空か断片です。何も削除されませんが、何も表示もされず、ページの回復はテーマの切り替えではなくデータ移行になります。

英国でカスタムWordPressテーマの費用はどれくらいですか？ 当社が提示する価格帯は、オーダーメイドのテーマでおおよそGBP 12,000からGBP 40,000、WordPressコア上のブロックテーマでGBP 6,000からGBP 18,000、ビルダー製サイトでGBP 2,000からGBP 6,000です。オーダーメイドの数字は初日に最も悪く見え、五年を通して最も良く見えます。ライセンス料がなく、プラグイン構成が小さく、最後のリニューアルがはるかに安いからです。

ElementorのサイトでCore Web Vitalsに合格できますか？ できますし、実際に多くが合格しています。Largest Contentful Paintの2.5秒未満とCumulative Layout Shiftの0.1未満は、良いホスティング、寸法を指定したメディア、ウィジェットを使いすぎない節度でたいてい届きます。抵抗するのはInteraction to Next Paintの200ミリ秒未満で、これは配信ではなくメインスレッドの作業量を映すため、ビルダーのマークアップとウィジェットのスクリプトが最も高くつく指標です。

ブロックテーマはElementorより良い代替になりますか？ 多くの場合そうで、しかもほとんどの比較が飛ばす選択肢です。ブロックのコンテンツはコメント区切りを伴うHTMLとしてpost_contentに保存されるためテーマの変更を生き延び、サイトエディターはマーケティングがデプロイなしでテンプレートとスタイルを編集できるようにします。ただし手間がないわけではありません。サイトエディターにはブロックテーマが必要で、誰かがデザインシステムをきちんと定義しなければ、同じ問題をコアの内側で作り直すことになります。