Author: DOuG pRATt

This will be a boring post about a technical aspect of blogging, called HTML output compression. I’m going to tag it so that anybody else who is wondering about the same thing I was a few days ago might find it.

There’s a site called Is My Blog Working?. A little while ago I plugged in the Dograt URL and saw this.

A couple of minutes later I refreshed the information and saw this.

The difference between these two views is the loss of Gzip compression. Newer Web browsers support compressed HTML pages. This can greatly reduce the amount of data that’s sent over the Net for a Web page. There’s no point in trying to compress something that’s already compressed, like JPEG images, but anybody who’s ever turned a text file into a ZIP file knows it’s like Wonder® bread — it squeezes down to a fifth or less of its original size.

WordPress is written in a scripting language called PHP. It’s possible to have compression done within PHP, and some WordPress sites do this, but it increases the processor load for the site. Bluehost, which this site runs on, temporarily throttles back individual sites that are using a lot of processor time. Dograt.com currently shares a Web server with nearly 3,000 other sites(!), and enabling compression in PHP would invite a big spike in my site’s throttling, that is otherwise lessened by the use of a WordPress plug-in called Quick Cache, which holds onto pages that have already been viewed, so they don’t have to be created again the next time somebody asks for them.

Other WordPress caching plug-ins can enable compression in PHP, but I don’t use them because the best place for compression to be done is below PHP, in the Web server program. For many blogs, including mine, that Web server is an open-source program called Apache. Enabling PHP compression when Web server compression is already working, and attempting to compress data that’s already been compressed, slows things down and accomplishes nothing, which is why WordPress doesn’t offer PHP compression as a standard feature.

Enabling compression in Apache for a site requires an entry in the site’s Hypertext Access File, .htaccess. This can be done manually, by editing the file, or through the control panel software. In cPanel the compression feature is found under Optimize Website.

So this begs the question, why is compression not always — in fact, it’s rarely — enabled for this site? It’s because Bluehost turns off Apache’s compression feature when the CPU gets too busy, as explained by Bluehost’s founder, Matt Heaton.

http://www.mattheaton.com/?p=228

We then wrote a patch to the Apache web server (This is what serves your websites to your browser) that interfaces with our CPU protection system. This patch checks our CPU usage twice a second and if CPU usage exceeds a certain threshold then we temporarily suspend mod_deflate. When there are unused CPU cycles then it reenables mod_deflate. By implementing it this way we get all the benefits of mod_deflate with none of the detriments of excessive cpu usage causing slowdowns.

Bluehost is vastly faster, more stable, and reliable than iPower, the hosting service I was using until two years ago. Oh, there are occasional blips, like cPanel wasn’t working briefly a couple of weeks ago, and every so often the site has been offline, but for the money I’m paying I’m pleased with Bluehost.