当我们去年接手了一家英国公司的 WordPress + Elementor 构建的企业网站项目后，客户向我们寻求帮助的原因是因感觉英国公司的后期服务反应太慢，无法满足他们的需求。
一开始，我对接手这样一个“烂尾”项目有所顾虑，毕竟担心会卷入“祖传代码”的泥潭之中。然而，仔细分析后发现，这个网站几乎没有任何技术含量，英国公司几乎没有写任何前后端代码，而是完全依赖 Elementor 进行页面设置。客户肯付费且态度坚决，于是我最终接下了这个项目。通过这次机会，我重新熟悉了整个网站，了解了每个模块是如何通过后台操作而非代码实现的。由此，我对 Elementor 构建的网站产生了一些感受。
首先是速度问题。前端速度还可以，毕竟这只是一个企业展示站，静态化和 CDN 优化后，普通用户的访问速度还能接受。但是后端速度却非常缓慢，特别是当网站尝试使用多语言插件（WPML）与 Elementor 时，速度变得难以忍受。查询量大和 Elementor 的细碎设置导致后台响应速度明显下降，而且随着网站数据量的不断增加，维护将变得越来越困难。
其次是代码混乱。许多人认为 Elementor 或类似的页面构建器（如 Divi）能够满足商业设计的需求。然而，通过这个项目的经历，我更加坚信这并非事实。使用 Elementor 构建的页面，如果需要进行各种布局微调，就必须编写一些 CSS。我发现一些类似的网站中，全局 CSS 和独立页面 CSS 直接输出在 header 里，有些甚至在代码块中直接输出，代码组织混乱得令人难以忍受。而对于某些设计需求，例如需要页面特效，仅靠设置功能显然无法满足，这就需要临时加入 JS 代码块，进一步“污染”整个代码风格。这样的项目维护对有些人来说将会非常痛苦，而且如此多的东西需要通过代码块实现， Elementor 的作用何在呢？
因此，接手这个项目的半个月后，我曾建议客户尽快对网站进行重构。我相信能够用更少的代码还原现有的设计和结构，否则网站维护费用将变得越来越难以估算。起初客户并不愿意接受，毕竟之前找英国公司建站的费用很高，这样的结果让人无法接受。然而，时至一年后，客户也无法忍受网站的速度，加之后续有一波新内容需要添加，终于决定让我进行网站重构。
除了 Elementor，我也在维护项目中接触到了许多 WordPress 使用者推荐的 Divi 主题。虽然我个人感受到 Divi 后台的速度比 Elementor 好些，但这种开发方式实在不够自由。一些原本只需要几行代码就能实现的功能，却需要进行繁琐的设置和写入样式和逻辑的修补。如果设计师提供设计稿，要求我们套用主题来还原设计，那将会非常困难，同时网站性能也会受到影响。
我感慨无论是国内还是国外，许多技术能力严重缺乏的建站公司都在使用这些“拖放主题”、“页面构建器”来制作网站。这样的网站开发成本很低，如果收费较低并且满足了一些小型企业的需求也无可厚非。但对于那些打着高端定制旗号，却以这种方式为客户建站的公司来说，这显然是不妥的。
综上所述，依我看来， Elementor 这类工具离“定制”网站的要求还有相当大的距离。
