Site Editor: slowdown on Safari when searching for new blocks to add

annezazu commented 1 year ago

Quick summary

An issue was originally opened in WordPress trac: https://core.trac.wordpress.org/ticket/57917#comment:4 and later opened in the Gutenberg GitHub repo: https://github.com/WordPress/gutenberg/issues/49208. However, upon testing, it can only be replicated on WordPress.com so I'm bringing the issue here.

Using the beta editor on Safari 16.3 on an M1-based MacBook Air running on Ventura 13.2.1, there is a substantial slowdown to the browser tab when searching for a block type to add: it takes a lengthy bit of time for the letters to all appear, and then any search results are slow to come in and have the images load. I did a search to see if the issue has been reported; I'm sorry if I missed it being reported before!

This is using the existing .com version of the WordPress site, which I think is bleeding edge, so to speak.

There doesn't appear to be anything suspicious in the console, but I'm not sure specifically what is powering the new editor so I'm not too sure where to look. I'm not running any ad blocker that might result in an improperly blocked failed call (although my network does run AdGuardHome)

So far I've tested with Firefox on both Linux (nixOS; unsure of the Firefox version) and the Mac (110.0.1) and the comparison is night and day; it's lighting fast in FireFox on both browsers. I can also confirm that using Safari on iOS produces the same problem (I assume other browsers would do the same, since they're all forced to use webkit).

I know that Gnome Web uses WebKit; I can try it from there on a Linux machine too, if it would help.

Unsure if it's a webkit issue or whether any custom theme would be a problem here. If it's a duplicate or if I can provide more information please let me know!

(link to original ticket, posted in the wrong place 😂 https://core.trac.wordpress.org/ticket/57917#comment:4)

Steps to reproduce

From the original report -- keep in mind in this case it's referring to the Site Editor:

Use new Beta editor .com site from the Safari Browser
Click the + icon
Start typing!

What you expected to happen

Fast response :)

What actually happened

Very slow reaction to trying to add a block.

Impact

One

Available workarounds?

No but the platform is still usable

Platform (Simple and/or Atomic)

No response

Logs or notes

Safari, both iOS and macOS.

worldomonation commented 1 year ago

I am able to replicate the issue on my machine with the normal post/page editor as well.

OS: macOS Ventura 13.2.1 Browser: Safari Version 16.3 (18614.4.6.1.6)

Checked Firefox 113.0a1 (2023-03-19) and the slowdown is present but it is not as noticeable. Also checked Edge Version 110.0.1587.69 but it was also not noticeable.

I am aware of a similar issue related to the block inserter slowing down with Gutenberg 15.1.0 (see discussion from 2023/02/15) but the nature of the issue is slightly different from here and the fix was merged upstream on 2023/02/20, so that cannot be it.

worldomonation commented 1 year ago

Additional testing

Jurassic.Ninja on both Firefox and Safari is fast.
Safari outputs a bunch of 404s in the console whereas the same is not seen on Firefox.

worldomonation commented 1 year ago

For the record, this is how the lag appears with the editor (/post).

https://user-images.githubusercontent.com/6549265/226748956-7e3d67c3-78da-48ee-9300-8c35b6c21ebf.mov

astatide commented 1 year ago

Since I happened to be looking at GH and on a machine with Gnome Web (Epiphany, which uses webkit) installed I did a quick test there and found similar slowdowns. (Epiphany 44.0-5-g1ad61b1ae+, which is using GTK4 but I'm not sure about the other libs).

Unfortunately I have no idea how to look at the JS console on Epiphany so I can't capture anything, and since it's a nightly version I'm extra uncertain about the specific webkit version but it does point to a possible webkit thing!

astatide commented 1 year ago

I suppose the lack of a map file isn't going to make debugging easier, but while I see the same console errors when I load up the site in Safari, there are no console messages when the actual slowdown occurs.

I hopped into the timings section and did notice some fun stuff; I cleared it out after everything loaded up, then clicked + and started typing to trigger the slowdown.

I exported the timings data but I'm not sure whether the data has any identifying information so I'm a little hesitant to add it as an attachment without scrubbing. I also specifically saved the data of the call that took over 8 seconds. It's mostly font data, which, I'm not sure if that's anything interesting or not?

8SecondFontCall.zip

astatide commented 1 year ago

Actually, the other long timing calls are the same document (with maybe a one line difference); I dumped the nearly 5 second about:srcdoc transfer contents and here's the diff:

5c5
< \margl1440\margr1440\vieww11520\viewh8400\viewkind0
---
> \margl1440\margr1440\vieww23080\viewh10620\viewkind0

Seems like it's sent many, many times.

EDIT: Could be a red herring; on another run (that I was attempting to record, but the exports from the timeline are MASSIVE; tried to load it into a pandas data frame but it's still just a mess) it was the actual GET call for an image that was marked as slow. Not sure there's enough data at this level to differentiate or clarify more; I do have the browser recording of the event if that's useful. It's large though.

cuemarie commented 1 year ago

📌 SCRUBBING : RESULT - Replicated / Could Not Replicate / Uncertain

Tested on Simple: Replicated (not as noticeable as AT in my test)
Tested on AT: Replicated (noticeable lag time between key strokes and the text appearing in the editor interface)

📌 FINDINGS/SCREENSHOTS/VIDEO

Looks like folks are already investigating here - just ran a quick scrub test to confirm I can repro as well in Safari Version 16.2 (17614.3.7.1.7, 17614

📌 ACTIONS

Assigned to Build

danielbachhuber commented 1 year ago

@cuemarie Can you see if you can replicate this again? If you can, this could be a good issue for @katinthehatsite to work on.

cuemarie commented 1 year ago

Happy to retest, @danielbachhuber

📌 REPRODUCTION RESULTS

Retested on Simple – Replicated somewhat
Retested on Atomic – Could Not Replicate

📌 FINDINGS/SCREENSHOTS/VIDEO Retested in Safari Version 16.6, and did not run into any sort of noticeable lag like what is shown above on Atomic. Simple site showed a bit of a delay when adding blocks from the block sidebar, when working in the Site Editor; take a look:

Atomic

https://github.com/Automattic/wp-calypso/assets/27249804/27acbe3f-b7dd-4202-83e7-7f00d1895bab

Simple

https://github.com/Automattic/wp-calypso/assets/27249804/2e5dab7a-8448-4478-8d26-b43554e08ae9

Seems a little intermittent, but I hope this helps

katinthehatsite commented 1 year ago

I started working on this and these are my notes so far:

on Simple sites, sometimes I can see a small slowdown but it is not consistent. I think generally, it is not noticable to an average user unless they are looking at this issue;
I am testing on macOS Sonoma 14.0 and Safari 17.0 (19616.1.27.211.1);
I could not find any patterns as of why sometimes it is a bit slower.

For comparison, I looked at Chrome 117.0.5938.132 and these were the times for completing the task of adding a block from the blocks search:

For the table block:

For the heading block:

My next step would be to run a similar test on Safari to see how fast it completes.

So far, visually I don't see much of a difference between the two.

katinthehatsite commented 1 year ago

I wanted to add some updates on the issue: I was able to reproduce the issue by using the search for the blocks instead of directly adding them either from the post editor or from the sidebar. Here are the steps:

Navigate to a new post or page
Open a sidebar to add blocks
Search for "quote" block and see how the whole screen freezes
I can see that in Safari profiler, this has a very high CPU usage:

I am not sure yet what is causing the issue but my suspicion is the preview of the patterns, for example, for quotes, that takes some time to populate:

Also, these "patterns" are not available in core and the issue on Safari does not happen in core:

https://github.com/Automattic/wp-calypso/assets/25575134/e8db7383-b136-4898-b0db-29113d0550df

As my next step, I will be checking how we are loading these "patterns" for blocks on WP.com and if they are indeed the ones causing the delay.

katinthehatsite commented 9 months ago

I was back at this issue again today and attempted testing it with the steps I mentioned above:

Navigate to a new post or page on Safari on an Atomic site
Open a sidebar to add blocks
Search for "quote" or "paragraph" block

And I am not able to see the issue happening anymore. Here is the screencast from Safari:

https://github.com/Automattic/wp-calypso/assets/25575134/be2fe7b3-2e57-440c-8a8c-f5096ce16107

I can also see that CPU improved and I can see it being two times lower compared to previous time (from 120% to 52%):

@cuemarie - would you be able to test this once again and let me know if the issue appears for you? If the loading looks good on your end, I think we can close this one for now. Thanks!

katinthehatsite commented 9 months ago

Since I can't reproduce the issue anymore, I am going to close it for now. If it can be spotted again, feel free to reopen it.

Automattic / wp-calypso