Let’s set the stage by reviewing some really important factors to keep in mind when scaling WordPress:
-
Visitors – Real people who are usually your customers or audience.
-
Requests – Each visitor to your site makes X number of requests each time a page is loaded. If you have 10 images on the page, plus the HTML doc, that’s 11 requests per visitor. Usually, we see sites making 20-50 requests per page load all the way up to several hundred and well beyond. This is important as it can exponentially increase the load on your server.
-
Cached Content – This is essentially content that does not need to make a call to the back end of WordPress or a database. We want as much content as possible to be cached and ideally not even on your main server but off the edge (more on this later).
-
Dynamic Content – Content that has to be processed by a database, think of an e-commerce shopping cart.
-
Logged in Sessions – Do users need to log in to your site? This is another critical factor that increases load.
You need to handle users on what content they are accessing. And the code of your site to ensure success when scaling WordPress. Let’s look at some real-world examples of how this might work.
A lot of people want to know how many server resources they need to handle X number of users. The problem is there are too many variables to make a blanket statement, otherwise scaling WordPress would be easy 🙂
In one test, I tested 2500 visitors on a cached site, with Cloudflare Enterprise and Full Page Caching. That test caused WordPress to use almost 3-4 full CPU cores on the site. This test did not include database load, only WordPress.
That same exact test, but by accident included a broken link to a page that caused a 404 error used double the resources.
It’s worth mentioning that these were both tested on Google c2 instances with 16 cores. See the impact of having one page in the mix that was not cacheable, WordPress load increases significantly.
