Typing block editor has significant lag, particularly on Chrome MacOS

[jamescl]

Describe the bug
Typing in the block editor (most noticeably in the paragraph block) editor has a noticeable delay.
The lag increases the larger the post becomes.

On one machine, we are finding that typing a sentence of 10 words can take 30 seconds to render on screen.

Using Chrome's performance tool I've observed that keypress/keyup/keydown/input & their child events are taking a long time to run.

As an example, and comparing different machines (specs at bottom), a keypress event is taking

• 500-1200ms on a Macbook Pro
• 150ms on a Microsoft Surface
• 50ms on a desktop
• 250-450ms on the desktop with 4x slowdown enabled in chrome

Using the editor on the macbook Pro is truly painful - every 10 words taking 3-5 minutes to compose and completely breaking up the editing experice - while the desktop rendering is only a little bit jerky.

Neither is acceptable and while the MacBook is a bit old, I don't think it's fair to expect everyone to have gaming PCs to write some blog spots.

I appreciate this issue is similar to #6466 and #7680 - but both of those were closed in #7699, and the performance issues persist.

To reproduce
Steps to reproduce the behavior:

1. Add new post
2. Start Typing / adding content

Expected behavior
To have a smooth typing experience.

Screenshots
If applicable, add screenshots to help explain your problem.

Chrome performance Macbook:

Comparing classic block and paragraph block typing "The quick brown fox jumps over the lazy dog"

Editor version (please complete the following information):

• Tested on clean version of WordPress 5.4.1 with no plugins and also on Wordpress 5.4.1 with only plugin being Gutenberg 8.2.1

Desktop (please complete the following information):

Machine 1: 2016 MacBook Pro / 2.9 GHz Intel i5 / 8GB RAM / MacOS Catalina 10.15.4
Machine 2: Microsoft Surface 2.5 GHz Intel i5 / 8GB Ram / Windows 10
Machine 3: PC Desktop / 3.3 GhZ Intel i0 / 32GB Ram / Windows 10

[talldan]

On one machine, we are finding that typing a sentence of 10 words can take 30 seconds to render on screen.

@jamescl That seems very unusual. All of the machines you mention seem relatively modern and I wouldn't expect that level of performance. I often test in virtual machines with much lower specs and haven't had those kind of issues 🤔

[youknowriad]

What plugins do you have? did you try disabling the plugins to see if it has any impact?

[jamescl]

hi @youknowriad - as mentioned, the test results shown are running WordPress 5.4.1 with no plugins and also on Wordpress 5.4.1 with only plugin being Gutenberg 8.2.1 and getting similar results. Prod with plugins and custom themes is worse, but can't pin it down to a particular plugin.

Have also tested on a brand new install with 1 post, 1 user, WordPress 5.4.1 and no plugins activated (akismet and hello dolly installed, but not active) running twentytqwenty theme. Keypress event on that site, using desktop is 30ms

As a comparison, a keypress when filling in this form on github takes 3.49ms - nearly a 10x performance difference.

Using the CPU throttling function in Chrome Dev Tools leads to dramatic performance declines, which might explain differences in testing/virtual environments vs real world usage when users have multiple tabs/applications open while putting together posts.

[youknowriad]

I'm pretty sure that's some variable here we're missing. We do perform performance checks on each Gutenberg release on a very large post (See the results at the bottom of these posts https://make.wordpress.org/core/tag/gutenberg-new/ ) and even for a very large post, I have a keypress event average to something like 30ms (macbook pro).

These benchmarks are generated by running npm run test-performance on a Gutenberg prod build.

[youknowriad]

How this got closed by the #22577 I don't understand? Github bug maybe

[talldan]

@youknowriad Looks like it was linked in the right-hand column on that PR, not sure how, maybe the wrong issue was linked.

[ellatrix]

I also haven’t been able to reproduce this on a MacBook Pro + Chrome. I also get about 30ms on average. Would it be possible to share example content, or does it start even with a new post and one paragraph?

[jamescl]

