Site Editor: Slow performance with complex block themes

[tyxla]

Description

As discussed with @draganescu and @youknowriad, the UI performance of the site editor using complex block themes (such as TT4) is pretty bad - it gets stuck, and takes a long time to load.

@draganescu made the observation that the UI may be not orchestrated properly - it’s too reactive to the whim of the router:

• user clicks on a page in the sidebar
• route changes
• frame renders the content for route
• user clicks back in the sidebar
• route changes
• both the sidebar and the frame are updated to the new route

@draganescu also suggested that one way to approach it could be to optimize it so that the UI is always updated 1st so that the thread is 100% free and once it’s done we can then update the frame.

Step-by-step reproduction instructions

• Start with the latest WordPress
• Install and activate the TT4 (Twenty Twenty-Four) theme
• Navigate between pages or templates and go back
• You'll see the UI stuck at animating the site editor
• On slower devices, you'll see the UI unresponsive for many seconds.

Screenshots, screen recording, code snippet

No response

Environment info

• Latest WordPress version
• Gutenberg trunk
• TT4 theme

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[tyxla]

cc @jsnajdr and @flootr for thoughts

[youknowriad]

I've recently added a "navigate" metric to the site editor to track this. It's a first step, the metric might not be perfect but at least it will help us get some visibility here.

[annezazu]

Tagging for @WordPress/performance folks!

[tyxla]

Today I timeboxed some experimentation with disabling the animations here and there, and it seemed like turning off only the framer-motion-powered animations of NavigatorScreen (see #56795) resolves most of the aforementioned performance issues. It appears like rewriting these animations to use CSS and leverage hardware acceleration should fix most of the problem.

cc @ciampo I recall you worked on those animations a while ago: do you recall any design decisions or discussions behind having them in the first place? I wonder how much of them we can remove or simplify.

[tyxla]

@draganescu could I borrow your help in testing #56795? Does it resolve the performance issue in your testing? Disregard that the NavigatorScreen animations don't exist, this is what we're intentionally disabling in that PR.

[ciampo]

cc @ciampo I recall you worked on those animations a while ago: do you recall any design decisions or discussions behind having them in the first place? I wonder how much of them we can remove or simplify.

Animations are one of the reasons why Navigator was created in the first place, although we could try to use vanilla CSS attributes instead of framer-motion and see what happens. I'll try to have a spike on that in the next days

[tyxla]

Thank you @ciampo! I'd be happy to take a look myself, but it may not be earlier than next week.

[ciampo]

we could try to use vanilla CSS attributes instead of framer-motion and see what happens. I'll try to have a spike on that in the next days

@tyxla , I've created a draft PR here to test the approach: #56909

Let me know once you've done some tests.

[tyxla]

@tyxla , I've created a draft PR here to test the approach: #56909

Fantastic, thank you! 🙌

Let me know once you've done some tests.

Tested it and left some feedback at #56909 (review)

[flootr]

I spent some time looking at the Patterns library because that part is still not performing well even though #56909 improves the overall experience a lot. I wanted to share some of the findings. My starting point was the lagging animation when changing between all and synced patterns on wp-admin/site-editor.php?path=%2Fpatterns:

Screen.Recording.2023-12-12.at.11.20.27.mov

Using a modern MacBook Pro with M1 Max Chip. The same user interaction but with 4x CPU slowdown:

Screen.Recording.2023-12-12.at.11.21.43.mov

Doing a performance analysis within Chrome devtools we get a graph like this (only 1 switch):

This all looked very confusing and convoluted so I tried to see what's going on by going to a pattern category with only 1 pattern to get a more focused performance graph and indeed the rendering of the BlockPreview component seems to take up a lot of space in the graph. Given that we're rendering about 20 of those on the first graph it's clear why it's so convoluted.

I pushed 69180b8 (#56973) to artificially slow down the rendering of those block previews and separate what's happening on a site with lots of patterns.

I'm not exactly sure how the BlockPreview component works but it seems like using lots of those is the culprit of at least some janky animations on the Pattern library section of the site editor. If I interpret correctly each of those is using their own Iframe with their own block editor environment which just takes a lot to process. This is not specific to TT4, it happens on other block themes or sites with lots of patterns, too.

[flootr]

#54999 seems relevant to my last comment.

[draganescu]

@flootr it may be that the perceived performance degradation comes from different things, maybe:

• navigating the navigator is stuttering because framer motion waits on the browser to calculate animation
• browsing patterns with previews is jittery because the block preview instanced as a client side editor so many times is too taxing.

Indeed #54999 is something I am trying to address in the linked PR there, stuck at the moment around rendering "demo" content when previewing empty blocks (which on the client just comes from "example" data).