If you’ve spent any time in ComfyUI, you’ve probably had that moment where a generation that used to take 15 seconds suddenly takes two minutes, and you have no idea why. Maybe you installed a new custom node, maybe an update changed something under the hood, or maybe your setup was never really optimized in the first place. Either way, the good news is that ComfyUI has a ton of room to be optimized (partly thanks to how modular and configurable it is), and most of the fixes don’t require a new GPU.
Below is a rundown of the changes that actually move the needle, from quick settings tweaks to slightly more involved installs. You don’t need to do all of them at once – pick a few the easier ones that match your setup, see if there’s a big improvement, and work from there.
1. Update ComfyUI before you make any optimizations
This sounds almost too obvious to mention, but it’s worth saying clearly: a big chunk of the “why is ComfyUI suddenly so slow” posts you’ll find online trace back to people running an outdated version. ComfyUI ships changes and optimizations constantly, and every so often a bug slips in that tanks performance for certain hardware or certain workflows. The fix usually lands within days, but only if you actually pull it.
Before you start messing with launch flags or reinstalling your Python environment, just update to be sure. If you’re on the portable Windows build, grab the latest release. If you installed manually, a simple git pull plus a dependency refresh takes care of it. It’s the cheapest possible fix, so rule it out first!
2. Get your attention mechanism right
The “attention” step is one of the most computationally expensive parts of running a diffusion model, and which implementation ComfyUI uses for it has a massive effect on speed. By default, a fresh install will fall back to PyTorch’s built-in SDPA (scaled dot product attention), which is fine but not the fastest option available.
A few upgrades worth knowing about, roughly in order of effort:
- xFormers – an easy install that gives a solid speed bump over the default attention with basically no downside.
- SageAttention (paired with Triton) – a bigger jump. People regularly report 30-50% faster generation on newer NVIDIA cards, especially with Flux and video models like Wan. It takes more setup (matching your PyTorch, CUDA, and Triton versions correctly is the fiddly part), but the payoff is real, and it doesn’t noticeably hurt image quality.
- Flash Attention – another strong option on newer cards, similar territory to SageAttention.
If you’re on an older GPU without support for these, don’t worry too much, xFormers alone will still help quite a bit. Just know that “attention optimization” is one of the highest-leverage changes you can make, so it’s worth getting right before chasing smaller tweaks.
3. Stop fighting your VRAM
A lot of slowdowns aren’t really about raw compute, they’re about ComfyUI constantly swapping models in and out of VRAM because it thinks you’re low on memory. ComfyUI’s smart memory management is usually good at guessing what mode to run in, but it doesn’t always guess right, and on some systems it can be genuinely wrong.
A few launch flags worth knowing:
--reserve-vram 2tells ComfyUI to keep a couple gigs free for your OS and browser, which can prevent the kind of stutter that happens when Windows itself needs memory mid-generation.--highvramor--gpu-onlykeeps everything loaded on the GPU if you actually have the headroom for it, avoiding repeated CPU-GPU transfers.--lowvramis there if you’re memory constrained, but only use it if you need it. It trades speed for the ability to run at all.--disable-smart-memoryis a blunt instrument for when the automatic management is doing more harm than good on your specific setup.
If you’re unsure which of these apply to you, open Task Manager (or nvidia-smi if you’re comfortable with a terminal) while generating and actually watch what your VRAM is doing. It’ll usually make the right flag obvious.
4. Check whether your models are actually being cached
Here’s one that’s caught a lot of people off guard recently, and it’s sneaky because it doesn’t look like a “settings” problem at first, it just looks like everything got slower for no reason. There have been reports of ComfyUI reloading checkpoints, text encoders, and LoRAs straight from disk on every single generation instead of keeping them cached in RAM or on the GPU like it’s supposed to. Since reading off a hard drive or even an SSD is drastically slower than pulling from memory, this alone can add 30-40% (sometimes more) to your total generation time, and it’s easy to blame on your hardware or workflow when it’s actually a caching issue.
The tell is usually your disk activity light going wild every time you hit generate, even though nothing about your workflow changed. If that sounds familiar, try adding one of these launch args:
--cache-classicrestores the older, more aggressive caching behavior, which for a lot of people has fixed the problem completely and stopped the constant disk hammering.--high-ramhas also worked for some users experiencing the same reload issue.
Neither of these costs you anything to try, and if this is what’s been slowing you down, the difference is immediate and obvious rather than subtle!
5. Let caching do some of the work for you
This one doesn’t get talked about enough. Diffusion models spend a lot of their compute recalculating things that barely changed from the previous step. Tools like TeaCache exploit that by intelligently skipping redundant computation in the attention blocks, and the speedups are not subtle, people report roughly 2x on Flux and similar gains on video models like Wan, with little to no visible quality loss.
Pairing that with model compilation (torch.compile, or TensorRT if you want to go further) stacks the benefit even higher. The catch with compilation is that your first couple of generations in a session will actually be slower while it compiles, so it’s best suited to setups where ComfyUI stays running for a while rather than being restarted constantly.
Neither of these requires touching your hardware, they’re purely software-level, which makes them a good next step once your attention mechanism is sorted.
6. Pay attention to what your browser is doing
This is another one people tend to overlook completely, because it feels like it shouldn’t matter. But ComfyUI’s interface lives in your browser, and the browser is doing real work while your GPU is busy generating.
A few things worth knowing:
- Live previews aren’t free. Every time ComfyUI sends a preview frame to your browser, that’s encoding, network overhead, and canvas rendering. On workflows with a lot of nodes or high step counts, this adds up. If you don’t need to watch every step, set the preview method to something lighter (or off entirely) either in Settings or with the
--preview-method nonelaunch flag. You’ll still get your final image, you’re just not paying the tax for updates you’re not really watching anyway. - The browser itself matters. Chrome-based browsers tend to handle ComfyUI’s canvas rendering noticeably better than Firefox in a lot of people’s experience. If your interface feels laggy even when generation itself is fast, it might genuinely be your browser rather than your GPU.
- Hardware-accelerated browsers compete for GPU resources. If your browser has hardware acceleration turned on, it’s using some of the same GPU that’s trying to run your diffusion model. On systems with less VRAM to spare, this can be enough to cause real slowdown or inconsistency between runs, especially if you’ve also got a dozen other tabs open with video or WebGL content. Closing unnecessary tabs, or disabling hardware acceleration for the browser you’re using for ComfyUI, is a small change that occasionally has an outsized effect. Similarly, a window that’s minimized or pushed to the background can behave differently than one that’s active and visible, since some systems throttle rendering priority for windows that aren’t in focus.
None of this is about your model or your VRAM settings, it’s just about not letting the browser quietly eat resources you thought were going entirely to generation.
There’s also a stranger one worth flagging, and honestly, nobody has fully cracked it yet. Several people have documented generation speed dropping noticeably, sometimes 20-40% or more on cards as strong as an RTX 4090, purely from running the browser fullscreen or maximized instead of in a small windowed view! In some of these tests, just moving the mouse or resizing the window mid-generation caused it/s to drop in real time, and shrinking the window back down snapped speed right back to normal. People have tested this across ComfyUI and Forge, multiple browsers, different PyTorch and CUDA versions, driver rollbacks, GPU clocks and power states, and even tried running the display off a separate GPU while the discrete card handled compute only, and no single explanation has held up cleanly for everyone.
Browser choice seemed to matter for some testers, with Chromium-based browsers like Brave taking a bigger hit than Firefox, but that pattern didn’t repeat for every single person who tried it, so it’s not a clean fix either. The leading theory floating around is some kind of contention between the Windows desktop compositor and the CUDA compute context while a window is being actively composited fullscreen, basically the GPU juggling two jobs instead of one, though that’s still a theory rather than a confirmed cause.
The practical takeaway: if you’re chasing every last bit of speed, it’s genuinely worth testing your own setup with the browser running in a small window instead of maximized, and trying a different browser if you’re currently on something Chromium-based. For some people that one change alone was worth a real, double-digit percentage speedup, which is wild for something that costs nothing to try.
7. Audit your custom nodes
Custom nodes are a huge part of why ComfyUI is so flexible, but every one you install adds startup time, and some add ongoing overhead even when you’re not actively using them, particularly ones that hook into the UI or run background checks. If you’ve been installing nodes for months without ever cleaning up, there’s a good chance you’re carrying dead weight.
Open ComfyUI Manager, disable anything you haven’t touched in a while, and restart. If startup time drops noticeably, you’ve found some of your bottleneck! You can also launch with --disable-all-custom-nodes temporarily just to confirm whether a slowdown is coming from a node at all before you go hunting through your list one by one.
8. Don’t ignore the boring hardware stuff
It’s easy to assume every slowdown is a software problem, but a few unglamorous basics matter more than people expect:
- Storage speed. Loading a large checkpoint off a spinning hard drive instead of an SSD can genuinely be several times slower. If your models live on an HDD, that’s worth fixing before anything else on this list.
- System RAM. ComfyUI and its custom nodes lean on regular RAM more than you’d think, especially with big workflows. If you’re sitting right at 16GB, upgrading can smooth out stutters that look like GPU problems but aren’t.
- GPU drivers. Outdated NVIDIA drivers can quietly cost you CUDA performance. It’s worth checking you’re current, especially after installing something like Triton or SageAttention that leans on newer driver features.
- Thermal throttling. If your generation times creep up the longer a session runs, check your GPU temperature. Dust, aging thermal paste, or poor case airflow can cause a card to quietly downclock itself mid-session.
9. Match your models to your hardware
If you’re running a 16GB VRAM card and trying to force a model built for 24GB, you’re not just risking out-of-memory errors, you’re likely triggering the exact kind of aggressive memory swapping that causes slowdowns in the first place. Quantized GGUF versions of popular models exist specifically for this, and they give up very little visible quality for a real drop in memory pressure. If you’re not sure whether your VRAM is the bottleneck, this is one of the first things worth testing.
10. A few workflow habits that help
Beyond settings and installs, how you build your workflow matters too:
- ComfyUI only re-runs the parts of a workflow that actually changed, so structure your graph to take advantage of that rather than forcing full re-execution every time.
- Each active ControlNet adds real overhead to every step, so only keep the ones you’re actually using connected.
- Avoid switching checkpoints back and forth unnecessarily within a session, reloading a large model from disk isn’t free.
- If you’re testing prompts or settings, work at a lower resolution first and only scale up once you’re happy with the result.
None of these fixes is a silver bullet on its own, but they compound nicely! Update your install, pick a faster attention backend, get your VRAM flags dialed in for your specific card, and stop letting your browser quietly compete for resources, and you’ll likely end up with a noticeably snappier setup without spending a cent on new hardware. Start with whichever one addresses your specific symptom (slow generation, laggy UI, or long load times all point to different fixes) and work outward from there.
An important mention: this article has been curated specifically for the current ComfyUI version (July 2026). If you are reading this in the future, there is a chance that your version of ComfyUI may well have patched some of the issues mentioned on this list. That said, it’s still worth trying out some of the easier steps and just seeing for yourself if there are any improvements to be had with your workflow.
