Custom Gutenberg Blocks for Tampa Sites
When custom Gutenberg blocks make sense for a Tampa WordPress site — theme.json patterns, block bindings, ACF integration, and when to skip page builders.
For about a decade, “WordPress design” meant a page builder. Visual Composer, then Beaver Builder, then Divi, then Elementor — each one promised drag-and-drop layout flexibility, each one came with real performance and lock-in costs, and each one became the de facto way most agencies built WordPress sites.
That era is ending. The block editor (Gutenberg), introduced in WordPress 5.0 and steadily improved since, now does most of what page builders do — natively, with better performance, and without third-party dependency. For Tampa businesses building new sites in 2026, the right starting point is the native block editor with custom blocks and patterns layered in where needed.
This page covers when to build custom blocks, when to skip them, and how the modern WordPress development workflow actually shapes up.
Why Native Blocks Beat Page Builders
The three reasons we’ve moved every new build to native blocks instead of page builders:
Performance. Page builders inject roughly 150–300 KB of CSS and JavaScript on every page load, even on pages that don’t use their components. Native blocks only load the CSS and JavaScript for blocks actually used on the current page. On a typical Tampa business site, this is the difference between an LCP of 2.8 seconds and 1.6 seconds.
Portability. Sites built in Elementor or Divi are very difficult to migrate off of. The content is wrapped in shortcodes and proprietary HTML structures that don’t render without the original builder. Sites built with native blocks store content as semantic HTML in the database — they remain usable even if every plugin is uninstalled.
Maintainability. Page builders change. Visual Composer became WPBakery, and old projects don’t migrate cleanly. Divi has gone through multiple incompatible major versions. Elementor has its own ecosystem of compatibility issues. Native blocks are maintained by the WordPress core team, with backward compatibility as a stated commitment.
For Tampa business owners who don’t want to be locked into a specific designer or agency’s preferred page builder five years from now, native blocks are the safer long-term bet.
How the Modern Block Editor Works
The block editor in WordPress 6+ has three main parts:
Core blocks. Paragraph, heading, image, gallery, columns, group, button, navigation — the standard library that ships with WordPress. Around 60 of them. For a typical brochure site, these handle 80% of content needs.
Patterns. Pre-designed combinations of blocks that produce a complete section — a hero, a three-column feature row, a testimonial grid, a CTA band. Patterns are reusable: insert one, customize the content, move on. We build a pattern library for every client site so editors can assemble new pages from approved sections without reinventing layout each time.
Custom blocks. Bespoke blocks built for use cases that core blocks don’t handle. Things like a service card with structured data baked in, a doctor profile pulling from a custom post type, a pricing table with dynamic logic, a map of Tampa neighborhoods linked to landing pages.
The decision tree we use:
- Can a core block do it? Use the core block.
- Can a pattern combine core blocks to do it? Build a pattern, reuse it.
- Does it need dynamic data or custom logic? Build a custom block.
Most pages on most Tampa business sites are built entirely from core blocks and patterns. Custom blocks come in for specific high-value use cases, not for everything.
theme.json — The Configuration That Matters
The single most important file in a modern WordPress theme is theme.json. This file controls:
- The color palette available in the editor
- Typography sizes and font families
- Spacing scale (margins, padding)
- Layout widths (content, wide, full)
- Which core blocks are available and which features they expose
- Block-level style defaults
A well-configured theme.json is the difference between a site that holds together visually as editors add new pages and a site that immediately drifts as people pick random colors and font sizes from infinite options.
We treat theme.json as a brand contract. The colors in there are the brand’s color palette — not “any color the editor can imagine.” The font sizes are the typographic system, not “type whatever number you want.” This is what makes the custom theme work hold up over years of editorial change.
When to Build Custom Blocks
Custom blocks are worth the development cost when they meet at least two of these criteria:
- Used repeatedly across the site. A “service card” block that appears on 30 pages is worth building. A one-off layout that appears once is not.
- Has structured data attached. A block that outputs schema.org markup for services, FAQs, or local business info is worth building once and using everywhere — it ensures SEO consistency.
- Pulls from dynamic data. A block that shows the three most recent blog posts in a specific category, or the current month’s offer pulled from a custom post type, can’t be done cleanly with patterns alone.
- Has business logic. A pricing table that adjusts based on a user’s location, or a booking widget that shows next available slots, needs real code behind it.
For Tampa client builds, we typically end up with 5–12 custom blocks per site. The most common categories:
- Service card — title, description, price range, link, structured data
- Team member card — photo, name, title, bio, social links, optional schema
- Testimonial card — quote, attribution, photo, optional review schema
- Location card — address, hours, phone, map embed, optional LocalBusiness schema
- Pricing table — tiered packages with consistent visual treatment
- CTA band — full-width call-to-action with consistent typography and button treatment
- FAQ block — accordion-style Q&A with FAQPage schema output
Each of these would otherwise be a page-builder element. Built once as native blocks, they perform faster and remain editable forever.
Block Bindings — The 2024+ Pattern
WordPress 6.5 introduced block bindings, which let you connect block content to dynamic data sources without writing a fully custom block. The most common use:
- An image block bound to a custom field from ACF
- A paragraph bound to a post meta value
- A button URL bound to a relationship field
This is a big deal because it dramatically reduces the situations where you need a fully custom block. A team-member page template can use a stock image block bound to the “headshot” custom field, a stock heading block bound to “name,” and a stock paragraph bound to “bio” — no custom block code needed.
We use bindings heavily on authority sites where most pages share a template but have differentiating data per page. It’s faster to build, easier to maintain, and lighter at runtime than the equivalent custom-block approach.
Block Patterns — The Workhorse
Patterns are where most of the design system actually lives. A pattern is a saved combination of blocks — a hero with headline, subhead, primary CTA, and background image; a three-column feature row; a testimonial section with three quotes; a CTA band before the footer.
Patterns can be registered globally (available in the editor for any new page) or scoped to a specific template. They can be locked (preventing editors from changing the structure) or unlocked (letting editors swap out specific content while preserving the layout).
For a typical Tampa business site, we ship 20–30 patterns. Editors building a new page assemble it from these patterns, swap in the page-specific content, and the result is on-brand without requiring design judgment from the editor. This is the workflow that makes multisite and large authority sites manageable.
Tooling and Workflow
Modern block development uses the @wordpress/scripts toolkit — webpack-based, batteries-included, hot-reloads in development. The folder structure for a custom block is small: a block.json declaring metadata, an edit component (React), a save component (or a PHP render callback), and a stylesheet.
For Tampa builds, our typical flow:
- Configure
theme.jsonwith the brand’s design tokens - Build the block pattern library covering the standard section types
- Identify the 5–12 custom blocks needed based on the content model
- Develop and register the custom blocks with proper TypeScript or PHPDoc annotations
- Document the pattern and block library so future editors (and future agencies) can extend it
The deliverable at handoff includes documentation. If we hand off a site and the new editor can’t tell what pattern to use for a new page, we’ve failed.
ACF Blocks vs Native Blocks
Advanced Custom Fields (ACF) introduced ACF Blocks years ago, before native React-based block development was mature. ACF Blocks let developers build custom blocks using PHP and ACF field configurations, without writing React.
In 2026, native blocks have caught up. ACF Blocks remain a faster path for simple custom blocks that don’t need rich editor experiences. Native blocks are better when the editor experience matters — when you want inline editing, real visual feedback, or block-specific toolbars.
Our default: native blocks for anything the client will edit frequently, ACF Blocks for engineering-team-managed structures that rarely change. With block bindings now mature, we use fewer ACF Blocks than we did two years ago — block bindings cover most of the same use cases with less code.
When to Skip Custom Blocks
A few cases where we explicitly don’t recommend custom blocks:
Very small marketing sites. A 10-page brochure site for a Tampa professional services firm rarely needs custom blocks. Core blocks plus a good pattern library is enough. Adding a custom block development cycle to a $4K project is overkill.
Sites the client will hand off to a non-technical editor immediately. If the client doesn’t have ongoing developer resources, custom blocks they don’t understand become a liability. Better to lean on patterns and core blocks, which any WordPress-familiar editor can work with.
One-off layouts. Don’t build a custom block for something that appears on one page. Build it as inline HTML or a local pattern, not a registered block.
How This Pairs With the Rest of the Stack
Custom blocks aren’t an island. They sit alongside:
- A well-configured custom theme that establishes the design system
- A clean plugin stack that doesn’t fight the editor
- Speed optimization that benefits from native block performance
- Sensible hosting that supports modern PHP and build tooling
For platform context, our WordPress versus Webflow page covers why this development workflow now compares favorably with the design-first tooling Webflow offers.
Bottom Line
Custom Gutenberg blocks are the right tool for Tampa business sites that need long-term flexibility, performance, and editorial reusability. They’re not always necessary — most pages on most sites work fine with core blocks and patterns alone. But for the high-value, frequently-reused structures (service cards, location cards, pricing tables, structured FAQ sections), the up-front investment in custom blocks pays back over years of content editing.
If you’re inheriting a site built on a page builder and wondering whether it’s worth rebuilding on native blocks, the answer depends on how much editorial work is happening and how long you expect to keep the site. For a site you’ll redesign in two years anyway, the page builder is fine. For a site you expect to run for five or more years with regular content additions, the native block approach pays back.
For the development side specifically, this is the work that separates a real WordPress agency from a “drag and drop a template” shop. We do the former. The infrastructure decisions you make at the start of a build show up every week for the next five years.
Want this applied to your Tampa business?
If you’re working through this for a real Tampa project, get a written diagnostic instead of guessing. The $500 SEO audit is refundable against any build engagement.