Based on the comments above, I've tried to re-create on a local install, and seeing mush faster results. Made me think I was going mad - but have attempted to try and figure out what's going on.

As an observation, the behaviour I'm seeing occurs when the CPU utilisation within the Chrome Task hits 100%.
So when typing a sentence under ideal conditions, CPU doesn't seem to peak past 20%, the typing is visually smooth and the profile in chrome performance looks like this:

If we turn on 4x CPU throttling in devtools, the same action sees CPU usage hitting 100%, the typing becomes laggy and the performance profile looks like this

Appreciate that the CPU throttle isn't real life, so then tried to see what might be the culprit in my environment, and most notably found that in my initial "clean install" I had 'SCRIPT_DEBUG' set to true in wp-config, and turning that off improved key-press events from around 40ms to 20ms

Which didn't explain the behaviour I'm seeing in my prod site, as that setting was off. I've tried unit testing plugins and my theme, and not seeing a noticeable difference from any in particular (although in aggregate they may well be having an impact).

What I can see having an impact on lag is:

• Running incognito seems to be faster - presumably because of the Chrome extensions I'm running.
• Having a preview tab open had a impact - presumably because chrome uses the same task to run both tabs.
• Putting stress in general on the machine in question (e.g. having lots of tabs open with video playing)
• More blocks and complex blocks (e.g. youtube embed inside a column) seems to cause higher CPU usage, although only intermittently.

Chrome's performance monitor shows that the CPU usage is from react.js

I think it's reasonable to conclude, therefore, that if you have some form of CPU constraint (either real or artificial) causes a visual lag on keypress events from Gutenberg's use of react.js

I can keep digging to find more specifics - but to be honest I'm not that familiar with js and even less so with react.... so the below might be a red herring, but here goes:

Using react devtools (and by necessity script debug on) - each keypress seems to result in render events on the block property pane, as well as the top toolbar. Screencap is with the "Highlight updates when components render." option selected in React DevTools for Firefox

I'm also seeing errors in the console in Firefox:
console errors.txt

• Warning: React does not recognize the isSelected prop on a DOM element. If you intentionally want it to appear in the DOM as a custom attribute, spell it as lowercase isselected instead. If you accidentally passed it from a parent component, remove it from the DOM element.
• Warning: Can't perform a React state update on an unmounted component. This is a no-op, but it indicates a memory leak in your application. To fix, cancel all subscriptions and asynchronous tasks in a useEffect cleanup function.

My key questions are

• Does the above help identify areas to improve performance?
• Is there some other way I could identify where a 3rd party plugin/theme/browser extension could be causing issues that could be raised with them?

[mcsf]

Is there some other way I could identify where a 3rd party plugin/theme/browser extension could be causing issues that could be raised with them?

@jamescl, do you by chance have the CoBlocks plugin active? I'm asking after finding some anecdotal feedback elsewhere.

[ellatrix]

Chrome extensions I'm running

Which chrome extensions are you running?

[jamescl]

@mcsf - No, not Running CoBlocks.

@ellatrix - Last Pass, Google Keep, DuckDuckGo Privacy Essentials, AdBlocker Plus.

Last two whitelisted and/or don't work on localhost.

I added on React Dev Tools - which in conjunction with SCRIPT_DEBUG' had an impact.

[melroy89]

I can also tell you, it's very slow in Firefox v84 as well! With an avg FPS of just 6... Even Cyberpunk runs faster.

See zip attachment for the Firefox profiling (json file).

profile_firefox.json.zip

[piterx]

I apologise if this is not relevant, I had a similar issue on Chrome today, but then realised I had a github gist embed link, which caused the issue. When I removed it it works OK.

[caluwaek]

I'm not enough of a techie to be able to provide these charted key lag details but I'm also experiencing a considerable lag when typing in the block editor in Chrome. Even in incognito modus where I only have one plugin (adblock) text only appears after a number of seconds. The cursor also sometimes stops blinking and completely disappears.

