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

Well, the thing is, the problem does not always occur. Also, not always on the same blocks... This makes it very hard to investigate, of course.
It seems to me it has something to do with the block-renderer, when you have several (more than 5) custom MB blocks in a page. The more custom MB blocks there are in a page, the higher the chance that one or more blocks will have this error. Sometime when I reload other blocks have the issue, sometimes all the errors are gone.

I've seen this behaviour in multiple websites where I integrate custom blocks into a custom-made theme, using the MB Blocks extension of Meta Box.

Do you have any other ideas than the ones you proposed?

Looks like it's a memory thing. Still, this indicates that the block renderer uses too much memory in the proces. I'm constantly reaching the limit of 1 GB, which should be more than sufficient.
Here some lines from the error log:

[Fri Jan 30 16:08:55 2026] Memory cgroup stats for /lve2428:
[Fri Jan 30 16:08:55 2026] oom-kill:constraint=CONSTRAINT_MEMCG,nodemask=(null),cpuset=/,mems_allowed=0,oom_memcg=/lve2428,task_memcg=/lve2428,task=lsphp,pid=3954594,uid=2428
[Fri Jan 30 16:08:55 2026] Memory cgroup out of memory: Killed process 3954594 (lsphp) total-vm:744688kB, anon-rss:80104kB, file-rss:15232kB, shmem-rss:4kB, UID:2428 pgtables:860kB oom_score_adj:0

MB Blocks editor causes heavy concurrent block-renderer requests → CloudLinux OOM kills → 503 “invalid JSON”

We’re running into repeatable 503 errors in the WordPress block editor specifically on MB Blocks‑based custom blocks. Hosting is CloudLinux with strict per‑user memory cgroup limits. We believe the MB Blocks editor render flow is causing multiple heavy PHP processes in parallel, exceeding the cgroup limit and getting killed.

Observed symptom in editor
“Error loading block: The response is not a valid JSON response.”

What we found (evidence)
We instrumented logging for MB Blocks related requests and captured memory usage and duration. The worst offenders are the WordPress REST block renderer calls for MB Blocks:

Example log entries (single requests):

• POST /wp-json/wp/v2/block-renderer/meta-box/cb-hero → ~7.8s, ~182MB peak
• POST /wp-json/wp/v2/block-renderer/meta-box/cb-kleurgroep → ~7.7s, ~180MB peak
• POST /wp-json/wp/v2/block-renderer/meta-box/cb-productcard → ~3.4s, ~182MB peak

We also see multiple block-renderer calls in parallel (same second), which means total memory easily exceeds our CloudLinux hard limit (e.g. 3–4 x 180MB). This matches OOM kills in kernel logs and yields 503 responses.

Relevant plugin code paths

• MB Blocks registers render_callback which gets executed via the WP REST block-renderer endpoint.
• In MBBlocks\Loader::prepare_render_callback_data, each block render populates fields with mb_get_block_field() for all fields, which appears to be expensive.

Files:

• vendor/meta-box/mb-blocks/src/Block.php (render + render callback registration)
• vendor/meta-box/mb-blocks/src/Loader.php (prepare_render_callback_data)

Reproduction (high-level)

1. Edit a post with multiple MB Blocks (8 blocks already trigger multiple 503s).
2. Observe concurrent POST /wp/v2/block-renderer/meta-box/... calls during editor load/preview.
3. With CloudLinux user memory limits, PHP processes are killed → 503 → invalid JSON in editor.

Request
Can you advise how to mitigate this (reduce parallel rendering, defer preview, cache block renders, etc.)?
Or is there a known issue in MB Blocks editor rendering that can be optimized to avoid simultaneous heavy block-renderer requests?

We can provide HAR files and request logs if needed.

Thanks!

Alright, I've tried the updated version you sent me.
It looks like the performance is somewhat improved, but I still get these errors. Less. but they're still there.