Performance: Improve the initial loading time and the feeling fo smoothness while typing in blocks.

[SchneiderSam]

Describe the bug
As the developer @youknowriad of GBerg asked me, I will now report a new bug: the editor is still slow after the official 4.3 update. I have the feeling that it has become even slower. Old bug that should be solved: #10418

In this article I have already explained what the problem is. Here again the roughest overview:

If you insert an article with a lot of words, headings and blocks, the following happens: the GBerg becomes extremely slow. You can hardly write. It may be due to my internet connection (see here), but I wonder why I can write in all other editors while I'm still sneaking around with GBerg. By the way, this bug has also been noticed by a member of Automatic (see here)

Old Editor:

That's clearly not the same content. Since I can't take the blocks one at a time. I did the test with over 7000 words and the write flow is much better and faster.

New Editor:
http://recordit.co/F7R4jUi7a6 (Please watch the console where you can see that I am writing.)

To Reproduce
Steps to reproduce the behavior:

1. Go to 'Code Editor'
2. Click on 'insert' and insert the following code.
3. Scroll down to 'new Block' and write a paragraph
4. See error: http://recordit.co/F7R4jUi7a6 (Please watch the console where you can see that I am writing.)

Expected behavior
A smooth write flow like the old editor. Without interruptions.

Desktop (please complete the following information):

• OS: Win10
• Browser Chrome
• Version 70

Additional context

• Please add the version of Gutenberg you are using in the description: 4.3 - 4.6
• Wordpress: 4.9.8

[ocean90]

Related: #11770

[florianbrinkmann]

I can reproduce that, I tested it with the by far longest article from my blog. Converting it from classic block to blocks takes a while but works, but typing has a delay from more than a second – much better (almost without delay on typing) in the old editor. My internet speed is 36.2 Mbit/s download and 8.96 Mbit/s upload. Testing with the content of @SchneiderSam works better. If it helps, here is the content of the post in HTML format (so the conversion to blocks can be tested, too): https://gist.github.com/florianbrinkmann/4e9e4d23eaefb8b23484badddd848196

[SchneiderSam]

So if I insert @florianbrinkmann content, nothing works for me anymore. That's pretty bad, I can't do anything here anymore. GBerg loads and loads... write with delay and Wordpress hangs up.

[rpkoller]

Loading an article on the editor page containing the content provided by @florianbrinkmann lead to a blank screen for 44 seconds and afterwards to another 56 seconds of FOIT (using Safari 12.0.1)

...and that test took place in a local dev environment by the way.

[spencerfinnell]

Can confirm 4.3 still takes about a minute to load:

Words: 3451
Headings: 29
Paragraphs: 34
Blocks: 218

The post is a list of column blocks with images and paragraphs in each columns.

Once loaded typing is very delayed/laggy.

[lkraav]

4.3: yep, we're also seeing editor massively slow down on long posts. Column blocks seem to be involved.

[aduth]

One additional piece of information which could be useful are any plugins active on a site, particularly those which may have recently updated to add compatibility with Gutenberg†.

† The thought here being to eliminate a possibility where a plugin is implemented in such a way that it could be affecting performance of the editor.

[spencerfinnell]

For mine the only plugin directly integrated with Gutenberg is Yoast SEO, but deactivating it makes no noticeable difference in load time or response time typing.

[SchneiderSam]

Tested with 5.0-beta4-43896 and no plugins. Same result. Especially with the content of florian :-)

[aduth]

There are a number of recent pull requests (not yet included in a plugin release) which seek to address some performance degradations related to interface updates in response to block updates (e.g. writing in a paragraph):

• Add hasInserterItems selector and improve getInserterItems selector performance #11845
• Refactor selectors used in copy-handler #11844
• Refactor the BlockToolbar compoonent to avoid getSelectedBlock #11843
• Refactor the block inspector component to avoid getSelectedBlock #11842
• Use getBlockName instead of getBlock in selectors #11841

One additional culprit I've noticed is that while specifically updating blocks within a nested context (e.g. Columns), there is some wasteful / unnecessary updating which occurs to the block's ancestors.

(The above GIF uses React DevTools "Highlight Updates" feature)

[spencerfinnell]

Are there any benchmarks for before and after these PRs?

