Performance issues in Firefox-based browsers

[AetherMagee]

What happened?

While using Firefox Developer edition 139.0b7, I found that performance is quite a bit worse than on Chromium-based browsers.

Upon starting to stream the response, the network usage steadily grows until it maxes out the connection, after which the streaming process begins to visibly lag:

After streaming a bit longer, RAM usage starts to creep upwards too:

Then, after several of those RAM "peaks", it settles and just streams extremely slowly if you keep the tab open:

However, if you switch to another tab or window while the streaming process is still going, then this happens:

As you can see, it stops as soon as I switch back to the tab.

The behaviour above is consistent in Firefox between platforms. Today I left it streaming on mobile, then switched to a different app (Firefox has "no background restrictions" set). It ended up OOM-ing my device completely.

Notes:

1. For some reason, the issue seems much less prevelant if you use a lighter model. For me, Gemini 2.5 Pro hits much harder than 2.5 Flash
2. I tried it without that 'token counter box' (a userscript) and it made no difference, so it's not the cause.

Version Information

ghcr.io/danny-avila/librechat-dev latest dd77a8d86027 7 days ago 951MB

Steps to Reproduce

1. Use Firefox or its derivative
2. Send a large message to a model (mine is ~70k tokens)

What browsers are you seeing the problem on?

Firefox, Mobile (Android)

Relevant log output

none

Screenshots

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[danny-avila]

Thank you for this detailed report about Firefox-specific streaming performance issues. Based on your observations, particularly:

1. The problem being worse with larger models (Gemini 2.5 Pro vs Flash, larger models likely emit larger chunks at a time)
2. Network usage growing steadily during streaming
3. RAM creeping up over time
4. The issue pausing when switching tabs

This strongly suggests a potential memory leak in Firefox's handling of SSE (Server-Sent Events) streaming. This aligns with your observation that the issue occurs during streaming and appears related to the network layer.

Recommended Next Steps:

1. Report this issue to Mozilla Firefox:

   • Visit bugzilla.mozilla.org
   • Create a new bug in the "Core" product, "Networking" component
   • Title suggestion: "Memory leak / performance degradation with SSE (Server-Sent Events) streaming"
   • Include your screenshots and details about:
     • The observed network usage growth
     • RAM usage patterns
     • Tab switching behavior
     • The fact it occurs with different models but is more severe with larger ones

2. Include reproduction steps:

   • Mention LibreChat (your deployment) as an example site using SSE
   • Note the correlation with model size (more data streamed = worse performance)
   • Link to this issue for reference if possible

3. Provide Firefox-specific information:

   • Your Firefox Developer Edition version
   • Confirm if you've tested with extensions disabled
   • Mention it happens across platforms (desktop and mobile)

While we investigate potential workarounds on our end, having this properly documented with Mozilla would be the most effective path forward for a proper fix, as this appears to be a browser-specific issue with how Firefox handles SSE connections.

Would you be willing to submit this bug report to Mozilla and share the bug link here once created?

[KiGamji]

https://bugzilla.mozilla.org/show_bug.cgi?id=1966410

[AetherMagee]

By the way, here's the screen cap of the issue in action: https://files.catbox.moe/a9377d.mp4

[AetherMagee]

@danny-avila After posting a report on Bugzilla, they seem to have confirmed that this is, in fact, an issue on LibreChat's side and not a Firefox bug. https://bugzilla.mozilla.org/show_bug.cgi?id=1966410

[danny-avila]

The author of the project above (LibreChat) didn't even bother

I can't reproduce the issue on firefox. I don't have this issue on either browser in question.

[AetherMagee]

Sorry for that misunderstanding, made a rushed assumption based on the initial answer.

I can't reproduce the issue on firefox.

Weird. I've tried it too in different configurations, and I could reproduce it every time. I could DM you the export of the exact conversation if that helps with repro.

[danny-avila]

Ok, taking another look, it may be related to the legacy stream handler, which is still being used by Google (and currently, only by Google and maybe Assistants API).

When you use the Google endpoint directly (and not with agents or a badge i.e. only "Code Interpreter" right now), it is still using the legacy way of emitting stream events. I detail in the docs how Agents introduced a 95% drop in data transfer, and part of many reasons everything will transition to that framework:

Using an agent, the same generation will transfer about about 52 kb of data, a 95% reduction in data transfer, which is that much less of a load on the server and the user’s device.

source

We can see with Google direct that a longer stream generation transfer can grow quite rapidly, up to several megabytes, and server-sent events may not be getting garbage collected until the stream is actually done, which might be causing something in the browser to short-circuit as well, and cause that climbing "peak" you see.

A generation that is just as long, if not longer, using Agents (or selecting a badge from the textarea as explained before) will struggle to make it past 100 kB.

Here you can see my network request which generated 5000 tokens at only 84.7 kB and ran for 2.2 minutes:

I will note this as a reason to accelerate the framework transition for Google to Agents (under the hood), likely along with feature updates for Google.

You can get around this by using Google via Agents as described before.

[AetherMagee]

After testing a bit more, the problem is indeed not present on Agents. The stream itself feels quite slower but that's probably just an issue in my testing env (I'm testing on another, weaker deployment since Agents are off on the main one)
Thanks!