WordPress theme architecture has changed significantly with the introduction of block themes and the Site Editor. Traditional WordPress sites commonly rely on PHP template files such as header.php, single.php, and index.php, while block themes use block-based HTML templates, template parts, patterns and the Site Editor. Many block themes also use theme.json, although classic themes can use theme.json too.
That raises an important practical question for developers and site owners: should a new WordPress project use a block theme or a classic theme? The answer depends less on assumed performance superiority and more on the project's editing requirements, template architecture, development workflow, customization needs, plugin compatibility, maintenance strategy, and long-term direction.
In this guide, we compare WordPress block themes and classic themes, explain how their template systems differ, examine theme.json, Site Editor and Template Editor workflows, PHP customization, responsive styling, asset delivery considerations, and show how to choose the architecture that best matches your WordPress project.
This guide was checked against current WordPress.org and WordPress Developer documentation for WordPress 7.1, block themes, classic themes, the Site Editor, Template Editor, templates, template parts, patterns, Global Styles and the theme.json version 3 reference. It is an architecture and workflow comparison, not a Digital Bhatti speed benchmark.
Last verified: September 24, 2026.
WordPress 7.1, released August 19, 2026, expands modern editor styling with responsive block styles, configurable viewports and additional style states. Those capabilities strengthen the Site Editor / Global Styles workflow, but they do not change the basic architecture distinction: block themes use block templates and the Site Editor, while classic themes remain PHP-template-based.
theme.json version 3 remains the current schema version. Classic themes can use theme.json too, so it should not be treated as proof that a theme is a block theme.
Choose Block Themes for Site-Editor-First Workflows; Keep Classic Themes Where PHP-Centric Architecture Still Fits
Block themes are designed around block templates, the Site Editor, Styles, patterns and site-wide block editing. Classic themes use PHP templates and can still adopt some modern features such as theme.json. Neither architecture is inherently faster, more secure or more SEO-friendly; choose according to editing model, compatibility, maintenance and development requirements.
Choose the Editing and Maintenance Model Before Choosing the Marketplace
Decide whether the project should be maintained primarily through the Site Editor and block templates or through PHP templates, hooks and established classic-theme workflows. Then evaluate individual themes inside that architecture.
Compare Lightweight Theme Implementations →1. WordPress Block Themes vs Classic Themes
The biggest difference between the two architectures is how the site's templates, styles, and editing workflow are managed.
Block themes use block-based templates and can be edited site-wide through the WordPress Site Editor. Classic themes primarily use PHP template files and may provide customization through the Customizer, the block-based Widgets editor, theme-specific settings, child themes, hooks, filters, or custom code. Some classic themes can also enable the Template Editor for post/page templates, but that is not the same as providing the full Site Editor.
| Area | Block Themes / Site Editor | Classic Themes |
|---|---|---|
| Templates | Block-based HTML templates and template parts | PHP template hierarchy and template files |
| Site Editing | Site Editor can visually edit supported templates, headers, footers, patterns, and global styles | Usually relies on the Customizer, theme settings, widgets, PHP templates, or custom code |
| Design System | theme.json, global styles, blocks, patterns, templates, and style variations |
PHP templates, theme CSS, Customizer/theme settings, hooks, options and, where adopted, theme.json |
| Customization Model | Strong visual editing with reusable patterns and block-based template composition | Traditional PHP customization, child themes, template overrides, hooks, and theme-level code |
| Performance Characteristics | Depends on theme implementation, blocks, assets, plugins, media, and infrastructure | Depends on theme implementation, template code, assets, plugins, media, and infrastructure |
There is no architectural rule that makes one theme type universally faster or better for Core Web Vitals. The implementation, page composition, plugin stack, asset delivery, and hosting environment matter more than the label block or classic.
At the theme-code level, WordPress documentation defines a block theme by the presence of block-based template files, including at minimum an index.html template in the appropriate templates directory. A theme.json file is common and useful but is not itself what makes a theme a block theme.
For a separate discussion of lightweight implementations, see our guide to lightweight WordPress themes.
2. How Block Theme Architecture Works
A. Block-Based Templates
Instead of depending primarily on PHP template files, a block theme defines templates using block markup. Headers, footers, navigation areas, archive layouts, search templates, page layouts and single-post templates can be assembled using blocks and reusable template parts. Current theme-development documentation recommends storing block-theme template parts directly in the theme's /parts directory.
This architecture shifts more of the site's presentation layer into WordPress's block system. Depending on permissions and workflow, editors can modify supported site-wide layouts through the Site Editor instead of changing PHP template files.
B. The Role of theme.json
The theme.json configuration file provides a structured way for themes to define settings and styles such as typography, colors, spacing, layout widths, block behavior, design presets, and other global controls.
Important: theme.json is not exclusive to block themes. Classic themes can also use it to configure and style the block editor and block content. Current WordPress documentation lists version 3 as the latest theme.json schema version; version 3 was introduced in WordPress 6.6, and older schema versions remain backward-compatible.
A simple configuration might look like this:
{
"version": 3,
"settings": {
"layout": {
"contentSize": "800px",
"wideSize": "1200px"
},
"typography": {
"fluid": true
}
}
}The exact supported properties depend on the WordPress version and theme implementation, so production configurations should be checked against documentation appropriate to the WordPress version being used.
C. Classic PHP Templates
Classic themes generally use PHP templates such as single.php, page.php, archive.php, functions.php, and header.php. Developers can use the template hierarchy, hooks, filters, child themes, and custom PHP to build site-specific layouts and application behavior.
This architecture remains useful for projects that depend heavily on custom template logic, legacy theme functionality, established development workflows, or integrations designed around the traditional WordPress theme system.
The full Site Editor is available with block themes. WordPress documentation also notes that a classic theme can enable access to the Template Editor, so template-editing capability should not be reduced to a simple “block themes can edit templates, classic themes cannot” rule.
3. What WordPress 7.1 Changes for Theme Workflows
WordPress 7.1 does not remove the distinction between block and classic themes, but it expands the modern styling workflow available through blocks and Global Styles.
Current WordPress 7.1 capabilities include:
- Responsive block styles: block styles can be customized for tablet and mobile viewports where supported.
- Configurable viewports: themes can define viewport values used by responsive block styling.
- Additional style states: modern block styling can express more interaction and responsive states through the Global Styles system.
- Improved Site Editor workflows: templates, patterns, pages and site-wide styles continue to be managed from the Site Editor for block themes.
These features can reduce the amount of custom CSS required for some block-theme projects, but they do not eliminate the need for testing, design governance or custom code. Themes and blocks that use custom controls may not automatically receive every core responsive styling capability.
Classic themes are not excluded from all modern editor features. They can use theme.json, the block editor, and in some cases the Template Editor. The architectural boundary is still whether the theme uses block templates and the Site Editor for the whole site.
4. Does Theme Architecture Determine Performance?
No. Choosing a block theme does not automatically improve LCP, INP, CLS, TTFB, or a PageSpeed score, and choosing a classic theme does not automatically make a site slower.
Performance can be affected by:
- Number and complexity of blocks or template components
- Images and other media
- Third-party scripts
- Plugins and their assets
- Font loading
- CSS and JavaScript delivery
- Server response time and caching
- Database queries
- Page structure and DOM complexity
- Hosting and CDN configuration
A carefully developed classic theme can be lightweight and maintainable, while a block theme can also be lightweight and maintainable. Either architecture can become inefficient when combined with excessive plugins, unnecessary scripts, oversized media, poor caching, or complex page composition.
For related front-end considerations, see our guide on eliminating render-blocking resources and the DOM & Rendering Performance Guide.
5. DOM Structure and Block Markup
Block-based layouts can produce nested HTML because Groups, Columns, Rows, Cover blocks, and other layout blocks may introduce wrapper elements. Classic themes and page builders can also produce deeply nested markup, so DOM complexity is not unique to block themes.
The existence of additional wrapper elements does not by itself establish a meaningful performance problem. DOM structure should be evaluated in the context of the complete page, including CSS selectors, JavaScript behavior, interactions, layout complexity, and device capability.
Instead of attempting to achieve an arbitrary DOM-node target, developers should:
- Avoid unnecessary nested Group and layout blocks.
- Use semantic HTML where the selected block or template supports it.
- Keep complex page-builder structures and decorative containers under control.
- Inspect the final rendered HTML rather than judging the editor interface alone.
- Test important layouts on mobile and desktop.
6. CSS Delivery: Block Themes vs Classic Themes
CSS delivery illustrates why theme architecture should not be treated as a performance ranking.
Classic themes may use a primary stylesheet, multiple component stylesheets, inline CSS, plugin-generated CSS, or conditional assets depending on how they are built. Some classic themes are highly selective about asset loading, while others ship styles that are not needed on every page.
Block themes can use global styles, block styles, theme.json-generated styles, inline output, theme stylesheets, and block-specific assets. The exact output depends on the WordPress version, theme architecture, blocks present on the page, plugins, and customization.
Therefore, statements such as "block themes always load less CSS" or "classic themes always use one large stylesheet" are too broad to be useful.
When reviewing either architecture, inspect:
- Total CSS delivered
- Number of CSS resources
- Render-blocking stylesheets
- Unused CSS
- Global and block-specific styles
- Plugin-generated CSS
- Critical content above the fold
For deeper asset-delivery analysis, continue with the CSS Performance Optimization Guide.
7. How to Compare Theme Architectures on a Real Project
Instead of publishing a synthetic performance benchmark, compare block and classic themes according to the actual requirements of the WordPress project.
Recommended evaluation criteria
- Use the same project requirements for both candidates.
- Compare how each theme handles templates and reusable components.
- Review editor experience for the people who will manage the site.
- Review required plugins and dependencies.
- Compare custom-development requirements.
- Check accessibility and semantic output.
- Review update history and WordPress compatibility.
- Inspect the rendered HTML, CSS, and JavaScript.
- Review the maintenance workflow for future developers.
- Test representative mobile and desktop pages after implementation.
Useful technical observations can include:
- Template structure
- Required plugins
- CSS and JavaScript delivery
- DOM structure
- Accessibility
- Editor flexibility
- PHP customization requirements
- Pattern and template-part reuse
- Upgrade and maintenance workflow
If you later run a genuine performance experiment, document the environment, theme versions, WordPress/PHP versions, plugins, page content, caching state, methodology, test runs, results, and limitations separately. That evidence should not be generalized into an architectural rule.
For server-side performance context, see our guide explaining how TTFB affects website performance.
8. How to Build a Maintainable WordPress Block Theme
1. Keep the Block Structure Simple
Use the fewest layout containers necessary to achieve the desired design. Avoid creating several layers of nested Group blocks when a simpler structure provides the same layout and editing experience.
2. Use theme.json Deliberately
Centralizing design tokens such as typography, colors, spacing, and layout widths can make a block theme easier to maintain. Define the settings and presets the site actually requires rather than exposing unnecessary design options to editors.
3. Audit Plugins and Third-Party Assets
A clean theme architecture can still become difficult to maintain if plugins add overlapping block libraries, duplicate style systems, large JavaScript bundles, tracking tools, or unnecessary dependencies.
4. Establish a Pattern and Template-Part Strategy
Reusable block patterns can make recurring layouts easier to manage. In current WordPress Site Editor workflows, template parts such as headers and footers are managed from the Patterns area. Establish naming and usage conventions so editors know which patterns and template parts are intended for production use.
5. Control Typography and Design Tokens
Use a consistent design system instead of allowing every page to introduce arbitrary fonts, colors, spacing values, and layout widths.
6. Use Caching According to the Application
Theme architecture does not replace normal WordPress caching. Full-page caching and persistent object caching can still be relevant depending on the site's workload and hosting environment.
Our guide to Redis vs. Memcached object caching provides additional technical background.
9. When Should You Choose a Block Theme?
A block theme can be a strong choice when visual site editing, reusable patterns, centralized global styles, and modern WordPress editing workflows are important.
- Content-focused websites
- Blogs and publications
- Sites where editors need control over templates and site-wide design areas
- New projects adopting the modern WordPress editing model
- Sites that benefit from reusable block patterns
- Projects where centralized design controls are useful
- Teams that want more site-level layout work handled inside the editor
The primary architectural advantage is not guaranteed speed. It is the integration of templates, patterns, blocks, global styles, and visual site editing within the modern WordPress editing system.
10. When Does a Classic Theme Make Sense?
Classic themes remain useful when a project depends heavily on traditional PHP templates, custom theme logic, established development systems, existing child-theme customizations, or compatibility with workflows built around the classic theme architecture.
- Legacy WordPress projects
- Highly customized PHP templates
- Sites with established classic-theme development workflows
- Projects requiring specialized server-rendered template logic
- Teams maintaining existing custom themes
- Projects where migrating to a block-theme architecture would add complexity without a clear benefit
Choosing a classic theme does not mean the project is outdated or poorly engineered. The important question is whether the architecture remains maintainable and appropriate for the site's requirements.
11. Migrating From a Classic Theme to a Block Theme
Switching theme architecture should be treated as a site migration, not merely a visual redesign.
Before changing architectures, review:
- Custom PHP templates and child-theme overrides.
- Widget areas and classic navigation menus.
- Customizer settings.
- Shortcodes and theme-specific blocks.
- WooCommerce template overrides.
- Custom post-type templates.
- Hooks and filters tied to the old theme.
- Schema or analytics code added through theme files.
- Accessibility and responsive behavior.
Build and test the replacement on staging before switching production. A block theme can reduce dependence on some PHP templates, but it does not automatically migrate custom logic from a classic theme.
Also separate content from theme-owned presentation before migration. Check whether shortcodes, custom blocks, custom post metadata, navigation behavior, schema, analytics, widgets, or layout logic disappear when the old theme is deactivated. Keep a tested rollback path and export or document important Customizer/theme settings before switching.
12. Theme Selection Checklist
- Choose based on project requirements: Do not select a theme solely because it is labeled block, FSE, classic, lightweight, or SEO-friendly.
- Review the template architecture: Understand whether future changes will happen through the Site Editor, PHP templates, child themes, or theme-specific systems.
- Check the actual output: Inspect HTML, CSS, JavaScript, images, fonts, and network requests.
- Review editor requirements: Determine how much layout control content editors should have.
- Check accessibility: Validate headings, navigation, contrast, keyboard interaction, labels, and semantic structure.
- Review maintenance: Check update history, current WordPress 7.1 compatibility, documentation, dependencies, and support.
- Audit plugins: Determine which additional plugins or block libraries the theme expects.
- Review customization strategy: Decide whether changes belong in
theme.json, patterns, custom blocks, CSS, a child theme, or custom PHP. - Test representative pages: Validate the complete implementation before committing to the architecture.
13. Commercial Theme and Design Resource Evaluation
If you are evaluating commercial themes or design resources, subscription libraries and individual theme marketplaces offer different licensing, update, support, and purchasing models. Keep that purchasing decision separate from the architectural question of block vs classic themes.
Do not assume that a theme is technically superior simply because its marketplace listing uses terms such as "fast," "SEO friendly," "FSE ready," or "optimized." Review the actual theme architecture, required plugins, demo output, update history, documentation, accessibility, customization model, and licensing terms before deployment.
Also determine whether you are purchasing a complete theme, a template kit, design assets, or another type of resource. These products can require different WordPress tooling and implementation workflows.
For a broader purchasing comparison, see our guide to Envato Elements vs. Envato Market.
14. Block Theme vs Classic Theme Decision Matrix
| Project Type | Architecture to Evaluate First | Reason |
|---|---|---|
| New content-focused site | Block theme | Site Editor, patterns and global Styles can reduce theme-file editing. |
| Existing custom PHP theme | Classic theme may remain appropriate | Avoid migration cost unless the Site Editor provides a clear operational benefit. |
| Editorial team needs site-wide visual control | Block theme | Templates, Styles, patterns and template parts can be managed in the editor. |
| Highly specialized PHP template logic | Classic or hybrid approach | Existing hooks, filters and template logic may be simpler to retain. |
| WooCommerce store | Test both against required WooCommerce features | Compatibility with Woo blocks, templates, extensions and checkout customizations matters more than theme label alone. |
| Agency maintaining many sites | Standardize on the model the team can support consistently | Maintenance, documentation and editor governance can outweigh architecture preference. |
15. Final Decision: Block vs Classic Theme Architecture
There is no universal technical winner between WordPress block themes and classic themes.
Block themes are particularly attractive for Site Editor workflows, reusable patterns, global design controls, block-based template composition, and projects adopting WordPress's modern editing architecture.
Classic themes remain practical for established PHP workflows, existing custom themes, specialized template logic, legacy projects, and teams that prefer traditional theme development.
Performance should be evaluated separately from architectural preference. Plugins, JavaScript, CSS, images, fonts, caching, hosting, database workload, page composition, and third-party services can affect either type of theme.
For headless architecture decisions, compare the WordPress REST API vs WPGraphQL guide. Hosting selection should remain a separate infrastructure decision rather than a deciding factor in block-vs-classic theme architecture.
The better approach is therefore to choose the architecture that fits the site's editing model, customization requirements, content structure, development workflow, compatibility requirements, and long-term maintenance strategy.
For stores, verify WooCommerce template/block compatibility and extension behavior on staging before changing theme architecture. Theme selection should not be used as a substitute for WooCommerce performance work such as PHP/database capacity, caching and frontend optimization.
Evaluate the Actual Theme Implementation Next
After choosing block or classic architecture, compare individual themes by rendered output, required plugins, accessibility, update history, editor workflow and maintenance—not by the label alone.
Review Lightweight WordPress Themes →Frequently Asked Questions
What is the main difference between a block theme and a classic theme?
A block theme uses block-based templates and supports the Site Editor for site-wide editing. A classic theme primarily uses PHP templates and traditional theme architecture, although classic themes can still use modern features such as theme.json.
Is Full Site Editing a separate WordPress theme type?
No. WordPress documentation distinguishes block themes and classic themes. “Full Site Editing” describes the broader site-editing capabilities associated with block themes and the Site Editor rather than a third theme type.
Can a classic theme use theme.json?
Yes. theme.json is not exclusive to block themes. Classic themes can use it to configure settings and styles for blocks and the editor.
Are block themes faster than classic themes?
Not inherently. Performance depends on the specific theme implementation, plugins, images, fonts, scripts, caching, hosting and page composition.
Can classic themes use the Site Editor?
No. Current WordPress documentation says the Site Editor is available with block themes. A classic theme can enable the Template Editor for post/page templates, but that is not the same as the full Site Editor and does not turn the classic theme into a block theme.
Does a block theme require theme.json?
No. theme.json is common and strongly useful for modern theme configuration, but WordPress documentation does not define a block theme by the presence of theme.json. The defining architecture is block-based templates, including the block-template index.html.
What did WordPress 7.1 add for theme styling?
WordPress 7.1 added responsive block style states and configurable viewports, along with additional Global Styles capabilities. These features strengthen modern block-based design workflows but do not make block themes automatically faster or more suitable for every project.
Should an existing classic-theme site migrate to a block theme?
Only when the benefits justify the migration work. Review PHP template customizations, child themes, widget areas, Customizer settings, WooCommerce overrides, shortcodes and theme-specific dependencies before changing architectures.
Abdul Shakoor
Founder of Digital Bhatti, an independent technical publication focused on web hosting and infrastructure, WordPress, technical SEO, web performance and automation.