Firefox is even worse and has additional problems. The most annoying being that the browser jumps back up in a post when you're trying to edit a block further down. Behavior that you sometimes see when page elements higher up in a page are still loading after you've scrolled down. Only in this case, the complete post is already loaded and it keeps happening.

MS Edge with all plugins disabled and most uninstalled works best for me. I'm thinking of keeping this browser clean just for writing posts and using the others for browsing the web.

[nekohayo]

I don't know if it's any help to know this, but I'm also seeing slow performance (without even measuring it, you just feel it) using Firefox (any version) on Linux (with an Xorg session, AMD Radeon open source graphics, webrender enabled) and what I noticed is that performance is generally okay when "freshly" opening a post for editing, but as time passes performance degrades significantly; it appears to me that I don't even have to be actively using the thing, I could simply write something at night, leave the computer turned on with the browser tab active with the Gutenberg editor, come back to it in the morning, and then it is unbearably slow... until I reload that tab.

So, maybe there is a time/decay/leak component to this, that your tests do not take into account? Or maybe I'm imagining things.

[mcsf]

Or maybe I'm imagining things.

These things are difficult to observe, let alone measure. :) So thanks for the balanced and qualitative report.

what I noticed is that performance is generally okay when "freshly" opening a post for editing, but as time passes performance degrades significantly; it appears to me that I don't even have to be actively using the thing, I could simply write something at night, leave the computer turned on with the browser tab active with the Gutenberg editor, come back to it in the morning, and then it is unbearably slow... until I reload that tab.

So, maybe there is a time/decay/leak component to this, that your tests do not take into account?

This reasoning is sensible. A while back, based on sporadic reports, we tried to spot memory leaks by comparing heap snapshots in between common editor actions like selecting blocks and inputing characters, but nothing definite emerged. So I'll try to replicate your circumstances by essentially letting a Gutenberg session in Firefox simmer for hours before I return to it.

For the record, I rarely notice any performance issues in Gutenberg on my machine, except when on a dev build and under specific load (e.g. running dev tools or a compiler). I'm on a 2017 MacBook Pro — a capable but ageing machine. So let's see what I can find.

In the meantime, if you have any additional info — such as specific interactions that are the slowest, or states of the editor that seem most affected — let me know.

[nekohayo]

I don't really know what I'm doing / looking at with the browser's web dev console perfs tab, but here are my observations where you can see the laggy typing occurring with Firefox... I hope this helps somehow: https://youtu.be/4sfGsPGupaA

This is by no means an underpowered machine; it is old, but we're talking about an eight-cores Xeon with a Radeon R270 ;)

My guess is that if you test with Firefox on Linux, you are likely to exacerbate the symptoms' manifestation, making it easier to trigger the bug on your end and make & test optimizations for it? Generally, my motto is "test on 10-15 years old machines, to feel what the userbase is feeling, because that's what many people use everyday in practice", and optimizing under those suboptimal conditions benefits everyone even under optimal conditions.

[mcsf]

Just wanted to say that I haven't been able to pick this up this week, but that it hasn't dropped from my radar.

[nekohayo]

Additionally, now that I'm thinking about it, this may or may not be related, but if it is, you might be able to establish some collaboration with the Mozilla folks regarding this: https://bugzilla.mozilla.org/show_bug.cgi?id=1593994

i.e. maybe it's Wordpress, maybe it's every individual app, or maybe there's a connecting thread (or not) where fixing the issue somewhere might help all apps and browsers...

[aquaspy]

Hey guys, anyone has news about this one?

The only thing I really don't like about gutenberg is the performance compared to the old editor

Especially if the post is long, it gets SLOW in the browser.

I believe that the performance will never be equal to the classic editor because of the extra features and ease, but at the same time, it could at least have a "performance" mode with a improved frontend performance for long posts.

I really don't know, but a lot of people are leaving Gutenberg due to this lag on large posts.

[caluwaek]

FWIW, we had similar issues on Chrome and moved over to MS Edge where the performance is better. I don't understand why, AFAIK Edge is using the same engine as Chrome, but we rarely see any lag. Most of our posts are about 4K words.

