How to Remove Gutenberg CSS in WordPress: Clean Unused Code

By default, WordPress loads wp-block-library.css across every single page of your site. If you aren't actually building with the Gutenberg block editor, that stylesheet is just dead weight sitting in your header, quietly tanking your First Contentful Paint score for zero return.

The Decision Framework: When to Remove Block Library CSS

Going in blind and disabling core WordPress styles is practically an invitation for broken layouts. Before you touch your functions file, you really want to check how your theme is built behind the scenes. Run through this quick breakdown first:

Classic Themes vs. Full Site Editing (FSE)

Modern block themes depend heavily on the Gutenberg framework to render practically everything, from headers and navigation down to footers. If you're on a full-blown FSE theme, stripping out the block library will immediately wreck your visual layout.

Classic themes, on the other hand, handle their own styling through a traditional style.css file. If you're running a classic setup with legacy widgets and drafting posts through the Classic Editor plugin, you can strip these Gutenberg assets without sweating it.

Page Builders and ACF Custom Themes

If your site leans on page builders like Elementor or Divi, they already generate their own styling grids and font rules anyway. Gutenberg's default styles keep loading quietly in the background without ever getting used.

You'll run into the exact same pattern with custom themes built around Advanced Custom Fields. When your template files handle the layout work directly, those core WordPress block styles are just unnecessary overhead dragging down your server response times.

Method 1: Remove Gutenberg CSS via Code

Dropping a clean snippet into your child theme is easily the most straightforward way to stop WordPress from loading assets you don't need. You can paste this right into your child theme's functions.php file or drop it into a snippets plugin like WPCode.

Dequeue Default wp-block-library and Global Styles

The core block library and those inline global styles eat up the most bandwidth here. You can tell WordPress to drop them entirely by hooking straight into the wp_enqueue_scripts action hook.

PHP

add_action( 'wp_enqueue_scripts', 'devcrea_remove_gutenberg_css', 100 );
function devcrea_remove_gutenberg_css() {
    wp_dequeue_style( 'wp-block-library' );
    wp_dequeue_style( 'wp-block-library-theme' );
    wp_dequeue_style( 'wc-block-style' );
    wp_dequeue_style( 'global-styles' );
    wp_dequeue_style( 'classic-theme-styles' );
}

We bump the priority up to 100 so your snippet runs after WordPress registers its default styles (which normally fire around priority 10). If you leave it at the default, the core handles will register anyway before your snippet gets a chance to intercept them.

Keep an eye on classic-theme-styles, which WordPress introduced in version 6.1 to inject basic block formatting into older themes. It’s totally safe to drop on clean custom themes, but leave it alone if your setup leans on core defaults for paragraph margins or basic image alignment.

Disable Inline SVG Filters

WordPress also likes to dump a massive block of inline SVG code right after your opening body tag just to support duotone color filters. If you already color-correct your photos in an image editor before uploading them, you honestly don't need this SVG block loading on your site.

PHP

remove_action( 'wp_body_open', 'wp_global_styles_render_svg_filters' );
remove_action( 'in_admin_header', 'wp_global_styles_render_svg_filters' );

Removing Specific WooCommerce Block Handles

WooCommerce bundles its own collection of block styles that hook into every single page by default. If your shop uses standard WooCommerce shortcodes rather than the newer block-based cart and checkout flows, you can safely strip those handles out. Throwing wc-blocks-style and wc-blocks-integration into your dequeue function will keep your store pages considerably lighter.

Surgical CSS Removal (Per-Block Dequeue)

If you'd rather not take an all-or-nothing approach, you can be more selective about what you drop. This route lets you ditch CSS for bulky layout blocks you never touch while keeping the styles for standard content elements. If you only ever write with headings and paragraphs, you can safely dequeue styles for heavy containers like columns or galleries.

PHP

add_action( 'wp_enqueue_scripts', 'devcrea_remove_specific_blocks', 100 );
function devcrea_remove_specific_blocks() {
    wp_dequeue_style( 'wp-block-columns' );
    wp_dequeue_style( 'wp-block-gallery' );
}

Method 2: Clean Unused CSS Using Performance Plugins

If digging through PHP files makes you nervous, you can get the exact same outcome using a solid optimization plugin with a clean dashboard. Perfmatters gives you a quick toggle called "Remove Global Styles" that clears out theme.json overhead in one click.

Another great pick is Asset CleanUp, which lets you audit every stylesheet loading on any given URL and disable Gutenberg assets site-wide or on single pages. Under the hood, these plugins just trigger the same dequeue functions based on your settings.

Measuring the Impact: Did It Actually Improve Performance?

Cleaning up codebase clutter always feels satisfying, but you want actual numbers to prove the change was worth making. That's why you should check your page weight before and after touching these styles.

Using DevTools Coverage Tab to Identify Dead CSS

Fire up Google Chrome, pull up your heaviest post, hit F12 to pop open Developer Tools, and press Ctrl+Shift+P to search for "Coverage." Hit the refresh icon to let the tool record the load sequence, then track down wp-block-library.css in the list. More often than not, you'll see a solid red bar showing that 95% to 100% of that stylesheet was never even touched by the browser.

Before and After: PageSpeed Insights and FCP Metrics

Run your page URL through PageSpeed Insights before changing anything and jot down your baseline First Contentful Paint (FCP) time. Once your snippet is live, purge your server caches and test the page again. Dropping that inline global-styles payload usually trims about 40 to 60 milliseconds off the initial render path, which gives your Core Web Vitals a nice, noticeable lift.

Breaking Changes and Rollback Steps

The main snag with killing global styles is that it can break custom CSS variables, particularly if your classic theme grabs color presets defined by theme.json. You'll see this crop up a lot on sites setting up CSS dark mode using custom properties, because those variables frequently depend on the global-styles output. If your buttons suddenly go transparent or your font sizes shrink out of nowhere, you’ve cut a little too deep.

If things go sideways, just pull the dequeue snippet out of your functions file right away. Clear your WordPress caching plugin completely, then purge your CDN cache if you're on Cloudflare. Open an incognito window to verify the styling is back where it should be, and make sure your browser isn't simply holding onto an older cached version of the broken page.

How to Verify and Troubleshoot

Once the snippet is in place, open up your site in a private browsing window. Right-click anywhere, hit "View Page Source," and run a quick Ctrl+F search for wp-block-library. If nothing comes back, your dequeue setup is doing its job.

If PageSpeed Insights is still flagging an "unused CSS" notice, you're almost certainly looking at an old cached version of the page. Clear out your WordPress page cache, wipe your server-level caching layers, and purge your CDN, then rerun the test inside a fresh incognito tab.

If your Media Library suddenly shows a blank grid, don't worry - that's an entirely separate issue usually triggered by a REST API conflict or JavaScript glitch rather than missing CSS. If your admin thumbnails ever stop loading after updating a plugin or clearing your cache, WordPress Media Library images not showing covers the most reliable troubleshooting steps to get them back.

If the site looks broken after removal: Bring the handles back into your setup one at a time so you can pinpoint which file your theme actually misses. The two most common offenders are global-styles (which handles CSS variables and color palettes) and classic-theme-styles (which handles basic block spacing on modern WordPress releases). Keep whatever single file your theme relies on, and leave the rest disabled.