WordPress Cache Plugins
WP Super Cache is pretty good, but W3 Total Cache is way out in a league of it’s own & must class as the number 1 WordPress cache plugin to speed up your blog.
With Google’s recent announcement that they are now using site load times as an additional ranking factor, there is whole army of bloggers on the look out for ways to speed up their blogs & believe me there are many different things you can do, depending on your proficiency with such things as image optimization, CSS optimization & of course PHP coding! But for your average Jo there are always the WordPress Cache Plugins, two of the best as far as I am concerned are WP Super Cache & W3 Total Cache.
WP Super Cache
Over the last couple of months I have tried WP Super Cache & yes it did speed things up, admittedly not as much as I would have liked, but there was a noticeable improvement in site load times.
For the novice blogger I don’t think this particular plugin is to be recommended, for the simple reason you are required to copy & paste several lines of code into your htaccess file. Now I know from the many comments and articles I have read, that just finding the htaccess file can be a major task for some of the less experienced bloggers & lets face it, it is one thing churning out articles, yet a whole different ball game when you have to start poking around in the guts of WordPress. Everything considered, I found WordPress Super Cache fairly basic in it’s abilities & as mentioned above, not the easiest WordPress cache plugin to setup.
W3 Total Cache
W3 Total Cache is a completely different story, it is packed with features that are completely missing from Super Cache. Whilst both Super Cache & Total Cache offer page caching & gzip compression, W3 Total Cache also offers Minify for Java & CSS, Database caching & the ability to setup a CDN (Content Delivery Network) using a sub domain on your own hosting account. Add to this the fact that there is no requirement to go messing around with your htaccess file & that W3 Total Cache installs on default settings that would suit 90% of bloggers & it becomes quite apparent which of these two WordPress cache plugins you should be using!
Republished by Blog Post Promoter
No related posts.
Posted by Steve (Admin)
on Jan 29 2012. Filed under Wordpress Plugins.
You can follow any responses to this entry through the RSS 2.0.
You can leave a response or trackback to this entry
I switched from Super cache to W3 Cache and noticed a dramatic increase in performance, thanks
I do apologize Frederick,
it would seem that my capitalization of the last paragraph was taken as hostility & shouting “Sorry” it was not intended as such & is just my habit of emphasizing a point. I have edited the offending paragraph ok.
You seem to think that I am constantly having a dig at Total Cache..? yet if you read what I have actually said, I actually state that in my opinion it is the best cache plugin out there. However this does not alter the fact that it does not work correctly for everyone, which was the reason I posted the article about manual entries in htaccess files ! After all , the more options people have open to them, the better eh..?
I am not one of these idiots on the net that reads something , takes it as gospel & then plasters it all over his own site, stating it’s the best thing since sliced bread! Anything I write about, I test first on this site, that was what this site was originally designed for, a test case / guinea pig & yes there are certain aspects I have not written about, probably because I don’t feel I am knowledgable enough on that subject, to be able to advise my readers correctly.
Anyway, although I may not have mentioned it in my articles, I have minified my java script, but not my style.css as it is in a constant state of editing hahaha (I’m forever tweaking), I also setup & tried a free CDN which was an abismal failure & just slowed my site even more. I am now discussing with Timthumb creators about moving the cache folder that stores all their resized images, to the wp-contents folder,
I have an idea that if I can manage that, then the CDN side of Total Cache (using a sub domain on my own server), may well work as these images are hard copies & not created on the fly. As I mentioned previously, the problem I had when I last tried it, was the fact there was no way to tell Total Cache that there was a folder full of images tucked away in the wp-includes folder (seems a stupid place to put it from my point of view).
Oh and before I forget, Google Adsense..? Yes I would love to find some method of optimizing Adsense as it is slowing my page load by 1.62 seconds. The best I have found so far is to use a plugin called datafeeder which replace the bulky java script code with a single line of php code, but it still slows the page load times.
Regards Steve
PS can we keep any response a tad shorter or I’ll have to dedicate an area of my site solely for legnthy discussions hahaha
I’m not clear why the hostility is necessary. So I apologize, I was not trying to undermine your efforts. We both try to help the community for free and I didn’t call your views ridiculous nor start yelling. Some thoughts + facts:
- The majority of shared hosts do not allow PHP based compression, shared hosting accounts dominate the marketplace as that’s what most care to invest in. W3TC compresses *once* and caches the compressed version and sends that until it expires. Making it compatible with the majority of shared hosting accounts and freeing resources to generate pages on cache misses, when comments occur etc. The technique you’ve put forward does satisfy some tests, but it will cause your server to buckle under load, which is what I hear time and again from users before using W3TC as their hosts complains to them about CPU usage. AFAICS, a remedy for this common user affliction is not mentioned in your tutorials.
Looking at webpagetest.org for this site, I suspect that this technique is also responsible for the nearly 1 second time to first byte, which is definitely a metric that I encourage users to pay attention to. Values like ~0.2s are fantastic (this requires the page to actually be cached on the server obviously). Clearly generating a page with PHP for every visitor is slower than allowing Apache (web server) to return the page to the visitor from the disk. Why do i care? Because this value affects the total time to start render, which is where the user experience comes into play. As an aside, there are lots of plugins out there that increase response time (bad) and your recommended method of compression often causes memory usage issues for some users, coupled with the fact that PHP’s gzip compression cannot be used in concert with the “flush early technique” with is something do it yourselfers typically implement to encourage an almost instant page render in the browser. AFAICS, implementation of the “flush early” technique or advice on how to reduce time to first byte is not in your tutorials.
- On this site in particular is not a good example of this case, however, if you were like most of the sites I’ve seen, they have often more than a handful of CSS and JavaScript files that would indeed benefit from the principles you’ve shown, but once again, the principle you’ve presented is circumstantial and incomplete. Those users with multiple CSS and JavaScript files can with W3TC, minify (concatenate, remove white space, comments etc and compress the resulting files) and then cache those results. Telling users to use mod_deflate to compress text based objects upon request is also a drain on resources since there is no caching there and ultimately under load response times will suffer. Hosts sometimes have issues with these, while others will do this for you (they do the caching on their side). Mileage varies. What I know for certain is that for a site like this one, there is a positive affect realized when the JavaScript files that are not used for navigation or other essential interactivity are moved to the or at least after so that they do not have to be completely downloaded before the browser can render the page. W3TC allows users to tweak issues related to page render (and therefore user experience) without modifying theme templates. AFAICS, there is no mention of CSS / JavaScript minification in your tutorials.
- Believe it or not minification of HTML in a given page actually produces significant (10-30%) gains in the compression that is ultimately realized via the technique of page compression you suggest or that in W3TC. W3TC does this for the users transparently without breaking screen readers or AdSense targeting code etc. The point of compression is to reduce file size to improve user experience via shorter download time. With HTML often a snappier page render is realized as well. AFAICS, there is no mention of this HTML minification in your tutorials.
- One of the larger wins for WordPress is the Object Cache, it’s basically a “runtime” cache that allows WordPress to generate new pages faster. Obviously this is not something the user interacts with directly, but it and/or database caching, improve user experience on a site with high traffic and lots of interactivity and lots of newly generated pages as a result. Faster response times are proven to make web sites more successful/profitable.AFAICS, there is no mention of how a user can implement this performance technique in your tutorials.
- Content Delivery Network (CDN) or at least increased pipelining (to improve progressive page render speed) of pages, is not made mention in of your list. Not all tools can detect every CDN, so most users fail this, but at least with YSlow it’s possible to change settings that allow users to see their true score (even if they are not benefiting from the low latency network of a true CDN). Anyway, with W3TC, you can create a subdomain on your own server (and use it) with multiple CNAMEs as well, and for image heavy or sites with lots of objects to be downloaded to overcome the max’ connection issues of browser and improve the “waterfall” download by having various types of objects downloaded in parallel to render the page faster. It seems to me the “self-hosted CDN” technique is one you could have in your tutorials as it allows users to improve page render for free, AFAICS, it’s not in any tutorials.
- This site also has AdSense, but your tutorials provide no guides on how to implement AdSense in a manner that does not block page render. That might be an interesting tutorial for your readers as it is a common affliction.
Side note: Lots of users have multiple themes today, that is one for desktop and other for mobile. W3TC allows users to optimize the above for all of those themes at once with all of the same benefits discussed above.
There are other subtleties, but these are the ones that come to mind at the moment. So I suppose the word optimized is in the end a loose term as one can look at lots of different tools in different ways to see if a site is consistent with the policies put forward by the creators of that tool. Or they can look at the various aspects of their site/server and respectively and optimize those pieces that matter to them. My plugin exists because most users need a quick fix or want to address more issues than those that satisfy test tools; what’s more there are fewer steps in deploying W3TC and achieving some performance wins than there are in DIY methods, which is why I bothered to create the plugin. You’ve made your preferences clear. Your readers may want to check out the work of Steve Souders or at least http://developer.yahoo.com/performance/rules.html for more information on some of the techniques I chose not to mention above or that were not already in your tutorials.
Great tutorials and thanks for helping the community.
“You can optimize your site however you wish, but what you have indicated that you have done follows no principles of true site optimization.”
Wow Frederick, do you often make a habit of coming out with such ridiculous statements.
Hell it must have been just pure luck that the entries I placed in my htaccess file to deal with “expires headers” & “file caching” just happened to work eh..? Oh & enabling file compression by whatever means is seen as optimizing ones site, by everyone apart from you it would seem.
Before coming out with anymore ridiculous statements, you may like to take a look at this article, http://www.my-blog-review.com/cache-plugins-wordpress/ which clearly shows the entries made in my htaccess file & at the bottom of the page also shows a screenshot of the test results carried out at http://www.webpagetest.org/ which I would think that (4 x A’s + 1 x F qualifies as optimized) especially as I reduced my site load times from 8.5 sec to an initial load time of 3.3 sec & repeat load of time of 1.6 sec (not optimized eh..?)
So thank you for your offer to optimize my site Frederick, but as I have achieved these results without the additional load of extra plugins, I’ll stick with what I have thanks.
You can optimize your site however you wish, but what you have indicated that you have done follows no principles of true site optimization. I maintain that the plugin was mis-configured for your case and I’m not really interested in arguing about it. I’ve spent a year installing the plugin and handling support requests for various types of hosting accounts and the only cases where the various degrees of options available are not a fit is when hosts are making assumptions for their users. Mileage varies, principles do not. If you want me to optimize your site we can give it a go, if not that’s fine too.
Frederick, it is not a case of insisting about anything!
At the end of the day W3 Total Cache is your plugin & as such you are bound to be biased towards it, but we both know that although it is far superior to Super Cache, it is not the answer for everybody! I myself tried both plugins on this site & eventually opted for manual entries in my htaccess file, simply because that is what gave me the best results. So if you read my articles you will clearly see that whilst I state that Total Cache is in my opinion far superior to Super Cache, unfortunately it did not work well enough for me.
No insistance, just a simple statement of fact backed up by an independant test result.
Ok, if you insist.
No Frederick, you misunderstand ! It is ” I ” that requested zlib compression to be enabled on my hosting account, my host has simply complied with my wishes.
As for there being no caching of files, I put my own entries in my htaccess file in order to cache my files & to be honest with you, this gave me a far better result when checked at http://www.webpagetest.org/ in fact if you check out the following article; http://www.my-blog-review.com/cache-plugins-wordpress/ & scroll to the bottom, there is a screen shot of my test result which shows the only thing lacking as a CDN.
Various hosts have different limitations. It’s surprising that your host wants to enable compression via PHP, which does no caching at all and adds quite a bit of load to the server. You can submit a bug submission form from the support tab of the plugin if you wish.
(Can’t seem to reply here, so replying to myself)
No, there is no way to tell it that because W3TC optimizes the HTML of your site and the timthumb cache does not update it the HTML of your page with the location of those cached files, instead it uses a PHP script to retrieve them all which is exactly why I said it’s a dated technique and impossible to overcome. I would have to add irrelevant functionality to W3TC just for this case and it would only benefit timthumb users. Instead the author can update their technique instead so users even without W3TC can benefit from the increased performance of up-to-date technique.
Actually Frederick, when I tested the plugin, it didn’t seem to matter what I did, I could not seem to get compression enabled & working and therefore my site load times suffered accourdingly.
When I uninstalled the plugin I then contacted my host & after a lengthy discussion they agreed to enable zlib compression on my account. Only then could I get confirmation that compression was enabled & working.
Well as the thumbnails generated by Timthumb are stored in a cache folder & not created on the fly, then I fail to see why they cannot be stored on a CDN.
When I tried to get it working, the problem I had was there was no way of telling Total Cache that the folder was in the “includes” directory & not where one would normally expect to find media files ie content & uploads.
I meant besides W3TC rules. If your host has the server pre-configured for compression that is difficult to check from the plugin so manual troubleshooting is required.
Timthumb is generating those thumbnails via PHP so there it is impossible to host them via CDN. The author of that plugin should be informed by it’s users that the technique is dated and no longer useful for them. (It also wastes server resources)
Yes, in fact when I used the plugin, it actually installed it’s own rules in my htaccess above the standard rewrite rules for WordPress, which was the last thing in my htaccess file.
Well Frederick,
As you ask, I found that the CDN made a total mess of my images, seems it just does not recognise Timthumb.php. Also I found that putting my own entries in my htaccess file actually produced better results than using the plugin. That said, I did find W3 Total Cache considerably better than WP Super Cache.
What problem are you finding exactly? When minifying JavaScript your gallery doesn’t work? Content Delivery Network functionality interferes? Or does your gallery not work with page caching? You can submit a bug submission form from the support tab of the plugin for tips/support.
Are your rewrite rules _above_ any rules needed by the caching plugin?
Hi Praz,
When I set this plugin up, as I recall the default settings that were pre selected worked just fine.
What exactly is it that your having problems with..? could you be more specific.
I’m currently using the W3 Total Cache and it seems powerful, but might be a little confusing for newbies. Even I’m unable to properly configure it. I’m struggling with the Browser based caching configuration. I don’t understand the Cache headers configuration.
Somebody can show some light on this?
@JK,
Yes this happens because;
1. Your host has already enabled compression
2. You or somebody else has included a manual entry in your code sheets to enable compression by using php.
3. There are possibly entries in your Apache htaccess file already enabling compression.
The problem occurs because you cannot enable compression twice !
Therefore if you are unable to locate the original source of the enabled compression, then I would suggest that you disable compression in W3 Total Cache & this should sort the problem out for you.
Hi, thanks for the comparison. I just switched from WP Super Cache to W3 Total Cache, bu I got a message as
“Either the PHP configuration, Web Server configuration or a script somewhere in your WordPress installation is has set zlib.output_compression to enabled.
Please locate and disable this setting to ensure proper HTTP compression management”.
I am totally confused as I am unable to locate it. I am on a shared server, can you help me?
Hi Kimi,
yes unfortunately some people have experienced problems with these plugins, myself included! However the majority of users do not have problems, although I realise that doesn’t help you.
I can only suggest that you try the disabling all cache & compression plugins & then try the method I outlined in a more recent post, using your htaccess file. This is the method I am now using on this site and hopefully you can see that it is working perfectly.
I have tried these two plugins, but both caused me error whenever i wanted to redirect or edit htaccess. Does anyone ever encounter this problem, or is it just me who can’t use it? lol
Thanks for sharing such a useful information. I am definitely going to use all tips.
Hey Latief, nice to see your still around, hope your doing fine.
This plugin is really help to speed your blog but not for me because I’m using theme with feature gallery content and it won’t work with this plugin.
Or you can give me your tips so I can us it on my theme?