…

On Sun, Aug 7, 2022 at 12:07 AM aquaspy ***@***.***> wrote: Hey guys, anyone has news about this one? The only thing I really don't like about gutenberg is the performance compared to the old editor Especially if the post is long, it gets SLOW in the browser. I believe that the performance will never be equal to the classic editor because of the extra features and ease, but at the same time, it could at least have a "performance" mode with a improved frontend performance for long posts. I really don't know, but a lot of people are leaving Gutenberg due to this lag on large posts. — Reply to this email directly, view it on GitHub <#22822 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFKPSWIDZPJGLU3ANJZSHXLVX3O3XANCNFSM4NQTM2FQ> . You are receiving this because you commented.Message ID: ***@***.***>

[t-hamano]

I really tried leaving it overnight on a low spec machine.
But there was no effect on performance before and after leaving it. We believe that the passage of time is not a problem, at least in a clean environment.

I wish we could find a solid reproduction step.

[nekohayo]

Thanks for trying this out @t-hamano ; just to be sure, did you try this on Firefox on Linux, or only Chrome and/or other OSes? I tend to think Linux's graphics stack tends to make some symptoms more apparent than other systems...

[t-hamano]

My test environment is as follows:

• OS: Windows 10 Home 32bit
• CPU: Atom 1.33GHz
• RAM: 2GB
• Browser: Google Chrome 105 (no extension)

@nekohayo
Do you think this issue is limited to the combination of Firefox and Linux? Or have you ever reproduced it in any other case? I can only run Linux machines in a virtual environment, but I would like to test again with that combination if necessary.

[Thelmachido]

I wasn't able to reproduce the issue, with the following environment:

1. I am using Chrome 105 on macOS (Big Sur) you can use the link to get more information about the browser
2. WordPress version 6.0.2
3. Gutenberg version 14.1.1
4. Twenty Twenty Two theme

[aquaspy]

I feel like this PR may fix it: #45545

@Thelmachido to reproduce, try this:

1- Go to https://wordpress.org/gutenberg/
2- Put the mouse pointer below "Say Hello to Gutenberg, the WordPress Editor"
3- Spam the enter key with text:

4- Use shift + the up key to select a lot of blocks quickly:

You can see a really huge spike on the CPU usage and a visible lag on the screen. This may seem like not a big deal, but it really creates a bad experience, specially on a bad/old PC.

I wrote a really long post with a lot of paragraph blocks and images blocks on a older pc. It was laggy to hit enter and type a new text.

The issue seems to get worse with long hours of editing. The more you use it without a refresh, the worse it gets in terms of performance

[Mamaduka]

