Updated: June 10th, 2009

* Lightning Fast is a blatant exaggeration. Got you to look though, didn't it?


Whether you are a web developer or a self-hosting business owner, the only excuse for not activating compression capabilities of your web server can be that you didn't know about it. And now that you are reading this, there is no excuse left at all.

Here is how big a single page of this blog was before compression was enabled on CSS and Javascript files (computed by YSlow):


And here it is after compression:


As you see, the difference is quite substantial – almost 30% savings.

Compressing your HTML, XML, Javascript, CSS, etc pages will mean less data transferred between the server and the client which:

  • reduces the bandwidth usage.
  • provides faster page rendering which in turn leads to less user frustration, higher conversion rates, lower bounce rate, etc etc etc.

Compression is especially important for users with slow connections as every kilobyte of your code is that much more painful to them.

Compression can be very effective – you can easily shrink your text, code (HTML, XML, Javascript, CSS, etc) to 10% of the original size (of course, your mileage may vary). 100KB page that needs only 10KB to transfer? Sign me up!

So, before I talk about the solution, let me describe what exactly happens when compression is turned on and how it affects older browsers that don't support it.

image Are you using jQuery?

Did you know that a minified jQuery file is 55KB? In order to achieve the advertised 19KB, you would still need to compress the .js file using the methods listed here.

Compression Mechanism Explained

In order for compression to work in the first place, the web server (Apache in my example) needs to support it. This is achieved by enabling one of Apache modules called mod_deflate. The server will then be able to compress the data to the DEFLATE standard using either the zlib (also known as deflate) or gzip implementations. Yeah, DEFLATE is both the standard the one of its implementations, for those confused. I know I was. This is best described in this Wikipedia article.

The following mechanism is used:

  • the server with a compression extension enabled is able to serve either compressed (smaller) or uncompressed (larger) pages, depending on what the client supports.
  • the client (that is, your browser) sends a special header called "Accept-Encoding" listing the DEFLATE implementations it's capable of decompressing. For example "gzip,deflate".
  • the server picks the best compression supported by the client (if any), compresses the files, and sends them over to the client.
  • the client receives the compressed files and decompresses them.

Are you using a load blancer?

If you are using a load balancer, it may already be configured to compress pages that pass through it. In that case, there is no need to separately configure compression on your web servers. In fact, it should be off to save CPU.

Are Your Pages Already Compressed? Test Them!

If you are not sure whether you are already serving compressed pages or not, test them! My favorite way is by using Charles HTTP Debugger. Another option is by downloading Firebug for Firefox and installing Yahoo's YSlow or Google's Page Speed. Just look at the response headers to see if compression is on (look for the Content-Encoding header). Here are some before and after examples:

Theme CSS













Create a .htaccess file in the top directory of your site with the following contents:

# DEFLATE by type - html, text, css, xml
AddOutputFilterByType DEFLATE text/html text/plain text/css text/xml
# DEFLATE by type - javascript
AddOutputFilterByType DEFLATE application/x-javascript application/javascript text/javascript text/x-js text/x-javascript
# DEFLATE by extension
AddOutputFilter DEFLATE js css htm html xml

Alternatively, you could put these lines into your Apache config within the Directory directive.

The AddOutputFilterByType directive adds DEFLATE filters to certain MIME types. I tried to assemble some of the common ones but feel free to add more, as each server may be configured differently and give out MIME types different from mine.

You can find your own server's MIME type definitions in the file that the TypesConfig directive is pointing to (mine is /etc/mime.types).

The AddOutputFilter directive binds the DEFLATE filter to specific file extensions, just in case they are not served with a proper MIME type. Feel free to add to this list as well.


1. In order to use this whole compression/deflate/gzip business, your Apache server must first have mod_deflate enabled. Without it, you will get the HTTP 500 error (Internal Server error). You can check which mods you already have enabled by checking with the output of phpinfo() function.


In order to enable mod_deflate, uncomment the line with "deflate_module" in your Apache config file. The location of this config file is highly dependant on your system. Some examples include

  • /etc/apache2/httpd.conf
  • /etc/httpd/conf/httpd.conf
  • c:\wamp\bin\apache\Apache2.2.11\conf\httpd.conf
  • some other place where your system stores Apache config files (read the special note below for OpenSUSE).

Here's what you should have:

LoadModule deflate_module modules/mod_deflate.so

On OpenSUSE, you actually enable modules a bit differently. Go to /etc/sysconfig/apache2 and look for APACHE_MODULES=. Then add "deflate" to the list, if it's not already there.

Now, restart Apache and check the output of phpinfo() again.

2. Adding AddOutputFilter and AddOutputFilterByType to .htaccess requires such overrides to be authorized by the main Apache configuration for that directory, otherwise it will return error 500 as well. The option you are looking for is called "AllowOverride" and mine was set to "AllowOverride AuthConfig" which wasn't enough. Changing it to

AllowOverride AuthConfig FileInfo

or just

AllowOverride All

fixes the problem. You can find more info about AllowOverride here.

3. In WordPress, if you are using Google Gears (Turbo mode) for caching some core WordPress files, they will not show up compressed. That is because they're not served by the remote server but rather reside locally (think of it as permanent cache). I was very confused at first when I didn't see jQuery.js in the HTTP log and YSlow reported it uncompressed.

Are you a WordPress user?

