Performance metrics
Building a performant editor is a very difficult task, it requires constant attention and monitoring to some key metrics. In the context of the WordPress block editor (aka Gutenberg), we constantly track the following key metrics:
- Loading time: The time it takes from the moment the user clicks the “new/edit post” link until the editor loads the post to be edited and becomes responsive to user input.
- Average Typing time: The time it takes for the browser to respond to characters being typed. This is one of the important metrics for an editor, this measure should ideally be very small, the user shouldn’t even notice any delay or lags.
We also track some secondary metrics that are specific to block editors including:
- Block Selection time: In a block editor, everything is a block and the user constantly jumps from one block to another. With this metric, we track the time it takes for the browser to respond when selecting a new block.
- Global Inserter Opening time: This tracks the time for the browser to respond when opening the global inserter (or the block library), showing the available blocks.
By constantly keeping track of these numbers while iterating on features and bug fixes for the editor, we managed to improve the performance of the editor drastically over time. In a previous post, I shared some of the techniques we used to make these leaps forward.
That said, one of the important aspects of WordPress and its block editor is their extensibility. The WordPress plugins repository contains thousands of plugins to super charge your WordPress Installation and editor. A typical WordPress install has at least a dozen of active plugins. And of course, plugins have costs: the editor needs to be performant intrinsically but also stay performant as you extend it.
Unfortunately, depending on the used plugins, this is not always the case.
Popular WordPress Plugins
The first report compares the metrics of 8 of the most popular WordPress Plugins on the repository in addition to Gutenberg itself (Gutenberg is always enabled in all the tests). Here’s the list of the tested plugins:
- Gutenberg v11.3.0 RC 1
- Akismet v4.1.10
- Contact Form 7 v5.4.2
- Elementor v3.3.1
- Jetpack v10.0
- Really Simple SSL v5.0.8
- WooCommerce v5.5.2
- WPForms Lite v1.6.8.1
- Yoast v16.9
Results
| Plugins | Loading time | Average Typing time |
|---|---|---|
| Gutenberg | 4318ms | 45.13ms |
| Akismet | -0.57% | +4.25% |
| Contact Form 7 | +4.15% | +3.92% |
| Elementor | +10.31% | +3.51% |
| Jetpack | +19.48% | -22.42% |
| Really Simple SSL | -0.65% | +1.84% |
| WooCommerce | +16.05°% | +6.51% |
| WPForms Lite | +5.52% | +20.05% |
| Yoast | +25.29% | +3.17% |
Observations
Here are some of my own take-aways from the numbers above.
- Most of the popular plugins have no impact or a reasonable impact on the loading and typing times of the editor.
- WooCommerce, Yoast and Jetpack have a noticeable impact on the loading time.
- Surprisingly, the Typing metric is faster when using Jetpack.
Analysis
- I think the results above are good news for WordPress. Most popular plugins don’t have a big impact on the editor’s performance.
- The plugins that deal the most with the editor: adding blocks, adding meta boxes or sidebars or extending the editor via slots… are the ones that are impacting the loading time a bit. They might be using extra JavaScript and Stylesheets in the editor.
Note: I tried including WordFence Security plugin in my benchmark, unfortunately, by default that plugins had a very big impact on the loading time which triggers timeout errors when running the performance tests for it. I was not able to gather the numbers for that particular plugin.
Block Editor Plugins
The second report compares the editor metrics for 10 of the most popular plugins that target the block editor specifically, whether it’s block library plugins, or plugins enhancing the editor with tools and customization options. The list of the compared plugins is the following:
- Gutenberg v11.1.0 only
- CoBlocks v2.16.0
- Editor Plus by Extendify v2.8.2
- EditorsKit v1.31.5
- Getwid v1.7.4
- Gutenberg Blocks and Template Library by Otter v1.6.9
- Kadence Blocks v2.1.7
- Redux v4.2.14
- Stackable v2.17.5
- Starter Templates v2.6.21
- Ultimate Addons for Gutenberg v1.24.0
Results
| Plugins | Loading Time | Typing Time | Block Selection Time | Inserter Opening Time |
|---|---|---|---|---|
| Gutenberg | 4237ms | 53.85ms | 58.23ms | 59.96ms |
| CoBlocks | +255.11% | -12.44% | +65.88% | +14.29% |
| Editor Plus | +1064.99% | -21.15% | +171.70% | +404.59% |
| EditorKit | +66.21% | +77.20% | +17.29% | +52.94% |
| Getwid | +3.75% | +2.21% | +9.07% | +1.08% |
| Otter | +36.30% | +22.28% | +12.83% | -1.13% |
| Kadence Blocks | +4.58% | +4.46% | +14.03% | -2.75% |
| Redux | +73.93% | +104.64% | +16.33% | +14.76% |
| Stackable | +19.58% | +10.06% | +6.80% | +20.60% |
| Starter Templates | +6.84% | +9.68% | +9.87% | +5.90% |
| Ultimate Addons | +13.73% | -20.43% | +9.24% | +15.23% |
Observations
Here are some my own take-aways from the numbers above:
- No surprise that these plugins have a more visible impact on the numbers since they specifically target and extend the block editor.
- The loading time is not consistently impacted by the block library plugins, some are doing better than others.
- Editor Plus and EditorKit impact all editor metrics significantly.
Analysis
- Editor Plus and EditorKit are plugins that add customization capabilities to the block editor in very different ways, they impact core blocks, add blocks and add tools to interact with the editor. Based on my experience, adding this kind of built-in features to the editor can quickly have a broad impact on performance because it can impact all rendered blocks. These are very valuable plugins, but I do think they’d require more care than typical plugins when it comes to performance. Tracking editor metrics for this kind of plugins is key.
- Lazy-loading editor assets (JS/CSS) is something we want to explore ultimately in the editor to keep the bundle size and loading time contained, but the loading time numbers here suggest that it’s not a fundamental issue in the block editor itself, since some block libraries do add a number of blocks (assets) without a meaningful or a big impact on the loading time. Plugins like CoBlocks, Redux or EditorPlus might be up for some quick wins there.
- In a previous version of this benchmark, I was noticing that most block libraries had a significant impact on the inserter opening metric. This led to some improvements to Gutenberg Core itself. Inserter items are lazy-rendered now meaning adding more and more items doesn’t impact the numbers as much as the numbers above confirm.
Note: A frontend metric would be a great addition to the key metrics to monitor for block library plugins, it’s often more important than editor-related metrics.
Methodology of the test
The tests were run sequentially on the same idle computer using @wordpress/env and the Gutenberg e2e performance job.
For each plugin, I didn’t configure it or enable/disable features, I just went with the default settings considering that most users are going to use the default settings and that they should be performant by default.
The editor is loaded and used with a particularly sizeable post (~36,000 words, ~1,000 blocks).
Of course, this is not a scientific method but based on my previous experience with these metrics, the numbers are meaningful with a margin of error of 5% to 10% to account for the randomness of CPU usage/timing of the test.
The full numbers are available here.
Running your own tests
One of my main motivations for this post was to highlight these issues more and encourage plugin authors to monitor the performance impact of their code. Performance should be considered a first-class feature. Of course the key metrics for each plugin might differ but a good first step is to run the Gutenberg metrics with or without your plugins and compare the results.
Here’s how you can do it on your own:
First, clone the Gutenberg repository and build it:
git clone [email protected]:WordPress/gutenberg.git
cd gutenberg
nom install
npm run buildThe next step is to run the WordPress + Gutenberg environment. We can just use the Gutenberg’s built-in environment like so: (Docker Desktop is a requirement here)
npm run wp-env startYou should be able to access the testing environment on http://localhost:8889
Install your plugin on the environment above directly from WPAdmin and activate it.
You’re now ready to run the tests like so:
npm run test-performance packages/e2e-tests/specs/performance/post-editor.test.jsAnd that should be it, you can run the tests as often as you wish, try different variations of your plugin, disable it, compare to other plugins…
Some Hints
While working on performance improvements on the editor, we noticed some trends that can help you find the bottlenecks for your own plugins:
- For the loading metric, consider checking the initial rendering of your components/UI, sometime deferring the initial rendering of non important UIs help.
- The size of the loaded assets can also have an impact on the loading metric.
- For the typing metric, consider checking your selectors (
wp.data.useSelect,wp.data.withSelect,wp.data.subscribecalls). My previous post goes into more details here. - Chrome Performance Monitoring tools is a great way to detect and debug performance regressions. One approach I personally use often, is to record a trace for a given interaction (like type a single character, open the inserter, load the page or any interaction you want to debug) and compare the resulting trace with and without your plugin.
Notes
- An initial version of this benchmark resulted in very different numbers from the ones we have today, I’ve reached out to some of the plugin authors and shared the numbers with them. I’d like to thank all of them, as they were all receptive. Some gains are already reflected in the new versions tested above and I know that the authors of the plugins above are working on more improvements in the upcoming weeks.
- If you run the same benchmarks locally, you might get different numbers and that’s totally fine. The machine running the test have an impact there, for instance your docker instance maybe faster but your browser slower resulting in numbers and rates that are different. That said, comparing to your own Gutenberg numbers should be relatively stable compared to the numbers on this post.
Conclusions
I would like to finish by encouraging folks to care about performance daily on their development workflows. For Gutenberg Core Itself, this post highlighted for me some good additions to include to our performance pipeline and some areas worth debugging.
Let’s make WordPress and its plugins blazing (Everyone is using this word lately, I finally found a place for it 😀) fast.
Thanks Nadir Seghir for the help with this post.