SSR blocks are all rendered at once in editor, causing 503 errors on low-resource servers

[Arifursdev]

Description

When editing an existing post that contains a large number of server-rendered blocks, the block editor attempts to render all blocks at once by calling the /wp-json/wp/v2/block-renderer/ API for every block simultaneously.

On servers with limited resources, this results in partial failures. Some blocks load successfully, while many requests return 503 responses. As a result, the editor shows the error message:

Error loading block: The response is not a valid JSON response.

Once a block fails to load, it is not immediately editable. To recover, the user must manually force a re-render by switching the block to “Edit as HTML” and then back to visual editing.

This behavior appears to be caused by aggressive, non-chunked rendering of server-side blocks in the editor.

Expected behavior

Server-rendered blocks should not all be rendered simultaneously.
Blocks should be loaded lazily or in small batches.
A loading or skeleton state should be shown while blocks are being rendered.

Actual behavior

All server-rendered blocks are requested at once.
Low-resource servers return 503 errors for many block renderer requests.
Blocks remain in a broken state until manually refreshed.

Suggested improvement
Implement lazy loading or chunked loading for server-rendered blocks in the editor, with a proper loading state. This would reduce server load, prevent 503 errors, and improve editor reliability for large posts and constrained hosting environments.

Step-by-step reproduction instructions

1. Set up a WordPress site on a low or moderate resource server
2. Create a post and insert a large number of server-rendered blocks (blocks that uses render_callback)
3. Save and publish the post.
4. Reload or Navigate to the WordPress admin and open the post for editing in the block editor.
5. Observe the network activity in the browser developer tools
   The editor sends many simultaneous requests to
   /wp-json/wp/v2/block-renderer/.
   Notice that some of these requests return 503 errors due to server overload.

Screenshots, screen recording, code snippet

No response

Environment info

WordPress 6.9

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• Yes

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure

[Mamaduka]

Thanks for reporting the issue, @Arifursdev!

Can you share an example number of SSR blocks on the page?

