Elementor 与自定义主题之争,通常被当成品味问题来吵,偶尔还被当成部落身份来吵。它两者都不是。它是一个成本问题,而且形状可以预测:页面构建器把成本从建站阶段挪到了网站的运营周期里。这笔交易划不划算,取决于两个几乎没人摆到桌面上的数字,一是网站有多少页面,二是这些页面多久改动一次。
争论迟迟没有结论,是因为双方都在用轶事说话。有人说构建器慢,另一个人贴出一张绿色的 Lighthouse 分数,什么也没有定下来。性能确实是一项真实成本,但它只是一张更长账单上的一行,同一张账单上还有授权续费、插件堆栈、内容编辑吞吐量、无障碍整改,以及最后把内容重新取出来的价格。
Elementor 不是一个糟糕的工具。对一大类网站来说它就是正确答案,诚实的比较应该先把这一点说出来。有用的问题不是构建器好不好,而是它在哪里不再划算,而那条边界比喧嚣的争论所暗示的要清晰得多。
Elementor 和定制主题,究竟哪一个更省钱。 Elementor 建站更便宜,运营更昂贵,定制主题正好相反。交叉点大致落在这样的位置:网站页面超过约 25 个,而这些页面来自一小组重复使用的版式;团队本来就在为开发工时付钱;并且有一个必须满足而不是只是向往的性能或无障碍标准。在这条线以下,构建器在总成本上通常胜出;在这条线以上,建站省下的钱会在两到三年内花掉。
页面构建器对你的输出到底做了什么
断言构建器很慢没有用,因为它有时并不慢。稳定的是机制,而机制有三个部分。每一部分都是倾向而非必然,这正是截图之争永远吵不出结果的原因。
文档深度
可视化构建器必须把版式表达成容器,而容器就是元素。区块套着列,列套着小工具,小工具又套着自己的包装层和内容。手写标记用两三个元素就能表达的设计,构建器会吐出六七个。
这种深度不是免费的。样式重算、布局和绘制都会随着浏览器需要遍历的节点数量、以及匹配这些节点的选择器复杂度而增长。谷歌关于 DOM 尺寸与交互性的指南给出了实用标尺:Lighthouse 从超过 800 个节点开始发出警告,并把超过 1,400 个节点的页面视为过量。构建器页面经常越过 1,400,一个带多个轮播和巨型菜单的长页面能达到三四千个节点。
这笔成本要付两次。一次在首屏渲染时,另一次在每一个改变 DOM 树的交互上,因为展开折叠面板或筛选列表会迫使浏览器重新走一遍同样的工作。
逐页生成的样式表
Elementor 自己关于 CSS 渲染性能的工程文章把两种输出模式说得很直白:CSS 要么被打印进文档里的 <style> 标签,要么被写进一个随页面加载的文件。文件输出是静态的,只有页面发生变化时才会重新生成。
两种模式都有一项容易被忽略的成本。样式是逐页生成的,而不是全站共享的,所以访客从首页走到服务页时,下载的是一份全新的样式表,而不是复用已缓存的那一份。使用内嵌模式时,CSS 会在每一次请求中随 HTML 一起传输,既撑大了文档,也彻底击穿了缓存。
手写主题把这件事反了过来:一份样式表,缓存一次,处处复用,访客打开的第二个页面在 CSS 上几乎不花钱。
在版面确定之前就运行的脚本
小工具各自携带自己的 JavaScript。轮播、标签页、折叠面板、计数器、弹窗和表单都会注册事件处理器,其中好几个还会在运行时才决定最终尺寸。当内容的位置要等脚本跑完才知道时,浏览器就会先画出一种版面,再画出另一种。
这就是经典的布局偏移模式,它还会和未设尺寸的媒体、加载迟缓的网页字体叠加放大。这些都不是无法修复的,但修复是逐个小工具进行的,每次编辑页面都得重做一遍,而编辑页面的人通常并不是当初做修复的人。
Core Web Vitals,以及构建器真正伤害的那个指标
先把指标清单弄对,因为大量关于构建器的评论至今仍在争论一个已经不存在的指标。Core Web Vitals 有三项,谷歌的定义精确给出了良好体验的阈值: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。
下面其余的数字是我们报出的价格区间,不是公布价,而且它们假设的是一个英国中小型企业网站,而不是一次电商开发。
建站、运营和终点处的改版
| 路线 | 建站 | 每年运营 | 生命周期终点的改版 |
|---|---|---|---|
| 构建器网站 | GBP 2,000 到 GBP 6,000 | GBP 400 到 GBP 1,200 | GBP 8,000 到 GBP 20,000 |
| 核心之上的区块主题 | GBP 6,000 到 GBP 18,000 | GBP 250 到 GBP 700 | GBP 4,000 到 GBP 12,000 |
| 定制主题 | GBP 12,000 到 GBP 40,000 | GBP 250 到 GBP 800 | GBP 5,000 到 GBP 15,000 |
请把它当作散文来读,因为表格只是把它概括了一下。构建器网站的建站费便宜三倍以上,而运营费最贵,因为那笔年度数字要背着 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,因为深层的生成标记和小工具脚本给主线程增加了工作量。核心指标只是众多输入中的一项,所以一个内容更好的慢速构建器页面,仍然胜过一个内容更差的快速页面。
如果我停用 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 里,因此能在更换主题后存活下来,而站点编辑器让市场部无需部署就能编辑模板和样式。它并非毫不费力:站点编辑器需要一个区块主题,而且必须有人把设计系统认真定义好,否则你只是在核心内部重建了同一个问题。
评论