Assuming I have no infinite scroll or anything else going on in my theme: Is there a way to enqueue my custom Gutenberg block styles and scripts so they are only (lazy) loaded in the front-end when the block is really used? Something like is_active_widget, just for blocks?

If I enqueue them inside a enqueue_block_assets function they're added to any site.

On github, I found this https://github.com/WordPress/gutenberg/issues/5445 , but it sounds like it's more on bundling than conditional load, so I still hope they didn't leave that optimization opportunity out - otherwise any other site will soon be junked with 20 additional scripts from numerous Gutenberg block plugins people install and only use once on a page (think of large image gallery block scripts for example).

Thanks & Regards!

4 Answers 4


Well, the styles and scripts you register in your php register_block_type call should only be loaded when the block is in use if i recall correctly.

If you want to load additional scripts or styles to be enqueued only if there is a block of type "my-awesome/block-type", you can use the has_block function in your wp_enqueue_scripts function like this:


function enqueue_if_block_is_present(){
     //We only want the script if it's a singular page
     $id = get_the_ID();

If you also want the script to be loaded on multiple views as well (like category archive or the blog page), you can hook into the the_content filter and enqueue the script there:


function enqueue_my_awesome_script_if_there_is_block($content = ""){
   //Be aware that for this to work, the load_in_footer MUST be set to true, as 
   //the scripts for the header are already echoed out at this point
   return $content;

Happy Coding!


Another way is to enqueue them inside the block's render_callback() function.

register_block_type( 'mkaz/test-block', array(
    'editor_script'   => 'mkaz-test-block-script',
    'render_callback' => function( $attribs, $content ) {
        wp_enqueue_script( 'mkaz-test-block-client-asset' );
        return $content;
) );

In the past it was invalid to enqueue stylesheets outside of <head>, but that's supported by the spec now.

x-ref: https://github.com/WordPress/gutenberg/issues/21838

  • Strangely enough apparently the render_callback is executed even on the Admin console when the content is being edited, so an if ( ! is_admin() ) { ... } check may need to be wrapped around the wp_enqueue_script(...), if one only wants to enqueue that script when the block is being rendered in the frontend. Commented Oct 13, 2020 at 17:25
  • I think that's because of github.com/WordPress/gutenberg/issues/18394
    – Ian Dunn
    Commented Oct 14, 2020 at 21:29

Thanks @kuchenundkakao for pointing me into the right direction. I'm still answering my own question as I want to give some more context for others that may stumble upon this.

So, there are several ways to load your custom blocks, mainly:

While registering the block in PHP (like described in the handbook) is the default method and future proof, the enqueue_block_assets variant can load multiple blocks without the need to split your blocks into seperate files and define them again in PHP. "create_guten_block" for example merges any number of blocks into three files by default (blocks.build.js, blocks.editor.build.css and block.style.build.css).

Both ways do not conditionally load styles (yet).

When using the create_guten_block method, enqueue_block_assets, and only having a single block defined (or set up to split the files per block), the conditional loading can be added using has_block:

    function my_awesome_blocks_cgb_block_assets() {
      if (is_singular()) {
        $id = get_the_ID();
        if (has_block('my-awesome/block-type', $id)) {
              plugins_url( 'blocks/dist/blocks.style.build.css', __FILE__ ),
    add_action( 'enqueue_block_assets', 'my_awesome_blocks_cgb_block_assets' );

You can combine register and conditional loading by leaving out the style / script parts in the register and load the according fontend files with enqueue_block_assets as in the code above.

The future proof method will be using register_block_type, as the script and style fields of it will most likely be used if conditional loading is ever implemented natively (see comment here).

  • and where does the register_block_type go? is it just left out? @user127091
    – user9
    Commented Apr 4, 2020 at 15:42
  • 1
    seems not to work when the block is converted to a reusable block!
    – Nic Bug
    Commented Jun 27, 2023 at 8:06
  • Correct, the has_block() function currently cannot detect what blocks are used within a reusable block since the Gutenberg markup for the reusable block contents doesn't live on the page—it only contains a reference to the reusable block reference ID. Example of reusable block Gutenberg markup '<-- wp:block {"ref":23393} /-->' Commented Nov 7, 2023 at 21:28

The solution from @IanDunn works, but only for custom blocks, since you overwrite the render callback of existing blocks otherwise. You can use the render_block_{$this->name} hook to include your script/stylesheet conditionally and check for all the block attributes whether your conditions apply.

An example conditionally adding a style for the core/group block:

static function my_group_callback( string $block_content, array $block ): string {
    if ( ! $condition ) { // check your condition
        return $block_content;
    \wp_enqueue_style( 'my-handle', $uri ); // adjust handle and uri
    return $block_content;

\add_action( 'render_block_core/group', 'my_group_callback', 10, 2 );

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.