
Is there life after page builders?
By Anne-Mieke Bovelett on May 7, 2024
Status: up to date
What options do I have left if I can’t (or shouldn’t) use a commercial page builder in WordPress?
It’s this question that I asked myself about two years ago when I began researching to see if I could find another solution to efficiently build accessible, sustainable websites for my customers. In my agency, the upsides of using any of the leading commercial page builders no longer outweighed the downsides.
The answer to this burning question
I successfully switched to Full Site Editing. Now, I could have left it at this and written a tweet instead.
But doing that, or simply writing a 450 word blog only singing praise to the Site Editor and the Block Editor is definitely not going to cut it. First of all, most visually oriented people (like me) are better served with a video or a webinar even, showing how that works. Second, this simply deserves an elaborate explanation.
I used to do all my projects with Elementor
Although I worked with all the leading commercial page builders, Elementor Pro has been my preferred tool for a long time. I’ve been more than vocal about that, too, and so were they. Not only did I use it to construct most of my customer websites, I also provided training to agencies on its usage up until a year ago. Elementor served as a significant cornerstone for my services!
Elementor currently has 15 million active installs. Which is not surprising as they have taken “What You See Is What You Get” (WYSIWYG) to the highest level. Slick is the word that comes to mind. Besides, Elementor introduced the possibility to display dynamic data from custom fields and post types a long time ago. They literally were years ahead of their time. They offer templating, per-template display conditions, and much more.
As such, it may seem strange that I would consider trading Elementor in for another solution. But here’s the thing: when I started tracking my time more closely after my portfolio had considerably grown, I realized using it was actually not saving me time anymore.
Advantages of commercial page builders at first sight
Business is business, if you want to grow your agency it’s not only about getting more clients and landing bigger projects, it’s also optimizing your internal processes where you can. At first sight, using a commercial page builder has its advantages in that regard.
- It saves time
It’s fairly easy to add all kinds of elements to pages, in most cases it’s a matter of drag and drop. - It saves costs
You don’t need to invest in custom development to implement your design in your website. - You get to cater towards customers who require freedom in setting up new pages
Customers who want to be empowered to create new pages on their website feel usually well served with a commercial page builder. Whether they truly are served well with all the reigns in their hands is debatable, but that’s a topic for another blog.
If this is all so great, why was I even contemplating life after page builders?
Because at some point, after I consistently tracked my time, I realized that even though it had seriously helped me to grow my agency through the years at high pace, it’s the quantity of projects that’s not playing in their favour.
It is not saving me time anymore. It has seriously began costing me money in ways that were not so obvious when I did not track my time vigorously. And I think this goes for many an agency!
- I was (and still am) losing time over updates going sideways. Usually not even because of Elementor itself, but because of third-party plugins I could not avoid in the more complex projects, clashing with it.
- Every project I had to invest more than usual in setting up the caching plugin to defer all kinds of scripts to optimize for site speed. Partially because of Elementor, but mostly, again, because of some of the unavoidable add-ons and/or third-party plugins.
- Every project I had to make sure the hosting settings were upgraded, because Elementor requires more memory than other tools.
- I had to invest time in coding around accessibility issues and debates with customers why they can’t have certain elements on their pages it they want it to be accessible.
More about backward compatibility, code, and accessibility issues
The base of their success is also the base of the issues I consider to be the cause of costly downside. Like every commercial page builder, they pro-actively cater towards the broadest possible audience. Which means every element must provide as much design flexibility as possible. And in trying to be chocolate, under the hood this results in bloated code.
While its core codebase is vast, and here and there still pretty old, it has been well-maintained. But rapid frontend technology advancements create constant backwards compatibility challenges for developers of page builders. They generally handle backward compatibility well. But a lot of the issues we are all coping with, are beyond their control.
- Some third-party add-ons within the ecosystem that grew around them, are not keeping up the pace, causing sites breaking on update. It’s horrendously time consuming to find out which one is the culprit and why.
- Both Elementor itself as these add-ons load scripts that are not always immediately necessary, which often slows sites down. This is also an issue for sustainability. The less energy consumption a website causes, the better.
- The partially old foundation of the code bases makes it a very slow process for their development team to make front-end output accessibility-ready. At every step they must ensure that they don’t cause breaking changes.
backward compatibility explained
Backward compatibility in software refers to the ability of a newer version of a software program, application, or system to correctly use and interpret data, files, or interfaces created with an older version.
Why the accessibility issues are such an issue for me
First of all, I don’t think it’s good to try charging a customer for working around shortcomings of a tool you recommended to them, when you haven’t told them upfront that custom coding would be required to make things accessible. I know I couldn’t, and that has driven up costs for my agency.
Second, it’s taking longer for Elementor to fix everything than I had hoped for. It’s a known fact that the development team works hard to improve their output. I’m not saying that to be nice. Have a look at the Elementor Pro changelogs! But it’s not going fast enough for me.
Time’s almost up – The European Accessibility Act (EAA) is coming
First and foremost: websites should always be created with accessibility in mind. For humanitarian reasons. And besides, you throw serious revenue out the window by not making your sites accessible.
Besides, in June 2025 the European Accessibility Act (EAA) will come into effect. It affects many businesses selling products and services to consumers in the EU, regardless of the fact if a site owner is outside of the EU. The legal and financial consequences differ per country, but what they have in common: they are substantial.
Life after page builders is Full Site Editing
I’m using a toolset where you no longer depend on more than one vendor for essential functionality and maintenance: Greyd.Suite. I teach fellow agencies how to use this as well.
Custom fields, a forms builder that can compete with the most extensive ones on the market, integrations with other platforms, popups, conditional content, and being able to display dynamic data everywhere. It’s all included.
They have cleanly extended global styles with the missing functionality that may have held you back from FSE in the past: responsive settings, spacing and breakpoints. And what’s more, they offer extended button styles and input field styles.
Sites load superfast, out of the box, and update blues is a thing of the past.
The switch to Full Site Editing was much smoother than I anticipated. And more importantly: I’ve achieved a much higher efficiency and was able to cut down costs (overhead and non-billable hours) by an average of 25% per month.
The cherry on top: accessibility in Greyd.Suite
As Greyd had the luxury to start on a clean and recent code base, making the code output of Greyd.Suite accessibility-ready is a much simpler process for them than for a company having to work on an older code base. As their mentor for accessibility, I can confirm that the majority of output is already accessibility-ready. If you happen to find anything that needs improvement in that field, reporting it results in swift action!
Join my webinar
I’ve decided to regularly give webinars, where I show you how easy it is to switch to full site editing. Follow me on Linkedin or Twitter, I will announce them there!