Optimizing Performance of WordPress Hosted on Cloud Servers

Optimizing Performance of WordPress Hosted on Cloud Servers is Required to Decrease the Latency and Page Loading Time. Technologies are discussed in this article. As for WordPress, the database is MySQL, not even MySQLi. PHP – MySQL Applications are famous but not known to be well performers. WordPress with modification or Plugin can run with PostgreSQL, but usually that is not a standard method follow. We are taking the widely used configuration for WordPress to Optimize, that is a typical Linux-Apache-MySQL-PHP (LAMP) Server driven WordPress. WordPress is not scalable, to make it fully scalable amount required to pay will not make the average webmaster happy, the wallet is unfortunately not scalable. So, some compromise is usually done.

Optimizing Performance of WordPress Hosted on Cloud Servers : Understanding the Basics

Practically, WordPress is not a Web App optimized for running on scalable Cloud Infrastructure. Technically WordPress should run quite nicely on a 256 MB server – unfortunately that is fully theoretical. There are Thousands of Plugins which adds more burden and the practical need to run WordPress nicely (with 5K Posts) becomes 01 GB. But, with only one 01 GB RAM, unfortunately; MySQL Server will not work optimally with co-shared processes and/or various running demons. The best solution would be to use :

1. Using a Database as a Service of 512 MB for MySQL Server
2. Using At least Two Servers of 512 MB size with Master Slave Configuration for running Apache2 and PHP
3. Using nginx Reverse Proxy Server of 512MB with some Cache System – Memcache or Redis

As, this configuration is not only costly but also demands always on person to check the server side, we usually take an 01 GB Server Running WordPress as common standard. Theoretically, if all the pages are converted to HTML and served as cached version, an 01 GB Server would be sufficient. Unfortunately, a WordPress with 5K Posts can never convert all the Pages to HTML on the fly, a regularly updated blog posts 4-6 Posts per day. All the HTML Pages are cleared after Publication of a Single Post. Again, if you increase the number of Physical Processors on a single Server and Allocate more RAM to make the caching process faster, unfortunately your bill will reach typical 3-5 server configuration for making WordPress running on kind of legacy mode to make it scalable.

Apache is a robust Web Server Software, it is PHP plus badly coded Plugins make it worser. nginx is a compromise to run the poor WordPress faster.  Apache is more secured, more developed. If you want to run WordPress with nginx WebServer – use a managed service. You can decrease the RAM to 512 MB. Still, 512 MB will not give much room to give PHP to use 256 MB of RAM.

We usually use :

1. Either W3 Total Cache Plugin Alone
2. WP Super Cache Plus 2-3 Add-on Plugins for WP Super Cache
3. Batcache Plus MemCache Plus some Other Plugins to combine and/or minify CSS, HTML and infamous Javascripts.
4. Memcache and Redis actually serves the same function.

Optimizing Performance of WordPress Hosted on Cloud Servers : Options

A PHP accelerator is definitely required on the server side. A PHP accelerator is a PHP extension designed to improve the performance of software applications written in the PHP programming language. Most PHP accelerators work by caching the compiled opcode/bytecode of PHP representation of php files to avoid the overhead of parsing and compiling source code on each request. There are various PHP Accelerators :

1. Alternative PHP Cache (APC)
2. eAccelerator
3. ionCube PHP Accelerator
4. Turck MMCache (it is a misnomer in strict sense)
5. XCache
6. Nusphere PhpExpress

Turck MMCache for PHP probably was the best solution, unfortunately it is not updated; Alternative PHP Cache (APC) is taken as the standard. eAccelerator is probably a fork of Turck MMCache, but in practical scenario with newest PHP, Alternative PHP Cache (APC) works better for most server hardwares. As like desktop computers, it matters what Processor, RAM, Chipset etc. are used on the server as hardware.

Second Part is that Caching Part. If we save data dynamically and serve in a pseudo static fashion – it actually becomes Caching – Disc Cache. We do not want go in to details, but Memcache or Redis is not the full solution to Cache all kind of data. We are talking about an 01 GB Server Running WordPress.

There are tweaks for Apache by enabling modules like deflate (gzip was for version 1 of Apache, we recommend to use both gzip and deflate directives on htaccess with overriding as Site specific settings – for browser issues, enabling both works better on tests). In the same way, there are tweaks for PHP, MySQL too.

For W3 Total Cache, the best settings is (again, it is for an 01 GB Server Running WordPress) :

1. Page cache method ==> Disk Enhanced
2. Minify cache method ==> Disk
3. Database Cache ==> Alternative PHP Cache (APC)
4. Object Cache ==> Memcached
5. Varnish server is better to use (you can use your another server like in a daisy chain)
6. CDN ==> Enabled except for the attachments for the sake of SEO (Google image search brings a lot of visitors)

Many things said in very small details, but unfortunately Google has added new “Laws” to measure “Quality” that practically renders W3 Total Cache using to an average result. It is difficult to score 90+ now as without hand coding, it is impossible to maintain all their points. There are many Managed WordPress Hosting services are available now, if you challenge; we can show, their own WordPress website can not score over 72 on Google’s test. Now on the security side, what W3 Total Cache does is not great, if you do a curl to get header :

X-Powered-By, X-W3TC-Minify are never standard headers and open up information about your setup. To modify them, you have to change them to arbitrary values, change ownership of the files to root and chmod to prevent overwritten. Other header data can be modified from php.ini file. You can compare the values with Yahoo! :