[SchneiderSam]

@aduth and @youknowriad - Tested with GB 4.4 and: it is still slow. Please continue, it doesn't make sense for me as an author to install GB if I can't write properly. I hope this will be fixed before Wordpress 5.0.

Do I expect too much?

[lkraav]

Do I expect too much?

Certainly not. I can confirm, on 4.4.0 my real-world content sample is still unusably slow to edit.

Hopefully the other related PR-s can do something, and we're not dealing with a massive architecture problem here.

[SchneiderSam]

There are a number of recent pull requests (not yet included in a plugin release) which seek to address some performance degradations related to interface updates in response to block updates (e.g. writing in a paragraph):

• Add hasInserterItems selector and improve getInserterItems selector performance #11845
• Refactor selectors used in copy-handler #11844
• Refactor the BlockToolbar compoonent to avoid getSelectedBlock #11843
• Refactor the block inspector component to avoid getSelectedBlock #11842
• Use getBlockName instead of getBlock in selectors #11841

All mentioned PRs were fixed with 4.4 - that's why I wrote again. That worries me:

#11811 (comment)

But well I don't want to depremiate anyone here, but I just have astomach ache: so far I was a huge fan of GB, but it's no fun.

[aduth]

Work toward improved performance continues. Hence why this issue remains open.

You may be interested in observing the Performance label to stay up with the latest: https://github.com/WordPress/gutenberg/pulls?utf8=%E2%9C%93&q=is%3Apr+label%3APerformance+

[SchneiderSam]

Okay, thanks for working so hard. Please keep up the good work. As I said, the worry comes only because we are not two weeks before the release.

Thank you!!!

[rpkoller]

retested with gutenberg 4.4, the content is the long article by @florianbrinkmann again and gutenberg is the only plugin installed on 4.9.8 running on local by flywheel. 35 seconds white screen and another 33 seconds FOIT.

[sgomes]

Hey everyone! After some investigative work on this, it seems to me that a big part of the problem with typing becoming slow as the number of blocks grows is the way the state tree is organised.

Block information is stored in state.editor.present.blocks, with the information for each individual block under state.editor.present.blocks.byClientId. There's also state.editor.present.blocks.order, which keeps track of block order in the document.

blocks: {
   byClientId: { [ clientId ] : { name, attributes, isValid ... } },
   order: [ ... ]
}

When a user types in the current paragraph block, this modifies state.editor.present.blocks.byClientId[id].attributes.content. This means that any selector that depends on state.editor.present.blocks or state.editor.present.blocks.byClientId will be invalidated on every keystroke, making it an expensive branch of the tree to depend on.

Now, there are some selectors that are able to get around this by depending on state.editor.present.blocks.order instead. However, the only real information there is the block ID, so for selectors like getGlobalBlockCount that take an optional name to filter by, it's not a valid option. This means that getGlobalBlockCount currently depends on state.editor.present.blocks.byClientId and thus gets invalidated on every keystroke. There are several other selectors in the same situation.

The solution I'm looking into, at @youknowriad's suggestion, is removing attributes from their current location in the tree structure, and placing them instead in state.editor.present.blocks.attributesByClientId. This would split the tree structure into a cheap branch that only gets updated when blocks get added/removed, or when the block type changes for a block (byClientId); and an expensive branch that gets updated on every keystroke (attributesByClientId).

blocks: {
   byClientId: { [ clientId ] : { name, isValid, ... } },  // Cheap
   attributesByClientId: { [ clientId ] : attributes },    // Expensive
   order: [ ... ]
}

Selectors could then be modified to depend on byClientId, attributesByClientId, or both, depending on what they need.

This should reduce the amount of unnecessary work going on, but it's hard to estimate exactly what the performance gains will be. There is significant time being spent on Redux with every keystroke at the moment, though, so it does seem that this could lead somewhere.

[SchneiderSam]

That sounds positive. Is there already a marching direction? Will that be fixed before 5.0?

I'm thinking of the comment by matt:

Some good measures of success for Gutenberg:

....
Can they create things they weren’t able to create before?

I find that an interesting statement. That's definitely something Gutenberg can't do and has considerable flaws. For authors and online marketers this is a mustiarte, otherwise I can completely do without GB.

