Elementor 與自訂佈景主題：真實成本

Elementor 與自訂佈景主題之爭，通常被當成品味問題來吵，偶爾還被當成部落身分來吵。它兩者都不是。它是一個成本問題，而且形狀可以預測：頁面建構器把成本從建置階段挪到了網站的營運週期裡。這筆交易划不划算，取決於兩個幾乎沒人擺到檯面上的數字，一是網站有多少頁面，二是這些頁面多久改動一次。

爭論遲遲沒有結論，是因為雙方都在用軼事說話。有人說建構器很慢，另一個人貼出一張綠色的 Lighthouse 分數，什麼也沒有定下來。效能確實是一項真實成本，但它只是一張更長帳單上的一行，同一張帳單上還有授權續約、外掛堆疊、內容編輯吞吐量、無障礙整改，以及最後把內容重新取出來的價格。

Elementor 不是一個糟糕的工具。對一大類網站來說它就是正確答案，誠實的比較應該先把這一點說出來。有用的問題不是建構器好不好，而是它在哪裡不再划算，而那條界線比喧囂的爭論所暗示的要清晰得多。

Elementor 和量身打造的佈景主題，究竟哪一個更省錢。 Elementor 建置更便宜，營運更昂貴，量身打造的佈景主題正好相反。交叉點大致落在這樣的位置：網站頁面超過約 25 個，而這些頁面來自一小組重複使用的版型；團隊本來就在為開發工時付錢；並且有一個必須滿足而不只是嚮往的效能或無障礙標準。在這條線以下，建構器在總成本上通常勝出；在這條線以上，建置省下的錢會在兩到三年內花掉。

頁面建構器對你的輸出到底做了什麼

斷言建構器很慢沒有用，因為它有時並不慢。穩定的是機制，而機制有三個部分。每一部分都是傾向而非必然，這正是截圖之爭永遠吵不出結果的原因。

文件的深度

視覺化建構器必須把版型表達成容器，而容器就是元素。區段套著欄，欄套著小工具，小工具又套著自己的包裝層和內容。手寫標記用兩三個元素就能表達的設計，建構器會吐出六七個。

這種深度不是免費的。樣式重算、版面配置和繪製都會隨著瀏覽器需要走訪的節點數量、以及比對這些節點的選擇器複雜度而增長。Google 關於 DOM 尺寸與互動性 的指引給出了實用的標尺：Lighthouse 從超過 800 個節點開始發出警告，並把超過 1,400 個節點的頁面視為過量。建構器頁面經常越過 1,400，一個帶多個輪播和大型選單的長頁面能達到三四千個節點。

這筆成本要付兩次。一次在首次繪製時，另一次在每一個改變 DOM 樹的互動上，因為展開摺疊面板或篩選清單會迫使瀏覽器重新走一遍同樣的工作。

逐頁產生的樣式表

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 目前在 WordPress 外掛目錄中的版本是 4.2.4，要求 WordPress 6.8 或更高、PHP 7.4 或更高，並回報超過一千萬次有效安裝 。編輯器 V4 圍繞 Elementor 所稱的原子元素重建了元素架構，採用 CSS 優先的做法，用該公司自己的話說，不帶有「舊有 DOM 膨脹的額外負擔」。Elementor 表示，從 4.0 起 Atomic Editor 是所有新網站的預設體驗 。

有兩點但書比這個標題更重要。第一，現有網站不會因為更新就獲得它。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 說句公道話

確實存在這樣一類網站，建構器在其中不是妥協，而是正確的工程決策，而且這一類很大。

一個十到二十頁的簡介型網站。沒有內部開發者，也沒有雇一個的打算。有一位行銷同事，需要改個標題、換張照片，或者今天下午就發布一個到達頁，不想走工單、分支和部署。預算真的撐不起一次量身打造的開發，替代方案不是一個更好的網站，而是一個更差的網站，或者乾脆沒有網站。

對這類情況，建構器把對開發者的依賴換成了一筆訂閱費，而這通常是一筆划算的交易。一個組織裡沒人能更新的網站，比一個稍重但行銷團隊完全掌控的網站，是更差的資產。量身打造這條路的失敗形態不是慢，而是網站因為每一次改動都要找外部的人而慢慢變舊。

還有第二個公道的理由，就是拿到第一筆收入的速度。用三週而不是三個月把一個像樣的網站推上線，其價值是任何 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 裡，設計系統由開發者定義，沒有第三方授權費，而網站編輯器裡的匯出會產生一個包含你的範本和樣式的佈景主題壓縮檔。

它沒有解決的是紀律。一個 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 直接以英鎊公布價格，所以不涉及任何換算。在 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。

下面其餘的數字是我們報出的價格區間，不是公布價，而且它們假設的是一個英國中小型企業網站，而不是一次電商開發。

