Block themes changed how WordPress sites are built. Instead of PHP templates and a separate page builder, the whole layout — header, footer, templates, patterns — lives inside the block editor. That sounds lighter, and it can be. But it can also go the other way: a block theme with heavy global styles, dozens of patterns, and unoptimized fonts can be just as slow as the bloated classic theme it replaced.
The difference is rarely the theme itself. It is how much work the theme asks the browser to do on every page, and how much of that work is actually needed for what the visitor sees. Get that balance right, and full site editing gives you a fast, maintainable site without a page builder in sight.
Why Block Themes Behave Differently
A classic theme usually ships one big stylesheet and a set of template files. A block theme works differently in two important ways.
First, styles are generated from theme.json. Every color, font size, spacing value, and layout setting you define in theme.json becomes CSS. That is convenient, but it also means sloppy settings accumulate: duplicate color palettes, unused font sizes, spacing presets nobody uses. The browser still downloads and parses all of it.
Second, WordPress loads CSS per block. In theory, only the blocks used on a page should load their styles. In practice, many themes and plugins register styles globally, or a page uses so many different blocks that the “only what you need” advantage disappears. A landing page built from twenty different blocks can easily pull in more CSS than a simple classic theme.
None of this makes block themes slow by default. It just means the usual speed advice needs a block-specific twist. You cannot fix a block theme by applying a generic optimization checklist and hoping for the best. You have to look at what your theme actually outputs.
Measure Before You Change Anything
Before touching a setting, get a baseline. Run your homepage and one typical inner page through PageSpeed Insights, and note the Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift figures, plus the total page weight and request count. Then open the same pages in your browser’s developer tools, on the Network tab, and sort by size. You will usually see the same suspects: a large stylesheet, a font file, a hero image, and a handful of scripts.
Repeat the test after each change, one change at a time. If two changes go in together and the score improves, you will not know which one did the work — or which one broke something subtle, like a pattern layout on mobile. For a repeatable testing routine, see our guide on how to test your WordPress site speed the right way.
Pay special attention to mobile results. Block themes are responsive by design, but wide template layouts, large pattern grids, and full-width images that look fine on a desktop monitor can be punishing on a phone. Test on a real device or a properly throttled mobile emulation, not just a resized desktop browser window.
Trim Global Styles in theme.json
theme.json is the single biggest lever you have. Open it and audit it the way you would audit a plugin list: if a setting is not used, it should not be there.
Start with the color palette. Many starter themes ship ten or more colors, plus gradients and duotone presets. Keep the palette to the colors your design actually uses — usually four to six. Do the same for font sizes: a scale of five or six sizes covers almost every layout, while a scale of twelve just adds CSS for sizes nobody picks.
Next, check spacing and layout settings. Generous spacing presets are harmless in the editor, but every preset becomes a utility class in the generated stylesheet. The same goes for custom block styles and variations. Each variation you register adds CSS, even if it is only used on one page. Remove the ones you tried once and never used again.
If your theme supports it, disable the features you do not need. For example, if you never use custom gradients or duotone filters, turning those settings off in theme.json stops WordPress generating their styles entirely. The savings on a single page are small, but they apply to every page on the site, which is exactly the kind of win that adds up.
One caution: do not edit theme.json on a live site without a backup, and do not edit a theme you did not build without checking whether updates will overwrite your changes. A child theme, or a theme built for customization, is the safe place for these edits.
Control How Block CSS Loads
WordPress is supposed to load only the styles for blocks present on a page. You can help it do that job properly.
First, audit your patterns. Patterns are convenient, but a pattern that combines a cover block, a gallery, columns, buttons, and a query loop pulls in the styles for all of those blocks at once. Reusing the same pattern everywhere is efficient; using a different elaborate pattern on every page is not. Standardize on a small set of patterns and reuse them.
Second, watch for plugins that register block styles globally. Some block plugins load their CSS on every page whether their blocks are used or not. If you find one, check its settings for an option to load assets only when needed, or replace it with a lighter alternative. Our guide to choosing a fast WordPress theme covers the same audit mindset for themes.
Third, be careful with the Query Loop block. It is powerful, but a query that pulls dozens of posts, each with a featured image and excerpt, can be heavy on both the database and the page weight. Limit the number of posts shown, use appropriately sized featured images, and avoid nesting query loops inside each other.
Finally, test the “should load separated styles” behavior after major WordPress updates. Core changes how block styles are enqueued from time to time, and a setting that worked in one version may behave differently in the next. A quick re-test after updating is cheaper than debugging a regression later.
Keep Templates and Patterns Lean
Full site editing makes it tempting to build elaborate templates: a header with three rows, a hero with layered blocks, a footer with four widget areas and a pattern for each. Every block in a template adds markup, and nested blocks add depth to the document structure. Deep nesting is one of the quieter causes of slow rendering, especially on lower-end phones.
Keep templates simple. One header row usually does the job of three. A footer with two areas is easier to maintain than one with five. Where a design calls for a complex section, ask whether it needs to appear on every page or only on one template. A heavy hero pattern on the homepage is a fair trade; the same pattern repeated on every blog post template is not.
The same discipline applies to reusable blocks and synced patterns. They are excellent for consistency, but a synced pattern that gets edited into something heavier quietly makes every page that uses it heavier too. Review your most-used patterns once in a while and strip out blocks that no longer earn their place.
Fonts: The Hidden Cost in Block Themes
Block themes lean heavily on typography settings, and typography usually means web fonts. A theme that loads three font families, each in several weights, can easily add hundreds of kilobytes and a render-blocking request chain to every page.
Limit yourself to two font families at most — one for headings, one for body text — and only the weights you actually use. If your design uses regular and bold, do not load light, medium, semibold, and extra-bold as well. Then host the fonts locally instead of pulling them from an external service on every visit; our guide explains the local-hosting method step by step.
Set font-display to swap so text renders immediately in a fallback font while the web font loads, and preload only the single most important font file — usually the regular body weight. Preloading every weight defeats the purpose. Finally, check your theme.json font settings after changing fonts: old font families that are no longer used sometimes linger in the settings and keep generating requests.
Images, LCP, and the Hero Block
In most block themes, the Largest Contentful Paint element is a cover block or a large featured image. That makes image handling the fastest route to a better LCP score.
Never lazy-load the hero image or the cover block at the top of the page. WordPress normally excludes the first image from lazy loading, but cover blocks and background images can slip through that protection, so verify with a test rather than assuming. Use a modern format and a properly sized image — a 2400-pixel-wide image displayed at 800 pixels is wasted bandwidth on every visit, and it is especially costly on mobile connections.
If your hero uses a background image rather than an image block, remember that background images cannot be lazy-loaded or prioritized the same way. Where the hero image matters for LCP, an image block with fetchpriority set to high is the safer choice. And keep the hero simple: a cover block with an image, a heading, and a button paints far faster than a cover block stacked with nested columns, overlays, and animated patterns.
JavaScript: Less Than You Think
Block themes themselves need surprisingly little JavaScript on the front end. The editor is heavy, but visitors never load the editor. Most front-end JavaScript on a block-theme site comes from plugins: sliders, animation libraries, form builders, social feeds, and analytics.
Audit that list ruthlessly. A slider plugin used on one page should not load its scripts site-wide. An animation library used for a single fade-in effect is rarely worth its weight. Where a plugin offers per-page asset control or delayed loading, use it; where it does not, consider whether the feature earns its cost. Our guide to reducing JavaScript execution time walks through measuring script costs and cutting them safely.
Also check for duplicate functionality. It is common to find a theme, a block plugin, and a separate optimization plugin all trying to handle the same job — lazy loading, for instance. Duplication does not just waste bytes; it can cause conflicts that are hard to trace. Pick one tool per job and disable the rest.
Caching Still Matters
None of the above replaces caching. A block theme still benefits from page caching, browser caching, and, on larger sites, object caching exactly like a classic theme does. The difference is that block-theme markup is generated from templates at request time, so a good page cache has more work to save you from — which makes it more valuable, not less.
Make sure your caching plugin is not excluding block-theme pages by mistake, and that cache purging works when you edit a template or a synced pattern. There is little point in a fast template edit if visitors keep seeing the cached old version for hours. After changing theme.json, clear the page cache and any CSS cache your optimization plugin holds, since generated styles are often cached separately from page HTML.
When a Block Theme Beats a Classic Theme
For all these cautions, a well-built block theme has real speed advantages. There is no page builder output to clean up, no shortcode processing, and no theme-options framework injecting scripts. Styles are generated from a single source of truth, which means removing a setting actually removes its CSS — something that is rarely true of a classic theme with a sprawling options panel.
The sites that get the most from block themes are the ones that embrace that simplicity: a small set of patterns, a tight theme.json, two fonts, and a short plugin list. If your block theme currently feels slower than the classic theme it replaced, the cause is almost never full site editing itself. It is the accumulated weight of settings, patterns, and plugins that nobody has audited since the site was built.
A Practical Audit Checklist
Work through this list on a staging copy first, then move the changes live one at a time:
- Record baseline scores for the homepage and one inner page.
- Trim the theme.json color palette, font sizes, and spacing presets to what the design uses.
- Disable unused theme.json features such as gradients or duotone filters.
- Standardize on a small set of reusable patterns and simplify templates.
- Reduce fonts to two families and only the weights in use, hosted locally.
- Fix the hero image: right size, modern format, never lazy-loaded.
- Audit plugin JavaScript and remove or delay anything non-essential.
- Confirm page caching and cache purging work after template edits.
- Re-test and compare against the baseline before moving on.
That audit usually takes an afternoon, and it tends to surface two or three changes that matter far more than any optimization plugin setting. Block themes reward the same discipline that makes any WordPress site fast: load only what the page needs, and prove it with a test after every change.