WordPress is without a doubt the most popular content management system in the history of the web. The power and versatility of the combination of technologies like SQL, PHP and web browsers have made it possible to produce a system that can be adapted for nearly any purpose including photo galleries, online comic books, and even web-based games.
When it comes to load testing and performance testing a WordPress based system, there are some technical details that have to be considered first. The basic principles of testing a web server are fairly consistent site to site, but the software involved in building and serving a WordPress system may be either subtly or completely different depending on how the server and the content management systems are configured.
If you are planning on instituting load testing of a WordPress-based system, here are some tips to get maximum efficiency out of the process and to make sure you test the site properly.
How to Properly Load Test WordPress Websites
The first and most important consideration for load testing a WordPress site is to recognize the web server software is no longer just returning data in response to a browser request. Several processes are involved in gathering data, and these processes are subject to a wide variety of architecture, CPU, memory, and hardware speed limitations.
The technical description of this kind of software is “multiple tier” or “N-tier” where the N is a number representing the different levels of software involved. A WordPress system has a minimum of three tiers, and sometimes more. The first is the database. The second is the middleware, written in PHP, which provides the business logic for the system. The third tier is the user interface and browser.
When load testing the system, it should be understood the database and the middleware tiers are both constrained by limits that may not be obvious during testing.
Testing vs. Production
The second priority in load testing a WordPress system is to make sure the exact configuration of server software on the test system is replicated on the production system. This should include the database version, the WordPress version, the theme, all the necessary plugins and wherever possible, the network itself.
While it might seem that something as apparently routine as a plug-in version might be of little concern in the grand scheme of things, depending on which plug-in you are testing, it can have a dramatic effect on apparent speed. This consideration feeds directly into the next priority.
It is always a good idea to test any web-based system with only the minimal amount of configuration and add-ons installed. In the case of content management systems like WordPress, having a caching plug-in or an accelerated mobile pages plug-in running can end up simulating a super-fast server that falls apart under any circumstances that prevent the caching or acceleration plug-ins from working properly.
Part of this process should be to verify that requests sent to the server during testing are actually touching the software on the server. If your test battery is only creating views of your site that have already been cached, you may not be getting the full picture of your site’s actual performance under heavy loads (with a tool like Load View).
Like any software, you should make certain you are running the most recent versions of all WordPress installations, plug-ins, themes and both database and PHP software, according to Web Hosting Buddy. Make certain your test systems match your production systems version for version as well. Even a slight difference can introduce variances into the testing process that will either cost you additional time tracking down the changes or additional work fixing things that aren’t broken and then finding out you still have variances.
Ultimately the whole point of a digital system is eliminating guesswork. For all intents and purposes, if your production and testing systems match, they should produce identical output and provide you with predictable performance when under load from real-world traffic and bandwidth constraints.
Testing a content management system can seem a lot like a police stakeout of a rather boring place where nothing exciting ever happens. While that is a colorful way to describe a job that can be repetitive, hearing the alarm and catching a bug because you ran that test for the third time might end up saving a half-day’s business—and that makes it worth the effort.