Preloading of ACF block pattern

@lgladdy I add this issue for improvement requests after ACF 6.0 release.

I see how nicely the preloading of ACF blocks in the editor now works. That's really good progress. Before, for example, I had up to 50 blocks that were also nested. And every time it took many seconds to load everything. Now they are there immediately. That's cool.

That's why I'm even more aware of the issue of slow loading of block pattern.

Is there any way to solve this like preloading blocks in the editor?

Let's say maybe a solution that block pattern are registered by ACF, like:

acf_register_block_pattern(...);

Then ACF knows that these block pattern exist and would preloading work then?

Originally posted by @CreativeDive in https://github.com/AdvancedCustomFields/acf/issues/654#issuecomment-1217663657

@CreativeDive We're not going to get that into ACF 6.0 I'm afraid - we're too close to release for anything other than bug fixes.

We're raise it as a feature request and I'll try and get it in 6.1, but it's a technically difficult problem to solve. Recent WordPress changes have already increased the size of a DOM load for a page with many blocks by multiple megabytes, and that's already causing issues for folks who use gzip encoding on their servers - as that process is taking too long for the block editor. Adding more content to the DOM would be a significant problem for them, which means we'd need to hot load in a secondary process to preload block patterns after the page load, and hope it completes before you open the pattern library.

Still, I'm sure we can get that done - it just won't be an immediate priority over the next month or so while we aim for the 6.0 release I'm afraid!

No source file, test, or entry point is named. Start by reviewing how ACF preloads blocks and how WordPress loads block patterns, then define an approach that makes patterns available without worsening the editor's initial DOM load or blocking pattern-library use.