There was a proposal for queueing requests (#6381). I closed it as won't fix. Since SSR should be regarded as a fallback or legacy mechanism, consumers shouldn't rely on it heavily.

[Arifursdev]

@Mamaduka Its a cheap shared hosting you could say, there maybe about 2-3 different types of blocks that is registered like this:

//...
register_block_type(
    $this->namespace,
    [
        'render_callback' => $this->renderCallback,
        'editor_script'   => $this->editorScript,
        'editor_style'    => $this->editorStyle,
        'attributes'      => $this->attributes,
        'supports'        => $this->supports,
    ]
);
//...

to reproduce the bug, maybe you have to limit the resources on your server and have as many blocks as you want, save post and try reload or browse to the edit post page on backend. If there are 250 blocks for example, it sends 250 fetch requests to the API at the same time. many loads up properly, and many waits for the other requests to finish and goes Error loading block: The response is not a valid JSON response.

[ozgursar]

Reproduction Report

Environment

• WordPress: 7.0-alpha-61215-src
• PHP: 8.2.29
• Server: nginx/1.29.4
• Database: mysqli (Server: 8.4.7 / Client: mysqlnd 8.2.29)
• Browser: Chrome 144.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.4
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.1
  • Test Server-Rendered Blocks

Steps taken

1. Created a test plugin to replicate the SSR blocks
2. Download here, install and activate: https://github.com/ozgursar/gutenberg-test-server-blocks
3. Add 50 SSR blocks to any post as follows:

<!-- wp:test/server-block {"content":"Server Block #1"} /-->
<!-- wp:test/server-block {"content":"Server Block #2"} /-->
<!-- wp:test/server-block {"content":"Server Block #3"} /-->
<!-- wp:test/server-block {"content":"Server Block #4"} /-->
<!-- wp:test/server-block {"content":"Server Block #5"} /-->
<!-- wp:test/server-block {"content":"Server Block #6"} /-->
<!-- wp:test/server-block {"content":"Server Block #7"} /-->
<!-- wp:test/server-block {"content":"Server Block #8"} /-->
<!-- wp:test/server-block {"content":"Server Block #9"} /-->
<!-- wp:test/server-block {"content":"Server Block #10"} /-->
<!-- wp:test/server-block {"content":"Server Block #11"} /-->
<!-- wp:test/server-block {"content":"Server Block #12"} /-->
<!-- wp:test/server-block {"content":"Server Block #13"} /-->
<!-- wp:test/server-block {"content":"Server Block #14"} /-->
<!-- wp:test/server-block {"content":"Server Block #15"} /-->
<!-- wp:test/server-block {"content":"Server Block #16"} /-->
<!-- wp:test/server-block {"content":"Server Block #17"} /-->
<!-- wp:test/server-block {"content":"Server Block #18"} /-->
<!-- wp:test/server-block {"content":"Server Block #19"} /-->
<!-- wp:test/server-block {"content":"Server Block #20"} /-->
<!-- wp:test/server-block {"content":"Server Block #21"} /-->
<!-- wp:test/server-block {"content":"Server Block #22"} /-->
<!-- wp:test/server-block {"content":"Server Block #23"} /-->
<!-- wp:test/server-block {"content":"Server Block #24"} /-->
<!-- wp:test/server-block {"content":"Server Block #25"} /-->
<!-- wp:test/server-block {"content":"Server Block #26"} /-->
<!-- wp:test/server-block {"content":"Server Block #27"} /-->
<!-- wp:test/server-block {"content":"Server Block #28"} /-->
<!-- wp:test/server-block {"content":"Server Block #29"} /-->
<!-- wp:test/server-block {"content":"Server Block #30"} /-->
<!-- wp:test/server-block {"content":"Server Block #31"} /-->
<!-- wp:test/server-block {"content":"Server Block #32"} /-->
<!-- wp:test/server-block {"content":"Server Block #33"} /-->
<!-- wp:test/server-block {"content":"Server Block #34"} /-->
<!-- wp:test/server-block {"content":"Server Block #35"} /-->
<!-- wp:test/server-block {"content":"Server Block #36"} /-->
<!-- wp:test/server-block {"content":"Server Block #37"} /-->
<!-- wp:test/server-block {"content":"Server Block #38"} /-->
<!-- wp:test/server-block {"content":"Server Block #39"} /-->
<!-- wp:test/server-block {"content":"Server Block #40"} /-->
<!-- wp:test/server-block {"content":"Server Block #41"} /-->
<!-- wp:test/server-block {"content":"Server Block #42"} /-->
<!-- wp:test/server-block {"content":"Server Block #43"} /-->
<!-- wp:test/server-block {"content":"Server Block #44"} /-->
<!-- wp:test/server-block {"content":"Server Block #45"} /-->
<!-- wp:test/server-block {"content":"Server Block #46"} /-->
<!-- wp:test/server-block {"content":"Server Block #47"} /-->
<!-- wp:test/server-block {"content":"Server Block #48"} /-->
<!-- wp:test/server-block {"content":"Server Block #49"} /-->
<!-- wp:test/server-block {"content":"Server Block #50"} /-->

5. Update nginx default.template of the wordpress develop environment as follows to simulate a low resource host:

limit_conn_zone $binary_remote_addr zone=blockapi:10m;

server {
	index index.php index.html;

	listen 80 default_server;
	listen [::]:80 default_server;

	server_name localhost;

	client_max_body_size 1g;

	error_log  /var/log/nginx/error.log;
	access_log /var/log/nginx/access.log;

	root /var/www/${LOCAL_DIR};

	absolute_redirect off;

	if (!-e $request_filename) {
		rewrite /wp-admin$ $scheme://$host$request_uri/ permanent;
		rewrite ^(/[^/]+)?(/wp-.*) $2 last;
		rewrite ^(/[^/]+)?(/.*\.php) $2 last;
	}

	location / {
		try_files $uri $uri/ /index.php?$args;
	}

	# Special handling for block-renderer with connection limit
	location ~ \.php {
		if ($request_uri ~* "block-renderer") {
			return 418;
		}
		
		try_files $uri =404;
		fastcgi_split_path_info ^(.+\.php)(/.+)$;
		fastcgi_pass php:9000;
		fastcgi_index index.php;
		include fastcgi_params;
		fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
		fastcgi_param PATH_INFO $fastcgi_path_info;
		fastcgi_pass_header Authorization;
	}
	
	location @block_limited {
		limit_conn blockapi 3;
		
		try_files $uri =404;
		fastcgi_split_path_info ^(.+\.php)(/.+)$;
		fastcgi_pass php:9000;
		fastcgi_index index.php;
		include fastcgi_params;
		fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
		fastcgi_param PATH_INFO $fastcgi_path_info;
		fastcgi_pass_header Authorization;
	}
	
	error_page 418 = @block_limited;
}

6. Restart environment with npm run env:restart
7. 🐞 Bug occurs (see screencast)

Expected behavior

• In low resource server environments, too many requests to /wp-json/wp/v2/block-renderer/ causes 503 errors.

Screenshots/Screencast with results

• Screenshot showcasing the problem

ssr-blocks-503.mp4

[Mamaduka]

@jsnajdr, @youknowriad, do you think it would be okay to use useAsyncMode or @wordpress/priority-queue in this case?

[youknowriad]

priority-queue seems like the right path here but I wonder if this issue is about blocks. For me this is a more generic issue, what about other REST API requests that can be triggered by blocks that may or may not be block-renderer. In other words, I wonder if we should have a built-in queue mechanism in api-fetch or if it can be a middleware that is third-party hosts or sites can "enable" and limit according to their resources