WordPress is one of the best platforms for blogging, presentations and much more. When the site starts having a nice amount of traffic, people often realize the loading speed needs to be improved.
Whether you want more speed in order to improve the visitor experience, or because of SEO considerations or a combination of several factors, you will definitely come into contact with tutorials on how to use caching plugins, switch to an nginx web server setup and many other ideas more or less complicated.
I will show how you in this post how you can achieve the most important boost of speed by spending only a few minutes defining traffic rules for your WordPress domain in the ClusterCS web hosting panel. Whether you’re a website owner, developer or sysadmin, I believe reading the few lines bellow will be valuable.
First things first, what is ClusterCS? ClusterCS is a remote web server management tool which means it’s a system that connects remotely to your server and installs necessary packages and settings for your domains to run smoothly.
For the purpose of this demo, we will consider the account setup and the WordPress site running under this control panel. I will give you a few more details on how to achieve this phase (it’s really easy) at the end of the article.
Let’s take for example this domain which has a WordPress installed wp2.at-byte.com
We want to go inside the “Speed” section for this domain. This section contains a rule based manager for splitting traffic between main servers (apache, lighttpd, nginx). A concept fairly new most likely for web server panels, this tool lets you use all those servers in parallel for the same domain, so you can can optimize your serving strategy.
Let’s rush into how this is done and then I will explain.
The default set of rules will already optimize resource delivery by assigning static files to be served through lighttpd (a wordpress page contains several such static files like images, javascript files, css style files, fonts etc – those files in a standard hosting are being served by the same apache but as a comparison I always like to make, that’s like using an elephant to carry a chicken egg ).
The default for the rest of the traffic is set to apache which tends to be the standard way of serving the WordPress main pages. One way recommended by many tech guys is to use nginx instead of apache for that task. Nginx can do 2 very important things in the context of what we want to achieve. It can replace apache completely and handle the php script processing had the other major role is that it can cache stuff and do so in a very smart way.
To be honest, just handling php with nginx over apache, is a debatable upgrade. Especially when considering some more changes that needs to be done for nginx to properly understand the WordPress required rules.
WordPress and many of its plugins usually requires a set of rules that either rewrite links, blocks unwanted bots, etc. Since apache was the standard way of doing stuff, all plugins will provide automation for .htaccess (the apache standard config file for those rules). When you switch to nginx you may need to search for a translation for those rules or in more difficult case rebuild them yourself.
This is why staying with apache for main php processing may still be the best choice for lots of people. But the other part we mentioned for nginx, caching, well that’s the golden prize. Nginx has a very smart cache system which can dramatically boost the loading speed. You will literally change your opinion of what a fast site means if you’ve never seen a similar config in action.
In order to use it, in ClusterCS you just need to create the caching rule. When you use caching, you have to be careful what you cache though. Some things need to remain dynamic. With WordPress, 3 important things may cover most of the setups:
-
- Don’t cache admin and pages for logged in users (dynamic personalized data for each user may be visible on those page) – WordPress maintains a cookie which is an indicator of this state – wordpress_logged_in;
- Don’t cache admin-ajax.php – this file is the main endpoint for ajax calls that usually need to happen without cache;
- Only cache GET requests – other types usually have important actions being carried and shouldn’t be lost.
So let’s put these rules on the board
Save, execute configuration and that’s it 🙂
After a few seconds of updating server configs, your WordPress blog will run on steroids.
For a few more technical details for the people that want to understand the technology more in depth, how this will work is that WordPress cache eligible requests will be sent to nginx which if it doesn’t have a cached page available or what it had is expired, it will just query apache for an updated page version.
This way the response for all requests are at one point being created by apache which is good considering the many custom .htaccess rules we have described earlier.
If you want to create your more advanced configuration, it is totally possible. You can enable custom configs, click generate on the one you need and get the lines you can then edit.
After enabling nginx cache, it should already be a major improvement for your website speed. Depending on your theme design, you may still gain an extra boost of speed if you minify your css and js files. Minification pretty much means combining the resources in one file (one ccss file and one js file).
There are WordPress plugins that can do this, a particular one that I like is W3 Total Cache, but when creating the minification rules, some trial and testing must be performed. Sometimes the order in which those files are placed in the html matters and you can’t just bundle everything automatically as they may brake things. If you’re not a technical person, I would recommend you consult a developer as it seems it’s never a straight forward tutorial on how to achieve this part.
If you like how ClusterCS is helping do a better management for your web server and websites, you may find additional information on how to create your first setup in the following examples:
-
- Add a Digital Ocean server
- Add an Amazon EC2 instance
Any other server should be fine as long as they are reachable through an external ip. ClusterCS is a remote system, which means you can use servers in any location if connectivity requirement is met. When you want to choose a server that will be managed by ClusterCS, please consider that it currently supports CentOS 6/7 and RedHat 6/7 and most of the variations of those distros such as Amazon AMI 2014-2016 etc.
Enjoy!