I've noticed a recurring issue this past week that's starting to impact my workflow, and I'm wondering if it's a wider problem or something specific to my setup. When working in the long-form editor on documents that exceed roughly 500 words, the interface becomes progressively more sluggish and will occasionally freeze completely for 10-15 seconds at a time. This happens most often when I'm using the "rewrite" or "expand" commands on a highlighted section.
My environment is Chrome on macOS, and I've tried the standard troubleshooting steps: clearing cache, disabling extensions, and testing on a different machine. The issue persists, which leads me to believe it might be related to the document state or a recent platform update. It's particularly noticeable after generating several iterations of content within the same document.
Has anyone else experienced similar performance drops in the long-form editor recently? If so, have you found any workarounds or identified specific triggers? I'm trying to determine if it's related to document length, a particular type of command, or something else entirely. Sharing any details about your own experience would be helpful for everyone to see if there's a pattern.
—HR
—HR
> "This happens most often when I'm using the 'rewrite' or 'expand' commands on a highlighted section."
That's the key. Those commands are almost certainly making API calls to a language model. Each iteration generates a new batch of tokens, and the editor is likely holding the full document state plus a history of revisions in memory. If you're running multiple iterations in the same document, you're stacking DOM nodes, undo/redo buffers, and possibly cached response objects.
You've already ruled out local environment issues. So it's either the platform's client-side memory management being garbage or the API itself throttling/timing out on the rewrite calls. I'd bet on the former.
Check the browser's performance tab while reproducing the freeze. If you see a mountain of detached DOM nodes or a heap snapshot that's ballooning, you've found your culprit. Workaround: hit "save as draft" and reload the page between heavy rewrite sessions. That flushes the in-memory state. If the issue returns immediately, it's the API side.
Has anyone tried this on a different browser (Firefox or Edge) to see if the behavior is consistent?
Your cloud bill is 30% too high
Yep, seeing this too on Firefox, same pattern. It's not just Chrome.
It definitely spikes after several AI edits. I've found it helps a tiny bit to highlight a *much smaller* section before hitting rewrite, like a single sentence instead of a whole paragraph. It seems to queue less internal state that way.
Have you tried the "copy section to new doc" trick? It's annoying, but if I take the block I want to iterate on and paste it into a fresh editor, the performance is fine. Then I paste it back. Suggests a memory leak tied to a single document's history.
measure twice, ship once
Same here, started for me too in the last week. It's been driving me a bit nuts.
I can second the point about the "copy section to new doc" trick from the other reply. I started doing that yesterday and it does seem to work, though it's a clunky workaround.
What I noticed is that just having the doc open for a while, even without using AI commands, seems to make it slower. Could there be a background process or something?
Yeah, that tracks with what I'm seeing too. The "generate several iterations" part seems crucial - it's like each revision leaves some residue in memory.
One thing I noticed: if you open the browser dev tools and check the Performance Monitor, you'll often see JavaScript heap size climb steadily after each AI command. It doesn't always get garbage collected properly, especially if you're quickly switching between edits.
A temporary fix I've been using is to periodically refresh the page (annoying, I know). But it does clear the accumulated state. Might be worth trying until there's a proper fix from the platform side.
Clean code is not an option, it's a sanity measure.