Use WP Super Cache for WordPress speed, not W3 Total Cache
We keep coming across WordPress customer sites that have hurt their performance by switching from the “WP Super Cache” plugin we recommend to a newer plugin named “W3 Total Cache”. Unfortunately, their site often ends up being far slower after switching to W3 Total Cache.
If you care about the performance of your site, please stick with WP Super Cache unless you have a very good reason to switch. It works, and it works well.
Some people tell us that W3 Total Cache works just as well if it’s properly configured, and they may well be right — but it seems like it’s difficult to configure properly. Our experience is showing that it’s easy to get wrong, and performance ends up suffering. WP Super Cache makes it easy to get great performance.
on Tuesday, March 9, 2010 at 2:17 pm (Pacific) Ryan Downie wrote:
What is difficult about using disk enhanced mode of W3 Total Cache for page caching? Do you guys even realize it’s one of the hightest rated out of 8000+ WordPress plugins and WP Super Cache has about 15% of the features?
on Tuesday, March 9, 2010 at 9:55 pm (Pacific) Robert Mathews wrote:
>What is difficult about using disk enhanced mode of W3 Total Cache
>for page caching?
Good question! Someone should do an interface analysis to see why some people are having trouble setting it up and not realizing that it isn’t working — and that in fact they’ve slowed their pages down by having W3 Total Cache do additional work. It’s frustrating to watch it keep happening.
We’re not alone in that opinion; this page has nice graphs suggesting that W3 Total Cache actually slowed things down compared to no caching. The page says that the W3 Total Cache author suggested turning off all options except “disk enhanced mode”, making it work like WP Super Cache, which seems to defeat the purpose of installing something more complicated.
>Do you guys even realize it’s one of the hightest rated out of
>8000+ WordPress plugins
Sure, but that doesn’t affect whether we’d recommend a plugin. I can think of other popular plugins that we suggest avoiding (WP-SpamFree and FireStats jump to mind as performance problems, for example).
>and WP Super Cache has about 15% of the features?
You’re making our point for us, really.
W3 Total Cache definitely does have far more features than WP Super Cache, which is useful if you need ‘em. Most people don’t use many of the features, though, and my guess is that the extra options are confusing them… or at least distracting them from the fact that “disk enhanced mode” is what really matters in terms of performance.
I’m personally not a fan of kitchen-sink plugins that attempt to do lots of disparate things, but that’s probably just my rabid Unix philosophy getting out of hand again. If someone wants the W3 Total Cache extra features and likes the plugin, they should by all means use it.
For users who don’t need anything beyond disk caching, which is most of our customers, it probably makes sense to stick with something simpler, and WP Super Cache fills that role pretty well.
on Thursday, March 11, 2010 at 5:31 am (Pacific) Ryan Downie wrote:
As a web host, I really call into question your competence with respect to web site performance. For shared hosting environments and some themes, users have no ability to use more options because of the limitations of the hosting provider. That’s you.
In terms of performance, the plugin is not a kitchen sink approach, it simply unifies all of the best practices for sites in one place. There are countless bells and whistles that could exist that do not. The reason why you have seen the author mention using on disk enhanced is because for some themes / host combinations servers are unpowered to minify HTML. That’s no one’s fault – it’s a fact.
If a site owner cannot understand the options they need a professional to help with their problem anyway and a professional will know how to custom settings to fit their need. The plugin has a 100k FAQ and every single options is commented. With defaults being optimized in each release to lower the bar for confusion. The fact that you watch it keep happening and instead don’t put a post with recommended settings for W3 Total Cache for your hosting environment shows a complete lack of understanding of your customers needs.
As Google and other search engines put more emphasis on speed as a factor in rankings and sites contain more and more JavaScript etc, only plugins like W3TC are going to make it easier for the inexperienced to get really high performance out of almost any hosting environment. Think it through.
on Thursday, March 11, 2010 at 5:37 am (Pacific) Ryan Downie wrote:
I’ve seen numerous people complain about WP Super Cache and numerous plugins for that matter and W3TC seems to be the only thing that makes WordPress really perform and scale it. Yes WPSC is simple, but just like W3TC it does not install with it’s optimal settings, no plugins can or should. If it were not so, you wouldn’t have anything to write about in this blog.
Maybe you should reach out to the author and actually get on board with what he’s doing. After all, the more users you have using W3TC properly the more sites you can run on your hardware.
on Thursday, March 11, 2010 at 7:14 pm (Pacific) Robert Mathews wrote:
Ryan, thanks again for your comments; they’re appreciated.
We actually have a great deal of experience with WordPress performance issues. We successfully host several busy, high-profile sites that other hosting companies couldn’t handle (even on dedicated servers), incorporating changes that go well beyond normal optimization.
For now, our experience suggests that WP Super Cache is the best choice for customers who don’t need the extra features of W3 Total Cache.
This is just a recommendation for people who are interested in our opinion, of course. Customers are welcome to use W3 Total Cache if they prefer it for any reason, and we’re always glad to help make sure that whatever software they use works as well as possible. As you said, that benefits everyone involved.
on Monday, March 15, 2010 at 11:44 am (Pacific) Shahab khan wrote:
I switched to W3 total cache from super cache, i thought it would be more faster! But i think i was wrong. So i am again switching to Super cache.
on Thursday, March 18, 2010 at 9:29 am (Pacific) Frederick Townes wrote:
For posterity’s sake I thought I’d post here. In terms of speed, these 3rd party posts should set the facts straight. In terms of ease of configuration, the new release has a cleaner interface and better default options. Now that the plugin has gone mainstream there are lots of people that don’t understand what their site’s bottlenecks are or what web site optimization is.
http://loadimpact.com/blog/wordpress-load-test-part-2-amendment
http://cd34.com/blog/scalability/wordpress-cache-plugin-benchmarks/
If users following the instructions on the installation page at wordpress.org, they won’t have any of the issues that some people seem to complain about. The plugin has options for various hosting scenarios, it’s not possible for me to automatically configure everything for all cases, so a future release will employ a help wizard also, but for now W3 Total Cache (0.8.5.2) is far easier to use and continues to be the fastest. More to come…
on Friday, March 19, 2010 at 5:48 am (Pacific) Ryan Downie wrote:
Nice stats Frederick. Love the new update Frederick. As for Robert, I can appreciate that you guys have some high traffic site, but if you consider that Frederick is the CTO of Mashable.com, which is probably has the most traffic of any blog not hosted by WordPress.com’s VIP service – so he wrote the plugin to make WordPress scale and as you will see is taking feedback to make the plugin more usable for a wider audience.
on Monday, March 22, 2010 at 6:35 am (Pacific) Frederick Townes wrote:
Robert, I should also mention that the example you referred to at that site clearly says that the writer discovered his site users a reverse proxy. He goes on to say that hyper cache is his preferred cache for that reason. As you know a reverse proxy is not the standard operating procedure in most hosting environments and if he wanted he could have used database caching only functionality in W3TC to achieve at least the same result as hyper cache.
on Sunday, May 2, 2010 at 9:31 pm (Pacific) JP Hunt wrote:
There is a new kid on the block! Quick Cache (http://wordpress.org/extend/plugins/quick-cache/). I think this plugin deserves some attention. I tried WP Super Cache and W3TC and was not satisfied. Quick Cache is super easy and powerful. For example: You can set the plugin to auto cache pages based on your sitemap. How sweet? No waiting for a visitor to cache pages.
on Saturday, May 8, 2010 at 10:52 pm (Pacific) me wrote:
W3TC ROCKS POINT.
on Tuesday, June 29, 2010 at 9:16 am (Pacific) Dan Reese wrote:
Frederick mentioned that I could have used “database caching only functionality in W3TC to achieve at least the same result as hyper cache.” However, I tried all of the options and, while W3TC seems like it’d work well in some cases, it doesn’t in mine because my hosting provider uses some non-standard-but-good things to help improve performance. Frederick was great and very responsive in trying to help get things working, but W3TC just wouldn’t work well in my circumstance. I may try W3TC (and WP Super Cache) again at some point in the future just to make sure.
In the mean time, I’ve switched from Hyper Cache to Quick Cache because of a bug I was seeing (and updated my post accordingly):
http://www.danandcheryl.com/2009/12/how-to-optimize-wordpress-part-2
–Dan
on Monday, July 12, 2010 at 12:33 pm (Pacific) Vlatko wrote:
It is clear that W3 total cache is far better than any other plugin for sites rich with JS, images, massive posts/pages, huge content overall and extremely high traffic.
For example a site with a dozen of Java Scripts, 2-3 large pictures on every post, 5000+ posts could not handle the high traffic without CDN, Minifying, Compression, Page and DB caching through Memcached or APC, even on a powerful dedicated server.
So all these options are in W3 total cache. As Ryan said “it simply unifies all of the best practices for sites in one place”.
on Tuesday, July 20, 2010 at 11:43 am (Pacific) Robert Mathews wrote:
I want to take a moment and point out that although we welcome all points of view, we still disagree with Frederick, Ryan, Vlatko and the other comments saying that W3 Total Cache is a good choice for most sites.
Vlatko, you’re describing the kind of sites we easily handle with WP Super Cache, using appropriate compression and caching settings for the auxiliary files. (Plus a CDN if you’re having bandwidth problems from the large images, although that’s a rare issue we’d consider completely separate from any of the others, and not a problem that should be solved in a “caching” plugin.)
The speed difference between the two in disk caching mode is unnoticeable in the real world according to the benchmarks Frederick posted. (By the way, the person running one of those benchmarks initially had the same problem many of our customers had, which is that they couldn’t figure out how to make W3 Total Cache do disk caching.)
Either plugin, when working properly in disk caching mode, can make any site you might run on shared hosting more than fast enough to handle a Digg / Slashdot listing or any other level of traffic we’ve ever seen (we’ve handled WordPress sites with over 50 page views a second for several hours sustained). Yes, if you’re running mashable.com, you need other options. But that’s not our customers, and W3 Total Cache can’t make mashable.com run well on a single-server shared hosting setup any more than WP Super Cache can.
So what we care about in the paragraph above is “when working properly in disk caching mode”. The more we see customers using W3 Total Cache, the more we see problems where it’s not working properly. Today we found that it created nearly a million cache files that it never deleted on one site, slowing that site dramatically. I’m sure people might say that the user set it up wrong, and perhaps that’s true — but we don’t see this kind of issue happening with WP Super Cache, and we believe that’s because WP Super Cache is simpler. Simpler is better if you don’t need more features, and few of our customers do.
So our recommendation to our customers remains: all other things being equal (and they probably are), choose the simpler WP Super Cache for WordPress caching.
on Friday, July 23, 2010 at 11:59 am (Pacific) Satya Prakash wrote:
I also think there is no use of W3 Total cache. Better if you understand those then use setting in .htaccess.
I switched to it for using subdomain as cdn. So, I need to merge all data to get rid of that. So still using it.
I prefer Hyper cache or super cache
on Wednesday, August 18, 2010 at 8:08 pm (Pacific) Karl Blessing wrote:
I use WP-Super-Cache on my site which is served by the nginx webserver, the nginx precompression module in combination with wp-super-cache (which correctly using the rewrite settings so it goes straight to the cached/gzipped files when they exist) is extremely zippy especially with how well nginx serves static files directly (better than apache by far).
on Sunday, September 26, 2010 at 3:52 pm (Pacific) Rob wrote:
Thanks for the interesting article and interesting debate.
I don’t want to throw fuel onto fire but I am currently trying to resolve intermittent performance issues with one of my WordPress sites. I am currently doing research to try and resolve the issue so any thoughts would be appreciated.
The site has 8,500 articles and is running WordPress 3.0.1 on a virtual server with 1GB of RAM. I have a couple thousand visitors a day and a load of bot traffic.
I was initially using Super Cache and PHP Speedy to do JS/HTML minification and then swapped to W3 Total Cache to see if that did any better. At the moment it hasn’t seemed to have improved the particular issue I am having however up until now I have been using the “Opcode Alternative PHP Cache (APC)” because that was the recommended option for a virtual server with APC installed. After reading this article I may switch over to disk based caching for the page and minify options.
My particular problem is that for 90% of the time my server runs fine and the average load is 0.05-0.25% however at specific periods throughout the day which is usually when new content is imported the load can quickly climb upwards (highest I have seen is 150.00!)
It seems that once the load gets above a certain point of no return that’s it and I usually have to reboot to get my site back up. I ended up writing this plugin > http://wordpress.org/extend/plugins/strictly-system-check/ to inform me when this happens and I have set it to email me at work once the load goes above 2.0.
I have banned a lot of bots with 403′s using htaccess rules and I have set up future expiry rules as well. I also disabled a number of a plugins I was using such as Bad Behaviour and Chennai central as when I looked at the code they seemed to carry out a lot of database queries and other RegEx tests which seemed to outweigh any performance gain that serving a Not Modified header or a 403 to a bot/spammer might bring.
I have also tuned the MySQL DB as much as I can. Adding extra indexes to WordPress core tables and any under-indexed plugin tables as well as increasing the major buffers and making sure any query that appears in my Slow log is looked at to see if it can be tweaked.
I am pretty sure the problem is related to the fact that whenever a link is posted on Twitter at least 30 different bots will hit the site straight away (I post to 2 accounts) > http://www.cloudtesting.com/blog/2009/12/23/what-happens-when-you-post-a-link-on-twitter/ therefore if I import 10 or more articles I can get quite a spike from bots in a short period of time. I presumed that a caching system was designed for exactly this purpose but as of yet no plugin seems to cope adequately.
This sudden spike in traffic seems to make my load spike straight away from <1 to 2-5 and then if I am lucky the load will then decrease back down to normal or in 1 out of 3 times it will just carry on climbing up and up until the site freezes.
Obviously I could throw money at the problem and upgrade or pay $$$ to someone to take a look but as I am a developer of 10yrs+ I would rather get to the bottom of the problem myself and I want to at least identify the root cause to see if it can be rectified before giving up. I have only just learnt PHP/MySQL this year having spent the last decade using MS technologies so I am in no way an expert with performing tuning on LAMP.
Any thoughts or tips would be gratefully received.
Also does anyone know of a good tool which will combine the logging of server load at intervals with logging of MySQL queries and the access log so that I can see if spikes in load correlate with particular pages OR database queries being executed. I am debating about learning Perl and writing something myself but I thought I would hunt around first.
Thanks for any help in advance
on Monday, September 27, 2010 at 12:24 pm (Pacific) Robert Mathews wrote:
Rob, thanks for the interesting comment. The load you mention is a busy-ish site, but it’s by no means busy enough that something like this should happen. WordPress, with either caching plugin, should be able to easily handle this. The caching plugins are designed to handle exactly the kind of situation you’re seeing (where you suddenly get lots of requests to the same page).
Our WordPress performance page has lots of tips beyond caching plugins that are useful even to WordPress users who aren’t our hosting customers. Try everything that applies, but in particular:
We’ll also contact you by e-mail for some more info about your site in particular.
on Monday, September 27, 2010 at 7:03 pm (Pacific) Rob wrote:
Thanks Rob for your detailed reply
I do currently have myTop installed as well as 2 perl scripts e.g MySQLTuner and MySQLReport which I use to check my DB status at regular intervals. I also have sar running logging at 5 min intervals (see output below)
I changed the W3 Total Cache to use disk (enhanced) for the page cache to see it that helps.
Also turned on the “cache 404 errors” option as well as in the Rejected User Agents box changed it so that non cached pages are only served up to Googlebot, Yahoo and MSN.
A Question on caching as you seem to know how these systems work. When new articles are posted into WordPress are cached pages created there and then or is it a case of waiting until someone hits the dynamic version first before a cached version is made.
Also you mention turning off minification. Am I right to understand that this is a problem because the minification is done separately from the caching?
Surely when a cached page is created it would do the minification, JS & CSS file combining etc once? Ideally it would create the cached page whenever a new article was posted so that a cached version can be served instantly.
The reason I ask is because the problem often happens when I import articles into my blog. This seems to cause a chain reaction and I get a sudden influx of bot traffic when links are posted to Twitter. Therefore because the content/pages are brand new I am presuming that there isn’t a cached version of the page available to serve up to the visiting bots. Also because they all hit concurrently they all get their own version of the dynamic page.
If the caching was done on saving the article rather than on first visit then I would be able to serve up cached content straight away which might reduce the load issue.
I had a spike in load earlier tonight which wasn’t related to new content being added to the site. The load quickly went up from 0.14 to 54.00 before it bubbled around the 50 mark and then dropped back again on its own accord. Often this is what happens and by the time I read my site reports the system is ok.
00:00:01 CPU %user %nice %system %iowait %steal %idle
00:05:01 all 4.70 0.00 2.18 1.34 0.19 91.59
00:15:01 all 3.57 0.00 1.65 0.18 0.16 94.44
00:25:01 all 3.48 0.00 1.50 1.08 0.33 93.62
00:35:01 all 4.05 0.00 2.01 0.74 0.40 92.80
00:45:01 all 2.82 0.00 1.25 0.76 0.16 95.01
00:55:01 all 2.79 0.00 1.17 0.62 0.13 95.30
01:05:15 all 2.74 0.01 1.80 43.20 0.34 51.92
01:15:03 all 4.98 0.01 2.40 42.96 0.46 49.19
01:25:01 all 3.23 0.00 1.36 1.02 0.08 94.31
01:35:01 all 2.68 0.00 1.24 1.33 0.08 94.68
01:45:01 all 2.50 0.00 1.11 2.27 0.10 94.01
Average: all 3.35 0.00 1.58 9.04 0.22 85.81
Also I hear that MyISAM is not particularly good for JOINS therefore would changing the storage type for the category related tables e.g terms, taxonomy etc to InnoDB help speed up SELECTS. I have a lot of data in those tables and many SQL statements that make use of multiple joins.
Thanks for all your help
Rob
on Tuesday, October 5, 2010 at 10:35 am (Pacific) Robert Mathews wrote:
For anyone following along at home, we had an interesting off-list (“off-comment”?) conversation with Rob about his site, and he eventually tracked it down to a problem causing his server to run out of memory. (His server is run by another company, not us.)
He fixed this by limiting the number of simultaneous Web site connections, which can seem counterintuitive — but when your server is overloaded, sometimes it’s easier to simply reduce the work it has to do.
He has a detailed followup post with lots more info. Thanks, Rob, for posting that — it will undoubtedly help other people in the same boat.
on Wednesday, October 6, 2010 at 8:28 am (Pacific) Portugese Wijn wrote:
Thanks for this post, your conclusion is exactly what I already suspected. W3 Total Cache might be faster when configured by experts on dedicated servers but for the majority of sites that are in shared hosting environments Super Cache seems to be the preferred option.
I have been experimenting with both plugins for my WordPress site and when checking the loading speed of both my blog and the feed on ismyblogworking.com Supercache was consistently faster than W3 cache.
on Friday, October 22, 2010 at 10:36 am (Pacific) Bhagwad Jal Park wrote:
For me, W3 Total Cache has the best minification options available. My set up is such that I need my JS scripts minified in a specific order for them to work. W3 allows me to do that and also specify which part of the page to load them in. Other plugins don’t allow you that fine a level of control.
Its CDN options are also sweet and you can also use a self hosted CDN at no extra cost.
on Thursday, December 9, 2010 at 4:17 pm (Pacific) Hayden wrote:
I think it depends on the type of web sites a lot. Image/media heavy, not image heavy etc.
WP Super Cache has a solid reputation and I think many text-heavy sites who switch from it don’t really need to and my not see improvements over WPSC. Other sites benefit but its certainly not a one size fits all for either options. Consider feedback, test, research and test… don’t leap as the OP is referring to.
on Tuesday, January 4, 2011 at 7:21 pm (Pacific) Michael Aulia @CravingTech.com wrote:
Wow.. I was thinking to migrate from WP-SuperCache as I’ve heard lots of good things about W3 TotalCache. Glad I found this post and the useful comments.. WP-SuperCache has served me well for the past 2 years so I guess I shouldn’t make the change.
Cheers for the wonderful post
on Monday, January 17, 2011 at 11:58 pm (Pacific) Michael wrote:
Thanks for raising a good topic!
I’ve also seen quite a few sites slowing down after W3 Total Cache activation because of wrong settings. For sure plugin is great but should mainly be used by experts.
Interesting to read some comments arguing with the number of people using the plugin, website’s popularity, etc…
Well even if Microsoft is the most popular software distributor, it doesn’t mean all their products should be selected first. Quite a few smaller companies make better softs.
So yes it’s always better to compare and select what suits you best
on Tuesday, January 18, 2011 at 2:41 am (Pacific) dave wrote:
Ryan Downie sounds like a total d*ck head. He needs to learn how to comment without sounding like an ass . I have used both W3 Total and Super Cache . On some high performance sites which need to withstand 100K burst visits a with Memcached or APC backing, I use W3 Total, for small sites, I just stick with WP Super cache as I’ve noticed it is actually faster.
on Tuesday, January 18, 2011 at 8:58 pm (Pacific) Susan wrote:
I’m also debating between the two plugins and haven’t quite decided. I would like to believe that W3 Total Cache is better but I’m finding it easier to load the sites utilizing WP Super Cache. Now that WP Super Cache has a CDN option, I think it becomes even more attractive.
on Sunday, January 23, 2011 at 1:15 pm (Pacific) Brad wrote:
“Nice stats Frederick. Love the new update Frederick…Frederick is the CTO of Mashable.com”
OK, OK!!! Yes the plugin works alright and has many options but after almost a 1 day tests, I also got better results in terms of speed with WP Super Cache (and Hypercache). I’m not talking of milliseconds here but of several seconds quicker display!
on Monday, February 7, 2011 at 12:12 pm (Pacific) John Chandler wrote:
I do not find that either of these caches cause any noticible improvement. What should I do?
on Monday, February 7, 2011 at 5:07 pm (Pacific) Peter Loredian wrote:
Was considering using W3 Total Cache in hopes of solving a particular problem. I’m familiar with the WP Cache line of plugins and switching caching plugins on production servers is difficult. I’ll stick with WP Super Cache for the moment and try to solve my problem some other way.
@John – Looks like I caught you at a perfect time. If you have a caching plugin already like WP Cache, changing to another caching plugin doesn’t have any obvious speedups. WP Super Cache with full ‘Preload’ mode enabled and no garbage collection caches all content to the hard drive but only when people visit the page the second time as a “new user”. People who have commented or are registered bypass the plugin and see a dynamically generated page. A new user hasn’t done these things. Where the “performance” comes from is if your site starts getting hammered with requests from users who have never been to your site. The plugins are designed to avoid hitting WP as much as possible and, under load from users who are just there for a single article, the web server just pulls from the cache directly and WP nor PHP are used. But this only applies to the main content of the page (View Source). Any callbacks on the page might still be uncached.
WordPress, as you’ve discovered, requires beastly hardware to handle any sort of load. It is the reason why ISPs have been forced to create dedicated server farms just for WordPress hosting. Performance, in the sense of WordPress, is the ability to not have the CPU spike to 100%. When the CPU is at 100% or you run out of RAM or disk space, you quickly get into resource starvation issues that perpetuate themselves and brings the server to its knees such that rebooting is the only way to recover the system. A lot of people recommend nginx, php-fpm, APC, MemCached, a WordPress caching plugin, and a MySQL replication scheme with the HyperDB plugin for busy sites. I can only attest to APC and the caching plugin (WP Super Cache) for the moment. APC, even as a dynamic (.so) module, dropped CPU load by 50% for us without modifying anything else. APC is also supposedly being integrated into PHP 6, which is why we chose it over eAccelerator and xcache. We’re still not happy with performance, so nginx and php-fpm are our next deployments. Replication – using multiple servers for a single site – is the next step after that, but we are trying to avoid that as long as possible because that obviously means $$$ and significant increases in support costs.
on Tuesday, February 8, 2011 at 11:06 am (Pacific) Robert Mathews wrote:
John Chandler wrote:
>I do not find that either of these caches cause any noticible improvement.
How are you testing it? You should find that it makes a huge improvement when repeatedly accessing the same page — it should be literally dozens, if not hundreds, of times faster. (It doesn’t speed up anything the first time you visit a page; it’s intended to speed things up when multiple visitors do so.)
The way we test this is using the “Apache Bench” tool. There’s an example of this in the “Can all this really help that much in the ‘real world’?” section of our WordPress Performance Tips page.
on Tuesday, February 8, 2011 at 11:24 am (Pacific) Robert Mathews wrote:
Peter Loredian wrote:
>We’re still not happy with performance, so nginx and php-fpm are our next deployments
In our experience, those won’t make much of a difference compared to the boost you got from using any disk caching plugin. Apache can already handle well over 1,000 requests a second for the disk cached file, and PHP with standard FastCGI already gives you more than 500 requests a second for a simple “Hello World” PHP file.
The problem is commonly the load from cases where the cached file isn’t used: visitors who have commented, plugins that exclude mobile devices from the cached version, and other situations that lead to running the WordPress PHP code despite the presence of a caching plugin. Nginx and php-fpm can maybe shave a couple of milliseconds off some requests, but if the problem is that you’re constantly running WordPress code that consumes a full second of CPU time because you’re using some nifty plugins, those milliseconds will be unnoticeable.
In a recent example, we had a customer get about 500,000 pageviews within 16 hours on a WordPress blog. For this to work, they had to disable their mobile device plugin during the heavy load. About 7% of their visitors are on mobile devices, which doesn’t sound like much — until you calculate out that if you exclude those visitors from seeing the disk cached version, and if the disk cached version uses only 1/500th of the CPU time of the non-cached version, then mobile visitors are consuming about 97% of the CPU time. Disabling mobile exclusions allowed the site to handle 35 times as many visitors as normal.
After a certain point, it’s all about compromises. <shrug>
on Tuesday, February 8, 2011 at 12:29 pm (Pacific) Peter Loredian wrote:
@Robert – Yup.
PHP APC has a significant impact on performance, but our first attempt at getting it to work caused unforeseen problems. We narrowed it down to either Apache or PHP as causing the problem as we had upgraded those as well, so we had to revert back to the old setup while we formed a different strategy. nginx and php-fpm formed part of that strategy. Today, we launched nginx + php-fpm + PHP APC + WP Super Cache. The CPU (eight core Intel Xeon) was hanging around 40% to 60% consistently before. Now the CPU is hanging around 10% to 15%. In our previous attempt, WP Super Cache, by itself, didn’t make much of a difference compared to WP Cache since CPU usage was hanging around the same level. PHP APC, however, dropped usage from that 40% to 60% range down to 15% to 20%. Combining those two things with nginx + php-fpm appears to have gained an additional 5% drop (10% to 15% range). Everyone here is claiming that all pages on the site are loading significantly faster now. I still have a couple more tweaks to make that will eek out a little extra performance and leverage some nginx features that are impossible with Apache. After today, we will literally be at the limits of WordPress on a single box.
IMO, anyone going down the ‘nginx’ route is either insane, financially restricted in some significant way, or, such was our case, at wits end over a bug with the usual Apache/PHP combo that prevents adding PHP APC into the mix. PHP APC is, by far, the more sane upgrade and the critical one we were after. The 5% improvement in performance from nginx + php-fpm was just a minor bonus.
The bug we were encountering also appears to be gone. But it could still be there and there could be other bugs lurking that we haven’t found yet. But for us the effort was worth it and I can breath a small sigh of relief.
on Tuesday, February 8, 2011 at 9:32 pm (Pacific) Robert Mathews wrote:
Peter Loredian wrote
>In our previous attempt, WP Super Cache, by itself, didn’t make much of a difference
>compared to WP Cache since CPU usage was hanging around the same level
That’s very odd. Replacing WP Cache with WP Super Cache should have dropped the CPU usage by a factor of at least five on a busy site. Are you sure the disk caching was working at all? For example, you should be able to load the same page hundreds of times in Apache Bench without PHP running at all (zero CPU time from PHP)…
But anyway, you’re right about using a PHP opcode cache. We use eAccelerator, but any of them that you can get working (they’re notoriously finicky) will really help for the cases where PHP does run. On WordPress sites with lots of beastly plugins, we’ve seen opcode caches cut the remaining CPU usage nearly in half. Definitely recommended.
on Friday, March 11, 2011 at 3:37 am (Pacific) Sally Croft wrote:
I am getting an error: Warning: Division by zero in /home/stuloan/public_html/blog/wp-content/plugins/w3-total-cache/lib/W3/PgCache.php on line 436
ever since I have changed super cache for w3 cache. I cannot accept comments, nor modify, mark spam etc. What’s the solution to it?
Thanks!
on Friday, March 11, 2011 at 3:15 pm (Pacific) Robert Mathews wrote:
Sally Croft wrote:
>I am getting an error [on a site at another hosting company] ever since I have changed super cache for w3 cache. I cannot accept comments, nor modify, mark spam etc. What’s the solution to it?
You should probably contact the support staff of your hosting company, or ask on the WordPress support forums.
But more generally, if you’re having problems you can’t solve with W3 Total Cache, it probably makes sense try WP Super Cache instead — or vice-versa, for that matter….
on Tuesday, March 22, 2011 at 6:29 am (Pacific) Cari Duit Blogmaster wrote:
I am totally agreed with JP Hunt. Quick Cache deserved more attention.
on Monday, May 9, 2011 at 8:39 pm (Pacific) Tim wrote:
Hi Guys.
First off let me tell you I know sweet FA about this stuff, but I know what I know so I will say this.
I have no idea how to properly configure W3, I have just built a new site using this plugin as I normally do, and once again it gives nothing but error messages about not reading headers, it might work eventually and as mentioned above it no great shakes in the speed department.
Now then, fellow sufferers of W3 shortcomings, one hour ago I installed WP super cache, once again it is highly geeky so I just used the defaults as recommended and activated it.
WOW, my site loads like lightning, I have never had a site load like and I have nine, it is absolutely outstanding and it worked immediately, no errors.
Now all you folks know a lot more about this than me, and nuts to the guy who said if you don’t understand it hire a professional, this is what is needed a plug in that does what it should and just works, no messing around.
I know nothing but I suggest everyone dumps W3 for super cache, I am going to trash it now on all my other sites, and load super cache it’s just outstanding.
I hope you don’t mind if I bung a link in for my new site as you are no following, It should be live within 48 hours.
<a href="http://acnetreatmentszoom.com/"
Thanks guys. God bless.
on Saturday, June 11, 2011 at 6:40 pm (Pacific) samozi wrote:
are you sure this is not an ad post for wp super cache? er
You just give us the conclusion without any technical contrast between the two cache plugins.
on Thursday, June 23, 2011 at 12:53 pm (Pacific) 2046 wrote:
Here is my experience,
After couple days of fitting with W3TC It never cached the page well(if any). Even more, the CPU went twice higher and the Memory as well. Pages were not cached, the time went approximately from 3 sec to 8sec. Grate caching
Unlike WP super cache that boost up the speed twice (not more) the Memory was far better and the CPU in normal.
One thing doesn’t work, the “preload cache”(if my memory works well), might be problem of the PHP version or something don’t know.
Now I’m trying Quick Cache
it works well The CPU is way lower compare it’s predecessors Memory just fine. (One thing is interesting, you raelly have to log out if you want to see the cache in progress, second browser in log out mode doesn’t work, at least not for me.) Now, it builds the chache from XML sitemap. Will see. If nothing else I can still torn on the Super cache.
We have half of the CPU on Xeon 2.4GHZ and 1.5Gb ram (WP 3.1.3 last W3TC). The W3TC eats it all the way and all it does were logs in footer with words “status: not cached” and couple erorrs in admin screen.
might by mi fault, but ..
I would like to know a person who is able to set up W3TC right.
on Friday, July 1, 2011 at 8:24 am (Pacific) Ian.J.Gough wrote:
WOW!
After running W3TC for about 6 months and humming and raring about changing to WP super cache i finally took the plunge and WOW it’s made so much difference and the whole plugin is simple and easy to navigate and a lot easier to configure than W3TC. Great post thanks,
Ian
on Monday, July 4, 2011 at 6:47 pm (Pacific) Bruce Keener wrote:
I think this, and the linked articles, is some of the most useful performance information I’ve ever seen. Very helpful.
I have a question that relates to a specific WordPress theme. Note that I am a 62 year old retiree, and not a linux expert in any sense of the word … I can handle a few basic commands but that’s it. I say that to say this: if I misstate something herein, just note that I’m still learning.
I very much like the look of Khoi Vinh’s Basic Maths theme, http://basicmaths.subtraction.com/demo/ , and have tinkered with it a little bit. It is designed to accommodate any modern browser, and has some css that is associated with each (some css is dedicated to Chrome, some to IE, etc). The browser knows which css to use based on tags within the body declaration (such as chrome, safari, ie, ….) Browser detection is done by javascript. When I tried it out a few months back, using SuperCache in the html-generation mode (caching of static files), I noticed that the cached html depended on what browser was used in viewing a page … if Chrome was used, then the body class had a Chrome tag, even if later viewed by IE … hence, the IE browser would be seeing a page intended for Chrome.
Once I saw that I went back to using other theme(s). But, now I noticed that the Basic Maths theme is approved for use on WordPress.com and since I know they use W3 Total Cache, I was wondering if the latter might work well with Basic Maths. From what I have read above, it seems like the only way it will work with any caching plugin is to not use it in disk mode, but to use php and maybe query caching. Is that correct, or I do I think I have a problem when I really do not? I tried communicating with Khoi on this, but was not clear enough to get my point across, and I’m not sure I’m clear enough here either.
Thanks again for the very informative discussion!
on Monday, July 4, 2011 at 8:35 pm (Pacific) Robert Mathews wrote:
Bruce Keener writes:
>I noticed that the cached html depended on what browser was used in viewing a page
Hmmm. If it’s doing that, then you’re right: it’s incompatible with any page-caching plugin, including WP Super Cache and W3 Total Cache in page caching mode. And if your site’s busy, you need page caching.
I’d consider it poor design for a WordPress theme to generate different HTML for different desktop browsers in this day and age. It’s unnecessary, and means you can’t use it on high volume sites, which is a pity.
on Tuesday, July 5, 2011 at 7:18 am (Pacific) Bruce Keener wrote:
Robert,
Thank you very much … I shall not waste anymore time on it then. Shame, though, because it is such a nice, lean, readable theme otherwise.
On the use of static 404 files (and 403 and 500 and etc), should these be placed in the root directory, or within the theme directory (www.site.com/wp-content/themes/themename), or both? This is something I definitely need to do because I have a number of 404′s (some of which will go away by adding an empty crossdomains.xml file, but several won’t go away because I have deleted a lot of useless posts).
You all also mention, in http://support.tigertech.net/wordpress-performance#don8217t-run-jmp , that it pays to put the following into the .htaccess file:
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule \.(jpg|jpeg|png|gif|ico|swf|bmp)$ - [nocase,redirect=404,last]
Can I do this even though I have the following directive in my .htaccess file (and if so, should it come after my directive)?
RedirectMatch permanent ^/[0-9]{4}/[0-9]{2}/[0-9]{2}/([a-z0-9\-/]+) http://www.keenerliving.com/$1
(This redirects old urls that contained year/month/date/title to ones containing only /title … I know that WordPress prefers to see a number first, but I figured if Matt Cutts’ busy site can handle doing a /title only format, mine surely can … besides, there’s no way to switch back to the date format now).
Many thanks. Hopefully your answers will not only help me but also any others like me who are not all that knowledgable about server ins and outs.
Bruce
on Tuesday, July 5, 2011 at 10:19 am (Pacific) Robert Mathews wrote:
Bruce Keener writes:
>On the use of static 404 files (and 403 and 500 and etc), should these be placed in the root directory
If you’re using our custom error pages shortcut, then they need to go into the site’s root directory. But note that this is just a shortcut for the more complex Apache ErrorDocument directive, which lets you put them elsewhere.
>Can I [use the display real 404s for missing images trick] even though I have [redirect commands] in my .htaccess file
Yep, that works fine! All Redirect commands in .htaccess files (including RedirectMatch, etc.) are evaluated before any RewriteRule directives.
>(and if so, should it come after my directive)?
The relative order of the two doesn’t matter. Conceptually, Apache first goes through the .htaccess file checking all Redirect (etc.) commands in order. If there weren’t any matching Redirect commands, then it goes back through the file and checks all the RewriteRule commands in order, starting from the top again.
>several won’t go away because I have deleted a lot of useless posts
Using Redirect commands for the deleted URLs (to simply redirect each to the top level of your site, for example) would improve performance if that’s a concern. But if it’s just a few hits, it’s probably not worth worrying about.
on Tuesday, July 5, 2011 at 12:19 pm (Pacific) Bruce Keener wrote:
Very helpful information, Robert. Thank you very much!
on Saturday, August 6, 2011 at 9:24 am (Pacific) Adam wrote:
I thought I might as well post here.
I used W3TC for 10 months. Then I switched to WP Super Cache. I noticed a few things:
WP Super Cache is just plain faster. That’s it.
On pages that weren’t cached, those were faster as well. WP Super Cache is a much lighter plugin than W3TC. There are sooooo many queries going on when a non-cached page with W3TC is requested.
Pages don’t flash when moving to another page like they did on W3TC. The images, js, css role over to the next page. (not sure if I explained that well)
I’m not sure if I mentioned this… it’s faster.
When W3 edge cleans up that plugin and makes it lighter, maybe I’ll think about switching back.
on Monday, September 5, 2011 at 7:42 pm (Pacific) Rakesh Kumar wrote:
Yes WP-Super Cache is great for all and no need to look another one.
on Thursday, September 8, 2011 at 1:51 pm (Pacific) adrian wrote:
i agree with ryan up at the top.
if you have control over your webserver, then awesome. you can add mod_pagespeed, handcode and juggle .htaccess files and whatever the frack you want.
but if not,, then you are saddled with a lot of directives that have to be placed in a form. and that form will end up looking dorkY and difficult. total cache has done a decent job at the interface with several tabs. i agree its a kitchen sink. but then it does allow you switch off / on a micro level. no big deal.
it just takes reading and testing. real barriers indeed based on literacy and time, but not impossible barriers.
and finally, super cache largely adds nice directives in your htaccess file. the real stuff is done by the original w3-cache. so if you have control over your webserver, then awesome. you can add mod_pagespeed, handcode and juggle .htaccess files and whatever the frack you want.
a
on Saturday, September 24, 2011 at 4:25 pm (Pacific) Frederick Townes wrote:
@Adam, the latest release has ~70% reduced memory usage and as such is “lighter”. As for those that think the word kitchen sync applies, what never seems to be understood is that W3TC gives you (advanced only for now) user interface to control how you want to optimize your WordPress site and server. That’s it. Making a single tool (plugin or not) that magically tunes your site is impossible, the first step is what I did, giving the user control and providing reasonable defaults.
Again, there’s nothing more robust and complete and while mileage varies, performance still remains a subjective thing in these conversations as no one has any empirical evidence and all themes/plugin/server combinations vary (again why the plugin was made as it is). So well said @Adrian.
on Saturday, September 24, 2011 at 10:09 pm (Pacific) Robert Mathews wrote:
Frederick,
Thanks for your comments. Sadly, my negative feelings about W3 Total Cache have only increased since my original post, which is unfortunate because I really, really want there to be a wide choice of good WordPress caching plugins available.
W3 Total Cache is fine when properly configured, but far too many people continue to configure it poorly because it allows bad choices. One common example we see is people configuring it to cache database results to disk, converting what are originally zero-latency in-memory reads to high-latency disk writes. This may work on dedicated servers, but disk latency is the usual bottleneck on shared hosting, and the fact that W3 Total Cache makes some people think this configuration is reasonable is frustrating.
>Making a single tool (plugin or not) that magically tunes your site is impossible
I really disagree with that. Such a tool exists for most WordPress sites on shared hosting servers. It’s WP Super Cache.
I know you think I’m being a jerk by denigrating your hard work, but honestly, I’m tired of fixing customer sites that worked perfectly well with WP Super Cache, which W3 Total Cache then completely breaks, then hearing customers tell me they switched because they read it “has more features”, none of which they needed. (Reading comments here suggesting that people who are having these problems lack literacy skills, etc., is also tiresome.)
I called W3 Total Cache “the site killer” in a tweet that you felt was “name calling”. That’s obviously a strong phrase I used: someone called it nasty, but it’s accurate far too often. I’ve seen W3 Total Cache cause extremely high loads (yes, sometimes completely “killing” sites) in more than a dozen separate cases, when I’ve never once seen WP Super Cache cause a similar problem. In each of those cases, the site owners were convinced that they set up W3 Total Cache properly.
If it bothers you that we often see it causing problems on people’s sites, then please change it so that people can’t configure it to dramatically increase the load on their sites, or at least that it shows a big warning when they’re about to do so.
Until then… it causes problems that I have to keep fixing, again and again, wasting my time. It’s probably not surprising that I get a little more annoyed every time I see someone using it instead of the perfectly good alternative that doesn’t cause these problems.
on Monday, September 26, 2011 at 3:30 pm (Pacific) Buntu Redempter wrote:
I think the “W3 Total Cache” plugin itself slows down the website. I noticed the difference when I installed this plugin the site changed the speed automatically. I think it’s because it’s very heavy with stuff and features.
on Friday, September 30, 2011 at 5:45 am (Pacific) Mickey wrote:
I’ve been using WP Super Cache for almost a year now, and I’m very satisfied with it. I use it on both shared and dedicated servers. Though it took awhile to figure out what worked best for my setup, I’m quite happy with it. I tested W3 Total Cache for a short period and even though it seemed to perform ok, I knew that it would take some more time configuring it for my sites. For what little more that could possibly be gained from using W3TC, I just decided to stick with WPSC. You really have test and experiment to see what works best for you set up.
I also cleaned up the default .htaccess rules that WPSC writes. It has several inefficiencies. I noticed a few tenths improvement by cleaning up the inefficient WPSC rewrite rules.
For some reason minification of CSS/JS files made my sites slower with W3TC. Even with WP Minify it seemed to slow down my sites. So instead, I YUI compress all of my CSS/JS files and gzip them manually. Then via rewrite rules, I have those served to the user if their browser supports it.
Just my 2 cents, I’m pretty sure everyone’s mileage varies. Not too many servers are set up equally.
on Monday, November 14, 2011 at 5:48 pm (Pacific) Justin wrote:
[This comment has been removed by Tiger Technologies due to inappropriate language and an abusive tone. Justin, you're welcome to re-post your comment, but please: no profanity, and no calling other people names.]
on Monday, December 5, 2011 at 11:57 pm (Pacific) Happeh wrote:
WordPress Supercache is faster than W3TC. I have switched back and forth multiple times over the last year or so and it is possible to feel and see the speed superiority of WordPress Supercache.
W3TC is also trouble. On one blog that the plugin was deleted from the directives were not removed from the htaccess file for some reason. The ISP complained about server loads and two blogs were deleted to try and stop the problem.
Then the people at the ISP discovered there were lots of W3TC calls being made which didn’t make any sense because the plugin had been uninstalled. Looking in the htaccess file revealed that all of the old W3TC directives were in there with the WordPress Supercache directives.
The two blogs deleted unnecessarily are still being rebuilt. I have a really bad attitude towards W3TC for causing that problem.
For a regular joe blow with a regular joe blow website, W3TC was always slow and troublesome.
WordPress Supercache is fast and no trouble.
on Wednesday, December 7, 2011 at 6:09 pm (Pacific) Abu wrote:
I tried using W3 Total Cache but I found it too difficult to set it up correctly. It keeps giving me errors messages when I activate the minify function and it also breaks my theme CSS.
I spent a lot of time trying to find a solution but in the end I’m just the average blogger so I switched back to the good old WP Super Cache.
Super Cache is very simple, you can get it up and running with no headaches. That’s what makes it the best caching plugin for me.
on Tuesday, December 20, 2011 at 12:55 pm (Pacific) Shabir Virk wrote:
Hmm, As far as i know Wp-Super Cache is better than W3 Total Cache.
it is easy, fast and cleaner than W3TC.
I am running 4 wordpress sites on my VPS which is only have 1Gb ram and 2 CPU cores.
And my daily page views of all the blogs are 225000 a day.
And my server is running fine till date and never run out of resources and it is running under max 30% cpu load and 45% Ram.
When i tried W3TC i lost the performance of my blog and my VPS freeze,
dont know for what reason.. i configure all the settings properly.
So guys in my opinion Wp-Super Cache is far better than W3TC till date. i cant say about the future
Thanks
on Tuesday, December 20, 2011 at 12:57 pm (Pacific) Shabir Virk wrote:
and Sorry i forgot to mentioned
I move all of my static images, CSS, JAVA scripts to CDN
Which is also help me alot to decrease the load
on Wednesday, February 15, 2012 at 5:30 pm (Pacific) conualfy wrote:
Hello!
I installed yesterday W3 TC and the default configuration made it slower than without caching. I am not saying that it cannot perform fast, but in my case, with default settings, it didn’t. Then I installed WP Super Cache and soon I could see that it got a lot faster.
Actually I am writing to you because of an issue I ran into. I have problem with WP Super Cache: although the pages load, I get a 403 response on the site root. See this analysis:
http://goo.gl/sQeck
As the site loads ok, something might not work because of this (don’t know). The first thing I could see not working is the reports of Pingdom / Montastic with site uptime.
PS: I also use 5G protection for .htacces (http://perishablepress.com/5g-blacklist-2012). I removed it and still got the 403, so I would guess it is from WP Super Cache. As far as I know, the server runs suphp.
on Thursday, February 16, 2012 at 12:14 pm (Pacific) Robert Mathews wrote:
conualfy wrote:
>I get a 403 response on the site root. [...]
>I also use 5G protection for .htacces.
>I removed it and still got the 403, so
>I would guess it is from WP Super Cache
What you’re describing sounds like a “5G protection” issue rather than a WP Super Cache problem. Showing 403 errors for certain IP addresses, etc., is exactly what those kinds of “protection” plugins do.
On a technical level, it probably added rules to your .htaccess file that block Pingdom, and even though you’ve disabled the plugin, the rules are still leftover in your .htaccess file. Cleaning the .htaccess file should fix it.
on Thursday, February 16, 2012 at 8:36 pm (Pacific) conualfy wrote:
Actually I’ve removed all 5G (it is still removed) and I still get the 403 (but the site works ok and fast, it only seems to have blocked Pingdom and Monstastic uptime reports robot). Also see here a test I just finished:
http://www.webpagetest.org/result/120217_CN_34d7f01a042fb2aa32e35102619ced4a/1/details/
It first appeared when I installed W3 Total Cache, then it continued with WP Super Cache that replaced W3TC.
I disabled WP Super Cache and like magic, that 403 was gone
F.
on Friday, February 17, 2012 at 3:50 am (Pacific) conualfy wrote:
Figured it out. Everything was ok with the .htaccess and WP Super Cache.
The problem was in the parent folder, there was another domain there with a .htaccess and I inherited that file’s rules. On this ocasion, my hosting support guys reminded me that those rules are inherited
Thanks!
on Tuesday, February 28, 2012 at 12:36 pm (Pacific) TumuTanzi wrote:
How about Quick Cache?
on Saturday, March 10, 2012 at 5:45 am (Pacific) Frederick Townes wrote:
Robert, thanks for replying. As I see, the path forward is what lots of others do and simply report the bugs and work with me (the developer) to give the users what they want. Users switch to W3TC for numerous reasons and TT was the only hosting company I’ve found thus far that won’t just send me bug reports like anyone else in the open source community. Some users even send patches. It’s not my interest in creating more work for you, my interest was in increasing google page speed scores on almost any web site and allowing users to have a quick start to increased performance while being able to tune their site for the way they use wordpress and the server resources they have available – the intention is to create a performance framework. You of course are welcome to your opinions, the fact that users want something and a host rejects it for a lesser quantity is precisely why we at W3 end up doing so many hosting migrations for clients. There’s no reason why we can’t recommend TT as a company that gets it, but the communication is off topic.
We welcome your bug submissions, time spent there will be reciprocated in bug fixes.
on Wednesday, March 28, 2012 at 10:28 pm (Pacific) Robert Rowshan wrote:
Fredrick, you don’t have to look far to see blogs being killed or at least ‘maimed’ by W3TC, case in point:
“How the W3 Cache Plugin for WordPress Killed My Feedburner (And How I Saved It)”
http://katywidrick.com/2011/08/02/when-you-hear-crickets-clear-your-cache/
It is clear that caching is an extremely powerful tool that can have as much, if not more, negative consequences for a blog as it can positive ones. It is like putting a total amateur driver in the seat of a Ferrari. Sure, it looks sexy and has promise of speed but it can also be deadly.
So either build in safety measures as Robert has asked for repeatedly or make it impossible (like WP Super Cache) for the plugin to damage the blog.
We all appreciate the work you’ve put into this and I agree with Robert when he says that alternatives are great when it comes to plugins. All people are asking you to do is to be cognizant of just how powerful and therefore dangerous this thing is!
cheers
on Wednesday, March 28, 2012 at 10:39 pm (Pacific) Robert Rowshan wrote:
can anyone enlighten us what WP Varnish is referring to in this benchmark test?
http://cd34.com/blog/scalability/wordpress-cache-plugin-benchmarks/
the only thing I can think of is https://www.varnish-cache.org/ but I can’t find any sort of wordpress plugin
??????
on Thursday, March 29, 2012 at 12:22 pm (Pacific) Ken wrote:
Take a look at the list of caching plugins in the introductory text of that page. “WP Varnish” is a link — just click on it for more information, including a download. You can also leave a comment on that page if you have more questions about its content; it’s not a page that we created, so we don’t know anything special about it, unfortunately.
on Thursday, April 5, 2012 at 8:14 am (Pacific) Gurjit Singh Khehra wrote:
Hello Dear Robert Mathews,
You’re right that WP Super Cache is much simpler and better than W3TC. I switched to W3TC, but then i realized that my website’s performance was even slowed down than an un optimized website. And even i set up W3TC according to an online guide. So then i removed W3TC. So this could be very harmful for a simple blogger.
Thanks for this nice article.
on Thursday, April 5, 2012 at 8:20 am (Pacific) Gurjit Singh Khehra wrote:
And this is my Blog:
Wiki For You
I am using Genesis framework and heard that W3TC works better on Thesis than Genesis. So please check my blog and tell me if i’ve done any faults. Or recommend me a good theme…(Free is better than paid).
on Thursday, April 5, 2012 at 2:18 pm (Pacific) Ken wrote:
It looks like your blog is using W3TC now. You should check the plugin documentation, contact the plugin author, or ask your hosting company if you have any questions about the best way to configure it. (Since you are not a customer of ours, we really don’t know exactly how your server is configured and what the best setup would be.)
We’re sorry we couldn’t provide what you were looking for!
on Monday, April 23, 2012 at 2:22 am (Pacific) Pierre wrote:
I do not have any idea about what you guys are talking about here. I was using W3 Total Cache until I get errors. Please don’t ask me about the errors because I do not know how to explain it. I am just a regular guy who owns a wordpress site. The WP Super Cache works well for my wordpress blog without an error and the load time is faster again. Thanks for the post!
on Tuesday, May 1, 2012 at 1:43 pm (Pacific) Varun Bansal wrote:
Thanks for all the debate ! Went with W3 Total Cache ! It has made my page speed better on google and better indexing of posts..getting higher traffic
on Thursday, May 3, 2012 at 1:37 am (Pacific) Bartholomew Gallacher wrote:
Well, you are comparing two different approaches and technologies here, so you should really, really take care about that aside the fact this post has been around for now two years and both plugins have been under constant development since then, gained more features and matured even more.
Both plugins have their use, are mature, widespread used and well tested. Super Cache is fine if you do not want to take the burden upon you to configure a shit load of options. SC is all about caching fully rendered pages, so that’s about it in a nutshell, which is fine for 99% of your visitors anyways. It just does that, nothing more, nothing less, nothing fancy in there, also page compression builtin and other stuff.
Super Cache is a good all around caching plugin for serving static files.
W3TC is about caching in general, so it naturally does way more than Super Cache. It is able to cache rendered pages, so that‘s the same like Super Cache, but further more it can cache database queries which might come in handy if your database server is shared, misconfigured, slowly whatever, it is able to cache objects, fine tune browser settings, it has minifying for HTML, Javascript and CSS built right in and so on and on…
So, yes W3TC has for sure much more options to configure if you want to, but that‘s quite natural if you consider the fact that is also has way more features. More features is equal to more options to configure, more nuts and bolts.
So W3TC does more and yes, it takes a little bit more time to configure it, but that is definitely worth it when you need it, asides you do not need to enable all of its options if you do not want to. It is well documented, so configuring it properly is no big deal if you want to do that.
In conclusion: if you want a painless caching plugin which serves static files to take much burden of your system, take Super Cache. If you want or need more than that, then W3TC is definitely the way to go for you, since it offers so much more than Super Cache and caches more than SC. W3TC is the mother of all caching plugins in WordPress anyways.
Aside that, of course all that is situational, and there are many benchmarks around, which measured the performance of those plugins. Of course again, benchmarks are always somewhat fictional, since the are not able to mirror normal behaviour patterns very well, so the best way to go to find out which plugins suits you best is to look up who uses it, what they are saying about their experience with it and its performance.
As far as I can tell, W3TC able to speedup my own wordpress blog way faster than Super Cache and that‘s why I am going to stick around with that. Your mileage may vary.
on Sunday, May 6, 2012 at 6:14 am (Pacific) Dallas wrote:
I agree totally that supercache is a better option for 90% of wordpress users. It still really benefits from using the advanced settings and a CDN (which are easy to do).
W3 Total cache has way too many options and is geared toward people who are so techy they don’t realise how tech-ignorant 95% of wordpress users are.
The other thing which drives me crazy with W3TC is the incessant clear cache messages whenever you change your plugins etc, which take you back to the W3TC admin page. Very inefficient, and quite scary for a novice WordPress user who worries what they’ve broken.