Compressing ProcessWire output

[Michael van Laar]

For nearly all of my projects I use SmartOptimizer (to minify CSS and JS resources) in combination with .htaccess rues (Gzip compression, expires headers, ETag removel etc.) of the HTML5 Boilerplate. This combination makes speed optimization pretty easy and effective.

But there is still one thing Page Speed and YSlow criticize: The HTML page itself (i.e. the CMS output) is not compressed. Obviously the HTML5 Boilerplate .htaccess rules don’t apply here:

# ----------------------------------------------------------------------
# Gzip compression
# ----------------------------------------------------------------------

<IfModule mod_deflate.c>

# Force deflate for mangled headers developer.yahoo.com/blogs/ydn/posts/2010/12/pushing-beyond-gzipping/
<IfModule mod_setenvif.c>
<IfModule mod_headers.c>
SetEnvIfNoCase ^(Accept-EncodXng|X-cept-Encoding|X{15}|~{15}|-{15})$ ^((gzip|deflate)\s*,?\s*)+|[X~-]{4,13}$ HAVE_Accept-Encoding
RequestHeader append Accept-Encoding "gzip,deflate" env=HAVE_Accept-Encoding
</IfModule>
</IfModule>

# Compress all output labeled with one of the following MIME-types
<IfModule mod_filter.c>
AddOutputFilterByType DEFLATE application/atom+xml \
application/javascript \
application/json \
application/rss+xml \
application/vnd.ms-fontobject \
application/x-font-ttf \
application/xhtml+xml \
application/xml \
font/opentype \
image/svg+xml \
image/x-icon \
text/css \
text/html \
text/plain \
text/x-component \
text/xml
</IfModule>

</IfModule>

Even if compressing HTML output is not that critical for speed optimization, it annoys me every time I see a Page Speed or YSlow report ;-)

Does anyone know how to compress ProcessWire’s HTML output?

[ryan]

I'm not sure that I've got enough knowledge these apache directives or this compression to say for sure, but it seems like it's basically saying to compress all requests that have the indicated content-type headers. Since ProcessWire would be delivering type "text/html" it seems like that would work. But maybe Apache only does this if the request is to an actual physical file or something?

You might try this shot in the dark: add a content-type header call to the very top of your template file (before any output):

header("Content-Type: text/html"); 

If you actually need to perform the compression yourself, then that would also be possible to do by hooking after Page::render, compressing the markup in $event->return, and then stuffing it back into $event->return. However, I'm still thinking that it seems like we should be able to get Apache to do this for you... just a matter of determining how. I have a feeling someone else here will know how to do this.

[Michael van Laar]

header("Content-Type: text/html");

… doesn’t work. Obviously Apache needs “real” files to perform the compression.

[netcarver]

I might be remembering this wrong from my deep past of playing in the mirky bowels of output buffering in PHP but I think you can do it by either adding something into php.ini or by setting up your output buffer to use gzip.

Check out ob_gzhandler().

Edited October 3, 2012 by netcarver

[jacmaes]

Michael, are you talking about minifying or compressing?

I can confirm that the HTML output (along with my js, css, and svg files) from PW is correctly compressed with the following line in my .htaccess, which is basically a shorter version of the code from HTML5 boilerplate quoted above:

<FilesMatch "\.(js|css|html|htm|php|svg)$">
SetOutputFilter DEFLATE
</FilesMatch>

The issue might be with your server then. You can double-check what's gzipped here: http://gzipwtf.com/

[Michael van Laar]

Problem solved. I just included the following line at the very beginning of my templates:

<?php ini_set("zlib.output_compression", "On"); ?>

Update: Don’t use this code. I just noticed that it made ProcessWire output the whole template content two times, one underneath the other. This is not intended.