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.