If you have opened the WordPress dashboard in the past few years and noticed a Site Editor where the Customizer used to live, you have already met full site editing. The question for most site owners and developers today is not whether block themes are real, but whether a given project should be built on one. Here is what actually changes, and how to decide.
What Full Site Editing Actually Changed
Classic WordPress themes are built from PHP template files (page.php, single.php, header.php) glued together with template tags and a functions.php file. Layout changes usually mean editing PHP or hiring someone who can.
Block themes flip that model. Templates are HTML files made of block markup, global design tokens (colors, spacing, typography) live in a theme.json file, and the entire header, footer, and template structure become editable inside the Site Editor without touching code. Template parts and patterns are reusable pieces you can swap in and out visually. The Customizer is largely retired in this world; global styles and templates handle what it used to do.
Block Themes vs Classic Themes at a Glance
- Classic theme: PHP templates,
functions.phphooks, widgets, Customizer, layout changes require code or a child theme. - Block theme: HTML templates,
theme.jsonfor global styles, Site Editor for templates and template parts, patterns for reusable layout blocks, largely no-code layout changes. - Hybrid theme: a classic PHP-based theme that opts into
theme.jsonsupport for some block editor benefits without going fully block-based. This is a common transitional step.
What Developers Gain and Lose
Building in the block world gives you faster prototyping, a design system your client can actually touch (global styles, reusable patterns), and less need to build custom fields just to let someone change a layout. A pattern library built once can be reused across dozens of templates and even client sites.
What you give up, or at least trade, is some of the granular control classic PHP templates offer. You can still hook into WordPress with PHP inside a block theme (render callbacks, filters, custom block variations), but the mental model shifts from “edit this template file” to “compose this template from blocks and parts.” Some page builder plugins and ACF-style field workflows are still catching up to block-native equivalents, so a heavily customized legacy site built around a specific builder may not have a clean, drop-in block theme replacement yet.
Performance Considerations
Either model can hit strong Core Web Vitals scores when built carefully: LCP at or under 2.5 seconds, INP at or under 200 milliseconds, and CLS at or under 0.1. The theme type itself is not the deciding factor, but it does change where performance risk shows up.
Classic themes paired with heavy visual page builders often ship extra JavaScript and CSS to power drag-and-drop editing, which can push INP in the wrong direction if not managed. Block themes render mostly static HTML with minimal JavaScript by default, which is a good starting point for Core Web Vitals, but sloppy patterns with unnecessary nested blocks or images missing explicit dimensions can still cause layout shift and hurt CLS.
None of this changes your caching strategy. LiteSpeed Cache full-page caching works the same way regardless of theme type, it caches the final rendered HTML. A persistent object cache backed by Redis or Memcached helps just as much on either theme model if your site runs WooCommerce or custom post types with heavier database queries. Cloudflare in front of the origin still handles edge caching, the WAF, bot mitigation, and DDoS protection independent of which theme architecture you choose. And running PHP 8.3 with OPcache is a solid baseline either way, since it speeds up PHP execution regardless of whether that PHP is rendering a classic template or powering block registration.
How to Decide Which World to Build In
A few practical signals make the decision easier:
- Client wants to edit layout themselves: lean block theme. Site Editor and patterns give non-developers real control without breaking things.
- Heavy existing investment in a classic page builder or large ACF-driven structure: classic (or hybrid) theme, at least for now. Migrating a large, mature site is a project of its own, not a side task.
- New build starting today with no legacy constraints: default to a block theme unless a specific plugin or workflow forces classic. This is where the ecosystem is investing.
- Agency maintaining many similar client sites: standardize on a block theme with a shared pattern library. It speeds up handoff and keeps design consistent across projects.
You can inspect and manage themes quickly with wp-cli, which is worth having in your toolkit regardless of which model you pick:
wp theme list --status=active
wp theme activate twentytwentyfour
wp option get templateThe Takeaway
Full site editing is not a temporary detour, it is the direction WordPress is building toward, but classic themes are not going away overnight and remain the right call for complex legacy builds. The practical approach is to match the theme model to the project: block themes for new builds and client self-editing, classic or hybrid themes where existing investment and workflow make migration premature. Whichever you choose, performance comes down to the same fundamentals: fast PHP, a real caching layer, and a solid edge in front of your origin.