Since Gutenberg became WordPress's default editor, the debate over whether to build client sites with native blocks or Advanced Custom Fields (ACF) has settled into genuine trade-offs rather than a clear winner. Here's what actually decides it for client and agency work, and why ACF remains the default for most projects here despite Gutenberg's maturity.
Table of Contents
What native Gutenberg blocks do well
- Zero additional plugin dependency. Blocks are core WordPress - no third-party plugin to keep updated, licensed, or worry about long-term support for.
- Familiar editing experience. Most content editors have used Gutenberg-style block editing somewhere before (Notion, Medium, and similar tools use similar patterns), reducing training time.
- Good fit for content-heavy, layout-flexible sites where editors genuinely need to rearrange content freely - blogs, documentation, editorial sites.
What ACF Pro does better for structured client sites
- Predictable, constrained content structure. A client can't accidentally break a carefully designed layout by rearranging blocks in a way the design never anticipated - fields are structured, not freeform.
- Cleaner separation of content and design. Content lives in structured fields; the Blade template controls exactly how it renders. This matters enormously for maintaining design consistency across dozens of pages.
- Better fit for repeatable, templated content - team member listings, service cards, pricing tables - where the structure is fixed and only the data changes.
- Simpler onboarding for non-technical editors. Filling in "Job Title" and "Bio" fields is a lower cognitive load than composing a layout from blocks, especially for clients who update content rarely.
Where this actually plays out on a real project
A marketing site with a handful of structured page types (services, team, case studies, a blog) fits ACF's model well - the design is fixed per page type, and the client just needs to update data, not layout decisions. A publishing-heavy site where editors genuinely need per-post layout flexibility fits Gutenberg's model better.
The mistake to avoid: choosing based on developer preference alone rather than the client's actual editing needs. A structured ACF setup handed to a client who wants Gutenberg's layout freedom feels restrictive to them. A Gutenberg setup handed to a client who just wants to fill in a form and never break the design feels like too many decisions.
What a structured ACF field group actually looks like
Registered in code (not just the ACF UI) so it ships as part of the theme and moves cleanly between environments:
/**
* Register a structured "Service Card" field group instead of leaving
* that layout decision to a freeform Gutenberg block.
*/
function rajangupta_register_service_card_fields(): void {
if ( ! function_exists( 'acf_add_local_field_group' ) ) {
return;
}
acf_add_local_field_group([
'key' => 'group_service_card',
'title' => 'Service Card',
'fields' => [
[ 'key' => 'field_service_title', 'label' => 'Title', 'name' => 'title', 'type' => 'text' ],
[ 'key' => 'field_service_desc', 'label' => 'Description', 'name' => 'description', 'type' => 'textarea' ],
[ 'key' => 'field_service_icon', 'label' => 'Icon', 'name' => 'icon', 'type' => 'image' ],
],
'location' => [
[ [ 'param' => 'post_type', 'operator' => '==', 'value' => 'page' ] ],
],
]);
}
add_action( 'acf/init', 'rajangupta_register_service_card_fields' );
The performance angle often missed
This theme's approach removes Gutenberg's default block library entirely on builds where ACF drives the content structure - because unused block editor assets (including wp-polyfill, a Gutenberg dependency) otherwise ship to every visitor regardless of whether the block editor's flexibility is even being used. For a marketing site with fixed page templates, that's pure weight with no benefit.
What I default to and why
For most agency and business client sites - where the design is fixed per page type and the client's job is updating content, not redesigning layout - ACF Pro paired with Sage 10's Blade templates is the default. It produces faster page loads, a more predictable content structure, and a simpler editing experience for clients who aren't developers.
If you're deciding this for an upcoming build, the right answer depends on how your specific client team actually wants to edit content day-to-day - happy to talk through which fits your project.
Get the free WordPress Security Checklist 2026
25-point checklist PDF - malware detection, hardening guide, login security. Used by 500+ WordPress site owners.
- β 25-point security checklist PDF
- β WordPress malware scan guide
- β Hardening checklist for any WordPress site
No spam. Unsubscribe any time.
You're in!
Check your inbox - the checklist PDF is on its way.
Need help with your WordPress site?
I'm a freelance WordPress developer who fixes exactly this kind of problem.
150+ projects. Clients in UK, US, UAE & Ireland. Fast turnaround.

Rajan Gupta
Freelance WordPress DeveloperI'm Rajan Gupta, a freelance WordPress developer based in India with 150+ projects delivered for agencies and businesses in the UK, US, UAE, and Ireland. I specialise in performance optimisation, Core Web Vitals, custom Sage/ACF builds, and WooCommerce development - every project ships with a 90+ PageSpeed baseline.