A client came to me with a busy e-commerce site, lots of moving parts, and performance that was dragging, especially in the backend. They were frustrated, and fair enough. It turned out another team had built the pages with just about every WordPress core block under the sun, on the theory that “core equals good.” On a site handling thousands of products and custom data, that assumption bites you hard.
The instinct for a lot of people, me included early on, is to lean into whatever WordPress hands you. Core blocks are right there and they are convenient, so what could go wrong? Plenty. It is easy to assume that because a block is ‘core,’ it is tuned for every use case. Not always, man. That is where the bloat creeps in, render times climb, and your admin panel starts to crawl.
This came up in a recent WordPress Dev Chat on November 19, 2025, where the talk about core block decisions landed on a simple point: not every core block is useful to everyone. The ‘Math block’ is the obvious case. It is niche, and for most sites it is dead weight. It still ships, and if you are not careful it loads along with everything else.
Choosing which WordPress core blocks to keep
So what is the practical approach? Be intentional. When a new WordPress version lands, like the upcoming 6.9 with its improvements to the Interactivity API and changes to the post editor, take a moment to evaluate rather than absorbing everything by default. Does the client’s site actually need what a new block does? Or is it just more weight on the page for no real gain?
On that client’s store, we found several core blocks that just were not needed. The default ‘Archives’ block, for instance, when they already had custom taxonomy archives, or ‘Tag Cloud’ when their navigation handled all the tagging. Every block, core included, ships its own CSS, JavaScript, and markup. Multiply that across dozens of blocks you never use and you have a real problem. The fix is not always a custom block built from scratch. Sometimes it is knowing what to remove.
Here is a simple way to unregister a core block you know you will not use. Drop it in your theme’s functions.php or a small custom plugin. Trust me, a little housekeeping goes a long way:
<?php
/**
* Remove specific core blocks.
*
* @return void
*/
function bbioon_unregister_specific_core_blocks() {
// Example: Unregister the 'Archives' block.
unregister_block_type( 'core/archives' );
// Example: Unregister the 'Tag Cloud' block if not used.
unregister_block_type( 'core/tag-cloud' );
// Add more blocks as needed based on your site's requirements.
// For instance, if you don't need the Math block (as discussed in dev chat)
// unregister_block_type( 'core/math' ); // Hypothetical block
}
add_action( 'init', 'bbioon_unregister_specific_core_blocks' );
?>The snippet looks trivial, but it makes a real difference to performance and to how cluttered the admin feels. Pruning core blocks you do not use means less code loading, fewer chances for conflicts, and a lighter, faster site. You decide which features your content creators see, instead of leaving that to WordPress by default.
The real cost of convenience
Convenience has a cost when nobody is watching it. WordPress core blocks are useful, but pulling in all of them without a second thought is how a site ends up bloated and slow. Before a block loads, ask whether the project actually needs it. That one habit keeps a site lean without much effort.
This stuff gets complicated fast. If you are tired of debugging someone else’s mess and just want your site to work, drop my team a line. We have probably run into it before.
