Has anyone noticed that either Chrome or ProseMirror, or ProseMirror in Chrome combined is kinda slow when you start dealing with large amounts of content? We’re noticing that other browsers work better with our application, and performance is pretty important to us. Anyway, I was wondering if anyone had any comments on whats going? If anyone has heard of anything or know anything that is ongoing, it would be nice to hear about it, no matter how small.
How big are the documents where you start noticing this?
They are very big, But, we have the same documents on Firefox and Safari. On those browsers, they function far better than Chrome.
Approximately 50+ pages or so, it becomes quite noticeable in the performance dip. It looks like updating to the newest versions of prosemirror did help. We were quite a bit behind. Its still not perfect, it looks like something called AppleSpell is part of the problem at least. But its not really that great.
Chrome plugins (e.g. Grammarly or other spell checkers) impact performance because they run in the same browsing context as ProseMirror. It’s only natural that Chrome will run slower than Firefox if you don’t have them installed in Firefox. Can you reproduce these problems on a fresh installation of Chrome without plugins? Chrome incognito modus disables most plugins - you can also try that.
Very big documents making things slow is a known issue. If you try to edit the same document in a plain contentEditable element, is it noticeably better?
We have been testing by trying to disable any and all spelling plugins. Its also a little more complicated for our user context as well. How to resolve problems with little user interaction. But, AppleSpell continues to come back up and be annoying. Suck up a lot of CPU cycles randomly but, only seems like Chrome is where it shows up.
Sorry, I’m not sure I understand what you mean by plain contentEditable element. I think the thing that sorta stands out to me is how firefox runs way better than chrome. My intuition is that its browser level issues with performance.
This may not help at all, but might be worth trying the tips at https://discussions.apple.com/thread/8385482 (thought I’d back up those dirs/settings if you don’t want to lose them)
Yeah, we did that too. We found it didn’t really help a whole lot.
I’m running into performance issues with large documents + decorations (non safari / apple OS chrome). I am nearly sure it’s simply due to large amount of visible DOM nodes, nothing in particular able to be optimized via prosemirror source code. I know this because I wrote a prosemirror plugin which sets certain nodes to be hidden via decoration (display: none) and when a large document is loaded but most of the nodes are hidden, performance becomes snappy fast. When unfiltered, there is noticable lag when adding characters / structure.
I’m thinking pagination or some type of smarter occlusion culling is the short / medium term solution. A solution without real time collaboration would be pretty straightforward. But with collaboration, it gets a bit more tricky.
Occlusion culling is difficult because simulating the full height of the scrollable container is indeterminate, and would require at least one real DOM render to predict accurately. I’m pretty sure this is how Google Docs operates (probably some cache layer for the real height while lazy loading)
I acknowledge this thread, Paginated Editing?, where it’s suggested prosemirror lib wouldn’t bake in this type of functionality, but it’s definitely important for the way my app is being used. (There are at least two other threads discussing pagination as well for any interested)
All of this being said, it’d be great to see some type of community plugin that bakes in either pagination and/or occlusion culling support. I’ll see what I could do, but can’t promise anything short term. I’d also be willing to have a discussion with anyone interested in implementing something of the sort.
4 Likes
I did a similar experiment ages ago. I basically load like 30% of this book:
Into the basic example of prosemirror, that is almost 500k words (so is massive).
You can check this on this link: https://cookie-turkey.glitch.me/
You can easily see the difference on performance of chrome vs firefox.
It is, but for me Chrome is doing a lot better on that than Firefox (so that seems contrary to @JCHollett’s experience from the first post).
Just tested on Firefox 72 and Chrome 79 on an old Macbook Air mid 2012 with only 4 GB of RAM, this 500k page works impressively well on Firefox, you can feel some input delay but nothing crazy while it’s indeed quite sluggish on Chrome. I didn’t think there would be such good performance on massive documents like that.
My feeling is that Chrome just has a harder time dealing with it but, It seems like other things might affect performance too.
Tested on linux debian: chrome 80 is not slow, firefox 72 is a bit slow.
Maybe the issue you see happens only on OSX ?
macOS 10.15.3 check of typing near the bottom of the document:
- Safari 13.0.5: quick
- Firefox 72.0.2: very slight lag
- Chrome 80.0.3987.100: significant lag
macOS 10.15.4 with a document that’s ~15000 characters / ~3000 words long (which is not that long):
- Safari 13.1 and Firefox 72.0.2 show almost no lag.
- Chrome 81.0.4044.138 and Brave 1.8.90 (also based on Chromium) both show significant lag, enough to be unusable.
This is with no plugins enabled on the editor. I’m seeing almost as bad performance if I copy my entire document into a plain contenteditable element so the problem seems to be with Chromium, not with ProseMirror.
I am nearly certain there is at least one other thread that discusses this issue.
Chrome Linux seems to deal with documents in the million-character range without much trouble, interestingly.
Is there possible to share github gist about the hiding plugin ? 
1 Like