Experiment: Measure performance impact of loading blocks and patterns #33804
Conversation
gziolo
force-pushed
the
try/performance-blocks
branch
from
bc51546 to
c850d47
Compare
Block Patterns removed
I see load time decrease by 182 ms, which is 3% faster. It's still in the range of the testing error that was estimated at 5%. |
|
Size Change: -117 kB (-11%) 👏 Total Size: 960 kB
ℹ️ View Unchanged
|
Most of the core block and all block patterns removed
I see load time decrease by ~352 ms, which is 5% faster. It's still in the range of the testing error that was estimated at 5%. I would be curious to learn what has the biggest impact on the loading time here – my initial assumption is the time to render all test blocks. Another observation is that It's also worth mentioning but the removed core blocks contribute to over 11% of the download size (CSS + JS) when loading the block editor:
|
Most of the core block and all block patterns removed, only blocks present in the loaded post
I see load time decrease by 95 ms, which is 8% faster. It's also evident that the size of the post is the largest factor that impacts the loading time. It's over 5 seconds decrease, which is 80% faster, when comparing the loading time for The conclusion is that core block and core block patterns don't have that much impact on the loading time, at least in the case of the e2e test scenario. We should seek for different testing approaches to validate how the bundle size increase for core blocks impacts the perceived performance of the block editor. |
|
Related is also #33767 where I tested not rendering drag/icons. 🤔 there is some impact, but we may want to keep 🔍 for why these are as slow for the number of items. (For example, maybe we're triggering a number of updates). |
|
Btw if folks are looking for leads on improving loading time, a handy thing to do in Chrome is use the "Start profiling and reload page" button, and make sure web vitals is checked.
Then I'd go through interesting network requests / remove JS to parse / any long running tasks to find any chunks to experiment with. To get a sense of potential gains it can make sense to fully comment out a piece to see if it's worth trying to optimize. (If there isn't a sizable impact we can skip to some other idea).
|
|
Thanks for testing this @gziolo!
I just did a quick check on trunk to see how much time is taken to parse JS from the block-library package. The package is sizable, but I saw several other JS dependencies that were as large or larger. One thing that stands out is how many other JS dependencies we have for the block editor. It might be interesting to separate out what's needed for wp-admin screens vs the block-editor (or what can be deferred for on demand or async loading). For example, is jQuery/backbone/underscore necessary when we're in fullscreen mode? Can we remove the moment dependency? Are we using all components from the component package? And so on...
|
|
One more thing. I discovered there is Size Limit GitHub Action: https://github.com/ai/size-limit.
It not only calculates bundle sizes like "Compressed Size" GitHub action but it also can:
I filed an issue #32665 some time ago that proposes to move the Classic block and Meta Boxes to their own package so it is loaded only with the post editor. The rationale behind that was to eventually stop loading jQuery or TinyMCE when those features aren't used.
There was a failed attempt to replace
This is where backward compatibility concern kicks in. Even when WordPress core doesn't use some of the components, they are part of public API so they need to be shipped in |
Oh that's a neat one ✨ Probably very useful to put that up or something similar, especially if we'd like to keep things fast loading after a round of loading improvements.
Very tempting to 👀 again on that since there are only a few usages.
Nice I'll try to catch up 👀 on related PRs
That's a good point. Over time we'll probably still need to think through a strategy for what might be a core/necessary component, vs opt-in extras. It feels like the package will naturally grow over time otherwise. |
|
#33903 from @youknowriad is close to land. It improves the loading time by nearly 5% for the post editor thanks to some optimizations to the block parsing logic. I'm about to change the base branch here to see how the loading time changes relative to the setup in this test branch. Although, there should be really no difference here. Update, there is no much difference with #33804 (comment). It's still 8% which isn't surprising because there are only a few blocks to parse in the tweaked perf test... |
gziolo
changed the base branch from
trunk
to
update/only-fix-classnames-if-needed
|
Let's close this PR. I will perform some more measurements separately. I'd like to play with the profiler as recommended by @gwwar in #33804 (comment) 🙇🏻 |
Description
Opened to measure the impact of loading core blocks and block patterns on the block editor's performance.
I want to check the performance metrics when: