WP Super Cache and mod_pagespeed

So I finally got a chance to try mod_pagespeed on this server. I particularly wanted to know if it behaved well with WP Super Cache as I’d read reports that it causes problems.

Unfortunately those problems are real but I’ve been told that a new release will be out shortly to address a few bugs so perhaps this will help.

If you’d like to try mod_pagespeed make sure you disable compression in WP Super Cache and clear the cache first. Even though the docs state that the module always generates uncompressed HTML it appears to do the opposite. In fact, it tries to load mod_deflate:

When things were working, supercached files were processed by mod_pagespeed correctly, I noticed inline Javascript was modified to remove whitespace and I presume other changes were made too but I already minify things and have static files off on another domain so perhaps the changes made on my pages are less minimal.

The changes made by mod_pagespeed, like minifying inline Javascript, are not cached by WP Super Cache so your server has to make these changes each time a page is served. I know that mod_deflate does not cache the gzipped page content, but zips up the page each time it’s served. Mod_pagespeed does however provide a caching mechanism so there’s a good chance those changes are cached there. I haven’t looked at the code so I don’t know.

I did have problems with dynamic pages. A simple phpinfo() refused to load quite often, and backend requests sometimes became stuck. Load on the server sky rocketed occasionally, usually when the module cache directory was emptied.

For now I’ve turned mod_pagespeed off but that might change as this is a young project and maturing fast! I’ll update this post whenever this happens.

Related

31 Replies to “WP Super Cache and mod_pagespeed”

I had a high server load problem with my blog on the 6nov and after checking I found that WP Super Cache might be the problem because it keep saying something was wrong with my MOD (something which I did not understand) so I removed it.

Do you have the exact error message? I presume it was something about mod_rewrite or one of the other Apache modules. That’s an issue for your server administrators as the module dependencies haven’t changed in years.

Perhaps they changed something around the same time you upgraded the plugin?

I cannot remember what was the exact error message but I can confirm it did say something like MOD rewrite was not working (I am not an IT expert as you can see from my blog). I will wait for an upgrade before trying WP Super Cache again as I dont want my host provider to shut me out again.

I looked it over, wasn’t all that excited about it.. unless it matures a lot I doubt I will do anything with it. I already do all of the things needed for optimization so I see no need to add another layer to the process that will likely just confuse things.

Here is another question. If mod_pagespeed were created by some random guy named Jim in his small 3 man shop somewhere in Utah and was identical to what it is, would it get the same attention it is because it is a Google product?”

Hi — great discussion. Thanks for giving mod_pagespeed a shot. We are trying to improve it based on this early feedback. In particular, please try our latest update to fix the high server load and general stability issues.

A few answers to questions raised in this article and the comments follow:

We will add support for WP Super Cache — it’s delivering gzipped HTML to downstream filters without marking it as gzipped. In the meantime, many users have pointed out the workaround of turning compression off in WP Super Cache. We added that to the FAQ. We believe mod_pagespeed complements the functionality of WP Super Cache and would like to interoperate better.

Donncha is correct; our doc has a bug in it; now reported as Issue 52.

All resource transformations, such as image compression and minification, are cached by mod_pagespeed so that the Apache server doesn’t have to recompute them on every page view. Server load can still be improved however, and we will be working on that in the coming weeks.

Joshua – thank you so much for commenting! I’ll give the new version a go today and update my post. I made the title of this post as neutral as possible because I know projects like this move at such an astonishing rate.

One final question – is the compressed page the module creates cached by it? If not, can mod_deflate be disabled by a configuration flag so Supercache can create a compressed copy of the page once and then serve that?

I totally agree with you that the module complements what Supercache does so I’m really excited to see the day when it’ll work perfectly!

To answer your question, mod_pagespeed does not currently cache the compressed HTML. It does cache compressed images, minified JS and CSS.

We will explore the benefits of adding HTML caching as well. Some HTML is generated dynamically and might not benefit from caching, but for static pages this could have a performance benefit for the end-user plus server load reduction.

i tried the new package of mod_pagespeed today morning (german time) – and it works. optimizing images, extend_cache works good but the page(s) are slower than without and yslow gives a lower rating finally.

