Compression in Drupal 7 I am running Drupal (latest version 7.22 ) on Apache 2.2 and I have also installed Varnish (module and proxy). In Apache, I have disabled the mod_deflate module. 
Reading around the web, it seems that the options on the performance page in Drupal (aggregate css,js) shouldn't compress the css and js files. However, browsing my site and checking the http headers, I see that I am receiving "Content-Encoding: gzip". Looking at the (default) .htaccess, I see that there are some rewrite rules in order to server gziped files to those clients that can read them. So, I guess this is where the "Content-Encoding: gzip" headers come from. Also, when I enable compression of cached pages on the performance settings page in drupal, I find that even the html of the page I am requesting (as anonymous user only) is returned compressed. My questions on the above are:

1) Do the options "Aggregate and compress CSS files." and "Aggregate JavaScript files." actually compress the aggregated files or is it just that .htaccess makes them seem like gziped? Using chrome developer tools, the files seem compressed. Checking them with the developer toolbar addon in firefox, however, (Information -> View document size) they are not reported as compressed (while the html file is always being reported as such, even when I access it as authenticated user!)

2) If they are indeed gziped, where does the compression take place? Can I control the level of compression, etc somehow?

3) I am always receiving X-Drupal-Cache "MISS". I don't care much since I have Varnish installed. Yet, since I am not hitting the cache, how come I am returned a compressed html file (that is not in the cache)?

4) Is there any chance that the Varnish module messes anything up? I am accessing the website with https so as to be sure that Varnish is bypassed, in any case.

5) If I enable mod_deflate, should I leave that part of .htaccess intact? I understand that mod_deflate doesn't allow for precompression, but what if the compression is better?

6) Also, if drupal compresses on its own the css, js and html files, what is the point of enabling mod_deflate for these files?

Here is the relevant part of my .htaccess file for reference:

  &lt;IfModule mod_headers.c&gt;
    # Serve gzip compressed CSS files if they exist and the client accepts gzip.
    RewriteCond %{HTTP:Accept-encoding} gzip
    RewriteCond %{REQUEST_FILENAME}\.gz -s
    RewriteRule ^(.*)\.css $1\.css\.gz [QSA]

    # Serve gzip compressed JS files if they exist and the client accepts gzip.
    RewriteCond %{HTTP:Accept-encoding} gzip
    RewriteCond %{REQUEST_FILENAME}\.gz -s
    RewriteRule ^(.*)\.js $1\.js\.gz [QSA]

    # Serve correct content types, and prevent mod_deflate double gzip.
    RewriteRule \.css\.gz$ - [T=text/css,E=no-gzip:1]
    RewriteRule \.js\.gz$ - [T=text/javascript,E=no-gzip:1]

    &lt;FilesMatch "(\.js\.gz|\.css\.gz)$"&gt;
      # Serve correct encoding type.
      Header set Content-Encoding gzip
      # Force proxies to cache gzipped &amp; non-gzipped css/js files separately.
      Header append Vary Accept-Encoding
    &lt;/FilesMatch&gt;
  &lt;/IfModule&gt;
A start:

1) Yes.

Note: If I really want to know what is going over the line, I use fiddler (Windows).

2) See function drupal_build_css_cache() in common.inc (line 3603). You cannot influence the level but you can influence whether it compresses or not with variable 'css_gzip_compression', see default.settings.php line 432.

BTW: You do not want to influence the compression level: for compress once, use many cases, maximum compression is always the best. Transfer time and decompressing time at the client is linear with compressed document size. So a 1-time slightly increased performance hit will save a lot of network activity and client side processing in the future.

3) -

4) -

5) Compression will be better as it will be done only once and it will be done better versus mod_deflate that will compress on each request and therefore will use a lower compression level. I don't know much about mod_deflate, but I guess that if there is already a  Content-Encoding header that tells the content is compressed, mod_deflate should not touch it. But I have had cases where I got a backup file that was compressed twice, so mod_deflate might not be that smart and should  explicitly be told to do so.

6) There is no point, but there might be for other requests, especially dynamic ones, i.e. non cacheable pages. Note that only aggregated css and js and cached pages (variable 'page_compression') are compressed by Drupal. Non cacheable pages are not compressed by Drupal.