Gutenberg: Performance: Improve the initial loading time and the feeling fo smoothness while typing in blocks.
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:
- Go to 'Code Editor'
- Click on 'insert' and insert the following code.
- Scroll down to 'new Block' and write a paragraph
- 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
SchneiderSam
All 88 comments
Related: #11770
ocean90
on 12 Nov 2018
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
florianbrinkmann
on 13 Nov 2018
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.
SchneiderSam
on 13 Nov 2018
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.
rpkoller
on 13 Nov 2018
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.
spencerfinnell
on 13 Nov 2018
4.3: yep, we're also seeing editor massively slow down on long posts. Column blocks seem to be involved.
lkraav
on 13 Nov 2018
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._
aduth
on 14 Nov 2018
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.
spencerfinnell
on 14 Nov 2018
Tested with 5.0-beta4-43896 and no plugins. Same result. Especially with the content of florian :-)
SchneiderSam
on 14 Nov 2018
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):
- #11845
- #11844
- #11843
- #11842
- #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)_
aduth
on 14 Nov 2018
Are there any benchmarks for before and after these PRs?
spencerfinnell
on 15 Nov 2018
@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?
SchneiderSam
on 15 Nov 2018
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.
lkraav
on 15 Nov 2018
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):
- #11845
- #11844
- #11843
- #11842
- #11841
All mentioned PRs were fixed with 4.4 - that's why I wrote again. That worries me:
https://github.com/WordPress/gutenberg/pull/11811#issue-230464225
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.
SchneiderSam
on 15 Nov 2018
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+
aduth
on 15 Nov 2018
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!!!
SchneiderSam
on 15 Nov 2018
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.
rpkoller
on 16 Nov 2018
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.
sgomes
on 22 Nov 2018
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.
SchneiderSam
on 22 Nov 2018
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.
rpkoller
on 23 Nov 2018
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.
brazenvoid
on 24 Nov 2018
@brazenvoid Thanks for sharing. This has to be fixed in any case. I can't work like this.
SchneiderSam
on 24 Nov 2018
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
La-Geek
on 24 Nov 2018
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.
dev4press
on 24 Nov 2018
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.
Otto42
on 26 Nov 2018
I’m using Firefox Nightly, currently version 65.0a1 (2018-11-25) (64-Bit) (on Windows 10).
florianbrinkmann
on 26 Nov 2018
I'm not sure why everybody is posting their internet speeds
People don't understand the tech details here always, so probably posting it just in case from a general "slow" perspective.
But regardless, I think the development team already knows the underlying architectural issue here. Hopefully it'll work out.
lkraav
on 26 Nov 2018
It should also be noted that the entire editor is slow, not just RichText elements. Updating the permalink slug (in the document settings) or anything else that takes input is slow.
There are 3 areas of improvement as far as I see:
- Initial parsing and rendering time -- time to first interaction.
- Typing/interacting with blocks (#12312)
- Interacting with the rest of the editor
spencerfinnell
on 27 Nov 2018
@spencerfinnell The PR #12312 should have an impact on both the second and third points.
youknowriad
on 27 Nov 2018
I tested it today with the content provided by @SchneiderSam and the problem persist for me. I tested it with Firefox in the current RC as well as with the nightly build plugin and wp 4.9.8. I also tested it with Chrome. There it lags a bit as well, but not as bad as with Firefox.
Here is a screencast with my xp: https://www.youtube.com/watch?v=yIV6REWM5tE
Ubuntu 14.04
Browser Information:
Name Firefox
Version 63.0.3
Build-ID 20181116161301
User-Agent Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0
Operating System Linux 4.4.0-139-generic
probably not too much new info as i see, the discussion on this topic has quite evolved, wanted to leave it anyway.
websupporter
on 27 Nov 2018
This happens even without inserting articles with a lot of words. The current release of Gutenberg just hangs horribly all over the place no matter what you do. You can restart your browser and expect it to work smoothly for about half an hour.
I have 16 GB of RAM. I have a 1080 TI. I have an i7 Haswell processor. I should not EVER be experiencing ANY LAG WHATSOEVER in a TEXT EDITOR.
frogdesk
on 29 Nov 2018
Retested RC2 with Safari 12.0.1 with Local by Flywheel and Florian Brinkmanns sample article (no plugins installed except wordpress beta tester plugin and the classic editor plugin but the latter was deactivated during the first test).
White Screen for 68 seconds
FOIT for another 35 seconds
after reactivating the classic editor and reloading the article:
No content in the body meta box 12 seconds
FOIT for another 2 seconds
Feels things remained bad or got even worse loading the article with gutenberg.
rpkoller
on 1 Dec 2018
Tested with my content + 4.6 and the performance is unchanged. The way it looks, it's not solved with 5.0. Too bad, but ok you're working on it. Thank you very much!
SchneiderSam
on 3 Dec 2018
Retested with RC3 in Safari 12.0.1 with Local by Flywheel and Florian Brinkmanns sample article (no plugins installed except wordpress beta tester plugin and the classic editor plugin but the latter was deactivated during the first test).
White Screen for 41 seconds
FOIT for 52 seconds
In context with the new release date in two days anywhere near production ready performance wise.
rpkoller
on 4 Dec 2018
In context with the new release date in two days anywhere near production ready performance wise.
Yeah. I'm not sure what exactly @m means in his article https://ma.tt/2018/11/a-gutenberg-faq/ where he writes:
We have had a stable RC1, which stands for first release candidate, and about to do our second one. There is only currently one known blocker and it’s cosmetic.
Makes me, for one, go :thinking:
lkraav
on 4 Dec 2018
As long as this point #12312 is not solved, I will wait with the update. That just doesn't make sense to me.
@sgomes and co: please keep up the good work. I can imagine that you get pressure from everywhere. Thanks for working on it! Unfortunately I can only help with my words! You're doing a great job!!!
SchneiderSam
on 4 Dec 2018
There are a number of additional performance optimizations which have been merged or approved for merge but not yet included in a release, as they missed the deadline for RC code freeze. These are slated to be included in a 5.0.1 patch release to follow soon after 5.0.0 .
- #11851
- #11899
- #12356
- #12379
- #12384
- #12386
- #12402
- #12460
- #12477
- #12480
- #11602
- #12521
- #12542
aduth
on 4 Dec 2018
@aduth great. You are great. It's really nice to see that you consider the wishes of the Cummunity and take them seriously. Please don't let the many negative comments dismotivate you. We as a community also have the responsibility to support you developers. That's a bit too short at the moment and I have to get my own nose into it.
Therefore: all thumbs up!!!! You are great!
SchneiderSam
on 4 Dec 2018
Still having these very slow load issues as well. Have been looking into solutions for the past week. I use most up to date version: Gutenberg Version 4.6.1, and Wordpress 4.9.8.
I created my first 20 or so posts with Gutenberg editor which was great with the exception of slow loads on longer posts which is most of my posts. They are generally long with many blocks and images. I then downloaded YoastSEO and it bugged down my site completely. My site was already running slow and with Troubleshoot mode I realized it was Gutenberg and then made worse combined with YoastSEO.
Now I have to use Classic Editor and a lot of my links no longer are embedded with nice preview that 'Gutenberg has and spacing is all off from when I used the nice Gutenberg platform.
So at this point, I either
- Use Gutenberg and deal with slow speed hoping for future update and then delete Yoast and figure out other solution for seo and meta descriptions.
- Or figure out better Editor that mimics Gutenberg without hampering load speed.
Any insight here would be greatly appreciated on how I can best proceed. @aduth @SchneiderSam
Didn't really get anywhere with my thread here:
https://github.com/WordPress/gutenberg/issues/12508#issuecomment-443919417
marcusblogger
on 5 Dec 2018
@aduth have you tested a build with those patches applied against loading a post with the content of the Florian Brinkmann article ( https://github.com/WordPress/gutenberg/issues/11782#issuecomment-438213916 )? Is it on par with those of TinyMCE now? And is typing and editing within that article possible in real time now? And out of curiosity why those patches haven't made it into 5.0?
rpkoller
on 5 Dec 2018
Still having these very slow load issues as well. Have been looking into solutions for the past week. I use most up to date version: Gutenberg Version 4.6.1, and Wordpress 4.9.8.
I created my first 20 or so posts with Gutenberg editor which was great with the exception of slow loads on longer posts which is most of my posts. They are generally long with many blocks and images. I then downloaded YoastSEO and it bugged down my site completely. My site was already running slow and with Troubleshoot mode I realized it was Gutenberg and then made worse combined with YoastSEO.
Now I have to use Classic Editor and a lot of my links no longer are embedded with nice preview that 'Gutenberg has and spacing is all off from when I used the nice Gutenberg platform.
So at this point, I either
- Use Gutenberg and deal with slow speed hoping for future update and then delete Yoast and figure out other solution for seo and meta descriptions.
- Or figure out better Editor that mimics Gutenberg without hampering load speed.
Any insight here would be greatly appreciated on how I can best proceed. @aduth @SchneiderSam
Didn't really get anywhere with my thread here:
#12508 (comment)
Hi,
so I see the developers are working on it. Take a look at this article. With the next update 4.7 and 4.8 this should hopefully be solved. I completely understand you. At the moment I'm only writing short articles because it's no fun. The only thing I'm doing right now is to be patient and motivate the developers with feedback.
By the way: I'm not a developer, I'm just a small author like you ;-)
SchneiderSam
on 6 Dec 2018
Marking high priority and assigning to the next minor release.
mtias
on 6 Dec 2018
The work listed by @aduth in https://github.com/WordPress/gutenberg/issues/11782#issuecomment-444144278 improves typing performance by more than 340% and will be shipped as part of WordPress 5.0.1.
It's unclear what action needs to be taken for this issue to be considered resolved. Performance work is never really "finished". For now, I'm moving this issue to 5.0.2 so that we can keep track of further performance improvements here.
noisysocks
on 10 Dec 2018
@noisysocks that is easy to assess. Use the Florian Brinkmann article. As soon as the loading of the article with caching disabled is en par or faster than with TinyMCE and the typing is without lagging and hickups in real time en par with TinyMCE then I would consider the issue resolved.
rpkoller
on 10 Dec 2018
Testing with 5.0 for the past few days, and I don't have any performance issues. I tested with the text that has 300+ blocks, 15000+ words, 50+ images, there are no noticeable delays with typing, or using the editor. But, browser RAM usage grows close to 2GB, with CPU using about 15%, and considering how much content editor handles, it is not that big of an issue. Tested on Lenovo laptop with 2 Core i5 CPU (with Hyperthreading, Gen7) and 8GB RAM. The issues I had with Beta and RC1 are resolved for me.
dev4press
on 10 Dec 2018
Testing with 5.0 for the past few days, and I don't have any performance issues.
I can't confirm that. 5.0 is slow. Wait for 5.0.1
SchneiderSam
on 10 Dec 2018
I can't confirm that. 5.0 is slow. Wait for 5.0.1
I believe that there are external influences that cause for some users to work fine, and for some to have performance issues, and it is not very surprising at all, considering that it is mostly JavaScript and React powering it. When I visit any Facebook page, my laptop feels so slow, like it is 10 years old machine. And I am surprised that Gutenberg in 5.0 works fine for me, but I am not surprised that it is broken for so many other users.
I really hope that Gutenberg performance issues can be solved for all users, but at this point, I am not so sure in that. If the system can be broken by the influence of an extension or two, few plugins maybe, it is fundamentally bad design at fault.
Still, I have not updated my websites yet, I have also opted to wait for 5.0.1.
dev4press
on 10 Dec 2018
No performance testing should be done without the Yoast plugin installed and Grammarly browser addon enabled as that is a normal use case scenario. If it performs perfectly fine without either of them, but the second you install one of them it becomes utterly unworkable, then the whole thing is unworkable.
And honestly it's not believable to me that anyone is having good performance on any setup even without these installed. I think your standards are just incredibly low. I almost guarantee that if I tried to type on your computer with Gutenberg I would be utterly dismayed.
Gutenberg doesn't work at all for text editing on my i3 laptop, my i5 iMac, or my i7/1080 Ti desktop, with or without plugins. Without plugins, it's unbearably bad performance, with them, it's completely useless, we're talking one frame per 5 seconds here.
What I really don't understand is, why is ANY lag being treated as acceptable?? That doesn't happen when you simply create a
Most helpful comment
Marking high priority and assigning to the next minor release.