[Plugin: W3 Total Cache] Google's mod_pagespeed and W3

There will never be a final word because as I indicated above mileage varies and in the end optimizing the application “from within” the application (if you will), is the place to start. So for that reason once W3TC is tuned everything else is superfluous.

Little case study for you from last night.

A friend was working on site optimization for a relatively new and “light” blog.

He is on shared hosting and isn’t yet using a CDN (though he probably will be within the next 24 hours.

He was hovering around the 3 second mark for starting to render just using the disk page cache from W3TC which is what most reviews of the plugin cover.

He can’t really influence his time to first byte on a shared hosting plan other than to serve a static page, so he thought there wasn’t much more he could do.

I pursuaded him to dig into the minification options.

The site: https://docsheldon.com/
Webpage speed test: https://www.webpagetest.org/result/101107_AYMY/

0.857 seconds to start rendering on IE7 which is a worst case scenario.

From time to first byte to start rendering we knocked about 1.5 seconds off the load time. The remaining .5 second is due to differences in server load and time to first byte.

There are still some modest improvements to be made.

I doubt 1/1000 W3TC users have exhausted the possibilities of using W3TC.

Thanks Andy, that’s helpful feedback.

Hi,

Frederick Townes has a number of good points. In particular, mod_pagespeed will not optimize the wordpress content generation flow.

However, there are a few points I feel it’s important to comment on, but I’d like to focus on the most important of these, which is the way mod_pagespeed extends cache lifetimes:

‘Extend Cache’ seeks to improve the cacheability of a web page’s resources without compromising the ability of the site owner to change the resources and have those changes propagate to users’ browsers.

Please read https://code.google.com/speed/page-speed/docs/filter-cache-extend.html to get an understanding of how this works.

Frederick’s point, “Provide control over the caching policies themselves, which actually need to be different for most sites”, highlights the classic compromise between cache TTL and the ability to quickly propagate changes, that mod_pagespeed solves without compromising either.

This has been an incredible win for mod_pagespeed in testing repeated page views.

“Provide control over the caching policies themselves, which actually need to be different for most sites”, highlights the classic compromise between cache TTL and the ability to quickly propagate changes, that mod_pagespeed solves without compromising either.

The case assumes that the origin server is used to handle static image requests, with complete use of W3TC, that is no longer the case. W3TC provides purge options for attachments in posts to ensure that the CDN is always delivering the latest version of an attachment and automatically purges any changes to existing files. Some techiques/technologies exist for the CDN to “rewrite” the file names of objects, but implementation is non-trivial at the moment.

As for the origin, I do not endorse using the origin for static files for numerous reasons, so I have deliberately chosen not to pursue this “win” as on shared hosting (or under-powered hosting), the performance compromise realizes diminishing returns.

mod_pagespeed is still beta and had some nasty bugs.

I would not use it until those bugs are fixed. Besides that, W3TC and mod_pagespeed are 2 different worlds.

Optimizing WP is not the same as optimizing Apache.

If you run e.g. mod_deflate on your Apache there is no need to run mod_pagespeed. If you know how to code (X)HTML correctly you don’t need it at all. If you knnow how to build optimized sites (JS/CSS/Images) there is no need for mod_pagespeed.

Besides that, W3TC and mod_pagespeed are 2 different worlds.

Optimizing WP is not the same as optimizing Apache.

There you go. That’s the bottom line.

If you run e.g. mod_deflate on your Apache there is no need to run mod_pagespeed

It’s not as simple as that because mod_deflate does not cache the files it creates, it’s always compressing on-the-fly, unlike the deprecated mod_gzip. So using mod_deflate “out-of-the-box” without using W3 Total Cache for example will speed up your site while reducing the scale of your web server.

Again, it all goes back to tuning applications to “unlock” server performance – inside out, not outside in.

As I said, my friend… mod_pagespeed does not speed up WP ??

Your W3TC is doing excellent work (I can handle the problems I have with W3TC).

I just made those comments for people who don’t already know. ??

I tried mod_pagespeed yesterday on a VPS – Ubuntu SE + Apache. A rough “first feel”:

CPU usage started rising steadily. Must admit that I was quite happy with how the site was running, and added pagespeed only because I heard it compresses images. (hint, hint)

Installed, did something else for a while, saw the spike, disabled. I suppose the pages rendered fairly well, but didn’t see anything mindbogglingly amazing. Not providing any data because I didn’t stick with it long enough to generate anything reliable. Saw CPU spiking rapidly and that was that for me. Enhancements are for websites, not for crashing the servers. If nothing the defaults need to be set safer till people can configure them.

If I test/tweak, I will update. At the moment, w3tc is doing just fine

FWIW, With w3tc, apc, memcache and varnish already, I don’t anticipate pagespeed delivering miraculous improvement. The only thing remaining is the images. Seriously.

Also, I am concerned with the compression of pagespeed, though I did not test it. I have seen that some scripts don’t combine/minify happily. What will pagespeed do to them? If someone can share their experience, that would be good.

Hi NerdInProgress,

mod_pagespeed doesn’t aim for miracles; it aims for rigorous automated application of web best practices without impacting or altering your origin content or deployment flow. To the extent that your flow already exhibits the best practices, mod_pagespeed may not offer much.

However, for a large number of sites on the net, including many using w3tc, mod_pagespeed finds opportunity for improvement. For a sampling of speed-up data from the 60k web sites that have installed mod_pagespeed, please see my Google IO talk, including video & slides: https://www.google.com/events/io/2011/sessions/make-the-web-faster.html

We’d love to resolve the cpu spike. One thing that would help is some data:

• to what extent did it spike? What was the load average? Did the cpu-load impact the performance as seen from a browser?
• Was the spike transient or does it last a long time?
• You mentioned you saw the main value being image optimization. Does your site have a lot of image content? Can you give the URL to your site?
• Transient load average increases are a known issue with a cold server-side cache. However, once all the optimized images are cached the load should decay to a reasonable steady-state. Once the cache is warm (assuming it’s large enough), much more content will be purely cacheable in browser-caches and any CDNs or other proxies serving your content, thus reducing the steady-state server load. We are working on reducing the transient load issues by throttling image rewrites.
• Other causes of load in mod_pagespeed are usually related to server setup, DNS, and other networking issues associated with mod_pagespeed issuing HTTP client requests back to the same server. There are usually simple solutions to this problem and we are working on improvements that will reduce the frequency and severity of them by default. Please see the faq: https://code.google.com/p/modpagespeed/wiki/FAQ

Also you’ll get more help from the mod_pagespeed community — should you be interested in pursuing it — if you post questions at https://groups.google.com/group/mod-pagespeed-discuss or raise issues at https://code.google.com/p/modpagespeed/issues/list . I only saw this because I contributed to the thread above.

Note also that we are working on adding more functionality to mod_pagespeed. We recently added domain-sharding and Javascript combining. We are working on — but have not released — image spriting. Techniques that are specific to the mobile experience are also in the works — we already have in place a growing database of mobile user-agents so that we can generate content optimized for the client.

Having said this, I want to state that I believe strongly that W3TC and mod_pagespeed are complementary. There was a comment earlier on this thread that described mod_pagespeed as an alternative but that is not the intent. Clearly generating great content at the origin is the first step toward high-performance web-sites, and only benefits mod_pagespeed by forcing it to do less work.

Hey, thanks for your very detailed reply. It makes me understand things better. I am a bit leery of spikes, since I recently was harassed off a server with CPU usage as the main reason for the site to be suspended. I may have overreacted.

I will keep this information in mind, and when I have a day or two off, I will personally monitor the website when I run pagespeed and respond with more practical information.

My site is not image heavy as such nor is it a big problem, but images have consistently been one area of low score historically, since I often forget to compress. So it was tempting that this can be automated, that is all.

My site is at https://aamjanata.com There are other sites as well on this server – all running WP, but they are configured similar and perform similar.

I am amazed and appreciate that you found this post and took the time to attend this. This, more than anything else gives me the confidence to try it trusting that I can get help fast if things go bad.