Easy Ways to Speed Up Access to a WordPress Site / Blog With W3 Total Cache

Must read:

Ferdian Alfianto

Ferdian Alfianto

Ferdian Alfianto is an Internet enthusiast, Mac Lover; likes using Wordpress, experimenting with Linux (especially Debian and Ubuntu), tinkering with pfSense routers, happy experimenting with LEMP (Linux, Nginx, MariaDB, PHP) and Redis. You can contact me here.

WordPress, it can't be denied for now is "The best free & open source CMS". Matt Mullenweg, founder of WordPress, when giving a presentation on WordCamp San Francisco in August 2011, announced that WordPress has experienced a very impressive growth. WordPress until August 2011 has been used by 14,7% sites / blogs that are included in the predicate "Top 1 Million". And 22 out of 100 new active domains in America use WordPress.

WordPress is a free, open source (open source), powerful, flexible, safe and support that is supported by millions of wordpress users around the world. Have a problem with WordPress? Just type your problem word in the Google search box, and thousands of solutions will be presented to help you.

Why does WordPress need caching?

Every time there is a visitor to our site / blog, WordPress will process the request which sometimes takes a long time. Initially WordPress will process PHP code which will make several calls to the database and make it HTML format so that it can be displayed on browser so that visitors can see the pages they request. On sites / blogs that have high traffic, this process can happen repeatedly tens to hundreds of times per page! And this can make server performance high, and as a result WordPress will run like a slug, aka slow.

With caching, WordPress will process the request via PHP to the database for the first visitor only. Furthermore, if there are other visitors who come to access it will be served via cache. With caching, WordPress no longer needs to repeatedly make requests to PHP & Database to serve every visitor. The impact of WordPress will remain fast even though it is accessed by many visitors.

Caching With W3 Total Cache

The easiest way to do WordPress caching is to use plugins. There are many choices of plugins for caching, including W3 Total Cache, WP Super Cache, Hyper Cache, etc.

I personally prefer W3 Total Cache because this caching plugin has quite complete features among other competitors, including support for CDN (content Delivery Network), Page Caching, HTML / Javascript / CSS minify, Object Cache, Database Cache, Varnish Purge, support for Cloudflare.

Benchmarks

To test WordPress before and after using W3 Total Cache, I use Apache Bench with option 10 concurrent connections for 1000 hits (with keepalive).

Note: I installed WordPress 3.4.2 with no additional content, only the default WordPress installation.

The command I run for benchmarks is:

ab -kc 10 -n 1000 https://www.my-site.com/

The results BEFORE using W3 Total Cache are as follows:

Server Software: Apache Server Hostname: www.my-site.com Server Port: 80 Document Path: / Document Length: 7423 bytes Concurrency Level: 10 Time taken for tests: 35.830 seconds Complete requests: 1000 Failed requests: 617 (Connect: 0 , Receive: 0, Length: 617, Exceptions: 0) Write errors: 0 Keep-Alive requests: 0 Total transferred: 7628800 bytes HTML transferred: 7424800 bytes Requests per second: 27.91 [# / sec] (mean) Time per request: 358.295 [ms] (mean) Time per request: 35,830 [ms] (mean, across all concurrent requests) Transfer rate: 207.93 [Kbytes / sec] received Connection Times (ms) min mean [+/- sd] median max Connect: 0 0 0.0 0 0 Processing: 29 357 59.6 386 498 Waiting: 29 357 59.7 386 498 Total: 29 357 59.6 386 498 Percentage of the requests served within a certain time (ms) 50% 386 66% 395 75% 398 80% 400 90% 405 95% 413 98% 491 99% 493 100% 498 (longest request)

The above shows that by 10 cuncurrent connections for 1000 hits, WordPress takes 498 miliseconds.

While the benchmark results using W3 Total Cache are as follows:

Server Software: Apache Server Hostname: www.my-site.com Server Port: 80 Document Path: / Document Length: 7093 bytes Concurrency Level: 10 Time taken for tests: 0.673 seconds Complete requests: 1000 Failed requests: 0 Write errors: 0 Keep-Alive requests: 996 Total transferred: 7400794 bytes HTML transferred: 7093000 bytes Requests per second: 1484.92 [# / sec] (mean) Time per request: 6,734 [ms] (mean) Time per request: 0.673 [ms] (mean) , across all concurrent requests) Transfer rate: 10732.02 [Kbytes / sec] received Connection Times (ms) min mean [+/- sd] median max Connect: 0 0 0.0 0 0 Processing: 0 7 20.6 1 89 Waiting: 0 7 20.6 1 89 Total: 0 7 20.6 1 89 Percentage of the requests served within a certain time (ms) 50% 1 66% 1 75% 1 80% 2 90% 4 95% 84 98% 85 99% 85 100% 89 (longest request)

There is a huge difference before and after using caching. By 10 cuncurrent connections for 1000 hits, WordPress only takes 89 miliseconds! Significant differences were also seen in other results, such as examples failed request nothing, unlike without cache failed request up to 617!

Summary

Always use caching techniques so that your WordPress can be accessed quickly. Reduce the use of too many plugins, because it will increase the request calls to PHP & Database, which will cause WordPress to work harder, and the effect will affect your WordPress speed.

Facebook
Twitter
WhatsApp
Telegram
E-mail

Latest articles:

MongoDB logo
Linux

Easy to Install MongoDB on Ubuntu 20.04

This tutorial explains how to install and configure MongoDB Community Edition on Ubuntu 20.04. MongoDB is a free, open-source document database. Belongs to the so-called database family

Related article:

rocket nginx

Rocket-Nginx + WP-Rocket: What are the Benefits?

What is Rocket-Nginx? Rocket-Nginx is a configuration add-on to Nginx for the WordPress cache plugin, WP-Rocket. The developer claims that by injecting the Rocket-Nginx configuration, the

Web Security

13 Easy Tips to Secure Your WordPress Site

The popularity of WordPress is a success, but it comes with consequences. More than 34% sites are built using the WordPress platform, of course this leaves WordPress sites vulnerable