建置、營運和終點處的改版

請把它當作散文來讀，因為表格只是把它概括了一下。建構器網站的建置費便宜三倍以上，而營運費最貴，因為那筆年度數字要背著 Elementor 授權、幾乎總會跟著來的付費擴充、圍繞它長出來的外掛堆疊，以及那項永遠差一點做完的週期性效能工作。

真正讓比較分出勝負的是改版那一欄。重建一個建構器網站比重建一個佈景主題網站更貴，原因上面已經講過：內容必須先被擷取出來才能被重建。放到五年的尺度上看，一個 GBP 4,000 的建構器網站和一個 GBP 20,000 的量身打造網站，落點比雙方預期的都要接近，而誰勝出取決於頁面數量和編輯頻率，而不是取決於品味。我們的網站成本拆解 講了這些區間在更大規模專案上如何變化，我們的網站開發服務 頁面則列出了一次量身打造的開發包含哪些內容。

如果你已經在建構器上並且想離開

只要順序排對，移轉是可處理的；排錯了，它就很痛苦。

從盤點開始，而不是從計畫開始。查詢文章中繼資料，找出哪些頁面實際帶有建構器資料，因為在大多數網站上這個數量遠比預想的少，而部落格文章通常本來就是純內容。然後分流：重建、轉換或刪除。大多數網站都拖著一條長長的尾巴，那些頁面一年沒人造訪過，也不值得花錢移轉。

先擷取，再重建。把每一個留下來的頁面繪製出來並保存 HTML，或者從文章中繼資料裡解析出 JSON，這樣你就有了一份獨立於外掛的內容副本。即使那些頁面你打算手工重建，也要這麼做，因為外掛一旦離開，這就是你唯一的副本。

保留網址。重建不是更換網址的理由，而每一個變更過的網址都需要一條指向其具體對應頁面的轉址。

然後逐頁推進，在最後一個頁面離開之前一直保留 Elementor，並且用真實的現場資料而不是實驗室分數去量測前後的 Interaction to Next Paint，因為一台快筆電上的實驗室分數只會告訴你問題從來就不存在。

結論落在哪裡

這個選擇不是意識形態問題。對一個小的、變化緩慢的、沒有開發者的網站來說，建構器是一個正當的答案，而且它是正確答案的次數遠比開發者願意承認的多。一旦頁面數量、版型重複使用、內容編輯吞吐量，或者一條硬性的效能與無障礙要求進入畫面，它就不再是正確答案，而過了那個點還繼續留在上面的代價，會被安靜地支付掉：付在每年的授權裡，付在整改裡，最後付在一次移轉裡。

Mecanik 兩種都做。對經濟上說得通的客戶，我們維運建構器網站；當它不再說得通時，我們把它替換掉，通常替換成核心之上的區塊佈景主題，而不是一次完全量身打造的開發。如果你想要一個直白的答案，判斷自己的網站落在這條線的哪一側，我們的網站開發 和 WordPress 開發 頁面說明了我們如何界定範圍，而聘請 WordPress 開發者時該問什麼 這篇指南則講了如何檢驗你面前的這個人，包括我們。

常見問題

Elementor 對 SEO 有害嗎？ 沒有。Elementor 不會阻止索引，一個做得好的 Elementor 頁面排名與任何其他頁面無異。它對搜尋的壓力是間接的，落在 Core Web Vitals 上，主要是 Interaction to Next Paint，因為深層的產生式標記和小工具指令碼給主執行緒增加了工作量。核心指標只是眾多輸入中的一項，所以一個內容更好的慢速建構器頁面，仍然勝過一個內容更差的快速頁面。

如果我停用 Elementor，我的頁面會怎樣？ 版型會消失。Elementor 把頁面結構以 JSON 形式儲存在 wp_postmeta 資料表的一個私有自訂欄位裡，而不是儲存在 post_content 裡，所以停用外掛後 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，通常靠好的主機、設好尺寸的媒體以及克制使用小工具就能達到。頑固的是低於 200 毫秒的 Interaction to Next Paint，因為它反映的是主執行緒的工作量而不是傳遞速度，而這正是建構器標記和小工具指令碼讓你付出最多代價的指標。

區塊佈景主題是比 Elementor 更好的替代方案嗎？ 經常是，而且它是多數比較都跳過的選項。區塊內容以帶註解分隔符的 HTML 形式存放在 post_content 裡，因此能在更換佈景主題後存活下來，而網站編輯器讓行銷部門無需部署就能編輯範本和樣式。它並非毫不費力：網站編輯器需要一個區塊佈景主題，而且必須有人把設計系統認真定義好，否則你只是在核心內部重建了同一個問題。