---
title: "Performance"
description: "How Lazy Blocks preloads block previews in the WordPress editor and caches the prepared block list, and what clears each of them."
url: "https://www.lazyblocks.com/docs/performance/"
source: "performance.mdx"
---
# 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](https://www.lazyblocks.com/docs/troubleshooting/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](https://www.lazyblocks.com/docs/blocks-code/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:

```php title="PHP"
add_filter( 'lzb_pro/preload_blocks', '__return_false' );
```

Previews then load one request at a time again, and the [Yoast and Rank Math integration](https://www.lazyblocks.com/docs/integrations/seo-plugins/), which reuses the same rendered HTML, falls back to fetching its own. See [lzb_pro/preload_blocks](https://www.lazyblocks.com/docs/php-filters/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](https://www.lazyblocks.com/docs/php-filters/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](https://www.lazyblocks.com/docs/managing-blocks/blocks-screen/), or from your own code:

```php title="PHP"
lazyblocks()->blocks()->clear_blocks_cache();
```

[lzb/cache_cleared](https://www.lazyblocks.com/docs/php-actions/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.

## Documentation Index
> Fetch the complete documentation index at: https://www.lazyblocks.com/llms.txt
> Fetch every page in a single file at: https://www.lazyblocks.com/llms-full.txt