Open the source of a typical WordPress page and you’ll probably find a stylesheet called wp-block-library, sometimes alongside wp-block-library-theme, global-styles and a handful of inline style tags. Together they can add a surprising amount of CSS to every page, much of it for blocks that page doesn’t use. A page with a few paragraphs and a heading might still download the styles for galleries, tables, cover blocks, navigation, search, quotes and dozens more. Most of that block CSS can be trimmed.
How much of that block CSS your pages load depends on whether you use a block theme or a classic theme, a couple of WordPress settings and what your plugins add. Understanding the mechanics lets you cut unnecessary CSS, reduce render-blocking requests and improve load times, especially on mobile.
Where block styles come from
Several layers contribute CSS related to blocks:
- Block library styles: the structural CSS for each core block, such as how columns lay out or how a cover block positions its overlay.
- Block theme styles: optional opinionated styles for core blocks, loaded as wp-block-library-theme when a theme opts in.
- Global styles: CSS generated from theme.json, including presets like colours and font sizes as CSS custom properties, and styles for elements and blocks.
- Block supports: small inline styles generated for individual blocks, such as layout and spacing settings.
- Third-party block styles: CSS for blocks from plugins like WooCommerce, form plugins and block libraries.
Each can be loaded in a combined way, all at once, or separately, only for blocks on the page.
Combined versus separate loading
Historically, WordPress loaded one combined stylesheet, wp-block-library, containing styles for every core block. Simple and cacheable, but wasteful: every page loads everything.
Since WordPress 5.8, WordPress can load styles for each core block separately and only when that block is present on the page. This is controlled by a filter:
Block themes have this behaviour enabled automatically. Because the page is fully rendered from blocks, WordPress knows exactly which blocks appear and loads only their styles.
Classic themes use the combined stylesheet by default. You can opt in to separate loading with the filter above. When enabled, block styles are printed in the footer rather than the head for classic themes, because WordPress doesn’t know which blocks are used until the content has rendered.
Loading in the footer means block styles can arrive after the content is visible, which may cause a brief flash of unstyled blocks. Test carefully on classic themes, particularly with blocks above the fold.
Inlining small stylesheets
WordPress also inlines small block stylesheets instead of loading them as separate files. Inlining avoids extra requests for tiny files, which helps performance, especially on HTTP/1.1 connections. There’s a total size limit for inlined styles, adjustable with a filter:
Raising it inlines more styles, reducing requests but increasing HTML size. The default is a reasonable balance for most sites. Change it only if measurements show a benefit.
Classic themes: what to do
If you use a classic theme that doesn’t use blocks much, for example where content is mostly built with a page builder, you may be loading wp-block-library on every page for no reason.
Check whether any content on the site uses blocks. If posts are written in the block editor, you need block styles on those posts. If the site uses a page builder everywhere and the block editor is disabled, you may be able to remove the block library styles entirely on pages without blocks:
Be careful: widgets, footer areas and template parts may use blocks even when post content doesn’t. Check the whole page after making this change.
The alternative, and often better, approach for classic themes that do use blocks is enabling separate loading with should_load_separate_core_block_assets and testing for layout flashes.
Block themes: already lean, but check plugins
Block themes load only the styles for blocks present on each page. Global styles from theme.json are generated and inlined. That makes block themes efficient by default.
The remaining weight usually comes from plugins. Many plugins enqueue their block styles on every page, whether or not their blocks are used. WooCommerce has improved this significantly in recent versions, loading block styles only where blocks appear, but other plugins vary.
For plugin blocks registered properly with block.json, WordPress can load their styles on demand too. If a plugin enqueues its CSS manually on every page, you may need to dequeue it on pages where its blocks don’t appear, or ask the developer to register styles through block.json.
Global styles and theme.json size
The global styles stylesheet is generated from theme.json. Large palettes, many font sizes, custom presets and per-block style definitions all add to it. A theme that defines fifty colours, twenty gradients and thirty font sizes outputs CSS custom properties for every one of them on every page.
To keep it lean:
- Disable default presets you don’t use, such as the default colour palette, gradients and duotones, with settings in theme.json:
- Define only the presets your design actually uses.
- Avoid duplicating styles in both theme.json and a separate stylesheet.
Measuring block CSS
Use the Coverage panel in Chrome DevTools to see how much of each stylesheet is used on a page. Open DevTools, press Ctrl+Shift+P or Cmd+Shift+P, type “Coverage”, start recording and reload. The panel lists stylesheets with the percentage of unused bytes.
High unused percentages on wp-block-library suggest you’re loading combined styles unnecessarily. Remember that coverage is per page and per viewport: CSS unused on one page may be needed on another or on a different screen size.
Also check Lighthouse’s “Eliminate render-blocking resources” and “Reduce unused CSS” audits, which highlight the biggest offenders.
A practical approach
For block themes:
- Trust core’s on-demand loading.
- Trim unused presets in theme.json.
- Audit plugins that load block CSS globally.
For classic themes using the block editor for content:
- Enable separate core block asset loading.
- Test pages for flashes of unstyled content, especially above the fold.
- Dequeue third-party block CSS on pages that don’t use those blocks.
For classic themes with page builders and no block content:
- Remove block library styles on pages that don’t contain blocks.
- Check widgets and template parts for hidden block usage.
Small gains add up. Removing 30 to 80 KB of unused block CSS from every page reduces render-blocking time, which helps Largest Contentful Paint on mobile, where every kilobyte of CSS delays the first paint.
A note on WooCommerce and other big plugins
Large plugins that ship many blocks can add significant CSS. WooCommerce, for example, provides blocks for products, the cart, checkout, filters and more. Recent versions load their styles more selectively than older ones, but it’s worth checking with the Coverage panel on a few page types: a blog post, a static page, a product page and the checkout. If the blog post loads WooCommerce block styles, a plugin or theme is enqueuing them globally.
Form plugins, slider plugins and block libraries with dozens of blocks are other common sources. Some block libraries let you disable blocks you don’t use in their settings, which removes their styles and scripts entirely. That’s often the easiest optimisation available.
Keep an eye on inline styles
Block supports such as spacing, layout and typography generate small inline style rules for individual blocks. On a page with hundreds of blocks, these can add up in the HTML. They’re usually small and efficient, because WordPress deduplicates them, but heavily customised layouts with per-block overrides produce more. Using theme.json presets and block styles instead of custom per-block values keeps them lean and makes the design more consistent at the same time.
Retest after updates
WordPress core and major plugins regularly change how they load block assets. An update can make a manual dequeue unnecessary, or occasionally make it harmful by removing styles a new version needs. After major updates, reload a few key pages with the Coverage panel open and check that nothing looks broken and no large unused stylesheets have returned.
Start with the heaviest pages
Begin with the templates that get the most mobile traffic, usually the homepage, blog posts and product pages. Trimming block CSS there gives the biggest real-world benefit for the least effort.
Frequently asked questions
Is it safe to remove wp-block-library?
Only on pages that don’t contain blocks anywhere, including widgets and template parts. Removing it from pages with blocks breaks their layout.
Does separate loading hurt caching?
Slightly, because more small files are involved, but WordPress inlines many of them. For most sites, loading less CSS outweighs the caching difference.
Will this affect the block editor?
No. These changes affect the front end only. The editor loads its own styles.
Do optimisation plugins handle this?
Many optimisation plugins offer options to remove unused CSS, which can include block styles. They work by different means and need testing, but they can complement these settings.
