Load testing WordPress plugins performances

When it comes to WordPress performance, a lot of players are involved and they all need to play together nicely to produce a robust and fast loading website. The hosting and the stack in general (caching, CDN, database) are of course critical, as well as the “size” of the site in terms of posts and images, and many other factors. 

In this article, we will focus on themes and plugins, which are equally important because every new plugin has an impact on the site’s performance, and a poorly coded theme can significantly slow down the entire site!

When we run performance audits, one of the first things we check is the list of active plugins and themes, and it is not rare to find bottlenecks there!

Before installing a new plugin, a question you should ask yourself is:

Do I really need all the functionalities the plugin brings into my site, and how significant is the impact on my site’s performances?

To make this concept more tangible, I decided to load test some popular WordPress plugins and show in plain numbers their “performance price.”

Getting ready to load-test WordPress

I choose to test on a strong foundation, so I put the target site on a very powerful and performance oriented hosting platform called Kinsta (affiliate link), and I strongly recommend it for a hassle-free hosting experience.

The active theme is Twenty Seventeen, which is very lightweight, and the plugins I tested were:

As part of the test, the website filled with about 1000 items for every post type (posts, pages, products, events, etc.) generated using FakerPress, a plugin that loads dummy data in WordPress. I conducted all the tests using Loader.io, a simple, reliable and free tool!

WordPress itself is insanely fast!

I ran an initial test with no active plugin, and the results were unsurprisingly good: with 10,000 users distributed in a period of one minute the average load time was 400 milliseconds for the first load, then about 100 ms when the cache started doing its job!

Clean WP front end load test

My initial plan was to test the front-end part of the site, even if some plugins only impact a specific section of the website. However, after running a second test with all the plugin active, I realized the outcome would not be so much different for one reason: the cache.

Kinsta uses a pretty aggressive full page cache, so once the page is in the cache, it will be fast, no matter how much content, CSS or JS is there.

So, to get a more reliable and consistent result, I decided to test the WordPress backend (which is uncached) and more specifically the Admin Dashboard.

Testing the backend, plugin’s impact is as huge as 12 seconds

I tested the two edge scenarios, all plugins active versus no plugin active, and the difference in seconds was huge: 0.304 compared to 12.895, a difference of more than 12 seconds!

AI ran the tests three times to ensure reliable results and minimize “server behavior” impact, and of course, test settings were always the same: 500 distributed in a one-minute test. I’m well aware 500 users in the backend would be too many, but I wanted to put a significant amount of stress on the server to highlight the impact of plugins.

Moving forward, I re-ran the test, deactivating each plugin one-by-one, to get its “performance price” and here are the results ordered from best to worst:

PluginImpact
Ninja Forms1,308 s
WPForms Lite1,344 s
Shortcodes Ultimate1,545 s
Caldera Forms1,580 s
Cookie Notice1,585 s
Contact Form 71,625 s
Page Builder by SiteOrigin1,708 s
Elementor1,829 s
Advanced Custom Field1,864 s
User Role Editor1,934 s
NextGEN Gallery1,948 s
Custom Post Type UI1,975 s
MailChimp for WordPress1,979 s
Sucuri Security2,492 s
WooCommerce2,913 s
All In One SEO Pack2,935 s
Yoast SEO3,483 s
Wordfence Security3,497 s
Jetpack by WordPress.com (19 modules active)3,662 s
The Events Calendar4,338 s
WooCommerce backend load test WooCommerce backend load test Yoast backend load test Yoast backend load test

Interpreting the results

Keep in mind this does not mean activating Yoast, for instance, which will slow down your backend by 3.5 seconds. We are stress testing the system, and if you are the only user in the backend, you will probably only notice a few milliseconds of performance loss, but at the same time, you will see that plugins do have an impact on performances even if we are testing an agnostic page (the WP dashboard).

According to the results, I would consider:

  • excellent: < 1.5 seconds
  • good: < 2 seconds
  • accettable: < 3 seconds
  • not good: > 3 seconds

What’s the next?

Of course, this test is not the bible, meaning that results could be completely different on another hosting platform or with other plugin combinations, as often the plugins can interact differently and even conflict. But it gives us a significant number of insights to think about!

It would be very interesting to load test the frontend and themes, as the most used part of a WordPress website, but also more challenging as plugins impact the front end in different ways. 

For now, the main takeaway is that we should be “frugal” with plugins, keep the number under control and consider some custom development for small or specific features.

Join the Conversation

10 Comments

  1. Thanks for a great post! Would be intresting to see the impact on the post editing screen as well. Some of the plugins you mention here have a hive impact on load time before you can start writing.

    1. Absolutely agree. As I said, this was a very first experiment and I used an agnostic page to see what happens. But it would be interesting to load-test specific areas of the backend related to plugin-specific features or common user behaviors.

  2. 1. Many plugins load more code in wp-admin than they do on the front-end of the site, so testing wp-admin is not really a good way to avoid caching. Just use someplace other than Kinsta that you actually control and tweak the caching and settings that way. Make sure you’re creating bottlenecks in the right places.

    2. Any remote network calls could throw this off a ton, curious if you can do any logging there. Also make sure the plugins are in the “connected” state.

    3. I’d like to note that for Jetpack each module often does what a full plugin would do someplace else, that’s a big part of what makes it ultimately more efficient than using individual plugins to accomplish the same tasks. Also some modules of Jetpack, like Photon, will create big performance improvements in the loading and optimization of the site, not to mention the benefit of optimized mobile pages or AMP.

    1. Hey Matt,

      1. I see your point. I did not move to the backend to avoid caching, it just “triggered” the idea in my mind. Of course, I could deactivate caching on Kinsta or test somewhere else, which I plan to do for the next ones.

      2. Good point, but I did not 🙂

      3. Well, you right here. I said I tested JetPack with half of its modules active, which is like having 20 active plugins at once so the result is not bad. That said, I was not testing any specific plugins, I choose the most popular and about JetPack, I activated a few modules to emulate a common behavior. It was more an investigation about the impact on the backend than a plugin specific analysis, which of course would require a totally different testing setup.

    2. I think testing wp-admin is as important as the frontend (of course depends). Thanks to caching, image optimization … it is quite easy to get a real fast frontend on average hosting services.

      Many [customer] complains come from a slow backend… because of whatever all these plugins do… It always feels, that there is a need for more powerful hosting, only because the backend feels unnecessary slow and unresponsive (in my opinion it is mostly inefficient database usage, no bulk operations for getting options or updating/getting meta).

  3. Francesco! Great post, great value. Thanks for doing “the work”!

    Would love to see you add:
    BeaverBuilder
    GravityForms
    Pods
    WordFence
    Sucuri

    🙂

  4. Yoast SEO! Then we need to disable unnecessary features like internal link analysis, readability that not applicable for a job posting site, also we don’t do on-page seo… but tried amp whole page speed lost.

Leave a comment

Your email address will not be published. Required fields are marked *