search

WordPress / gutenberg

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

Typing block editor has significant lag, particularly on Chrome MacOS #22822

Open jamescl opened 4 years ago

jamescl commented 4 years ago

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

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

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

Editor version (please complete the following information):

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

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

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

jamescl commented 4 years ago

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

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

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

talldan commented 4 years ago

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

ellatrix commented 4 years ago

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

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

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 image

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:

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

ezgif-6-ebab661e1516

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

My key questions are

mcsf commented 4 years ago

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

Chrome extensions I'm running

Which chrome extensions are you running?

jamescl commented 4 years ago

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

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

image

piterx commented 3 years ago

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

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

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

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

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

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

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

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

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 https://github.com/WordPress/gutenberg/issues/22822#issuecomment-1207289763, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFKPSWIDZPJGLU3ANJZSHXLVX3O3XANCNFSM4NQTM2FQ . You are receiving this because you commented.Message ID: @.***>

talldan commented 2 years ago

For anyone reporting issues, it'd be great to provide further details (as much as you're comfortable sharing):

Performance can be hard to quantify without that information, especially over the two years since this was reported. The code base will have changed significantly and there may be new or different factors that cause issues compared to the original reports.

aquaspy commented 2 years ago

@talldan sure, let me add some details. Brave 1.41.100 / Artix Linux(fork of arch linux). This computer is using a Athlon 200GE with 16GB of ram

Yes, I have 10 plugins installed: Academy Certificates, Academy LMS, Admin Tools Professional for WordPress, Akeeba Backup Professional for WordPress, Disable Bloat for WordPress & WooCommerce, Query Monitor, Redis Object Cache, Resize Image After Upload, WooCommerce, WP Rocket. All of them on the latest version

Divi Theme.

Wordpress 6.0.1, I'm not using the Gutenberg plugin.

Import this post: Example WP Post

One thing that I noticed is that refreshing the page helps. For example, if you are writing a long post for 3-4 hours and restart your browser, performance will be better

This is the example post that you can download to test image

aquaspy commented 2 years ago

On my Brave, I only have these extensions: https://i.imgur.com/mYWpZAq.png

But I have similar results on a incognito tab, so I don't think it's brave/extensions fault.

talldan commented 2 years ago

Great - thanks for the extra details.

One thing that I noticed is that refreshing the page helps. For example, if you are writing a long post for 3-4 hours and restart your browser, performance will be better

Would you say you're seeing good performance after refreshing, or still quite poor (but better)?

Reduction of performance over 3-4 hours sounds like a memory leak. This isn't something that the project measures currently, there are automated tests that open a browser session and edit a long post, and record the amount of time it took, but they all start a new browser session.

Testing something over 3-4 hours is much more difficult. 🤔

nekohayo commented 2 years ago

@talldan Just in case you forgot (since it's been a while), my two comments above some months ago did point towards duration-based symptoms appearance, rather than actions-based slowdowns, i.e. that it has something to do with a memory leak or compounding resources usage. Just leaving the computer in front of Gutenberg's editor overnight and coming back to it in the morning made the problem show itself on Firefox on Linux with AMD/Radeon graphics; I don't recall if I observed that with Intel graphics as well, but I would be surprised if those weren't similarly affected. Do you have a spare machine that could be left turned on overnight and then inspected/profiled with your debugging tools in the morning?

aquaspy commented 2 years ago

Hmmm, didn't though about a memory leak, I can leave a blank post up on night and check ram usage to see.

I can also record a video I guess.

Well, I thought Gutenberg lag was related with this one https://github.com/WordPress/gutenberg/issues/23427

But perhaps it's really a memory leak that can be addressed later

ndiego commented 2 years ago

This issue was reviewed in today's Editor Bug Scrub. We have been unable to replicate using the latest versions of Gutenberg and WordPress. Has anyone else been able to replicate or is able to provide some additional information?

t-hamano commented 2 years ago

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

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

My test environment is as follows:

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

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 commented 1 year ago

I feel like this PR may fix it: https://github.com/WordPress/gutenberg/pull/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: image image

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

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 commented 1 year ago

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

mcsf commented 1 year ago

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 commented 1 year ago

@mcsf, I just generated 50 paragraphs using Batman Ipsum. @aquaspy also shared an example post - https://github.com/WordPress/gutenberg/issues/22822#issuecomment-1208116312.

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

trenzterra commented 1 year ago

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 commented 1 year ago

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

ndiego commented 1 year ago

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 commented 1 year ago

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

ellatrix commented 1 year ago

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

Mamaduka commented 1 year ago

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

t-hamano commented 1 year ago

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.

https://github.com/WordPress/gutenberg/assets/54422211/6cf0bdc7-9a93-4a15-8c5a-a2d04a4cc1dc

Environment info

Mamaduka commented 1 year ago

Thank you, @t-hamano!

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

t-hamano commented 1 year ago

@Mamaduka

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

Yes 😅

t-hamano commented 1 year ago

Measurement Report

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

Measurement Steps

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

Environment info

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 ![list-view-branch](https://github.com/WordPress/gutenberg/assets/54422211/b4ddd5bf-ba13-4ebb-b14b-485953522720)

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 ![character-count](https://github.com/WordPress/gutenberg/assets/54422211/eea51478-8a37-465c-985b-19f924fbe3a7)

profiling-data-with-outline.zip

t-hamano commented 1 year ago

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)

https://github.com/WordPress/gutenberg/assets/54422211/58a1510b-c440-411f-a146-a9a6ca9cc9da

tyxla commented 1 year ago

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

Trying out one potential improvement in https://github.com/WordPress/gutenberg/pull/54819.

Mamaduka commented 9 months ago

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 commented 9 months ago

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.