Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I heard that static contents like CSS and JavaScript can be better delivered in GZip format. And Content Developer Network (CDN) always does so.

However I don't understand how the format works. First when I tried making a gzipped file via command-line. The file extension is .gz. This is different from .css and .js. How do browsers recognize which file is gzipped or not.

Second, how browsers "decompress" files? I dragged my index.html.gz onto my browsers. But no one worked.

  • How do such gzipped work in the real world?
  • What do I need to do if I want to serve CSS/JavaScript using Gzipped format.
share|improve this question
up vote 4 down vote accepted

The gzipping you're talking about is invisible to the end user, and for that matter, to you as a developer. It's taken care of by your web server, and the client's web browser.

For IIS, you need to enable the GZip ISAPI extension (check around on this site for a how-to), and for Apache it's mod_deflate.

When the web browser has completed its request, but before sending it out into the wide world, it will gzip the content and put a special header in, so that the browser knows the content is compressed.

When the web browser receives the response, it then unzips the data, and reads the file. This is completely transparent to the end user.

You usually only want to use GZip on text files. There's no point in using it on images, as images are already heavilly compressed.

I noticed a drop from 90Kb page size (load time of approx 1 second) to about a 5Kb page size (load time, .4 seconds) when enabling GZip on all static content (CSS, Javascript, etc).

What you would find if you watched the packets with Wireshark and re-assembled them, you would request /index.html, but the webserver would fetch /index.html, GZip it into /index.html.gz and send it off. Yhe web browser knows this and unzips it so that it's back to /index.html, so when you go to View Source you see /index.html, not /index.html.gz

share|improve this answer
Acutally no for IIS - no ISAPI extensions on at least recently current versions (IIS7+). Turn on Content Compression for static and optionally dynamic content (the first for files, the later for generated content). These are - like all IIS functionality in 7+ - optional installs. Make sur ehey are installed. – TomTom Mar 12 '10 at 7:09
True. For IIS 6 it's an extension – Mark Henderson Mar 12 '10 at 10:18
There are some web servers that allow you to pre-zip static files using gzip, and then serve those files directly without having to wait on compression if the client's request includes an "Accept-Encoding: gzip" header. For instance, the nginx "gzip_static" directive does this. You also need to leave the "uncompressed" version behind for clients that don't support compression (almost all do, except if they are going through a crappy antivirus or security proxy that strips the Accept-Encoding header). IIS 6+ actually automatically caches compressed versions of static files to the same effect. – rmalayter Sep 30 '10 at 13:27

Generally Gzip compression of static content from a web server is done via Apache mod_deflate

This is usually only done with text files in the formats of text/plain, text/html and text/xml, it can be done with other plain text content types (css, js etc) but that can cause issues with early versions of internet explorer. (edit:aparrently v6 and below)

Images should be compressed already in what ever format they are stored in, so there should be no additional (ie mod_deflate) compression applied to those.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.