search

WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.
https://wordpress.org/gutenberg/
Other
10.5k stars 4.19k forks source link

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

Closed SchneiderSam closed 5 years ago

SchneiderSam commented 5 years ago

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: mapqmabb67

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):

Additional context

ocean90 commented 5 years ago

Related: #11770

florianbrinkmann commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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)

bildschirmfoto 2018-11-13 um 14 01 59

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

spencerfinnell commented 5 years ago

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 commented 5 years ago

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

aduth commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

aduth commented 5 years ago

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):

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.

xmas

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

spencerfinnell commented 5 years ago

Are there any benchmarks for before and after these PRs?

SchneiderSam commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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:

screenshot_1 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.

aduth commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

La-Geek commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

lkraav commented 5 years ago

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.

spencerfinnell commented 5 years ago

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:

youknowriad commented 5 years ago

@spencerfinnell The PR #12312 should have an impact on both the second and third points.

websupporter commented 5 years ago

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.

frogdesk commented 5 years ago

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.

rpkoller commented 5 years ago

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.

SchneiderSam commented 5 years ago

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!

rpkoller commented 5 years ago

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.

lkraav commented 5 years ago

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:

SchneiderSam commented 5 years ago

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!!!

aduth commented 5 years ago

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 .

SchneiderSam commented 5 years ago

@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!

marcusblogger commented 5 years ago

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

  1. 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.
  2. 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

rpkoller commented 5 years ago

@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?

SchneiderSam commented 5 years ago

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

  1. 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.
  2. 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 ;-)

mtias commented 5 years ago

Marking high priority and assigning to the next minor release.

noisysocks commented 5 years ago

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.

rpkoller commented 5 years ago

@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.

dev4press commented 5 years ago

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.

SchneiderSam commented 5 years ago

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

dev4press commented 5 years ago

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.

frogdesk commented 5 years ago

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