If you are a WordPress user, don't assume WordPress is going to automatically compress your pages. In fact, as you install more and more plugins, the payload becomes larger and larger with those additional CSS and Javascript files.

You owe it to yourself and to your users to immediately enable compression on your blog.

Here is what happened after I enabled compression on this blog.





Bonus – WP Minify

For even better results, I suggest you have a look at my good friend and talented WordPress master Thaya's plugin called WP Minify. It preprocesses and aggregates all or most of your CSS and Javascript into just 2 files, thus saving on the number of HTTP requests. It also minifies content to achieve smaller size.

My blog before WP Minify:


After WP Minify:



That's all folks. Let me know if something was unclear and I'll be glad to clarify it.

A few references that pointed me in the right direction and allowed me to provide a more complete solution:

โ— โ— โ—
Artem Russakovskii is a San Francisco programmer and blogger. Follow Artem on Twitter (@ArtemR) or subscribe to the RSS feed.

In the meantime, if you found this article useful, feel free to buy me a cup of coffee below.

  • Heh I've never been able to get this to work, more than likely I have to bug my host about it. When I ran phpinfo(), I did not have a Load Modules block section like you talk about here, but I did find a couple sections where gzip and deflate were noted, one of them "HTTP_ACCEPT_ENCODING gzip,deflate ". What do you think?

  • @Joren
    Mmm, that may not be enough – try to contact your host and alternatively find the place in your configs where modules are loaded.

  • Mike

    I write the line in my .htaccess, but it compress just in the root directory and it don't compress the javascript in my other folder. why ?

  • @Mike
    .htaccess should apply to subdirectories by default. Check that no other rule interferes (from httpd.conf, for example) and that those other directories don't override compression settings.

    Finally, see if you can enable all kinds of apache logs and look for clues there.

  • I just tried the method you described earlier with the .htaccess file and it's incredible.

    I must note that it works not only in localhost webservers, at your own, but in providers webservers also!!

    My webpage's response speed increased 25-40%, without specific measurement to be made!!

    Thanks a lot Artem.

    Web Developer
    Athens, Greece

  • I enabled mod_deflate on my server, yet the HTML & JS are not being gzipped. Any ideas?

    • Brad, I looked at your site and I see that both js and css are being gzipped correctly. What made you think it wasn't?

    • Brad, depending on how you have your compression set up, you might only be compressing your content.

      But Artem said he sees everything compressed so you're probably good to go.

      • Oh, Brad and I sorted this out offline. He wasn't looking at the right place ๐Ÿ™‚

  • Good tutorial, Artem. Like you hinted at in the beginning, everyone might want to make sure that visitors to theirs sites aren't composed of a lot of people using older web browsers.

    As far as I know, anything from IE6 service pack 1 and below probably won't show your page correctly if you have compression enabled.

    I'd suggest checking your Analytics program and make sure most of your visitors aren't using these older browsers. You can also check browsershots.org to see how your site will appear to others after you set up compression.

    As an alternative and if you can't get the .htaccess code to work, you could always try enabling compressing through php.

    • Yeah, I remember doing that at first but the PHP technique only compresses PHP files and potentially only your theme file. I would still encourage one to get apache to do the work as it will apply to JS and CSS too.

  • Hi, I applied the methods and modified the .htaccess file. God, it saved me some bytes really if not many. Thanks a lot.

  • Herbie Hysteria

    I have a grade 'C' on YSlow! and it suggests using compression to increase performance. i already have supercache and p-minify but for some reason around mid-march of this year my site load time went from 2 seconds to 6, and its never come down from there

    initially, i was thinking it was a plugin i installed that resulted in the increased load time, but finding the culprit has proved harder than it seems

    thanks for the detailed post, im definately going to try this today and will report back with the results, i am 100% i can improve ,my site load time with this

    thanks again!

  • Thanks for referring to my Brightscape Blog posts Artem. You took the subject of page load time much further in an informative and useful way.

  • Gestion des Risques

    Excellent post, thanks, but I still can't compress html pages even after putting these lines in .htaccess.

  • Adrian

    Super post although I'm a tad confused. I've tried everything and still cannot compress a html page. This is more complicated than I first thought.

  • Victor

    Hello, I did not see .php listed as one of the file types to compress. Is .php files supported?

    We use that on our website.

    Thank you

    • PHP is covered by supporting compression for HTML. PHP is a server-side language that just creates HTML.

  • Will

    Great article. This may help some who are not getting compression even after enabling in .htaccess. I had the same problem and the fix was to turn on compression in my php.ini file and change from -1 to 1 for the compression amount. I am getting 77.3% compression now and went from about 8 seconds of load time to about 1.5secs.
    The problem I am having now is the same as Mike. I get compression on root level files but none of my css or js files in wordpress folder or further down in the directories are compressed. I checked my .conf file and don't see anything in there that would conflict. Any additional ideas would be greatly appreciated. Thanks again for a great article.

  • Dmitry

    ัะฟะฐัะธะฑะพ ะพะณั€ะพะผะฝะพะต. ัั‚ะฐั‚ัŒั ััƒะฟะตั€!

  • Pingback: ์›Œ๋“œํ”„๋ ˆ์Šค ์†๋„์™€ ์„ฑ๋Šฅ ์ตœ์ ํ™”ํ•˜๋Š” 10๊ฐ€์ง€ ๋ฐฉ๋ฒ• | Small Database()