[ChatGPT Web] Very long conversations cause severe UI/input lag and incomplete message navigation loading

Product / surface

• ChatGPT Web (chatgpt.com)
• Google Chrome 152
• Ubuntu 20.04
• Observed: September 11, 2026

What issue are you seeing?

Very long ChatGPT conversations become progressively slow and eventually noticeably laggy in the browser.

Two symptoms are consistently visible:

1. UI/input lag in long conversations

   • As a conversation grows, the page becomes increasingly sluggish.
   • Typing in the current composer/input box itself starts to lag.
   • The same browser and account remain responsive in a new short conversation, so the slowdown appears strongly correlated with the size/length of the current thread.

2. Incomplete message navigation/history index until old messages are manually loaded

   • The message navigation / message directory for a long conversation does not initially contain the full thread.
   • Only part of the conversation is represented.
   • To make the full navigation/history index appear, I have to repeatedly scroll upward and eventually reach the very first message, causing older messages to be lazily loaded.
   • Only after the full transcript has been progressively loaded does the full message directory/navigation become available.

This makes long-running research and technical threads difficult to use: the longer a thread becomes, the worse both interaction latency and navigation become.

Steps to reproduce

1. Open ChatGPT Web in Chrome.
2. Use a single conversation for a long-running workflow with many user/assistant turns and substantial text content.
3. Continue adding messages over time.
4. Observe that page interaction becomes progressively slower.
5. Type into the composer and observe increasing input latency / typing lag.
6. Open or inspect the message navigation/directory for the conversation.
7. Observe that it does not initially contain all historical messages.
8. Scroll upward repeatedly through the conversation until the oldest messages are loaded and eventually reach the first message.
9. Observe that the navigation/directory then fills in with older entries that were previously missing.
10. Open a fresh short conversation in the same browser session and compare responsiveness.

Expected behavior

• Composer/input responsiveness should remain fast regardless of conversation length.
• Rendering a very long transcript should not make keystrokes or the current message composer lag.
• Old message bodies may be lazily loaded or virtualized, but the message navigation/index should be complete independently of transcript hydration.
• Users should be able to jump directly to any historical message without first scrolling through the entire conversation to force-load it.
• Long conversations with hundreds or thousands of turns should use bounded rendering/hydration cost.

Actual behavior

• Long conversations become increasingly sluggish.
• Typing in the composer becomes visibly delayed.
• The message navigation/history index is incomplete on initial load.
• Older navigation entries only appear after manually scrolling far enough upward to hydrate the corresponding historical messages.
• In practice, obtaining the complete message directory can require scrolling all the way to the first message.

Why this matters

This particularly affects long-running research, coding, and project conversations where preserving a single continuous thread is useful.

Users should not have to choose between:

• keeping accumulated context in one thread; and
• maintaining a responsive UI and usable navigation.

Possible areas to investigate

These are hypotheses, not confirmed root causes:

• insufficient DOM/list virtualization for long transcripts;
• full or repeated Markdown/layout/reconciliation work on historical messages during composer updates;
• composer state coupled to large transcript render state;
• excessive React/component reconciliation as thread size grows;
• message-navigation data derived only from already-hydrated transcript nodes instead of thread metadata;
• lazy-loading of transcript pages unintentionally gating construction of the navigation/index;
• repeated observers/layout calculations over a very large rendered message tree.

Requested improvements

1. Use stronger transcript virtualization / bounded rendering for very long chats.
2. Keep the composer/input path isolated from historical transcript rendering so keystrokes stay responsive.
3. Load the complete lightweight message index/navigation metadata independently from message-body hydration.
4. Allow direct jump-to-message to trigger targeted loading of the relevant page/range instead of requiring sequential upward scrolling.
5. Add performance testing for very long ChatGPT Web conversations (hundreds to thousands of turns).

Related reports checked

I searched the public openai/codex tracker before filing. There are related Codex Desktop issues about large histories and long-thread performance, but I did not find an exact open report combining these two ChatGPT Web symptoms:

• progressive UI/composer lag in a very long ChatGPT Web conversation; and
• incomplete message navigation that only becomes complete after scrolling to hydrate the full history.

A related ChatGPT Web history-pagination report is #38946, but that concerns Archived Chats pagination and is a different reproduction path.

Additional information

The issue is reproducible enough to affect normal use of long conversations. I can provide browser performance traces, DevTools screenshots, or additional diagnostics if maintainers specify what would be most useful and safe to share.

No repository file, test, or entry point is identified; begin by confirming whether this repository contains the ChatGPT Web surface described and locating the long-conversation rendering and navigation paths. Done should include a reproducible long-thread performance test, responsive composer input, and complete navigation available without sequentially loading the entire transcript.