Split CSS loading in WPBakery

With WPBakery 9.0, we introduced split CSS loading as part of our broader work to make frontend asset delivery more efficient and reduce the amount of unnecessary CSS loaded on each page.

Improving WordPress performance often involves reducing the amount of CSS loaded on each page. As web platforms become more feature-rich, the stylesheets that power them often grow into monoliths – large, single files containing every possible style for every possible element. While this was once the industry standard, it creates a significant weight on the Critical Rendering Path.

In our latest research, we investigated how to move beyond basic minification. By applying CSS code splitting – a common front-end optimization technique, we explored how to load only the styles required by a page. Below, we break down the methodology and the results using WPBakery Page Builder as a real-world use case for CSS optimization.

The problem: The performance cost of monolithic CSS

For those unaware, CSS optimization is a way to make websites faster, by implementing various techniques and best practices of reducing file sizes, improving loading times and optimizing files. Blue Triangle, for example, covered in more details, various ways for CSS optimization you can learn from.

So, WordPress tools usually load a single large CSS file that contains every possible style. This “one-size-fits-all” approach feels wrong (and slow) for several reasons:

• Parsing: A stylesheet loaded in the document head is generally treated as render-blocking, meaning the browser must download and process it before rendering the affected page content.
• Render-blocking: Because the CSS file is large, it blocks the page from rendering visually, which directly hurts your First Contentful Paint (FCP) score.
• Waste: On most pages, up to 90% of that CSS isn’t even used, but the browser still has to waste bandwidth and processing power on it.

Our team wanted to see if splitting this CSS into smaller, modular pieces would make sites lighter and faster without breaking any existing layouts.

Methodology: Transitioning to modular CSS orchestration

To validate this approach, the team focused its research on Conditional Enqueuing. Instead of a static delivery system, they developed a logic-based system that scans page content and only loads the specific styles required for that instance.

Using the shortcode-based architecture of WPBakery as their testing environment, the team implemented the following optimization steps:

• Deconstruction: They broke down the global stylesheet into separate, element-specific LESS files.
• Dependency mapping: They identified the core CSS required for the editor to function and separated it from the”utility CSS required for visual elements.
• Smart logic: They’ve built a toggle-based system (Legacy vs. Optimized) to allow for side-by-side performance testing. This ensured the team could measure the reduction in unused CSS warnings in tools such as Chrome DevTools and Lighthouse.
• Regression testing: A crucial part of CSS optimization research is ensuring that splitting code doesn’t cause Flash of Unstyled Content or FOUC. Each element was tested to ensure it maintained its visual integrity when loaded in isolation.

The goal was to prove that a builder can be both feature-rich and high-performance by simply becoming smarter about how it delivers its assets.

Testing and validation

To verify the efficacy of CSS splitting, WPBakery’s dev team conducted a series of controlled tests using identical page layouts. The objective was to isolate the asset delivery mechanism and measure its direct impact on browser performance.

This process focused on four key technical benchmarks:

• Visual integrity: Ensuring zero regressions in layout or styling when the monolithic global stylesheet is replaced with modular chunks.
• Payload reduction: Measuring the exact decrease in CSS file size across pages of varying complexity.
• Browser execution efficiency: Tracking the time saved during the construction of the CSS object model (CSSOM).
• Performance under scarcity: Observing performance gains on lean pages that only use a small fraction of the builder’s total component library.

Preliminary data confirms that on pages with limited element sets, the CSS payload is significantly reduced. This improvement directly correlates to higher scores in the Reduce Unused CSS audit within Google Lighthouse and other Core Web Vitals assessment tools. Full percentage-based results will be published alongside our version 9.0 release to provide a transparent, verifiable data set for performance enthusiasts.

How does this improve CSS loading performance?

The primary benefit of split CSS loading is reducing the amount of unused CSS. When fewer CSS rules are loaded, the browser has less work to do before it can render the page, which translates to faster parsing, fewer render-blocking resources and more predictable performance as page complexity increases.

The impact is especially relevant on pages that use a limited set of elements, as they no longer carry the full styling footprint of the entire builder. Knowing that the browser blocks page rendering until it has loaded and parsed all CSS, a process known as the critical rendering path, optimizing it ensures more efficient and faster delivery.

Wrapping up

In simple terms, the change looks like this: instead of always loading one large CSS file, styles are now split by element and loaded only when needed. Legacy mode remains the default and users can choose between Legacy, Hybrid, or Optimized modes depending on how they want CSS handled. In upcoming updates, we plan to apply a similar approach to JavaScript loading and switch the default CSS mode to Hybrid.

This type of background work, together with TTFB and all the previous performance improvements, is just one of the ways we constantly work to improve WPBakery Page Builder, providing a fast, secure, trustworthy tool for building. We hope this research, too, has shed light on the importance of this point and helped you learn new things.