Hi Bricks Team!
As we build more complex WooCommerce and Membership sites with Bricks, aggressive page caching (LiteSpeed, WP Rocket, Cloudflare, FastCGI) is a must for performance. However, we constantly struggle with dynamic elements (Mini-carts, User Greetings, Wishlist counts, User-specific Query Loops, Currency Switchers).
Currently, we have to either:
-
Bypass caching entirely for logged-in users (kills performance).
-
Use server-side ESI (Edge Side Includes) via caching plugins. But ESI is server-dependent (mostly LiteSpeed) and often breaks Bricks CSS/JS because the styles for the ESI block aren’t loaded correctly on the frontend.
The Proposed Solution: Introduce a native toggle in Bricks Elements (especially Basic Text, Rich Text, and Query Loops) called “Render Dynamically (Client-Side Hydration)” or “Load via AJAX”.
How it should work under the hood:
-
Server-side: Bricks renders the element’s wrapper and classes as usual, but leaves the inner content as a skeleton/placeholder (or default text). This allows the entire page to be safely cached by any caching plugin.
-
Client-side: Once the DOM is loaded, a lightweight native Bricks JS script fetches the dynamic data for these specific elements via the WP REST API (or a custom AJAX endpoint) and replaces the inner HTML.
Why this is a game-changer for Bricks:
-
Server-Agnostic: Works flawlessly with LiteSpeed, Nginx FastCGI, WP Rocket, Cloudflare APO, etc.
-
No Broken CSS/JS: Because Bricks still generates the DOM structure and CSS classes during the initial render, the design won’t break (unlike ESI).
-
Ultimate Performance: We can serve fully cached static HTML to everyone (even logged-in users), updating only the tiny dynamic fragments on the fly.
This would make Bricks the absolute undisputed king for high-performance dynamic websites. Thank you for considering it!