good question. my guess is that mod_pagespeed is a better choice between the two, given that it is compiled code. So, if you can install the mod, do it. I bet that W3 total cache’s performance boost, when running in addition to the mod, will be negligible (if any)…
I bet that W3 total cache’s performance boost, when running in addition to the mod, will be negligible (if any).
False.
Not so fast (no pun intended), as you can see (evidently there are scale/performance issues as it takes >8 seconds before Google’s web server responds to a request for a page that’s ~2K); things are not so simple.
If you have W3 Total Cache you do not need mod_pagespeed. Furthermore, mod_pagespeed does not:
- Optimize WordPress’ performance w/r/t generating pages/posts/feeds on-the-fly
- Integrate with any content delivery network
- Support Nginx which is a better performing web server than Apache (in this case)
- Provide granular controls for minification of HTML, CSS or JavaScript, which means that it’s quite easy for sites to be broken unless they are tuned (manually modified) for mod_pagespeed’s policies/behaviors
- Provide control over the caching policies themselves, which actually need to be different for most sites
- Preload pages from the site to cache them and allow the server to scale further
- Minify 3rd party CSS or JavaScript
- Import 3rd party images (attachments) so you can control the caching policy they follow
- Respect HTML comments used by screen readers (for the disabled) or for Google AdSense targeting for example
- Optimize respective themes, nor give you control over which user agents you show them to (e.g. mobile themes)
- Optimize progressive render performance of a given page
- Allow grouping of JavaScript files into various (asynchronously) embed locations to give more control over initial render time, which is a key factor in improving time on site and user engagement
- Respect the uniqueness of each site on the web. There are still numerous other features that have not yet been released for W3 Total Cache that a web server module cannot deliver in an automated fashion
Make no mistake, there are lots of seemingly similar solutions for optimizing web sites and what Google is doing is not actually a new thing. There will never be a replacement for optimizing the application itself and for providing granular control over the same.
In the end, if every site were the same and performance problems easy to resolve, web hosting companies would either have all applied some standard solution about 10+ years ago or all be advertising their unique solutions to this problem to differentiate themselves from the rest.
evidently there are scale/performance issues as it takes >8 seconds before Google’s web server responds to a request for a page that’s ~2K
8 seconds? It’s only 0.5 seconds with me?
For WordPress + W3 Total Cache I think you’ll not win much with mod_pagespeed (I didn’t look in detail if Google is doing some things not yet implemented by W3 Total Cache).
But I’ll surely install mod_pagespeed for my non-wordpress sites. (eg. phpBB forum, java, …) which don’t have the excellent W3 Total Cache features available because it’s not wordpress…
Wim
8 seconds? It’s only 0.5 seconds with me?
Dunno, not sure why that happened.
I tested out mod_pagespeed with W3-total-cache and after about a hour apache stopped serving pages. The same thing happened to another user testing out mod_pagespeed with w3-total-cache. I also noticed that my cpu usage and disk IO both spiked right when apache crashed.
I would be interested in hearing from others experience as well, but at the moment I would advise anyone testing the two to not assume apache will not crash eventually with mod_pagespeed.
@jeremy Winter, it would be interesting to know what your settings were for W3TC and mod_pagespeed.
@frederick
I was running mod_pagespeed as default with all corefilters enabled. For W3TC
Page Cache: Disk(enhanced)
Minify: Disk
Database Cache: Opcode – APC
Object Cache: Opcode – APC
CDN: Disabled
Browser Cache: Enabled
I can post my W3TC config export if you are looking for more details.
Well yes, that would be more useful. Also the settings for mod_pagespeed.
Interesting. Why haven’t you used more mod_pagespeed options? What does your site’s MRTG for load and transfer look like?
I tried it for a few minutes with my host (dreamhost) but I started to get some garbage code and decided to deactivate mod_pagespeed for the moment.
It is a low trafic website right now so I rather stick with W3TC for now and wait a little to see the improvements and some comments from people who actually know what their doing.
But if it helps, I would gladly turn it on again for a day and show the results.
@frederick I was using the default CoreFilter set as it is default and are “generally safe for most web pages”. The way I understand this is that the ModPagespeedRewriteLevel can be set to the CoreFilters or PassThrough setting. PassThrough simply allows you to select which filters you wish to use selectively. CoreFilters is a select set of filters that the developers thought were ready for mainstream.
Most of the other settings are actually not very important, according to the support over at the mod_pagespeed page at Google Code. You don’t have to set the ModPagespeedDomain for example.
I’m still not convinced that this problem has anything to do with W3TC, it’s more likely a bug that will be needed to be worked out with mod_pagespeed.
Oh and my load and transfer is usually fairly minimal, when Apache crashed though, I had a big spike in cpu usage (relative to normal) and Disk IO. Apparently there is to be some expected cpu and DiskIO overhead with mod_pagespeed so this may or may not have been a direct part of the problem.
*Update – I just took a look at the FAQ on the mod_pagespeed site and there is a new entry about WordPress.
I am using WordPress and my log is filled with errors and my pages are blank
Disable compression in the WordPress plugin, so that mod_pagespeed will process uncompressed HTML. mod_pagespeed automatically adds mod_deflate to the filter after running, so the optimized HTML will be compressed before serving.
I will do some testing and report back.
I disabled compress as per the FAQ, but still resulted in a unresponsive server. Mod_pagespeed just released a new version via SVN that reportedly fixes some of these bugs, but I will not be checking it out at this time. If anyone else builds the new release. feel free to share your results.
At least we can confirm the issues have nothing to do with W3TC.
If you really want to test out mod_pagespeed, pop over to the mailing list and there is a reference there for a proxy.
http://torbit.com/proxy.php
In testing a test page on my site that is fairly well configured the proxy mod_pagespeed caused a 4 point decrease in my PageSpeed 1.9 score 🙂
As in it went down from 92 to 88
As far as I can see it doesn’t give you any advantage over w3tc and the effort to set it up is far more than w3tc.
Yet is there any harm to using both? I see benefits to features in both. I’ve not encountered any errors or issues so far, but I’d just like to know what the official word is.
