Re: mod_pagespeed and WordPress caching plugins - WP Super Cache, Quick Cache and W3TC

1,249 views
Skip to first unread message

Ilya Grigorik

unread,
Oct 25, 2012, 3:33:00 PM10/25/12
to mod-pagesp...@googlegroups.com
Hi Vivek. 

We don't have specific guides for those plugins, but a couple of suggestions:

WP Super Cache and a few others cache and compress the files (gzip), and then feed them to the server. With mod_pagespeed, we can decompress and recompress, but that's duplicate work.. So one specific suggestion would be: disable gzip compression in these plugins, but make sure that you have mod_gzip or similar configured on your apache server. 

The general workflow is:

Let WPSC, or similar plugin cache the PHP output, then let mod_pagespeed apply its content and asset optimization filters, and then let Apache run its gzip compression at the end.

Ilya

On Wed, Oct 24, 2012 at 5:55 AM, OC2PS <vi...@csillamvilag.com> wrote:
Now that mod_pagespeed is in 1.0, please can someone help me understand the best cache and configuration for WordPress?

mod_pagespeed is great, but it obviously can't optimize the script itself, which is where a WordPress caching plugin comes in. Should I use WP Super Cache, Quick Cache or W3TC? And how should I configure the plugin so as not to break anything, esp w.r.t. PageSpeed

Bryan McQuade

unread,
Oct 25, 2012, 3:37:05 PM10/25/12
to mod-pagespeed-discuss
Yep, what Ilya said. One small addition: If you are using Apache 2.x, mod_deflate is the module you want to install to enable gzip compression. mod_gzip was the Apache 1.3 module, IIRC.

Joshua Marantz

unread,
Oct 26, 2012, 9:25:06 AM10/26/12
to mod-pagespeed-discuss
I thought one of the WP plugins might have compressed in the plugin itself and cached the result.  I don't remember which one. This caused problems for mod_pagespeed when it was initially released 2 years ago, because it was trying to parse the gzipped stream as HTML and wasting a lot of time & log space reporting syntax errors.

I think, compounding the situation, that plugin wasn't properly setting the Content-Encoding header.   This led to a fix a long time ago where mod_pagespeed would sniff content for HTML (first non-whitespace character a '<') to minimize the chance it would try to parse non-HTML from an upstream filter.

Now mod_pagespeed will silently ignore content that is not identified as being gzipped but appears not to be HTML.  It will gunzip and optimize gzipped HTML when the proper header is there, but that's not ideal either as an extra gzip/gunzip step is done per request.

-Josh



On Fri, Oct 26, 2012 at 9:08 AM, Hans van Eijsden <hans...@gmail.com> wrote:
Well, as far as I know, when you enable compression in W3TC, it only adds a mod_deflate section in .htaccess. A good thing I think, because then there's still only one stage of compression.

Op donderdag 25 oktober 2012 21:33:41 UTC+2 schreef Ilya Grigorik het volgende:
Reply all
Reply to author
Forward
0 new messages