With an ever growing need to have instantaneous website access, load testing is getting a lot more traction in the conversation. In fact load testing is just one part of a full suite of metrics for measuring everything from speed with no one on your site to maxed-out crazy holiday shopping season performance. Your site’s performance is critical day to day for SEO and casual browsing and ecommerce. Let’s dive in.

Load testing WordPress means understanding your capacity. Knowing when a WordPress site will fall over is important for giving your customer a seamless and performant experience. Without load testing, you’re just guessing.

Jack Slingerland, Founder, Kernl.us

Simple Speed Test

Many of us don’t have 1,000,000 page views per second, insane volumes of media being accessed, or are running our sites on a server in the attic on a 386sx Dell. We’re not pushing the limits on a day to day basis or using horribly out of date infrastructure from a host. If you don’t know about it yet, GTmetrix is your best friend here, it’s free if you don’t mind your site being added to the public record, and provides a wealth of data. Even better it has a simple summary. In the case of RobertJacobi.com, we get some pretty high marks:

These are pretty darn good, and you can really dive deep into all the items that may be causing bottlenecks. Even on the free version I can see that Time to First Byte (TTFB) is insanely fast (~50 ms) and that the DOM is fully loaded at 159 ms.

Just for fun, let’s compare to WordPress.com.

The Fully Loaded Time looks awful on the face of it but surprisingly the site loads much, much quicker, almost instantaneously. The trick, lazy loading, GTmetrix is literally grabbing everything even though JavaScript magic makes the site appear. This will be an important distinction later.

This is the first order test you should be performing on your site. If you’ve got problems here, fix them, all the other types of tests will just look awful and you really want to nail down the issues that are being exposed by GTmetrix. WordPress.com could certainly improve some factors which would probably reduce internet congestion and compute time in my browser but they’ve obviously maximized performance on the back-end.

Stress Testing

Let’s get to the next type of load testing, stress testing. This is the application of extreme amounts of web traffic (think a controlled denial of service attack) to see at what point the sites becomes unusable. There are a couple of ways stress testing is performed. There is a simple and friendly WordPress Load Testing service like Kernl Load Testing or something a bit more complex that fundamentally performs the same service like k6 (formerly Load Impact). The k6 model of testing utilizes virtual users (VU). It’s definitely more complex and the exact process is for me is a bit confusing, so I’ll let them speak for themselves.

Virtual Users(VUs) are the entities in k6 cloud service that execute your test script and make HTTP(s) or websocket requests. VUs are concurrent and will continuously iterate through the default function until they ramp down or the test ends. Any number of VUs will create a number of sessions a factor larger than their total count, depending on test and script length.

For example, if you ran a test with 10 VUs for 10 minutes and the default function took each VU 30 seconds to complete, you would see roughly 200 completions/total sessions generated from this test. This is approximate and will vary based on your ramping configuration.

As far as I understand, what the above means is that 1 VU will run through a script, make requests, and so long as 200 Response Codes are received all is well and timing can be calculated. Now here is the very important part, if you a running k6 against a fairly static site, the data will be quite accurate. If will hit the web pages, CDN, associated CSS, JavaScript, and other media. The question is are the assets fully loaded? That’s a definite maybe depending on the web server configuration but in most cases a 200 should include the full response data. One large question is how does this kind of stress testing evaluate a true user experience in a more complex application (i.e. ecommerce carts and checkout).

Complete Performance Testing

With Complete Performance Testing, I’m calling this CPT, the test tool evaluates the website at complete load. The test suite will download and execute all site assets fully, this means that cached items are ignored, JavaScript and CSS are download and rendered, and local sessions are instantiated. This is the most extreme way of rendering the site since “static” WordPress pages will typically not be re-rendered if they are cached at the edge by a CDN but in the cases of complex applications which rely on dynamic content generation based on session state those pages cannot be cached at the edges so you will need CPT.

The complete test will literally spin up full instances of a browser, run through automated or manually created test scripts, and continue to browse the site with an originally empty local cache. This is absolutely more resource intensive for the test provider but has the absolute benefit of drawing a picture. The Supervisor platform does exactly that and you can even see the browsers spin and go through the pages.

Running high volume wordpress site with dynamic content such as shopping carts demands a lot of expertise on the hosting provider. WordPress does not scale exceptionally well out of the box and you can’t cache the dynamic content. With load testing you can verify you are on the right hosting plan and all the different settings in the hosting are set correctly.

And even simple heavily cached WordPress sites could benefit from load testing if you expect a lot of users because there is always a limit what your site can handle.

Lauri Kasti, CEO, Supervisor.com

Conclusion

There are many ways to validate the performance of your site, the question is, which provides the best set of metrics to help you know when you need to examine the code or increase infrastructure. I think a combination of tools at the end of the day will get you a very good idea of what needs to be done.

I absolutely recommend starting with the simple speed test provided by GTmetrix, if your site is failing here then there is no need to move on, fix the issues pointed out and see if code and plugins will get you to the holy grail of two seconds or less at no load.

After performing your initial tests, if you’re site is 100% “static” and not relying on any user-generated content (UGC: comments, carts, etc.), then Kernl, k6, or many other solutions will be able to hurl a significant traffic load and let you know at what point your site cracks under the strain. With that you should be fine

If you have any UGC, you should evaluate what percentage is UGC is typically being accessed and go with a two prong approach. If UGC is 35% or less of activity start with regular stress testing and following complete performance testing on just the pages where UGC exists. Conversely if 65% or more activity is dynamic and complex, run Supervisor against your entire site.

Performance is critical, make sure it is part of your site’s lifecycle.