[rpkoller]

Tested the same post with the RC. 27 seconds white screen and 7 seconds FOIT. Still far away from an acceptable performance. :/ ... and on a side note so far i only tried loading the post with gutenberg now the first time tried to type something in it. from typing a sentence of 40 characters until that sentence showed up at once in the block i typed it in it took 19 seconds.

[brazenvoid]

Hope this gets fixed soon. We are novel writers and translators. Our editors are sick of the slow speed typing of GB that they copy it into Word, edit and then put it back. Unfortunately we switched to GB on our free plan sites to maintain compatibility...

We don't have a crazy amount of paragraphs in each post, perhaps about 60-80 and 2 separator blocks. About 7-8 pages worth of content. Still typing or deletion happens with a perceptible delay.

All of us have 15-50Mbps connections.

[SchneiderSam]

@brazenvoid Thanks for sharing. This has to be fixed in any case. I can't work like this.

[La-Geek]

No label bug?

Is this no bug?

Gutenberg 4.5.1, WP 4.9.8

I have tested with Gutenberg 4.5.1, WordPress 4.9.8 (no other plugins). With the Text of @florianbrinkmann, I inserted the HTML into classic editor (text view), saved, converted it to Gutenberg Blocks. The conversion had a duration of 12 seconds. Now when I type in a block, every letter needs more than 1 second.

development version (5.0-RC1-43944)

--- nothing else installed than beta tester plugin ---
New post, block classic -> edit as HTML -> insert copied HTML of Florian, publish. Converts to blocks (12 second), type in a block, every single letter needs more than 1 second.

I don't know, if this has any relevance:
MySQL Version 5.7.19
PHP Version 7.2.11-2+0~20181015120510.9+jessie~1.gbp8105e0
PHP max_execution_time 360
Tested PHP Max Execution Time 260 secs
Reported PHP Memory Limit 2048M (local) / 2048M (master)
Tested PHP Memory Limit 1716 MB
PHP Maximum File Upload Size (server-reported) 50 MB
Post Max Size: 50M
Max Input Vars: 1000

My internet speed is 150 Mbit/s download and 10 Mbit/s upload

[dev4press]

I too have tried a few of my longer articles 2500+ words with 10 to 15 images, one or more tables. Converting to Gutenberg takes more than 15 seconds for each article. Typing later is slow for shortest of the articles 2550 words, and unusable for an article with 4121 words (more than one second for each letter), Chrome (and same in Firefox, both latest versions), memory usage climbs rapidly, and CPU usage goes close to 50%. All this is done with clean WP 5.0 RC install, default theme and no other plugins, on Lenovo laptop with i5 8gen CPU and 8GB of RAM. I wasn't going into details what the Chrome console shows, but this is unusable.

This has to be marked as a bug, and it has to be resolved before you can even think that Gutenberg editor is anywhere close to usable. If it remains in the 5.0, you can use Gutenberg with texts with up to 1000 and a moderate number of blocks. I noticed slowness with any text I tried that gets to be a bit longer.

I doubt that any developer working on it has tested Gutenberg in the past year with text longer than the demo text. I know that 3000+ words texts are not common, but this will affect not only long text but complex layouts with nested blocks. I can't even imagine what kind of chaos will start when a third party blocks are added. Or imagine, if you try to do some casual editing on some older laptop or tablet even, that will be very frustrating.

[Otto42]

I'm not sure why everybody is posting their internet speeds, but posting your browser information might provide more insights into the issue at hand. The editor runs in your browser. Knowing why your browser might be slowing down would be more useful.

[florianbrinkmann]

I’m using Firefox Nightly, currently version 65.0a1 (2018-11-25) (64-Bit) (on Windows 10).

[youknowriad]

Works great for me in different browsers, you must have an issue somewhere, a plugin or something else.

[wpaustria]

Yeah! 4 sure it must be my dev insta...

The testing system is a €100 VPS, the insta is brandnew.
Now I have deactivated all the plugins - as you can see from the video of the screen cast I just made

https://youtu.be/HwFnG77QOvk

Still nothing works..
For sure it's my fault.

[youknowriad]

I'm sorry it doesn't work for you. I'm not saying it's your fault, I'm just trying to find what's going wrong. If you want me to record a screencast to show that it works for me, I can.

