Bricks Builder Hosting

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.

Query loops object-cachedEditor writes never cachedFree migration
Query-loop tuningEditor-safe cachingFast CSS regenerationDaily backupsFree SSL24/7 support
A builder that queries

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.

Meta indexedObject-cached

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.

REST exemptNo rate limit

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.

Operations

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
Query loops
Meta keys indexed
18 loops
Editor saves
REST cache bypassed
writing
Global CSS
Regenerated on save
cached
Nightly backup
Replicated offsite
running
Performance

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.

Indexed
loop meta keys
Cached
template lookups
NVMe
storage on every plan
MagicWP170 ms
Unindexed meta query loop1850 ms
CSS regenerated in-request760 ms

Illustrative comparison of a loop-driven archive on a large post table. Your numbers depend on post count and loop complexity.

Configuration

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.

SettingWhat we doWhy
Query loop meta keysIndexed individually, with results object-cached per loopA 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 endpointsExempt from page cache and excluded from rate limitingBricks 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 generationRebuilt at save time and served as a static fileRegenerating the stylesheet during the first request after a save makes one unlucky visitor pay for the whole rebuild.
Template part lookupsObject-cached rather than re-queried per renderHeaders, footers and reusable sections are separate posts, so each one is an extra query on every page until something caches them.
Upload and execution limitsRaised for editor requests specificallyA builder save posts a large structured payload in a long-lived session, which limits sized for an ordinary page view terminate part way through.
Plans

Simple, transparent pricing.

Every plan includes free migration, daily backups, SSL and 24/7 support.

MonthlyYearly
Starter
For personal sites, blogs, and portfolios.
$20/mo
Billed $240 yearly · save $60
  • 1 WordPress site
  • 10 GB NVMe disk
  • Free SSL
  • Daily backups
  • One-click deployment
  • Support tickets
Start free trial
Pro★ Most popular
For growing businesses and busy stores.
$80/mo
Billed $960 yearly · save $240
  • 5 WordPress sites
  • 50 GB NVMe disk
  • Free SSL
  • Daily backups
  • One-click deployment
  • Priority support tickets
Start free trial
Enterprise
For agencies and high-traffic platforms.
$250/mo
Billed $3000 yearly · save $600
  • 20 WordPress sites
  • 200 GB NVMe disk
  • Free SSL
  • Daily backups
  • One-click deployment
  • Dedicated support
Start free trial
FAQ

Questions, answered.

Why is my Bricks archive slower than the rest of the site?
Almost always the query loop. Filtering on a meta value without an index means a full scan of the post meta table on every render. Indexing the key and caching the result is usually the whole fix.
I lost changes in the Bricks editor. What causes that?
A save that never reached the server — usually a rate limit or a cached REST response. Both endpoints are exempt here, and a failed autosave surfaces rather than being swallowed.
Does page caching interfere with Bricks?
Not with the front end, which caches like any other HTML. What must be excluded is the editor and its REST routes, and those are excluded by default.
Why does the site look unstyled right after I save?
The global stylesheet is being regenerated. We rebuild it at save time and serve it as a static file, so the visitor who arrives next is not the one waiting for it.
Is Bricks heavier than a block theme?
At render time it does more work, because it resolves queries and templates rather than outputting saved markup. That is a fair trade for what it gives you, provided the database side is set up for it.

Run Bricks Builder on a host that understands query loops.

Free migration, indexed loops, and an editor that never quietly drops a save.