Menu card lists mount every loaded page, so switching menus stutters on large workspaces
- Dominant language
- TypeScript
- Stars
- 156k
- Forks
- 24.6k
- Avg merge
- 22h 9m
- Merged PRs (30d)
- 610
Description
### Self Checks
- [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542).
- [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general).
- [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones.
- [x] I confirm that I am using English to submit this report, otherwise it will be closed.
- [x] 【中文用户 & Non English User】请使用英语提交,否则会被关闭 :)
- [x] Please do not modify this template :) and fill in all the required fields.
### Dify version
1.17.0
### Cloud or Self Hosted
Self Hosted (Docker)
### Steps to reproduce
1. Use a workspace with a large number of apps and knowledge bases. Ours has 432 apps and 169 datasets.
2. Open Studio and scroll far enough that infinite scroll loads several pages.
3. Click between the top-level menu entries — Home, Studio, Agents, Knowledge, Skills, Integrations.
Related: #41396 is the same class of problem in the Web Apps sidebar, fixed in #41397. The difference is that the sidebar stays mounted across route changes, so its cost is repaint, while these page-level grids are re-mounted from scratch on every visit.
Studio, Knowledge, Skills and Snippets each flatten every loaded page into one array and render a card for every entry. React Query caches the whole infinite query, so returning to a list re-mounts every accumulated page in a single commit rather than the page-sized batches that scrolling adds.
Measurements from a Safari Web Inspector timeline recorded while clicking through the top-level menus (3.06s):
| Metric | Value |
| --- | --- |
| Rendering frames | 23 in 3.06s (~7.5 fps), worst frame 976ms |
| `composite` | 1067.7ms total, 35% of the recording |
| `paint` | 12,112 records totaling 34.5ms (highly fragmented) |
| All script categories | ~830ms combined |
| Navigation RSC payloads | 340 B – 3.2 KB each, 12–58ms |
So the cost is in painting and compositing, not in JavaScript or in loading.
Frame pacing tracks how many cards a route mounts, not how it fetches:
| Route | Entries in this workspace | Stutters |
| --- | --- | --- |
| Studio | 432 | yes |
| Knowledge | 169 | yes |
| Agents | 8 | no |
| Skills | 4 | no |
Skills uses the same accumulating infinite query as Studio and does not stutter, so the driver is the number of mounted cards rather than the data-fetching pattern.
A controlled A/B/A sweep on the same deployment, interleaving factors across three rounds and taking medians so the collaboration-mode refetch cannot land on one factor (baseline re-measured first and last, 16.6 / 17.9 fps):
| Change | fps |
| --- | --- |
| baseline | 17.3 |
| `mask-image: none` everywhere | 28.7 |
| `mask-image: none` inside cards only | 28.1 |
| `mask-image: none` inside the left nav only | 18.6 |
Every card carries CSS `mask-image` icons, and they are the largest single paint factor. The un-virtualized rows multiply exactly that cost.
Two things worth recording so they are not tried as fixes: disabling `backdrop-filter` made things about 2x worse, because it removes beneficial layer promotion; and `content-visibility: auto` on the cards was within noise, because it skips rendering for nodes that are already mounted and does not stop them being created on navigation.
### ✔️ Expected Behavior
Switching between menu entries costs about the same regardless of how many apps or knowledge bases a workspace holds, because the list only mounts the cards near the viewport.
### ❌ Actual Behavior
Every loaded page stays mounted and is re-mounted and repainted when returning to the list. On a workspace with 432 apps, switching to Studio or Knowledge drops to ~7.5 fps, and the clicked entry gives no feedback until the commit finishes, so the click often looks like it was missed and gets repeated.
Contributor guide
Research direction
Start with the Studio, Knowledge, Skills, and Snippets menu routes and locate their infinite-query list grids. Reproduce the issue with a large workspace, then compare how many cards are mounted and painted when switching menus. Done means list pages mount only cards near the viewport and menu switching no longer stutters as loaded pages accumulate.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- css, react, typescript
- Domain
- frontend, performance
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100