I can reproduce the typing lag when emulating a slow CPU (4x slowdown). The lag is evident when trying to type fast or, in my case (since I can't type that fast), just bashing random keys fast.

Looking at the performance recording, I see that useInputAndSelection > onInput takes around 83ms on keypress.

Steps to reproduce

• Create a testing post - 1500-1700 words
• Slow down CPU using DevTools.
• Try typing fast.

[mcsf]

Thanks for looking into this, @Mamaduka.

• Create a testing post - 1500-1700 words

Since the shape of a post can have great influence on the results, could you share what you used?

[Mamaduka]

@mcsf, I just generated 50 paragraphs using Batman Ipsum. @aquaspy also shared an example post - #22822 (comment).

P.S. Several people on Twitter mentioned that they experience noticeable lags with long-form content.

[trenzterra]

I also have the same issues on Chrome, particularly with a ThinkPad X13 with 16GB of RAM and Ryzen 7 4750U running Windows 11. Tested on a clean WordPress installation.

When plugged into AC, performance is still ok. On battery (even in High Performance mode), pressing and holding 'backspace' gets choppy. I noticed that performance improves when the "Top toolbar" option is disabled.

I have similar results on a Latitude 5430 with 32GB RAM and i7-1265U.

Not as noticeable on a desktop.

I also experience sluggish typing on Firefox (which I normally use) even on my desktop.

[aquaspy]

@trenzterra try to install the gutenberg plugin. It usually improves the performance for me. Either way, I think this may get fixed soon.

[ndiego]

There are several performance improvements planned for 6.2. That said, performance can always be improved, and each release will strive to do so. I have updated the issue labels and will keep this issue open until 6.2 is released. If anyone experiences additional performance issues when using the latest version of Gutenberg, please add them here or create separate issues. Thanks!

[G33kNoob]

any update on this issue? cause I feel uncomfortable, seem another tool faster at typing

[ellatrix]

Worth noting that with the fixed toolbar option the performance will be worse (same with inspector controls).

[Mamaduka]

@ellatrix, @mcsf, there's a new report with reproduction steps - #51210.

[t-hamano]

I will also describe another reproduction step.

I used large-post.html as content, which is also used in the performance test. In my environment, I see a noticeable drop in performance when the Document Overview panel is open. Enabling the fixed toolbar had no effect.

• Open the post editor.
• Type some more letters in a paragraph block and check the response.
• Switch to the code editor and paste the entire contents of large-post.html.
• Get out of the code editor. It may take perhaps 10 seconds or so for the content to appear.
• Type text. In my environment, I could see a significant response drop here.
• Hide the Document Overview panel and type the text again. In my environment, performance seems much improved.

e4943e651c6c008143bf3df206a08b54.mp4

Environment info

• OS: Windows 11
• CPU: Inter Core i5-1035G1 @ 1.00GHz 1.19GHz
• RAM: 64GB
• WordPress Version: 6.3-alpha-55905
• Gutenberg Version: 16.0.0-rc.4 (latest trunk)
• Browser: Chrome 114.0.5735.110, Firefox 113.0.2

[Mamaduka]

Thank you, @t-hamano!

Do you get the same results when running tests on WP 6.2 without the Gutenberg plugin active?

[t-hamano]

@Mamaduka

Do you get the same results when running tests on WP 6.2 without the Gutenberg plugin active?

Yes 😅

[t-hamano]

Measurement Report

I used the Profiler of the Chrome extension React Developer Tools to check the rendering status of each component.

Measurement Steps

• Open the post editor.
• Switch to the code editor and paste the entire contents of large-post.html.
• Get out of the code editor.
• Open the Document Overview Panel.
• Start recording.
• I typed a total of 5 letters about 1 second apart.
• Stop recording.

The above procedure was tested with the List View and Outline tabs open respectively.

Environment info

• OS: Windows 11
• CPU: Inter Core i5-1035G1 @ 1.00GHz 1.19GHz
• RAM: 64GB
• WordPress Version: 6.3-alpha-55905
• Gutenberg Version: 16.0.0-rc.4 (latest trunk)
• Browser: Chrome 114.0.5735.110, Firefox 113.0.2

Measurement Results

The JSON file attached to each result should be able to be imported in Chrome's Profiler page for more information.

When the List View panel is opened

I don't know much about this tool, but it looks like the ListViewBranch is rendered many times.

Screenshot

profiling-data-with-list-view.zip

When the Outline panel is opened

There does not appear to be a large number of renderings, but the calculation process for word and character counts might be heavy.

Screenshot

profiling-data-with-outline.zip

[t-hamano]

I checked again with the latest trunk and it appears that performance has improved somewhat in my environment. Maybe thanks to #51518 🤔

(Compare with the video of this comment)

5723a91db63162a30285d451f5526126.mp4

[tyxla]

I'm able to reproduce with a large post and when typing swiftly.

Trying out one potential improvement in #54819.

[Mamaduka]

Hey, everyone 👋

I just wanted to check if you got a chance to test typing performance improvements that shipped with the latest versions of the Gutenberg plugin and are coming in core with the next major release.

[tyxla]

I can no longer reproduce without throttling (I'm using the same machine as before and the same large post as before), so things are definitely better!

However, with 4x CPU throttling, it's still easy to reproduce, so I'd expect there are still opportunities for improvement.