Performance
Lazy Blocks caches in two places, and each answers a different complaint. Editor preloading is why block previews can appear with the page instead of one request per block. The blocks cache is why a change to a block can keep showing the old output.
Editor block preloading
Without it, every lazy block on the page asks the server for its preview when the editor opens. A post holding twenty of them opens with twenty requests, which is the cause behind Receive a 504 and 429 error Too Many Requests.
With Pro active the previews are rendered once while the edit screen loads and handed to the editor with the page, so the first draw of every block costs no request at all. Editing a block afterwards fetches its preview as usual.
Inner blocks are the exception. A block using an Inner Blocks area is preloaded without its children, because preloaded child markup and the live preview fight each other and the live one has to win.
The feature is on by default. Turn it off when you are debugging a preview that will not refresh:
add_filter( 'lzb_pro/preload_blocks', '__return_false' );Previews then load one request at a time again, and the Yoast and Rank Math integration, which reuses the same rendered HTML, falls back to fetching its own. See lzb_pro/preload_blocks.
The blocks cache
Building the list of blocks means reading every block you have made and turning it into block data and controls. That result is cached for a day, so the work happens once rather than on every request.
lzb/cache_expiration changes how long it lasts. Return 0 and the list is rebuilt every request, which is worth doing while developing and not worth doing in production.
Blocks registered from PHP with lazyblocks()->add_block() are never cached. They are rebuilt on every request, so they cannot go stale.
The cache clears itself when:
- a block is saved
- a block is deleted, trashed or untrashed
- any plugin is activated or deactivated
- the theme is switched
- any plugin or theme is upgraded
You can also clear it from Clear Cache on the Blocks screen, or from your own code:
lazyblocks()->blocks()->clear_blocks_cache();lzb/cache_cleared fires afterwards, for anything of yours that caches on top.
Saving a block in the builder clears the cache, so a block that still shows its old output was almost certainly changed some other way. Writing block meta directly with update_post_meta() is the usual culprit: it triggers none of the events above, and the old list stands until the day is out.