-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incredibly slow to load editor for a post with 93 instances of TinyMCE #8822
Comments
I tested with WordPress 4.9.8 and Gutenberg 3.5.0 and I was unable to see the same problem happen. I suspect there's something specific in your content that triggers this problem for you, and it would be really good to try to pinpoint that if possible. Does this problem happen for you with every post you open or just some of them? May I ask how many images are used in the post called "Images" from your video example? I'll keep an eye out for similar reports since there isn't enough information in your report to go on yet. Noting a similar performance issue with more detailed testing steps for reference: #8675. |
That's quite strange, I can't reproduce this and haven't noticed a difference in performance lately. I'm also a MacOS Firefox user, so our browser setups are similar. Could you give us more information about your site's environment? Are you running other plugins, any that might add extra Gutenberg blocks, etc.? Does downgrading to 3.4.0 or another version affect performance? |
@designsimply Sorry, GitHub didn't update the page with your comment, didn't mean to repeat a lot of what you said 😅 |
I tried downgrading to 3.4.0. It's still quite slow but possibly a couple of seconds quicker Vid for 3.4: https://cl.ly/3b420T360E1t I found these errors/messages in the Console:
========= Here's a couple of pics of the Network Waterfall from Firefox Quantum: In case it helps, here's a pic of part of the Performance Waterfall from Firefox Developer Along with the Call Tree for that large section Lastly, here's the actual page content. It's basically a page with examples of all sorts of blocks. The site is a local site, so you obviously wont see the images. (If its of any help and you want them, let me know and I can provide them to you)
|
Thanks for all of the info, that’s super helpful :-)
Do you have any plugins installed on the site? Just curious if they’re impacting anything.
|
@tofumatt I do have a number of plugins on this particular site. It's a site for one of my themes on .org so I have a bunch of plugins activated so that I can test the theme against it. BackupBuddy On another test site with only ACF, Gutenberg and WooCommerce, I can see a similar slowness though. It's taking a minimum of 15 seconds to load the editor page |
I'm able to reproduce similar results in the latest Firefox Quantum, running WordPress 5.0 and Gutenberg Chrome exhibits similar behaviour, but not quite as extreme. It took my computer 10 seconds to render the content in Firefox, 2.5s in Chrome. Most of the time is in TinyMCE: presumably because there appears to be 93 instances of TinyMCE being rendered: each one takes a fraction of a second, but it adds up. 🙂Updating TinyMCE to the latest version doesn't give me any improvement. @iseulde was looking at re-using TinyMCE instances a while back (#341). Have you had a chance to think about this some more? @androb: Do you have thoughts on how we could approach this? |
I experience similar behavior, in Safari on macOS. A quick performance profile also suggests TinyMCE instantiation being the culprit. FWIW I'm on a Core i7 MacBook Air with Turbo Boost disabled. It's slightly better with Turbo enabled but still noticeably slow. |
Noting additional context at #8720, which I closed in favor of this one. |
I've looped in @Afraithe and @spocke who may have some suggestions. Is
there any guidance around how many instances should be supported?
On Mon, Aug 13, 2018 at 8:56 AM Andrew Duthie ***@***.***> wrote:
Noting additional context at #8720
<#8720>, which I closed in
favor of this one.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#8822 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACD2sNgyL8ArhhN9Q6LB08zccHB5ZoJCks5uQcvxgaJpZM4V34Ms>
.
--
Andrew Roberts, Tiny <https://www.tiny.cloud> CEO
+1 (650) 833-9352
|
Moby Dick is a decent performance test. When I paste that content into Classic Text mode, then switch to Visual, it takes 3-4 seconds to render. Doing the same in Gutenberg... 🙃 I think the only realistic option is to re-use instances, the question is what's the best way to configure that. |
Makes sense to try and reuse the instances. I have seen some pretty crazy
edge cases over the years. I talked to someone the other day using
WordPress to create legal documents that could easily run to hundreds of
paragraphs.
If there is a realistic upper limit for the foreseeable future we may want
to warn before loading or gracefully bail out.
|
So, here's something fun: the performance on creating a new TinyMCE instance whenever a Here's a branch (which has its own bugs, it's just a proof of concept) if you want to try it out: https://github.com/WordPress/gutenberg/tree/lol/8822-delete-and-recreate-tinymce |
Over 40-50 instances you will start to see some significant performance issues, I remember we discussed this with the Gutenberg team early on in the project, especially when you split on Paragraph level content. Should be fairly easy making all types of the same block use the same instance? That should cut down on the unique instances quite quickly. Also as pento experiments with, create a tinymce instance on focus of the area. This is what we used to recommend to ppl running hundreds of instances in tinymce 3.x, we had a special mode for it. Didn't quite need it in TinyMCE 4 so the mode was removed (can still do it manually ofc). |
If it's created on focus, it will still have quite a lot of instances around after some writing. It may be a good temporary solution. I'll look at a solution where we create just one instance for TinyMCE instance with the same settings. Most blocks use the same settings apart from the quote blocks, list block, and table block. When focussing a new RichText area we can swap out the target element, flush undo levels, and so on. |
Well the performance issue should be around the creation of the instances, not having them active, but I haven't tested that. But as you say, compacting the instances to same-block should allow it to scale much better though. |
looked a bit into this too and came to pretty much the same conclusion: large number of instances is not performant, even when there is very little content in them. Also, a single instance with a very very long content (a post with 50k words) may have performance issues too. Then some operations in the editor (like things running on A limited number of instances by "editor settings type" or "block type" seems to solve most problems as it keeps initialization delays to a minimum and moving an instance and resetting its content is fast (as long as that content is not "huge"). Another good alternative is to create instances on focus, and destroy them on blur after few seconds of timeout (as the user might have misclicked, etc.). A possible problem with both of these options is that we may loose the TinyMCE state, i.e. if the user was in the middle of a multi-step operation (like inserting a link) when the instance was moved and reset, we will "loose" all of the steps. This will be somewhat mitigated with the second approach if the user focuses the instance again during the timeout. With both of the above approaches we may need to consider keeping "classic block" instances "on" at all times as it seems they would be affected by the edge cases the most. |
Yet another approach (I know, this is getting quite complex) may be to initialize TinyMCE on focus and always keep two or three instances around, the new one plus couple of the last used. This will take care of most concerns/edge cases caused by moving or resetting instances, and at the same time will be quite performant. |
While it's good to note the impact of initializing hundreds of TinyMCE, which will be common with text-heavy posts, I think it might be good as well to apply the problem to blocks in general. Why do we initialize hundreds of blocks when only a couple are visible on screen at a time? What about blocks which don't use TinyMCE but are still "heavy" (e.g. Code block with CodeMirror)? Could we take these ideas of on-demand instantiation but make them less specific to TinyMCE, and toward blocks in general? Perhaps using something like react-virtualized (react-window) or similar to do virtualized list rendering. |
One potential concern with on-demand TinyMCE loading is race conditions. Is the initialization asynchronous and thus prone to user interaction not being captured by TinyMCE? Or synchronous and causing noticeable delays in the focus initialization? |
Some (early, incomplete) exploration of on-demand TinyMCE initialization at #9040 |
Just want to highlight @paulwilde's issue #9048 (closed to merge into here):
Most of the discussion here is around instantiation, but I've also experienced seriously degraded performance in Safari even after the instantiation finishes, similar to what's described above (many blocks, lots of nesting, etc.). If I had to guess it's related to memory allocation (my understanding is that Chrome allocates a high/fixed amount of memory to each tab, sort of like a PHP-FPM worker, whereas Safari allocates memory to each tab more conservatively) but that's also just a guess ;) |
There are some common events that cause code to run on all blocks ( I agree with @aduth's earlier comment that the most scalable solution is going to be something that only renders blocks when they're in view. |
I'm working on a 5,100 word post and Gutenberg is already showing signs of degraded performance; lag is evident while typing. Post is all text. Running on a local installation, just WordPress 4.9.8 and Gutenberg 3.9.0, in Chrome 69.0.3497.100 64-bit. |
So this might not all be TinyMCE... see #10427. |
Closed by #10723 |
Describe the bug
Have just updated to v3.5.0 and it's incredibly slow to open the editor. It now takes approximately 15 seconds just to open a simple page to edit it. Not only that, it sits on a blank page (with the just main left-hand menu & admin bar) for the majority of the time so it actually looks like the page just didn't load, but if you wait long enough the rest of the editor eventually loads.
Video: https://cl.ly/3t391J1y1Z1J
To Reproduce
Steps to reproduce the behavior:
Expected behavior
It shouldn't take this long just to start editing a page. It shouldn't look like it stopped working.
Desktop (please complete the following information):
The text was updated successfully, but these errors were encountered: