Environment / My Setup:
- NocoBase Version: v2.1.6 (Latest Stable Release)
- Deployment: Docker / Docker Compose
- Database: PostgreSQL
- Browser: Google Chrome (Latest version)
Hi everyone,
I am experiencing a severe frontend rendering and hydration delay in NocoBase v2.1.5 when using the new **Modern Pages (v2).
—Bug Description:
Whenever I add or reload a page containing buttons (such as Primary action buttons, Submit buttons, etc.), they initially render as completely blank/empty rectangles. It takes around 30 seconds for the buttons to finally hydrate, load their styles, text, and icons, and become fully functional. If I refresh the page (F5), the exact same 30-second delay happens all over again.
—What I have tested so far:
-v1 (Classic Pages) work perfectly:** This issue only happens inside v2 (Modern Pages) layouts.
-Not a browser cache issue:** I tried clearing the browser cache, testing in multiple browsers (Chrome, Edge, Firefox), and using Incognito mode. The issue persists.
-Not a local hardware issue:** I tested accessing the application from my mobile phone, and the exact same 30-second rendering delay occurs.
Hello, what are the configurations of the client machine (CPU, memory) and what browser version is it?
Hi, confirming the same issue here — and I think I found a pattern that might help narrow it down.
Environment / My Setup:
- NocoBase Version: tested on both 2.1.0 and 2.1.7 — same issue on both
- Database: PostgreSQL
- Browser: Chrome (latest)
Same symptoms as described above: Modern Pages (v2) take a long time for action buttons to render/hydrate after being added or after a page reload. Classic Pages (v1) work instantly, no delay at all, every time.
Key finding: I have two separate NocoBase instances, and the bug only shows up on one of them.
- Instance A (affected): an older installation that ran on v1.9.40.x for a long time, then was upgraded up to 2.1. Modern v2 action buttons are slow to render on this one.
- Instance B (not affected): a fresh installation, installed recently and updated straight to 2.1 without ever running an older version. No delay at all on this one, Modern v2 buttons render instantly.
So this doesn’t look like a blanket v2 rendering bug — it seems specific to instances that went through an upgrade path from 1.9.x, not to v2 itself. My guess is something left over from the old client-v1/schema-based pages (old UI schema records, a disabled-but-still-present plugin, stale cache, etc.) that the new FlowEngine-based Modern pages aren’t handling cleanly.
Other details that might help:
- It’s not only on page load/reload — it also happens live, while still in the page builder. If I click “Actions” on a table block and add a new action button via “Add new”, the dropdown shifts slightly (as if something was inserted right away), but the new button itself takes a long time to actually appear on screen.
- This happens even with a single test table containing just 1 record, so it doesn’t seem related to data volume.
- I also ruled out server resources as the cause — other parts of the app (reading/writing actual collection data) are fast; it’s specifically the page-builder/button rendering inside Modern v2 pages that’s slow, and only on the upgraded instance.
Does this match what you’d expect from the 1.x → 2.x upgrade path? Is there a known cleanup step (old uiSchema records, deprecated plugins, cache) that’s supposed to run after upgrading that might not be completing? Happy to share console logs, plugin list, or test anything that helps.
@hongboji
What’s your NocoBase version? Is a fresh installation or upgraded from lower one?
Hi, to answer your question directly: I’m running NocoBase 2.1.9 (Standard Edition), and yes, it’s an upgraded instance, not a fresh install — confirms the pattern I described above.
Some additional context that might help narrow this further:
- I tested disabling Cloudflare’s proxying (DNS-only/grey-cloud mode, traffic going straight to my server with no CDN involved) — the ~30s delay disappeared completely, and action buttons rendered instantly, matching the speed of direct IP access. With Cloudflare’s proxy (orange-cloud/CDN mode) re-enabled, the delay came back.
- This suggests Cloudflare’s proxy layer may be involved, though I can’t fully confirm the exact mechanism yet.
- This at least rules out server resources, database performance, and the container itself as the sole cause, since the exact same backend stack is in play in both the slow and fast scenarios — the variable that changed was whether Cloudflare’s proxy/CDN layer was active.
- If Cloudflare is indeed a factor, my guess would be something related to how it handles the response (buffering, compression, auto-minify/Rocket Loader-type JS optimizations, or similar) potentially interfering with the sequential API/WebSocket calls needed for hydration — but that’s speculation on my part at this point.
1 Like
I’m facing the same issue. Have been using Nocobase since version 1.9.x and after all upgrade cycles, the current version i’m using ins 2.1.12-full. Some of the issues I’m facing:
a. Action buttons on v2 pages are loading after 13-15 seconds. I too have cloudflare proxy enabled for the subdomain. It worked properly in 2.0.x version but facing it since the time i upgraded to 2.1.x
b. Markdown on v1 pages not rendering properly. Moreover the markdown blocks are rendering again after 13-15 seconds.
on a side note, if I access the app directly using the host IP & port, everything works fine. But when access it with the actual domain name, it doesn’t. The subdomain DNS is through cloudflare, so i’m sure there is something to do with cloudflare proxy blocking these blocks.
1 Like
Mine only work when I disable proxy (the DNS resolved directly to the server IP)
1 Like
I already tested it on localhost and it works correctly; on my own machine, the system has no bugs at all. I think the problem is when they go through Cloudflare
Thank you for your feedback. Please upgrade to the latest version and check if the problem is resolved.Back up your database before upgrading.
It still the same. I upgraded to 2.1.15-full, but still the same problem. Had to revert back to DNS only to make it work. Hence, this has still not resolved.
It’s already been fixed with the latest 2.1.23 update. Thanks!
