23 October 2026Our visual editor. Don't work harder, but smarter.
When we think about performance, we usually think about websites that load faster. But speed is just as important for the people who work on a website every day. For this release, we took a closer look under the hood of TwelveBricks to see how we could make key features work more efficiently!
Only rebuild what has been changed
When you make a change in our visual editor, those changes need to be saved and processed. Until recently, this meant rebuilding the entire editor and sending it back to the browser, including parts that hadn't changed at all. Especially on longer pages with lots of components, this resulted in unnecessary processing.
That's why we've changed how Drupal rebuilds our editor. Instead of processing everything again, we now look specifically at what has changed. We then rebuild only the necessary components and rows and send those updates back to the browser.
The editor still works exactly as you're used to, but a lot less work happens behind the scenes.
Do not process configuration over and over again
A large part of our component and theme settings is defined in YAML files. These are configuration files that describe things like which properties a component has and how it can be displayed. This information is used in many places throughout the platform. As a result, certain tasks, such as reading and processing configuration files, were being repeated more often than necessary.
To address this, we've introduced a dedicated cache. It stores things like component definitions, content type settings, and theme-specific colors and other properties. Since this configuration typically only changes when we roll out a new release, we can reuse the results for a long time.
This means less time spent repeatedly reading YAML files and rebuilding settings. Small optimizations like these can add up quickly when they're used throughout the platform.
Fewer unnecessary image checks
We also found opportunities to improve how images are processed. To display an image correctly, we sometimes need to determine additional properties. Does the image have a transparent background? Where is its focal point? And what are its dimensions?
Some of these checks require opening and analyzing the actual image file. That takes processing time, even though the results rarely change.
That's why we've added caching here as well. For example, we no longer need to repeatedly check whether an image contains transparency. We can also reuse calculated information about focal points.
The result? Fewer file operations and less unnecessary processing when building pages.
Smarter caching with our new CDN
Beyond the editor, we also looked at how pages are delivered to visitors. Caching plays an important role here. By temporarily storing a previously generated page, Drupal doesn't have to rebuild it for every visit.
We've increased the shared HTTP cache lifetime (s-maxage) from 15 minutes to 2 hours. This allows pages to be served from the cache for longer. That sounds simple, but there's an important consideration. When you cache pages for longer, you don't want visitors to see outdated content.
That's why this change goes hand in hand with our new European Content Delivery Network (CDN). We've configured the integration with Drupal so we can precisely identify which pages and components need to be refreshed when content changes.
This allows us to combine longer cache lifetimes with the ability to make updates visible quickly. In the future, we hope to fine-tune these cache settings even further.
Keeping our technical foundation up-to-date
We've upgraded our application and development environments to PHP 8.4. PHP is the programming language that powers Drupal and, in turn, TwelveBricks. New PHP versions bring improvements to code execution, memory usage, and technical capabilities.
By keeping our platform up to date, we can benefit from these improvements and continue running on a modern, supported technical foundation.
What does all this mean?
The improvements in this release have one thing in common: we're trying to eliminate work that doesn't need to be done.
How much faster a specific page or action becomes depends on the situation. Factors include the number of components, the complexity of the page, and which data is already cached. That's why we're deliberately not claiming a general percentage improvement. Instead, we want to show where we've eliminated unnecessary processing and why that makes a difference. The first measurements are already showing promising results:
⚡ 82% less time needed to complete the same task.
📉 18% less memory usage.
Our goal remains the same. A website shouldn't just be fast for visitors. It should also be easy and efficient for the people who manage it every day.
-
Sean Blommaert