Do too many block library plugins affect speed?
Activating two block library plugins is an OK thing to do. On BlockClones.com, we’re using the following four block plugins:
- Conditional Blocks
- Kadence Blocks
These may not be the final plugins we use. But it’s what we’re using now. They all play nice together and don’t cause extra slowdowns of any sort. So far.
Here’s the good news. In Gutenberg releases before 10.1, styles for blocks are enqueued in a single file. That caused extra page load. Today, they load only what’s necessary when viewing content.
The WordPress development team made it so blocks only load when and where used. We’ve tested over 80 block library plugins for site drag. That is global loading even when not used on a page. For the 73 block libraries we found that work, the results are here:
The numbers generated are with no block plugins activated. We tested with the Pingdom speed tool for changes. Any block with a load time listed below 176ms is transparent. When remove the boilerplate overhead, there are zero delays. That’s in the column labeled “Time ms.” Worst-case plugins are at the top (avoid those). 40 of the plugins toward the bottom cause no extra loading on the page or posts.
This is fantastic news for speed and hasn’t made press yet on blogs.
Selective activation is inherent in blocks now. And many block plugins add no slowdowns at all. But not all. Always test.
So how much does using a block slow a site page?
This is unknown. We only were testing an “empty” page with only one block plugin activated – and no blocks used on the page.
Do more blocks cause more drag?
With no blocks activated, 1 to 50 block features may exist in a library. But the results are the same as if activating none.
We review the plugins we use while making “clone” example sites. These are reverse-engineering case studies. We take an existing site and get the “look” using block-cloning techniques.
Should you create all blog posts in the block editor even if it’s only text and some images?
Yes. Standardize for efficiency and simplicity. You’ll love the editor once you get through the learning curve. We’ve been hardcore fans of Classic Editor simplicity. But we’re convinced now the block editor is better and continues to improve. Not using it will become a liability as time goes on.
We are supporting the Astra theme. It’s fast but also “feature-rich.” They added header and footer features on their last big revision 3.0. They are now on v3.2.0. They also have over 1 million users. The only free themes close (for numbers of users) are created by WordPress. They’re attractive because of their longevity and the support of hundreds of developers.
GeneratePress makes us nervous. If Tom Usborne got run over by a bus, end of story. But if San Francisco fell in the ocean, WordPress still keeps going.
Is it okay to have two block libraries installed and activated?
Yes. It is OK. Beware. We’ve found a few block plugins causing problems. You can’t be sloppy about this. The offenders are not on the list. We know we can have all 73 safe libraries coexist together and not bring down a site. Like any plugin, third-party block libraries can conflict with:
- the theme
- other blocks
- or cause voodoo weirdness
For example, the free Enhanced Blocks plugin wouldn’t work with Astra. Why? Voodoo. Will it work with others? We don’t know. But if it won’t work with Astra, we won’t touch it. It’s deleted from the list.
If blocks have overlap or redundancy, deactivate the duplicates you don’t use. But you may not even need to do that. The block editor is babysitting block activation only when used on a page. It’s smart.
Uncompressed download file size is indicative of plugin potential slowness. The smaller – the lighter. The bigger – the more bloated and slow.
This is not the case with block library plugins. There is no direct correlation between site speed overhead and package weight. We can’t make speed judgments by megabyte package size anymore.