There is an existing option to build the blocks manifest file ( wp-scripts build-blocks-manifest ) that would be a good performance improvement. My suggestion is that Gutenberg enable it by default.

Background

While looking through PHP-SPX trace files for potential performance improvements I came across gutenberg_reregister_core_block_types() as a likely target. It was consistently in the top 10 slowest sections of the PHP code for each WordPress processed request. This surprised me, as it is only called once and the rest of the top 10 items are called many times ( apply_filters ) or are in the top because they are part of the base layer of handling each request ( wp-settings.php ).

After looking over the code I wrote out a quick proof of concept to generate a PHP blocks manifest file. That significantly reduced the amount of time spent in processing gutenberg_reregister_core_block_types(). The exact size of the improvement varied, but in each test run it was sizable and worthwhile. In my tests there were 117 blocks that needed to be processed.

Then it was pointed out that Gutenberg already had a way to build a blocks manifest file - that was done back at the end of 2024. But it was never hooked up to the build process. Being able to require in a single PHP file, that can then included in the opcache, is a solid win.

My request is that wp-scripts build-blocks-manifest be hooked up to the default build process of Gutenberg, so that the manifest file can be shipped in releases. If for some reason the wp-scripts build-blocks-manifest approach isn't acceptable, I'm happy to work on alternatives. The current overhead of gutenberg_reregister_core_block_types() is too high to ignore.