Server file compression

[fside]

I've never used this, myself. But even with broadband, some say it's an improvement. In Apache, all one need do is add a few lines to htaccess, even on a virtual hosting server. Compress htm, html, css, and js. And that's it. But in IIS6, I don't know if that's possible? Does anyone know? Virtual web hosting outfits aren't always staffed by the brightest bulbs. And asking them to modify global server settings . . ?

And if I can specify compression in a specific .php file, what to do about .css or .js files, then, in IIS6? I can't name those, .php. Does anyone know? It's really the javascript that concerns me.

[cameraman]

For the javascript, google 'dean edwards packer'. For the rest, google 'iis gzip compression'.

[Achernar]

[microsoft.com...]

Found while following links from this thread:
[webmasterworld.com...]

[fside]

Cameraman, I have the 'eviled' packed version, now. Even that's a third the size, zipped up. The full file is 70K, which isn't much these days. And it's only 5K more than the zipped 'eval' version when compressed. But Achernar, it looks like the only thing for IIS6 is to have administrative privileges. You have to have your own server. It looks VERY complicated, with lots of steps. For Apache, so I'm told, a simple line in an .htaccess file is all it takes (there is overhead searching for and loading these, however, on the server side).

Of course, there's also cache control that can force reloads and slow things down. But just in terms of reducing text file bulk, I like the idea of auto-compression by the server.

[Achernar]

But Achernar, it looks like the only thing for IIS6 is to have administrative privileges. You have to have your own server. It looks VERY complicated, with lots of steps. For Apache, so I'm told, a simple line in an .htaccess file is all it takes (there is overhead searching for and loading these, however, on the server side).

I've never touched an IIS server. ;)
On apache, you must also have admin rights to enable gzip. If you want access through htaccess, the administrator must have installed the module, and allowed it to be configured by htaccess.
Usually the module is installed and enabled by default, or is not installed at all.

Regarding the IIS server, can't you get in touch with the administrator?

[edited by: Achernar at 2:24 pm (utc) on Mar. 10, 2008]

[vfoo]

Personally I use YUI Compressor. (Used to use edwards packer, but it requires a bit of cpu overhead to uncompress on client download of large files. It's certainly better than nothing however!)

I've found that gzip and YUI compressor works great together.

See: <snip>

[edited by: dreamcatcher at 3:50 pm (utc) on Mar. 10, 2008]
[edit reason] no urls as per T.O.S [webmasterworld.com].Thanks [/edit]

[dreamcatcher]

To compress your PHP/HTML output, you can pop the following at the top of your PHP files:

ob_start('ob_gzhandler');

dc

[fside]

vfoo, I don't know how to make gzip work. I placed a gzipped version in my directory, and included the rewrite rules to serve up a .gz if a .js was requested. But the .js was sent anyway. I don't know. I did get it to work in htaccess for both css and js, but by using the FILES 'tag'. But now my js is getting 'chunked', unless I precompress with something like YUI compressor or JSLint.

So this works, but sends the .js out as a 'chunks', which seems to defeat the whole purpose:

<Files *.js>
SetOutputFilter DEFLATE
</Files>

And this just doesn't work, at all:

RewriteEngine on
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{REQUEST_FILENAME}.js -f
RewriteRule ^(.+) $1.gz [L]

Neither does the add output filter line.

As for IIS, I think M$ assumes one has administrative access. But on these shared hosting servers, you're at the mercy of someone else, maybe even in a call center. And they won't know what to do, even if part of it is just a matter of bringing up a few menus and checking some checkboxes. And since I myself don't know what's going on with this, really on either server, I can't help them out.

[fside]

As for the original OP about IIS, I wonder if I'm just going to give up trying to figure it out.

I just setup on a new Apache hosted server. And I just wanted to note that I had made a mistake in the .htaccess commands. I never did get that .js for .gz rewrite substitution to work. That would have been ideal. But the deflate did work. And the addevent deflate also worked. The host was just using a different CONTENT-TYPE string or spec for javascript files. It was calling them, "application/javascript".Once I changed over to that, gzip started to work.

The problem I have now is - chunking. The response headers for the .js show - gzip. That's great. But for some reason, the time it takes to get the .js is longer than it takes for images files which are about the same size or larger. Something about the chunking. I reduced the .js file to under 50K. It didn't make any difference. The response was still coming back - chunk. And it was still hanging up a bit waiting for the transfer. I don't know.

[cameraman]

The way server compression works, it's transparent to the humans involved - you don' t have to do anything to the source files. The javascript compression is an additional step that you can perform.

I believe that what vfoo was saying is that if you use the YUI compressor on your javascript, the compressed output seems to play well with the further gzip compression that the server would do before transmitting to the visitor's browser. I don't think vfoo meant for you to manually gzip your javascript.

[fside]

Cameraman, as I understand it, one can gzip a file, upload it to the server with a file of the same name, but with the .js suffix, and something like the script I posted, previously, would rewrite things and return the gzipped file, not the .js. And the browser would 'inflate' and use it as the originally requested .js. But it didn't work. The server kept sending out the .js.

Now I do get gzip in the response. But I also get the word - chunk. And that could be slowing things down. Whatever the reason, it seems that transfer time is unusually long for a file that should compress down to about 20K. It seems like the entire thing is being served, and even more? Here's an example response:

One of the .jpg files:

HTTP/1.x 200 OK
Server: Apache/2.0.61 (Unix) PHP/4.4.7 mod_ssl/2.0.61 OpenSSL/0.9.7e mod_fastcgi/2.4.2 DAV/2 SVN/1.4.2
Etag: "d4c69bfd-5fbe-a4965b80"
Accept-Ranges: bytes
Content-Length: 29510
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: image/jpeg

This goes by quickly.

The one .js file, which should compress to about 20K:

HTTP/1.x 200 OK
Server: Apache/2.0.61 (Unix) PHP/4.4.7 mod_ssl/2.0.61 OpenSSL/0.9.7e mod_fastcgi/2.4.2 DAV/2 SVN/1.4.2
Etag: "1c3c3c59-b63e-54e59140"
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Encoding: gzip
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/javascript

This seems to hold things up too long.

[fside]

I was going to modify the above, but time expired.

So, I figured it out. The rewrite rule was written wrong. But when I got it right, the browser couldn't handle the gzipped alternative. So whatever method is used I guess I'll just let Apache do it, instead of using pre-gzipped files.

This 'trick', I guess it is, was probably posted to webmasterworld at some point in the past. If so, perhaps no one remembered. But this works if placed in the .htaccess. Even the guys running the server (this particular site is on a virtual/shared hosting account) think file compression is turned off. Might as well keep them in the dark, about that. The .htaccess is in the root directory, so affects all files in all subdirectories. It compresses text, javascript, stylesheets, xml, etc:

<FilesMatch "\.(php¦html¦js¦css¦doc¦txt¦xml)$">
SetOutputFilter DEFLATE
</FilesMatch>

That will do it. That'll work. I've got a 70K .js that was shrunk down to 20K, in this way. All the .css are shrunk. And of course, the site loads up faster, particularly first time there with nothing cached!

[fside]

I'd also add that I think the advantage of this is not only that it can be set for a directory or all directories at once, as can the other methods, but that it avoids the business of content-type naming, which seems to vary a bit. Depending on the server, I've seen three different strings identifying javascript, alone, and there may be others. XML files might go by different 'types', etc. You never know.