Bricks is normally distributed as a theme with its own React-based visual canvas bundled in, the same shape as Divi and Avada — but that canvas is an editor-only surface in wp-admin, not something visitors ever load. On the public frontend, Bricks compiles builder data down to plain server-rendered HTML, so page content is served static.
Bricks can be resource-heavy at request time. Bricks renders its layout on every dynamic request, adding real PHP and DOM overhead beyond plain HTML.
We expect pages built with Bricks to load dramatically faster once served statically — that rendering cost is paid once at publish time, not on every visit.
Fully Static
Page rendering is plain server-rendered HTML with no client-side hydration on the public frontend.
The wp-admin builder canvas, including its own REST API (bricks/v1), is restricted to logged-in, capability-checked editor use — the same private/inert shape as Divi's and Elementor's own builder editors, and was never part of the public surface.
None needed — Bricks declares no public routes, AJAX actions, or cookies of its own outside the private builder canvas.
No special setup — detected automatically once active.
This is a light pass, not yet verified against a live install — previously Bricks had no Compatibility Layer profile at all, only a Shield Bar row. Confidence here is set lower than themes already checked against a live install; treat this as a reasonable starting point pending that verification, not a guarantee.
Static Shield Lite is free to install and inspects your actual plugins, not just what's publicly visible.
Get Static Shield
Tulapp