UI has been slow on low VRAM for a few months

[gabrielfougeron]

Prerequisites

• I am running the latest version of ComfyUI
• I have searched existing issues to make sure this isn't a duplicate
• I have tested with all custom nodes disabled (see how)

What happened?

In order to preserve as much vram for my discrete GPU, I'm running Comfyui with one screen running off my integrated GPU (integrated on the cpu) with 2Go VRAM. Lately, the UI has become extremely slow (it takes 1-2 seconds to pan, disable/enable node, select node, edit node value etc). I suspect this has to do with VRAM swap on my integrated GPU, because this does not happen when I run on a monitor plugged in my discrete GPU. The UI is so slow, that it becomes hard and frustrating to interact with (displacing nodes is a nightmare, group select as well, doing anything fast and reliably feels almost impossible).

This happens even before any model is loaded, before any task is put in queue.

It is hard to pinpoint when (i.e. what Comfyui version) the change occured, especially since I don't update more than circa once/month. I'd say about 2 months, maybe a bit more.
I was running comfyui-frontend-package version 1.28.8, just upgraded (using pip) to 1.33.3 and it is the same.

Are there settings I could change to mitigate this issue ? I already lowered the max FPS of the UI to 15.

Steps to Reproduce

1. Run Comfyui off of screen ran by very low end / integrated GPU

How is this affecting you?

Visual/UI issue only

ComfyUI Frontend Version

1.33.3

Browser

Chrome/Chromium

Console Errors

Logs

Additional Context

No response

┆Issue is synchronized with this Notion page by Unito

[gabrielfougeron]

Update: I tried enable Nodes2.0 and it is much better already! Not sure it was meant as a feature of Nodes2.0, but very interesting

[dosubot]

Hi @gabrielfougeron! I'm Dosu and I’m helping the ComfyUI_frontend team.

Great to hear that enabling Nodes2.0 improved your UI performance! Nodes2.0 introduces a new Vue-based rendering system with a push-based reactivity model and spatial queries, which are designed to improve responsiveness and reduce lag, especially during interactions like panning and zooming. While the main goal was to modernize and optimize the frontend, these changes can have a noticeable positive impact on systems with limited VRAM or integrated GPUs, as you've experienced. The performance gains come from more efficient state management and reduced overhead during UI updates, though rendering is still ultimately limited by GPU memory and browser hardware acceleration requirements. So, the improvement you noticed is an intended benefit of the new architecture, even if not specifically targeted at low VRAM setups citation citation.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[gabrielfougeron]

Thanks @dosu bot! To be clear, I don't really consider the issue solved, mainly because Nodes2.0 is not mature yet (missing features include filter suggestion list, poor compatibility with a few nodes, awkward/diffrent behavior compared to Nodes1.0 when clicking/ scrolling wheel, way smaller text, etc).

[dosubot]

Totally understand—Nodes2.0 is still evolving, and your feedback about missing features (like the filter suggestion list), node compatibility, and UI behavior differences is spot on. There are active improvements happening (for example, recent updates have focused on node resizing, layout, and scaling in Nodes2.0), but some gaps remain before it can fully replace Nodes1.0 for everyone’s workflows citation citation citation.

If you need to stick with Nodes1.0 for now, a few settings might help with UI slowness on low VRAM systems:

• Lower the “Maximum FPS” (you’ve already set this to 15, which is good).
• Try disabling DOM element clipping (Enable DOM element clipping) and tooltips (Enable Tooltips) in the settings—both can reduce rendering overhead.
• Make sure hardware acceleration is enabled in your browser (disabling it usually makes things worse).
• If you’re still seeing lag, some users have found that using an older frontend version (pre-1.10.4) can help, though this comes with tradeoffs citation.

Let me know if you want more details on any of these tweaks or if you run into specific compatibility issues with Nodes2.0—I can dig deeper!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[m8rr]

windows 11 4k 120hz, comfyui 60hz, AMD 780m IGPU, RTX4070s, Edge browser

Maybe it was after the subgraph came out and the top tab became two lines?
There is no problem if i use comfy at around 1080 in windowed mode.
However, if i maximize comfy or use F11 to full screen, it becomes really slow at 4K.
Even if i set Windows to use 4070s on Edge, it's around 20fps.

It gets much better in 2.0. But before, it was okay without 2.0.

[m8rr]

When the Edge window size was about 3500x2000, FPS dropped from 30 to about 5.
WF has about 10 nodes and one subgraph group.
Tested in v1.32.9 and v1.34.2, I checked the FPS by dragging the workflow.

I deleted several nodes, but it was still slow.
I went back to the beginning and delete only subgraph group, then FPS became 30.
Then I pressed F11 to make it 4K, it became slow again. Although it's better than 5.

And I confirmed that this also makes comfy very slow, like subgraph.