lzb_pro/preload_blocks Pro

Turns off editor block preloading, which is the switch to reach for when a post with many blocks trips the server's request limit or when a preview will not stop showing stale markup.

The default is true. With preloading on, Lazy Blocks Pro captures the HTML of every block WordPress renders while the edit screen loads and hands it to the editor as window.lzbProBlocksPreloaded, so previews appear immediately instead of each block fetching its own render over REST. Two situations call for switching it off. A post carrying dozens of blocks issues that many render requests as the screen loads, and a host that rate limits will answer some of them with a 504 or 429. And while debugging a block whose preview does not match its output, the preloaded copy is the one you see first, so turning this off forces a fresh render on every change.

Attributes

Usage

function my_lzb_pro_preload_blocks( $enabled ) {
  // Skip preloading on the post types whose pages carry the most blocks,
  // where the burst of render requests hits the host's rate limit.
  $screen = function_exists( 'get_current_screen' ) ? get_current_screen() : null;
 
  if ( $screen && in_array( $screen->post_type, array( 'page', 'landing' ), true ) ) {
    return false;
  }
 
  return $enabled;
}
 
add_filter( 'lzb_pro/preload_blocks', 'my_lzb_pro_preload_blocks' );

The switch is narrower than it looks. Returning false skips the script and the localised data, and nothing else. Both render filters Lazy Blocks Pro registers stay hooked, including the one that blanks Inner Blocks attributes in the editor, so turning preloading off does not restore those values in the editor render.

Removing the data also removes it from the Yoast and Rank Math integration, which seeds its content cache from the same window.lzbProBlocksPreloaded object. That integration falls back to fetching each block over REST, so the SEO analysis still sees the block output, one request per block instead of none.

The feature itself is described in Performance.