The question: can you have admin editing and front-end performance?
Traditional WordPress: the boss loves editing in the admin, but PHP rendering drags down the front end. Pure static site (Astro): blazing fast, but clients/editors can’t change content themselves.
Headless WordPress = WordPress as the backend (content management) + Astro/Next as the front end (presentation) — the best of both worlds.
Three headless flavors (lightest to heaviest)
Flavor 1: Full static export (lightest)
- Keep using the WordPress admin as usual; install a static-export plugin (Simply Static / WP2Static)
- Periodically export the whole site as static HTML and put it on a CDN
- Does Bricks work? Yes — it renders to HTML at build time and exports
- Best for: showcase sites whose content changes infrequently
Flavor 2: Headless + API (standard headless)
- WordPress acts as a pure content repository, served via REST API / GraphQL
- The Astro/Next.js front end pulls data and renders
- Bricks’ role: Bricks is a theme — in headless mode the front end doesn’t use Bricks (Astro replaces it). Bricks lives in the admin, structuring content (ACF custom fields + content orchestration)
- Best for: long-term projects that need admin editing + front-end performance
Flavor 3: Hybrid (progressive)
- Most pages are static; dynamic blocks (comments/search/user areas) use APIs or SSR
- Astro’s islands architecture supports this natively
- Best for: sites with both content and interactive features
What does Bricks actually do in a headless setup?
People keep asking “can Bricks go headless?” — the answer: Bricks is a theme, so in a headless setup the front end no longer uses it, but its value shifts to the admin side:
- Content structure design: Bricks’ dynamic data / custom field concepts help you design the backend content model (field planning for products/posts/categories)
- ACF + CPT orchestration: in headless mode the real “content assets” live in ACF fields; Bricks’ building philosophy (containers/components/dynamic data) maps directly onto the content model
- Transition-period templates: if you’re not fully headless yet, Bricks can keep running in traditional mode while you design the content structure to headless standards — swapping the front end to Astro later won’t require touching the content
In other words: the “structured content mindset” Bricks teaches you is worth more than Bricks itself in a headless world.
Cost-benefit analysis
| Dimension | Traditional WP + Bricks | Headless WP + Astro |
|---|---|---|
| Front-end performance | 95/100 | 100/100 |
| Admin editing experience | Good (Bricks visual builder) | Good (WP admin + ACF) |
| Development complexity | Low | Medium-high (API integration, previews, auth) |
| Maintenance cost | Medium (plugins/security/updates) | Low (front end has no attack surface) |
| Best stage | Fast start | Long-term / large-scale sites |
When should you go headless? (Find your situation)
Yes, go headless:
- The site is a long-term play (5+ years) with content that keeps growing
- Front-end performance is a core KPI (B2B export sites / SEO-sensitive sites)
- Your team has front-end skills and can maintain Astro code
No, don’t:
- Content changes constantly and clients edit daily (the headless preview/publish pipeline adds latency)
- Heavy WooCommerce (complex store interactions make headless expensive)
- The team only knows WordPress; nobody can maintain a front end
The biggest headless pitfall: preview and editing experience
Traditional WP’s “edit and see it instantly” has to be built yourself in a headless setup:
- Draft previews: the front end has to pull draft content (auth + API)
- WYSIWYG: in headless mode the editor and the front end are two separate systems — Bricks’ visual editor doesn’t work on the headless front end (the front end is rendered by Astro; the Bricks editor can’t touch it)
The fix: design the content model well (well-defined fields), let editors just fill in fields, and let front-end templates handle presentation — make “filling in content” simple instead of chasing “visual drag-and-drop.”
A pragmatic path (progressive)
Phase 1: Run Bricks in traditional mode (launch fast; design content structure to headless standards)
Phase 2: Once content accumulates, migrate the front end to Astro (reuse the content model + API)
Phase 3: Put islands on key interactive blocks (comments/search), max out site performanceThis isn’t “scrap it and start over” — it’s “the same content asset, a better engine.” Bricks gets you validated fast in Phase 1; Astro maxes out performance in Phase 3.
Conclusion
Headless WordPress isn’t a hassle — it’s the natural choice once the site grows up. If your site:
- Has content worth keeping (SEO assets) → worth migrating
- Competes on performance → worth migrating
- Is just a temporary project → don’t bother
Bricks + headless = the admin’s editing experience + the front end’s ceiling-level performance. The cost in the middle is “development complexity,” but it’s a one-time investment with long-term returns.
