Major WordPress Optimization Tips
Today the WordPress is one of the most popular CMS. Originally conceived as a blog engine, today it is used for a different types of sites like news portals and online media in particular. Corporate websites, educational and entertainment projects operate on WordPress.
WordPress is used by our many clients who quite often ask us questions on setup of this CMS.
There are plenty of detailed installation instructions and the WordPress setup & configuration online. The majority of publications about WordPress don’t grasp what we will in this article. We’ll talk about how to optimize the WordPress sites operation and also provide a row of recommendations on increasing the level of security and work stability. In all examples Ubuntu 12.04 is used.
Database Engine Configuration in the WordPress Optimization
Database Engine Selection
MySQL database server configuration is necessary for the proper WordPress optimization. Recently alternative implementations (forks) of this DBMS were widely adopted. The most popular of which are Percona Server and MariaDB. In many installation instructions published on the Internet it is recommended to use MariaDB.
We recommend to use Percona Server as this fork on comparing with standard MySQL is more efficient and stable. Besides, Percona has ampler opportunities to collect system statistics.
You must first import the keys in order to install Percona on a server:
$ apt-key adv --keyserver keys.gnupg.net --recv-keys 1C4CBDCDCD2EFD2A
Then you necessary to add to the file/etc/apt/sources.list the following repositories:
deb http://repo.percona.com/apt precise main deb-src http://repo.percona.com/apt precise main
And execute the command:
$ sudo apt-get update
After that it is possible to install percona-server by means of the standard package manager:
$ sudo apt-get install percona-server-server percona-server-client
Choose the Engine: MyISAM or InnoDB?
The most popular MySQL-based engines are MyISAM and InnoDB. There will be questions in productivity and consistency when the engine is selected incorrectly.
We will thoroughly consider these engines’ features in the WordPress optimization process.
MyISAM shows good results on the SELECT that is in many respects caused by the support absence of transactions and external keys. However, in case of modification and post adding the whole table gets temporarily locked. And in case of a big load can be delayed seriously.
Undoubted advantages of this engine are also full-text query search and a compression. The data format in MyISAM is cross-platform that allows to transfer without problems data from one server to another. Simply by copying the databases’ binary files (tables).
In the modern MySQL versions, the InnoDB is used as a default engine.
Unlike MyISAM, InnoDB supports transactions and external keys. Percona Server uses its own XtraDB engine completely compatible to InnoDB. Data in InnoDB/XtraDB is cached. When the most part of data is read out from a cache, productivity of InnoDB/XtraDB is many times higher, than at MyISAM.
There are plenty of articles devoted to the comparison of MyISAM with InnoDB / XtraDB, as well as MySQL with its forks (see the performance test here also). We will not go into theoretical details and confine ourselves to practical advice: MyISAM should be chosen only in cases where full-text search is needed. InnoDB / XtraDB will perfectly handle all other tasks. By the way, in MySQL / Percona Server 5.6+ full-text search for InnoDB is already supported.
Optimizing Database Engine Configuration
The amount of data in the database will defiantly grow as the site develops and there will be a need to change the database settings. To ensure optimal operation of the site it is desirable to regularly check how optimally configured the current MySQL configuration. The most famous and popular of many scripts with which help it is the easiest to implement that test is mysqltuner.pl. It can be downloaded with the following commands:
$ wget https://raw.githubusercontent.com/major/MySQLTuner-perl/master/mysqltuner.pl $ chmod +x ./mysqltuner.pl $ ./mysqltuner.pl
This script collects MySQL statistics and issues recommendations on improving the existing settings.
Web Server Configuration in the WordPress Optimization
Apache Options
The Apache settings are stored in a /etc/apache2/apache2.conf file
In the Apache configuration file there is such parameter as max_clients — the maximum number of the processes launched for parallel processing of client requests. It could seem that for this parameter it is necessary to set the maximum value at the beginning. In real practice, however, everything happens differently.
Say, one Apache process can consume 20 MB of RAM. If max_clients is set to 200, then under peak load for all processes, 200 × 20 MB = 4 GB of memory is required — and this is only for Apache! As a result of a lack of memory, even the simplest queries will be executed very slowly. And the software on the server may stop working.
For that reason, setting the max_clients parameter too high is not advisable. If the number of requests exceeds the specified value, all these requests will be queued and processed as soon as the busy processes are freed.
With the intention of advancing the performance, it is also suggested to disable keepalive-connections by adjusting the corresponding line in the configuration file:
KeepAlive off
Backend + Frontend = Apache + Nginx
Roughly high-loaded web project must have a multi-level architecture. For most WordPress projects the two-tier architecture of Backend – Frontend is quite suitable. We endorse using the next bundle — Apache for the backend and Nginx for the frontend.
The other alternative is php-fpm as a backend and the same old Nginx for the frontend (see the configuration instructions here). Numerous publications state that the php-fpm + Nginx bundle works faster or consumes much less memory. We cannot agree with that completely.
Apache + Nginx
The available Internet tests should be treated with a healthy share of skepticism in the WordPress optimization process: often php-fpm + Nginx demonstrates better results simply for the reason that Apache was not set up appropriately (see the test report and its critical analysis; a curious discussion here). Based on our own experience, we can say that for most WordPress projects the combination Apache + Nginx is quite suitable. The choice of the answer should be based not only and so much on the increase in productivity but on the specifics of the tasks being solved and considerations of technological convenience. And Apache, in our opinion, is more flexible configuration. It can be used both as a separate web server, and as a backend for Nginx, and as a frontend for php-fpm.
The following is the over-all pattern of the work: Nginx receives requests from users which then either passes to Apache or processes it itself. Apache will be sent requests related to the processing of dynamic content – for example, php-scripts. Nginx independently processes requests for the return of statics – for example, graphics, JS, CSS, text files, XML files.
After processing the request and passing the contents of Nginx, Apache is turned off and goes to processing other requests. Thanks to this, the work is significantly accelerated (which is important, for example, with a slow Internet connection).
In addition, the distribution of dynamic queries can be accelerated using the Memcached server.
Ensure Security in the WordPress Optimization Process
Numerous plugins are used to widen functionality of WordPress. In many circumstances these plugins could be vulnerable and because of it some system administrators have a slightly pessimistic view on it. The WordPress websites quite often become an attacks target but over time developers boost plugins removing the existing safety cracks. Further down we will give some more advice on the WordPress setup by the means of which it is possible to make the website less vulnerable.
Protect yourself from WordPress server scripts malware and vulnerabilities
We recommend using the ClamAV + Maldet scanner. For instructions on how to install and configure AV, please click here. You can also use the WPScan program to find vulnerabilities.
Change the database table prefix
By default, the prefix “wp_” is set in the WordPress database. This simplifies the use of vulnerabilities with MySQL injection: if you know the name of the table it is much easier to insert malicious code, change the information in it or even delete it altogether. In new WordPress versions, you can choose the installation prefix.
If you use an earlier WordPress version, you can change the prefix using specialized plugins. The most famous and popular is the Prefix Changer. It should be noted, however, that many of these plugins do not always work correctly. So it is recommended that you back up the database before using them.
Move the wp-config.php file
The wp-config.php file stores important WordPress settings that you want to protect from unauthorized access. By default, this file is saved in the root directory but you can move it to the directory above. The WordPress will search for it automatically when the wp-config.php file in the root directory not found.
Get SSL certificate and enable SSL encryption
Add the following lines to the wp-config file in order for this:
/* Enable SSL Encryption */ define(‘FORCE_SSL_LOGIN’, true); define(‘FORCE_SSL_ADMIN’, true);
Delete the WordPress version information
If an attacker finds out that you are using an outdated WordPress version, then the vulnerabilities and hacking of your site are highly possible. Therefore, it is better to delete the version information.
First, you need to delete the your_site/readme.html file where you can easily find out which WordPress version you are using.
You can also learn about the version you are using from the header.php file which is located in the theme folder. It contains the following line:
<meta name = "generator" content = "WordPress”;
You can delete the whole row completely. If there is no such line in the header.php file of your theme, it is most likely inserted automatically by WordPress when the wp_head () function is called up. In this case, you can remove the version information from the section by adding the following code to the functions.php file:
remove_action(’wp_head’, ’wp_generator’);
function selectel_remove_version() {
return ’’;
}
add_filter(’the_generator’, ’selectel_remove_version’);
Change the security keys
The wp-config.php file mentioned above has a section with security keys. It looks like this:
define(’AUTH_KEY’, ’’); define(’SECURE_AUTH_KEY’, ’’); define(’LOGGED_IN_KEY’, ’’); define(’NONCE_KEY’, ’’);
The keys are used to hash the passwords. In many cases, even skilled users do not pay attention to this section. Meanwhile, it’s quite easy to change security keys. Just follow https://api.wordpress.org/secret-key/1.1 and copy the generated keys to the wp-config.php file. This procedure is sufficient only once during the initial setup of the site.
Limit access to the wp-content and wp-includes folders
For security reasons, it is recommended that you block access to the wp-content and wp-includes folders’ contents. It is necessary to close access to any files except graphics, JS and CSS. To do this, you need to create a .htaccess file in each folder and put such code into it:
Order Allow,Deny Deny from all Allow from all
Create an empty wp-content/plugins/index.html file
Due to this, information about which plugins you are using will become unavailable. WordPress plugins can contain vulnerabilities and the intruders might use it.
You can also add the following line to the .htaccess file stored in the plugin folder to make the listing inaccessible:
Options-Indexes
Limit access to the wp-admin folder
In order to restrict access, you need to create a .htaccess file in this folder and insert the following code into it:
AuthUserFile /dev/null AuthGroupFile /dev/null AuthName «Access Control» AuthType Basic order deny,allow deny from all # for example specify the IP address of the home computer allow from # here we specify the address of one or more IP-addresses from which we will write to the blog at work allow from allow from
It is not always convenient restricting access by a specific set of IP addresses. You are able to configure access to the wp-admin folder only with a password. To do so, you need to create a .htauth file:
$ htpasswd -c /home/yourdirectory/.htauth
And insert it one level above the / public_html/
Then you need to create a .htaccess file in the wp-admin folder and input the following code to it:
AuthName 'Admins Only' AuthUserFile /home/yourdirectory/.htauth AuthGroupFile /dev/null AuthType basic require user <username>
Conclusion
The configuration of even such a simple and user-friendly CMS as WordPress is a quite difficult and full of technical nuances task. Even experienced users do not constantly pay attention to all of them especially during the WordPress optimization process. We hope that the provided recommendations will be useful to you. In return we are always ready to help on customization, setup and the WordPress optimization of difficult projects.
Of course this list of recommendations provided in the article is not complete. We will be very glad to see your comments on your own experience of WordPress optimization.