Slow perceived performance compared to Classic Editor

[danielbachhuber]

First, try typing a couple paragraphs in Gutenberg. Then, try typing the same paragraphs in Classic Editor.

When you experience these two experiences side by side, Gutenberg is noticeably slower than the Classic Editor. In fact, for any amount of substantial writing, the Classic Editor is refreshing to use over Gutenberg.

I'd suggest we:

• Find some way of benchmarking this experience as a performance metric.
• Track down and address the source of slowness. There could be a silver bullet, or it could be a variety of factors.
• Ideally, work the performance metric into our automated testing system.

[bobbingwide]

I felt that the editor slowed down when upgrading to 2.5 a while ago. I was unable to identify the true cause but noted a few red herrings.

1. During initial load there may be unsatisfied REST requests for open meta boxes which are still completing. Workaround: Keep meta boxes ( tags, categories, publish status, page attributes ) closed.
2. For new posts auto saving kicks in constantly. Workaround: Publish the post you’re editing.
3. Check you don’t have any Browser developer tools slowing down the process which are Watching variables that change a lot. Workaround: Close developer tools.

I don’t know how to count instructions per keystroke but I imagine that’s what’s needed... trace through all the processing performed when a keystroke has been made and look for too much stuff going on.

[danielbachhuber]

@jorgefilipecosta Any ideas for how we might be able to benchmark performance in an automated way?

[aduth]

A point of clarification: Are perceived performance issues being observed while in development mode (with debugging constants), or in the distributed plugin form?

[danielbachhuber]

Are perceived performance issues being observed while in development mode (with debugging constants), or in the distributed plugin form?

Both.

[jorgefilipecosta]

Sorry @danielbachhuber, I missed your ping.

Regarding benchmarking performance in an automated way, maybe we can make use of puppeteer.
One simpler test could be make Gutenberg open a huge post and use waitFor page function to count the time until the post is loaded.
Another test could be pasting something and use the waitFor function ( count the time it took) with a selector that only appears after the paste is complete like a block that should be created.

[noisysocks]

Note that Puppeteer has metrics() which could be useful.

I think automatically tracking two metrics and monitoring for them for regressions would work quite well for us:

1. Time to first meaningful paint
2. Time between pressing a key and text appearing on the screen

[danielbachhuber]

Yep. Specific to this issue, it's keystrokes that are slow to me. Typing into Gutenberg feels like typing into Slack when I have a bunch of organizations open.

[aduth]

What is the threshold by which we can consider this resolved?

[danielbachhuber]

It's still pretty slow, to be honest. I don't know if it's possible to get it to Classic Editor fast, but that's the target I'd shoot for.

[notnownikki]

Just adding a "slow for me too" here. It's got really bad with the last release. Holding down a key in a paragraph block can freeze the browser.

This gif doesn't show it exactly, but the more I type in a post, the worse it gets, and holding down a key when I recorded this, it took 5 seconds for the screen to update when I took my finger off the key.

[notnownikki]

I've noticed that the more paragraph blocks you have in a post, the worse it gets.

[gziolo]

Can you check how many entries do you have created for the editor's internal history (undo/redo feature)? You would have to open Redux devTools and investigate.

[notnownikki]

Yes, although I'm not sure the undo/redo is the problem I'm seeing.

If I have 1 paragraph block, things seem ok.

If I create 30 paragraph blocks, the lag is extreme, freezing the browser if I hold down a key.

If I then delete those 30 paragraphs and go back to 1, the lag disappears.

[notnownikki]

I've opened an issue with steps to reproduce here: #7680

[aduth]

#7699 may have a reasonable impact here, along with a number of other performance-labelled pull requests which have been merged recently.

I also observed that <StrictMode> seems to be doubling the number of store listeners we have active at any given time. This should be present in development mode only (not the plugin distributable) but (a) we should confirm this and (b) we should see if this doubling can be eliminated. Not sure if React is creating a separate copy of the element tree or similar.

[frogdesk]

I feel like I am living in the twilight zone here. This seriously wasn't addressed before full release? Mind = boggled.

[danielbachhuber]

@whywaitwebs There are several performance improvements to be released in 5.0.1, so keep your eye out for those. Achieving the best possible performance is on everyone's mind.