if i activate filtes like js / css opti. and rewriting apache works for some minutes and then again, too much processes for my little apache. i relly admire pagespeed mod for apache and i know its just a question of time that it really improves the most setups. so i can wait and look forward.

We’ll sort out the remaining server load issues as quick as we can. Could you possibly provide a link to your site? You don’t have to enable mod_pagespeed on it; we’re happy to look at your unmodified site.

Rewriting Images (and size) work as filter, even extend_cache does is job, but with filters like js / css rewrite or even whitespace removal apache goes down somehow and the speed lags (request..). if i really put the core_filter(s) in (activate it) apache goes down (requests) after 10 seconds? 😉

i`m not sure. still it could be my faul in the configs somehow and after all the years i sure have a strange and chaotic setup on some vhosts.

today moring i played with the new mod_pagespeed build and it works with image opti. and extend_cache, but yslow and under chrome and FF i recognized its slower than without pagespeed modul. thats why i have turned it off at the moment.

i compiled mod_pagespeed yesterday again and it works without an problem with extend_cache and image fliters. Only if i use filters like js or css stuff apache goes down. it`s still not perfect but with the 3 filters (img suff and extend cache) it works.

Thanks for checking this out, Donncha. I got excited too at first, but then read into it and saw all the problems people were having in general, and saying it was slowing down instead of speeding up their server. Stay away for the time being, will maybe check back in 1/2 a year or so.

i ve got the same experiences with mod pagespeed.. finally its slower than w/o mod_pagespeed. its nice to have images rewritten and so on, but it does not make the site running faster by now. tested with apache benchmark, yslow and so on. IÂ´m not sure why but pagespeed can truley slow down things – a lot of apache processes can happen and so on.

so i turned it off by now because optimation on serverside / vhosts without mod_pagespeed seems better to me.

to wp super cace

i tried the cdn option but die result was, that link to posts were rewritten to and didn`t work anymore.

Chris – thanks for testing the CDN functionality! It’s bizarre that your post URLs get rewritten as it’s working fine here and I have the same permalink structure as you.
You could try the original plugin, OSSDL CDN off linker. It shouldn’t conflict with Supercache but it shares the same settings.

i tried the nightly from wp super cache on http://www.sarsura-syrien.de (blog from girlfriend..) and there it happend.. the permalinks get rewritten. Do you think i should update them after changing cdn settings? i could try it, of course 😉

thanks for you tipp i will try the plugin after playing around with your new feature in wp super cache 😉 thank you very much for your answer, Donncha.

the â€œ.php, .htmlâ€ helps, it works now. will upload the new svn file, too. now it works without any problem. really great. now i have to figure out how the vhost for the cdn should look like.. expires, cookies and so on hm.

I have installed the mod_pagespeed to one of our servers and am VERY pleased with the results. One of our clients has a large wordpress site and even with best practices implemented was taking to long to load. This mod literally off seconds and the site is loading like a champ. I want to Install it on my other servers; however, there are many legacy sites running PHP4 and http 2.0 on them. Does anyone know if this mod would effect them adversely? Appreciate the input and good post!

I’d think you’d need to work on moving them over to php 5 and apache 2.2 or at least look at mod_security etc as they really are legacy! http://php.net/ChangeLog-4.php (at least 2.0 apache is still active).

To be sure there are still issues to fix but we’ve also just done a new release that fixes the most important ones. We hope the wp-super-cache community will try it. Please be sure to turn compression off in wp-super-cache as that will prevent mod_pagespeed from rewriting the page. The HTML will be compressed downstream of mod_pagespeed by mod_deflate.

RE image-optimization in Apache — the cost will not be as high as I think you’re thinking. mod_pagespeed caches the rewritten images and only re-analyzes based on the origin TTL. So if you set your origin TTL at 1 day, then the behavior will be exactly you recommend.

We believe any of the speedups from mod_pagespeed being reported on the web are due to images. mod_pagespeed is not black magic: everything it does can be done manually; it’s just a lot easier to do it automatically.

The Golden Compass
First of a three part fantasy/sci-fi series. Some people hate it because of it's anti God message but it's a great read. I found it hard to put down. There's even a Snopes article about the film adaptation.