[youknowriad]

If nothing appears, maybe there's a JS error somewhere, which browser are you using?

[wpaustria]

Freshly installed (*) FF 64 with enabled uBlock origin.
Nothing fancy here.

(*) cause I bought myself a new laptop - and I can warmly recommend it - it's an Acer Swift 5 SF515 ;DD

[florianbrinkmann]

@wpaustria you need to install and activate the Gutenberg plugin to test the latest version I think.

I just tested my article with Gutenberg 4.9 and it is much better now (still has a small delay (but far away from a type delay that can be measured in seconds), and converting from one classic block to single blocks still takes some time and Firefox asks if the page should be stopped).

[youknowriad]

I think I found the issue.

TypeError: Argument 1 of Node.removeChild is not an object.

Is this what you see on the console? I think there's probably a javascript error somewhere blocking pasting entirely but nothing related to performance. Let's open a separate issue for it.

[wpaustria]

Tried it on a freshly installed Chromium:

https://youtu.be/gTMHEAs68Mc

And considering @florianbrinkmann's proposal, I installed the Gutenberg plugin and tried again..
Have a look at the attempt which didn't lead to have the text copied:

https://youtu.be/W-X6hPB4OfY

There is a JS problem as you can see in the console...

[youknowriad]

Thanks for the tests @wpaustria I have the same error when pasting. If you want to try the performance, you can try pasting to the html editor and then converting to blocks.

I'm closing this for now.

Here's the JS bug issue #13527

[rpkoller]

@youknowriad with what version or build number you consider this issue fixed? I've tried again after seeing the issue got considered as fixed with the latest plugin version 4.9.0 and retested with the florian brinkmann article. 40 seconds white screen and another 64 seconds FOIT with a local test install in Local by Flywheel. still anywhere near from fixed for the initial load imho. typing performance is at least not stalling and freezing anymore but still far away from a real time typing experience. feels slow-moving.

[rpkoller]

@youknowriad have you seen my question 18 days ago?!

[youknowriad]

I tried testing again, I notice that the initial loading time still needs to be improved, I agree. I still think the big performance issues are fixed. Work on performance is not stopping.

[rpkoller]

so what are your loading times on your computer with the article by florian brinkmann? and are the loading times with gutenberg en par with the loading time with tinymce with the florian brinkmann article? then i would consider the loading times as fixed. but at the moment on my side i have still as stated 40 seconds white screen and 64 seconds foit with gutenberg compared to about 12 seconds overall with tinymce if i remember correctly.

[youknowriad]

Loading times for me are 15 seconds for Gutenberg and 6 seconds for the classic editor.

[rpkoller]

But still 2,5 times slower than TinyMCE. But the far more worrying part is your loading time with 15 seconds compared to mine with 104 seconds (btw have you cleared the caches upfront?). I don't know what computer and local setup you are using but my tests were run on a MBP 13" early 2011 with 8 GB of RAM running on Local from Flywheel. I think the computer and device should also be taken into account when dealing with loading times and performance. So I agree that the work on performance never stops but the benchmark for performance should be older less powerful computers and devices not the latest most powerful. I would consider the ticket fixed and ready for afterwards improvement and iteration as soon as Gutenberg is en par with the loading times of TinyMCE on older less powerful machines and device with the article of Florian Brinkmann with caches cleared upfront. Till then I consider the issue not fixed and would keep the issue open.

[rpkoller]

@youknowriad ok retried with 5.1 right now. MBP early 2011 with 10.13.6 and Local from Flywheel. With WordPress 5.1 no other plugins installed. Used the Florian Brinkmann article and cleared caches upfront in Safari 12.0.3.

With Gutenberg:
59,2 second white screen
78 seconds FOIT
137,2 seconds overall

Installed Classic Editor 1.4 afterwards (also cleared caches upfront again)
11,78 seconds loading time overall

Gutenberg still needs to chop off at least 125,42 seconds so that this ticket could be considered as fixed imho.

[youknowriad]

@rpkoller Can you please create a separate issue about the initial loading time, I agree there's still some work we should do there. This issue is too long and hard to grasp for contributors at the moment, so I think a new issue is better.