Performance issue with Chrome v96

Hello, After updating chrome from v95 to v96 we are having major performance issues. It’s kind of hard to nail down, as it only seem to happen in larger documents.

The issue seems to show up in function selectionToDOM(view, force).

When testing in FF, Edge or Safari or from Chrome prior to v96 we don’t see this issue.

Anyone else notice a performance hit from Chrome v96?

1 Like

Hmm, I don’t see any performance issues in this demo with over 200000 words.

Google Chrome Helper (Renderer) process for consumes % CPU up to 100% and the tab becomes very sluggish when large payload has been entered/pasted in the editor. This issue seems to occur only on Chrome 96.

  1. Official Google Bug: Issue 1271648: regression: ultra-slow typing in some editors
  2. Google Investigates Chrome 96 Upgrade Issues
  3. Google Chrome 96 has issues just after a day of its release

From my own manual testing, many other common editors are seeing the same performance degradation. I see at least: Salesforce Quip and Coda being impacted and also AtlasKit (which depends on ProseMirror). Additionally I see that Etherpad Lite framework is being impacted.

@marijn Is there any chance that this can be mitigated by patching ProseMirror? It looks like is unaffected by this issue. I’m wondering if that’s because each line is a separate content editable in Notion.

I don’t know, since I haven’t investigated this. If you do, and find the specific circumstances that trigger this issue, feel free to let us know.

Bumping that I see massive degradation but mostly in documents that have a lot of text that is triggering chromes auto spell checker by any chance. Every input requires recalculation of all text within the contenteditable. Would make sense that notion would not have this bug if they are chopping up their documents as such.

From investigations we are seeing significant impact at Atlassian (still pulling out data, so this is based on eyeballing perf charts of users with chrome 96), and are currently investigating a “fix” where we may disable spellchecking for some users.

I’m seeing the slow-down in a raw contentEditable element as well, so I think the only recourse is, indeed, selectively turning off spell-check until this is fixed on the Chrome side. (The version 98 build still seems to have the issue too, unfortunately.)

Spell check was always a bottleneck in chrome. See: Performance Issues with ProseMirror and Chrome

But it has probably gotten significantly worse in the lastest version :upside_down_face:

1 Like

FYI, in Chrome, you can copy and paste chrome://settings/?search=spell into the URL bar then disable Spell check from there.

For anyone interested. We think the right bug on googles side is 1271918 - chromium - An open-source project to help move the web forward. - Monorail.


Yep. Its also disable-able from the right click menu (context menu for the spell check underline)