[GH-ISSUE #23067] feat: Reduce message batch size & unload off-screen messages to prevent memory bloat and UI freezing #35408

New Issue

GiteaMirror · 2026-04-25T09:36:59-05:00

GiteaMirror commented

2026-04-25 09:36:59 -05:00

Originally created by @ShirasawaSama on GitHub (Mar 26, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/23067

Check Existing Issues

I have searched for all existing open AND closed issues and discussions for similar requests. I have found none that is comparable to my request.

Verify Feature Scope

I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions.

Problem Description

Yes. Currently, Open WebUI loads 20 messages per batch in a chat. For conversations with rich content (code blocks, LaTeX, images, long markdown), this leads to:

Massive memory usage — hundreds of heavy DOM nodes are rendered at once, even though most are off-screen.
Page freezing / UI becoming unresponsive — especially on mobile devices and low-end hardware.
Phone overheating during active conversations due to constant rendering of off-screen content.

This makes long conversations practically unusable on phones and even sluggish on desktops.

Desired Solution you'd like

Two changes:

1. Reduce the initial/incremental message load count

Change the default batch size from 20 → 4 (or make it configurable).
When the user scrolls up, load older messages on demand (load-more / pagination).

2. Unload (unmount) off-screen messages when the user sends a new message

When a new message is sent or received, unmount or hide messages that are no longer in the viewport.
This keeps the active DOM lightweight at all times.
A simple approach: only keep the latest N messages (e.g., 4) mounted in the DOM; replace the rest with placeholder elements of the same height to preserve scroll position.

Alternatives Considered

Why not Virtual Scrolling?

Traditional virtual scrolling (like react-window or tanstack-virtual) is designed for uniform, scrollable lists. Chat messages have variable and unpredictable heights (especially with streaming, code blocks, and markdown rendering), making true virtual scrolling complex to implement correctly.

The proposed approach is simpler and more practical:

Paginate (load fewer messages initially)
Cull (unmount off-screen messages when new ones arrive)

Additional Context

Yes. Currently, Open WebUI loads 20 messages per batch in a chat. For conversations with rich content (code blocks, LaTeX, images, long markdown), this leads to:

Massive memory usage — hundreds of heavy DOM nodes are rendered at once, even though most are off-screen.
Page freezing / UI becoming unresponsive — especially on mobile devices and low-end hardware.
Phone overheating during active conversations due to constant rendering of off-screen content.

This makes long conversations practically unusable on phones and even sluggish on desktops.

Originally created by @ShirasawaSama on GitHub (Mar 26, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/23067 ### Check Existing Issues - [x] I have searched for all existing **open AND closed** issues and discussions for similar requests. I have found none that is comparable to my request. ### Verify Feature Scope - [x] I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions. ### Problem Description Yes. Currently, Open WebUI loads **20 messages per batch** in a chat. For conversations with rich content (code blocks, LaTeX, images, long markdown), this leads to: 1. **Massive memory usage** — hundreds of heavy DOM nodes are rendered at once, even though most are off-screen. 2. **Page freezing / UI becoming unresponsive** — especially on mobile devices and low-end hardware. 3. **Phone overheating** during active conversations due to constant rendering of off-screen content. This makes long conversations practically unusable on phones and even sluggish on desktops. ### Desired Solution you'd like Two changes: #### 1. Reduce the initial/incremental message load count - Change the default batch size from **20 → 4** (or make it configurable). - When the user scrolls up, load older messages on demand (load-more / pagination). #### 2. Unload (unmount) off-screen messages when the user sends a new message - When a new message is sent or received, **unmount or hide messages that are no longer in the viewport**. - This keeps the active DOM lightweight at all times. - A simple approach: only keep the latest N messages (e.g., 4) mounted in the DOM; replace the rest with placeholder elements of the same height to preserve scroll position. ### Alternatives Considered ### Why not Virtual Scrolling? Traditional virtual scrolling (like `react-window` or `tanstack-virtual`) is designed for **uniform, scrollable lists**. Chat messages have **variable and unpredictable heights** (especially with streaming, code blocks, and markdown rendering), making true virtual scrolling complex to implement correctly. The proposed approach is simpler and more practical: - **Paginate** (load fewer messages initially) - **Cull** (unmount off-screen messages when new ones arrive) ### Additional Context Yes. Currently, Open WebUI loads **20 messages per batch** in a chat. For conversations with rich content (code blocks, LaTeX, images, long markdown), this leads to: 1. **Massive memory usage** — hundreds of heavy DOM nodes are rendered at once, even though most are off-screen. 2. **Page freezing / UI becoming unresponsive** — especially on mobile devices and low-end hardware. 3. **Phone overheating** during active conversations due to constant rendering of off-screen content. This makes long conversations practically unusable on phones and even sluggish on desktops.

GiteaMirror closed this issue

2026-04-25 09:37:00 -05:00

GiteaMirror commented

2026-04-25 09:37:01 -05:00

@ShirasawaSama commented on GitHub (Mar 29, 2026):

I recommend keeping at least 3 elements outside the screen when offload.

@ShirasawaSama commented on GitHub (Mar 29, 2026): I recommend keeping at least 3 elements outside the screen when offload.

GiteaMirror commented

2026-04-25 09:37:02 -05:00

@Classic298 commented on GitHub (Mar 29, 2026):

you recommend loading 4 message pairs - depending on screen size, that might only fit like half of the screen. what if we load 8?

how do you track which oones are outside of the screen? but yeah 3 outside the screen make sense

@Classic298 commented on GitHub (Mar 29, 2026): you recommend loading 4 message pairs - depending on screen size, that might only fit like half of the screen. what if we load 8? how do you track which oones are outside of the screen? but yeah 3 outside the screen make sense

GiteaMirror commented

2026-04-25 09:37:02 -05:00

@ShirasawaSama commented on GitHub (Mar 29, 2026):

you recommend loading 4 message pairs - depending on screen size, that might only fit like half of the screen. what if we load 8?

how do you track which oones are outside of the screen? but yeah 3 outside the screen make sense

"4" is the default value set in our production environment, and it has been in place for over six months. Of course, I think making this configurable is also an option.

Reason: Four messages are sufficient for display on most screens we’ve tested (such as desktop monitors, laptops, and mobile devices); we maintain an internal test list that includes a wide variety of devices.

If the messages doesn't fill the entire screen, it will now load automatically. This not a problem.

@ShirasawaSama commented on GitHub (Mar 29, 2026): > you recommend loading 4 message pairs - depending on screen size, that might only fit like half of the screen. what if we load 8? > > how do you track which oones are outside of the screen? but yeah 3 outside the screen make sense "4" is the default value set in our production environment, and it has been in place for over six months. Of course, I think making this configurable is also an option. Reason: Four messages are sufficient for display on most screens we’ve tested (such as desktop monitors, laptops, and mobile devices); we maintain an internal test list that includes a wide variety of devices. If the messages doesn't fill the entire screen, it will now load automatically. This not a problem.

GiteaMirror commented

2026-04-25 09:37:02 -05:00

@Classic298 commented on GitHub (Mar 29, 2026):

If the messages doesn't fill the entire screen, it will now load automatically. This not a problem.

ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh

yes then make it 4

@Classic298 commented on GitHub (Mar 29, 2026): > If the messages doesn't fill the entire screen, it will now load automatically. This not a problem. ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh yes then make it 4

GiteaMirror commented

2026-04-25 09:37:04 -05:00

@Classic298 commented on GitHub (Mar 29, 2026):

much in favor of this - configurability not inherently needed i think

@Classic298 commented on GitHub (Mar 29, 2026): much in favor of this - configurability not inherently needed i think

GiteaMirror commented

2026-04-25 09:37:05 -05:00

@Classic298 commented on GitHub (Apr 13, 2026):

026903399b

@Classic298 commented on GitHub (Apr 13, 2026): https://github.com/open-webui/open-webui/pull/23318/changes/026903399be73ac4b6c226647110e5662d043a50

GiteaMirror commented

2026-04-25 09:37:05 -05:00

@frost19k commented on GitHub (Apr 21, 2026):

Scrolling up is jumping all over the place now in 0.9.1

It's a real challenge to make the page land where you want it to when scrolling up.

Work around is scroll up passed where you want to land then scroll down.

@frost19k commented on GitHub (Apr 21, 2026): Scrolling up is jumping all over the place now in 0.9.1 It's a real challenge to make the page land where you want it to when scrolling up. Work around is scroll up passed where you want to land then scroll down.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#35408