{"id":328,"date":"2013-09-24T09:22:05","date_gmt":"2013-09-24T09:22:05","guid":{"rendered":"http:\/\/blog.shineservers.com\/?p=328"},"modified":"2013-09-24T09:22:05","modified_gmt":"2013-09-24T09:22:05","slug":"test-wordpress-caching-plugins-w3-total-cache-vs-wp-super-cache-vs-quick-cache","status":"publish","type":"post","link":"https:\/\/www.shineservers.com\/2013\/09\/24\/test-wordpress-caching-plugins-w3-total-cache-vs-wp-super-cache-vs-quick-cache\/","title":{"rendered":"Test of WordPress Caching Plugins \u2013 W3 Total Cache vs WP Super Cache vs Quick Cache"},"content":{"rendered":"<p>There\u2019s been a lot of talk about which is the best caching plugin for WordPress. There\u2019s no doubt in my mind which is best, and that\u2019s W3 Total Cache. I\u2019ve reached this conclusion based on logic, theory and a knowledge of how it should be done. W3TC performs best in theory, but is it the best when tested and what are the pros and cons of the different types of caching tools available? That\u2019s what I\u2019d like to take a closer look at here. I\u2019m going to look at both performance and load times. For that I\u2019m going to use two tools in particular,\u00a0<a href=\"http:\/\/tools.pingdom.com\/fpt\/\" target=\"_blank\" rel=\"noopener noreferrer\">Pingdom Tools<\/a>\u00a0and\u00a0<a href=\"http:\/\/httpd.apache.org\/docs\/2.2\/programs\/ab.html\" target=\"_blank\" rel=\"noopener noreferrer\">AB Test<\/a>\u00a0(Apache Benchmark test). However, I\u2019ve also used other tools to assess load times on the website both during periods of heavy use and during single visits.<\/p>\n<p>I\u2019d like to begin by describing the different plugins, before I reveal the test results for the three.<\/p>\n<h2>The test<\/h2>\n<p>The test was carried out on a site which most closely resembles a \u2018real-world\u2019 website, with the caveat that the site doesn\u2019t get crawled or found by Google. This is the newest English language version of WordPress for which I\u2019ve bought the currently\u00a0<a title=\"View the theme here\" href=\"http:\/\/www.dashboardjunkie.com\/show\/themeforest-unitedthemes-nevada\" target=\"_blank\" rel=\"noopener noreferrer\">popular Nevada theme<\/a>. I\u2019ve set the theme up with standard content supplied by the developers through XML import. Permalinks are activated.<\/p>\n<p>Pingdom Tools and Apache Benchmark are used to look at load times and performance on the site, respectively. In addition to these two tests I\u2019ve also used Gomez Networks, Load Impact and Google Chrome to achieve a valid end result which best approximates reality \u2013 FastCGI functioned as the engine for PHP solution. For the Apache Benchmark test I ran the following which means that 1000 tests were run with 10 simultaneous users:<\/p>\n<p><strong>ab -n 1000 -c 10 http:\/\/www.domain.com\/<\/strong><\/p>\n<p>Each testing tool was run 10 times, both with and without a caching plugin, and it\u2019s the average result which will be shown at the end. In total, 250 tests were run with intervals of ten minutes and a single AB test on a static html file (where I had copied the html code from the site being tested) to see how much the server could actually handle under those conditions.<br \/>\nIt\u2019s important to point out that the tests only look at HTML caching\/Page Caching because this is the element which the plugins in question have in common. Some of them also have CDN, Gzip, and Browser Caching but these won\u2019t be considered as they\u2019re not shared by all plugins.<\/p>\n<p><strong>Tests to be divided up as follows:<\/strong><\/p>\n<ul>\n<li>Test without plugins of any type (50 tests)<\/li>\n<li>Test using caching plugins and their standard settings (50 tests)<\/li>\n<li>Test using caching plugins in their optimized versions (50 tests)<\/li>\n<\/ul>\n<h2>W3TC (W3 Total Cache)<\/h2>\n<p><a href=\"http:\/\/wordpress.org\/extend\/plugins\/w3-total-cache\" target=\"_blank\" rel=\"noopener noreferrer\">http:\/\/wordpress.org\/extend\/plugins\/w3-total-cache<\/a><\/p>\n<p>W3 Total Cache is a plugin that has pretty much everything in terms of speed optimization. Among other attributes, it has HTML caching, which we\u2019re testing here, and minification, Object Cache, Database Cache, Gzip, browser caching, CDN, Varnish, minification of js and css files, minification of html code, auto caching and a lot more.<br \/>\nW3 Total Cache creates its html caching files by taking PHP output and putting it into two html files on the server, one compressed and one uncompressed. When this URL is requested a small rewrite in htaccess checks to see if the browser can support compressed files, and if the cached file exists, which, if it does, is then displayed to the user. If it doesn\u2019t, it will continue on to WordPress and show that page\u2019s content. If caching is permitted, W3TC will then create a cached version of the requested page and display it to the next user who requests it.<br \/>\nIf you want to set up the whole plugin with all its features, it will typically take 1 to two hours, depending on website type, content, activity, theme etc. But when you\u2019ve set up the plugin and all its features your website will run pretty well. But it\u2019s no substitute for normal optimization of, for example, pictures or the usual requirement that your theme and plugins have been well coded.<\/p>\n<h2>WP Super Cache<\/h2>\n<p><a href=\"http:\/\/wordpress.org\/extend\/plugins\/wp-super-cache\/\" target=\"_blank\" rel=\"noopener noreferrer\">http:\/\/wordpress.org\/extend\/plugins\/wp-super-cache\/<\/a><\/p>\n<p>WP Super Cache is a page caching plugin which offers some different options including page caching and CDN. It\u2019s easy to set up and doesn\u2019t require much tech knowhow from the administrator. It uses three different caching methods with the default setting being the next best of the three options (via PHP). Unlike W3TC it doesn\u2019t create a compressed version of the cached file by default, but of course this is something you can ask it to do.<br \/>\nSetting up the entire plugin takes about twenty minutes. It\u2019s a small plugin that\u2019s quick to install, and pretty much anyone can do it.<\/p>\n<h2>Quick Cache<\/h2>\n<p><a href=\"http:\/\/wordpress.org\/extend\/plugins\/quick-cache\/\" target=\"_blank\" rel=\"noopener noreferrer\">http:\/\/wordpress.org\/extend\/plugins\/quick-cache\/<\/a><\/p>\n<p>Quick Cache is an even smaller plugin which only handles page caching. There aren\u2019t many settings to speak of but on the other hand it\u2019s incredibly easy to use. The only thing you need to do is to activate the plugin and switch \u2018page caching\u2019 on.<br \/>\nOther settings deal primarily with when page caching is permitted and when cached files should be deleted. There is also an option for browser caching but the developers recommend that you don\u2019t activate this.<\/p>\n<h2>Shared Features of the tested plugins:<\/h2>\n<p>Common to all is, of course, caching of the html on which the homepage is built. That\u2019s about the only thing which all the plugins have in common. So only testing can show the delay-reducing effect on the server before the html code is relayed to the user. Which brings us to testing of load times and performance.<\/p>\n<h2>The first test<\/h2>\n<p>The first test is carried out on a static html file copied from the code which the home page of the website throws out. This is to see how much the server can handle and how quickly. The result shows that the server should be able to handle around 4,738.14 requests per second and that 1,000 requests from 10 simultaneous users takes on average 0.208 ms. That\u2019s quite fast and puts almost no strain on the server.<\/p>\n<p><strong>Four variables have been measured:<\/strong><\/p>\n<ul>\n<li>Waiting time on the server before file is passed on to the user<\/li>\n<li>Number of requests the server can handle per second<\/li>\n<li>Waiting time as measured by other testers (for example, Pingdom\u2019s yellow bar)<\/li>\n<li>Full load time for the website<\/li>\n<\/ul>\n<p>The last of these, full load time for the website, isn\u2019t really something we should look at in this test. That\u2019s because there are so many factors (for example, js, css, visuals) which determine how quickly the website loads that it doesn\u2019t give a fair reflection of each plugin\u2019s ability. The only common denominator shared by all plugins tested is page caching \/ HTML caching and therefore this is the only element we can use to compare performance for these plugins and decide which is best.<\/p>\n<p><img fetchpriority=\"high\" decoding=\"async\" alt=\"files-on-website\" src=\"http:\/\/www.dashboardjunkie.com\/wp-stuff\/uploads\/files-on-website-1024x783.gif\" width=\"584\" height=\"446\" \/><\/p>\n<h2>Plug and Play Settings<\/h2>\n<p>This test was carried out using nothing more than the default settings of each plugin, in other words just switching them on. It didn\u2019t take more than five minutes to install and set up each plugin. In short, one attribute was chosen and the plugin was activated.<\/p>\n<h2>Wait time<\/h2>\n<p>Wait, time to first byte, execution time. You can call it many things but your main concern is to keep it to a minimum. Firstly, to ensure a faster response time for the end user and, secondly, to lighten the server load, thereby allowing the server\/webpage to handle more visitors simultaneously. An added bonus is the reduced risk of server overload and crash due to too many requests. I\u2019m sure you\u2019ve seen it when a product with broad appeal is shown on tv \u2013 you visit the website only to find lots of people have thought the same as you and the site is either intolerably slow or fails to load.<\/p>\n<p><img decoding=\"async\" alt=\"wait\" src=\"http:\/\/www.dashboardjunkie.com\/wp-stuff\/uploads\/wait-1024x783.png\" width=\"584\" height=\"446\" \/><\/p>\n<p>On the accompanying green diagram, with measurements provided by external tools (Pingdom tools, for example), you can see that it took the server around 426ms to generate the html to be relayed to the user. With caching plugins this improves considerably and the best in this regard was W3 Total Cache with just 27.9 ms on average.<br \/>\nThe reason that it\u2019s faster than WP Super Cache or Quick Cache, for example, is quite simple. W3TC has created a static HTML file which, by means of a simple rewrite in the htaccess file, is shown to the user, if, that is, a static version exists. In contrast, WP Super Cache and Quick Cache both need to begin by going through WordPress in order to fetch the cached file (html and php) which they have previously generated.<br \/>\nQuick Cache is slightly faster than Super Cache. Though I haven\u2019t investigated all the reasons for this, one of them is the fact that Super Cache processes a lot more data than Quick Cache, having as it does large files which check if the page should be fetched as a cached version and if the cached version of the page should be saved.<\/p>\n<h2>Number of requests and upload time on the server<\/h2>\n<p>The above principle holds true when looking at the number of requests the server can handle \u2013 the more the better. With a base measurement of 11.7 pages a second for the website without any caching plugins, a test of W3 Total Cache makes it possible for the server to handle no fewer than 3,636.4 requests per second. Quick Cache, with 691.1, was again better than WP Super Cache, with 334.5. Twice as good, in fact, and for the same reasons I\u2019ve mentioned above.<br \/>\nThe time which the server uses to create\/generate\/fetch the html which the user\u2019s browser then processes must be as low as possible. The end result is that the server can handle lots more traffic simultaneously. With a corresponding decrease in the risk of crashing or requests timed out. W3TC does this in 0.238 ms \u2013 that is, not even one millisecond. Which means the website will load faster for the individual user and at the same time be able to handle a sudden spike in the number of visitors.<\/p>\n<p><img decoding=\"async\" alt=\"time-per-request\" src=\"http:\/\/www.dashboardjunkie.com\/wp-stuff\/uploads\/time-per-request-1024x783.png\" width=\"584\" height=\"446\" \/><\/p>\n<p><img loading=\"lazy\" decoding=\"async\" alt=\"requests-per-second\" src=\"http:\/\/www.dashboardjunkie.com\/wp-stuff\/uploads\/requests-per-second-1024x783.png\" width=\"584\" height=\"446\" \/><\/p>\n<h2>The complete load time for the website<\/h2>\n<p>In a way the results from this part of the test are not especially usable because, as mentioned before, there are too many contributing factors at play to be able to draw any concrete conclusions from the data. Sometimes pictures, js and css files can be slow to load and other times fast. Even in the 120 tests I carried out I got results that ranged from up to 2300ms down to 1000ms (one second). The main culprit after plug and play optimization was almost always javascript files, which with a little optimization should bring the full load time down and give more stable measurements.<br \/>\nSo even though full load time is best for W3TC we can\u2019t declare it the winner on this basis alone. We need to look elsewhere to see or test the effect of html caching. And we can only do that after we\u2019ve optimized js, css and pictures \u2013 otherwise they\u2019re simply too unstable.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" alt=\"loadtime\" src=\"http:\/\/www.dashboardjunkie.com\/wp-stuff\/uploads\/loadtime-1024x783.png\" width=\"584\" height=\"446\" \/><\/p>\n<h2>Conclusion of plug and play tests (5 minute installation and setup)<\/h2>\n<p>W3 total cache is the clear winner in the plug and play test, mainly because it uses, as standard, the best method of caching and displaying page versions to users. It does this by completely bypassing PHP and WordPress and sending a static html to the user. Apache is super fast at handling static html files, so that\u2019s definitely the way to go if you\u2019re thinking about page caching. The only way to make it faster would be to completely drop the rewrite and instead generate files with their names and location already fixed, as we saw in the first test of the static html file.<br \/>\nThe reason W3TC doesn\u2019t quite get top marks in performance terms is precisely because it is a rewrite which the server must negotiate in order to reach the correct cached file. This results in the number of requests being 1000 fewer and processing time being around 0.080ms slower.<br \/>\nThe two other plugins, in contrast, start up the PHP engine and WordPress and carry out a huge amount of data processing and finally end by displaying the cached html to the user. That\u2019s the major drawback with these two plugins \u2013 that by default they run through PHP and WordPress.<br \/>\nLuckily though, WP Super Cache has another option, one which resembles the way W3TC does things. That\u2019s what I\u2019d like to test now.<\/p>\n<h2>Optimized settings for HTML\/Page Caching<\/h2>\n<p>In the last test I looked at the default settings of each plugin. I used at most five minutes installing and setting up each one, simply switching on html\/page caching.<br \/>\nBut in this test I\u2019d like to see what happens when I use twenty minutes (max.) setting up WP Super Cache in particular. The aim is that it performs best in terms of html\/Page Caching \u2013 still the attribute which all plugins have in common.<br \/>\nI\u2019m not going to look at Quick Cache as the previous tests have exhausted its possibilities. W3TC has already been optimally set up, by default, when it comes to page caching, so we\u2019ve already covered it in prior tests.<br \/>\nI should mention in passing that W3TC also has the ability to minify html code but because the other plugins don\u2019t support this it doesn\u2019t fall within the compass of these tests.<\/p>\n<h2>WP Super Cache optimized<\/h2>\n<p>Under the heading \u2018advanced\u2019 you should take the following steps to best exploit the potential offered by Super Cache:<br \/>\nChoose \u201cuse mod_rewrite to serve cache files\u201d<br \/>\nTick \u201ccompress pages\u2026\u201d<br \/>\nAnd save.<br \/>\nIf the htaccess file hasn\u2019t been changed then you need to follow the instructions which follow after you have saved the file. This will require you to manually insert the rewrite code in the htaccess files.<br \/>\nTest results after setting up Super Cache optimally:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" alt=\"Test Results Combined\" src=\"http:\/\/www.dashboardjunkie.com\/wp-stuff\/uploads\/Test-Results-Combined.jpg\" width=\"600\" height=\"476\" \/><\/p>\n<p>As you can see on the orange and blue graph, the improvement in Super Cache is quite significant. Performance has gone from 334.5 requests per second right up to 2268.5 per second, almost an eight-fold improvement. Wait time has been reduced from a little over 3 milliseconds to under 0.5. Overall waiting time has dropped from 52.6 to 32.3. The full load time, which again we shouldn\u2019t emphasize too much, has gone from 1832 to 1581. All in all quite a big improvement for WP Super cache.<\/p>\n<h2>Conclusion (The WP Caching Plugin Test Winner)<\/h2>\n<p>I conclude that W3 is the winner, with Super Cache in second place and Quick Cache coming last. The perceptive reader will have spotted that Super Cache didn\u2019t quite become as fast as W3TC even when using the same technique. There\u2019s a reason for that.<\/p>\n<p>In the same way that W3TC wasn\u2019t quite as good as in the first test because of rewrites in the htaccess files, the same thing happens to WP Super Cache. The difference, however, is that WP Super Cache creates around 60 lines of rewrite while W3TC only creates about 20.<\/p>\n<p>To explain briefly, the more lines you have in htaccess, the worse the performance and speed. Not least when it involves mod_rewrite, which rewrites use and which is a slow and unwieldy module in Apache.<\/p>\n<h2>It\u2019s not just about load time<\/h2>\n<p>Yes, there are more things than load time to be considered when choosing a caching plugin. Of course it\u2019s great when your website loads quickly for users but it\u2019s also very important that performance is good. The faster the performance, the quicker the load time.<\/p>\n<h2>Reader request<\/h2>\n<p>At the request of regular readers I carried out a further test, one in which I used 1 hour to optimize all the functions available in W3TC. Or, more accurately, the only things I chose to optimize were minification of html, css and javascript, Browser caching and CDN. Even though after optimization I could still have further optimized theme, pictures and content etc., W3TC still managed to come down to an average load time of 537ms, with a variation of 100ms during the test, indicating that website stability was also improved. It needs to be tested some more to find out exactly how quick it\u2019s become.<\/p>\n<p>I\u2019m sure many of you are thinking \u2013 \u201cYeah, well, you don\u2019t really need to optimize anymore.\u201d To that my answer is both yes and no. It all depends on your website, what you want to use it for and not least how many visitors you get. Of course, the more visitors you get the more essential it becomes that each of them can access your site as quickly as possible.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>There\u2019s been a lot of talk about which is the best caching plugin for WordPress. There\u2019s no doubt in my mind which is best, and that\u2019s W3 Total Cache. I\u2019ve reached this conclusion based on logic, theory and a knowledge of how it should be done. W3TC performs best in theory, but is it the [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[60],"tags":[],"class_list":["post-328","post","type-post","status-publish","format-standard","hentry","category-linux"],"acf":[],"aioseo_notices":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.shineservers.com\/wp-json\/wp\/v2\/posts\/328","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.shineservers.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.shineservers.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.shineservers.com\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.shineservers.com\/wp-json\/wp\/v2\/comments?post=328"}],"version-history":[{"count":0,"href":"https:\/\/www.shineservers.com\/wp-json\/wp\/v2\/posts\/328\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.shineservers.com\/wp-json\/wp\/v2\/media?parent=328"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.shineservers.com\/wp-json\/wp\/v2\/categories?post=328"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.shineservers.com\/wp-json\/wp\/v2\/tags?post=328"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}