Bricks Builder hosting where the query loop stays fast.
Bricks renders from live queries rather than from saved markup, so the page a visitor gets is assembled per request. That is a database question long before it is a builder question.
Everything a query-driven builder asks of a host.
Most page builders save HTML. Bricks saves a structure and runs it, which moves the cost from storage to every single request.
Query loops that do not scan the table
A loop filtering posts by meta value is an unindexed scan unless somebody adds the index. On a few hundred posts it is invisible; on twenty thousand it is the page.
Editor autosaves that always reach the server
Bricks saves over REST while you work. A cached or rate-limited endpoint loses the last few minutes of a layout and gives no indication it did.
CSS regenerated without a blank site
Global class changes rebuild the stylesheet. Regenerated on the request that asked for it, the first visitor after a save waits for the whole thing.
Templates and components resolved once
Header, footer and section templates are separate posts fetched on every render. Cached, they are free; uncached they are extra queries on every page of the site.
Long editor sessions that do not time out
Building a page is a long-lived session with large payloads. Execution and body-size limits sized for a page view cut it off mid-save.
Build without losing work.
The failure that matters with a builder is not slowness, it is a save that silently did not happen and a layout you now have to rebuild from memory.
- Editor endpoints exempt from cache and rate limits
- Autosave failures surfaced rather than swallowed
- One-click admin login
- Restore any daily backup from the dashboard
An archive built from a query loop.
The template is small. What costs is the query behind it, run once per loop per page, against whatever indexes happen to exist.
What we change for Bricks Builder
These differ from a standard WordPress site on the same plan, and each follows from a builder that renders from queries rather than from saved markup.
| Setting | What we do | Why |
|---|---|---|
| Query loop meta keys | Indexed individually, with results object-cached per loop | A loop filtering on a meta value runs an unindexed scan by default, and the cost only becomes visible once the post table is large enough that nobody wants to touch it. |
| Builder REST endpoints | Exempt from page cache and excluded from rate limiting | Bricks autosaves over REST while a layout is being built, so a throttled or cached endpoint discards recent work and reports success while doing it. |
| Global CSS generation | Rebuilt at save time and served as a static file | Regenerating the stylesheet during the first request after a save makes one unlucky visitor pay for the whole rebuild. |
| Template part lookups | Object-cached rather than re-queried per render | Headers, footers and reusable sections are separate posts, so each one is an extra query on every page until something caches them. |
| Upload and execution limits | Raised for editor requests specifically | A builder save posts a large structured payload in a long-lived session, which limits sized for an ordinary page view terminate part way through. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
Why is my Bricks archive slower than the rest of the site?
I lost changes in the Bricks editor. What causes that?
Does page caching interfere with Bricks?
Why does the site look unstyled right after I save?
Is Bricks heavier than a block theme?
Run Bricks Builder on a host that understands query loops.
Free migration, indexed loops, and an editor that never quietly drops a save.