JavaScripts gzipped but not sent gzipped

[pcguru]

I don't know if browsers support getting javascript files that are gzipped, but they should?

I have this in Web server admin under "GZIP Compression Tuning":
Compressible Types: text/*
Min Static File Size (bytes): 300
All text files should be compressed then (have none smaller than 300 bytes. =))

The css files I have are included in html like below and that works beautifully. A static .lsz-file is created and according to http://www.websiteoptimization.com my css-file is of size 2KiB, it's 25 KiB uncompressed.

<style type="text/css" media="screen"><!-- @import url(/style.css.php?lang=SE); --></style>

The js files I have are included like this:
<script type="text/javascript" src="/js/functions.js"></script>

Javascript files do not get the static .lsz-file and their size through websiteoptimization matches the original size.

I tried adding this to admin:
Compressible Types: text/*, application/x-javascript

Now .lsz-files are generated for the js-files, but websiteoptimization still reports the original size.

 

[xing]

pcguru, unfortunately we cannot reproduce this problem.

1) Verify that permissions are set to the folder containing the javascripts so litespeed can write to it: for the .lsz files.

From your post, it looks you don't have any permission problems.

2) To verify compression, there are two quick ways via Firefox.

A) Use FireFox, clear all "Tools >> Clear Private Date". Make sure "cache" is checked. Then reload the browser to the script url and check "Tools: Page Info". The KB line shown is the size of the script. Compare the size with the size on server to see if wether Firefox received compressed format. If not, the size line will show the same value as that on server.

B) Even easier, install Firefox's "Live Header" extension and it will display the http headers of requests. You can verify compression by viewing those headers directly.

 

[pcguru]

https://www.XXX.com/style.css

GET /style.css HTTP/1.1
Host: www.XXX.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3
Accept: text/css,*/*;q=0.1
Accept-Language: sv,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 30
Connection: keep-alive
Referer: https://www.XXX.com/
Cookie: PHPSESSID=XXX

HTTP/1.x 200 OK
Content-Encoding: gzip
Vary: Accept-Encoding
Server: LiteSpeed
Date: Fri, 12 May 2006 07:10:06 GMT
Content-Type: text/css
Content-Length: 3792




https://www.XXX.com/js/functions.js

GET /js/functions.js HTTP/1.1
Host: www.XXX.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3
Accept: */*
Accept-Language: sv,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 30
Connection: keep-alive
Referer: https://www.XXX.com/
Cookie: PHPSESSID=XXX

HTTP/1.x 200 OK
Server: LiteSpeed
Date: Fri, 12 May 2006 07:10:06 GMT
Accept-Ranges: bytes
Etag: "e12-4420404f-13b27"
Last-Modified: Tue, 21 Mar 2006 18:05:03 GMT
Content-Type: application/x-javascript
Content-Length: 1314
Content-Encoding: gzip
Vary: Accept-Encoding
Cache-Control: max-age=604800
Expires: Fri, 19 May 2006 07:10:06 GMT


The size 1314 is the compressed size so you are right, it seems to work, even though the order of the headers are different. That shouldn't matter anyway. Perhaps websiteotimization just don't accept gzip/deflate on js-files!

Firefox doesn't show js-files in the media-tab of page information. And it doesn't show size anyway when sent over https so I'm gonna trust the headers here, thanks for the plugin tip!

 

[andrewbevitt]

As a note for future reference. When I had the content types like this:
text/*
application/x-javascript

Only text/* content was compressed. Changing the content type field to:
text/*, application/x-javascript
fixed the problem.

To Developers:
Other configuration values that use text areas generally accept one value / line - perhaps this one should be the same?

 

[xing]

Andrew,

There is no right way or wrong way to do it. All our multi-item fields are comma delimited. Others like newline, we think comma is much more fool proof especially with people doing a lot of copying and pasting now-a-days.

We also have contextual help for each item so click on the help button on the page you are editing to see the proper/accepted format.

 

[andrewbevitt]

I agree comma separated is a better choice .. and oops it does say it in the help .. I was half earlier when I thought it didn't -- the contextual help information is great.

The reason for replying is to question if it would hurt to consider reformating the input to replace new lines with commas? Yes it is in the documentation but replacing \n with , is easy; anyway its just a thought.

Edit: Fixed bad grammar

 

[xing]

Auto-reformatting is always possible but I think a better solution is better inform the user in the first place. Perhaps if you mouse-over the field title, or a format icon next to the field, a format/info tooltip will popup. We are always looking for ways to improve the UI experience but we prefer to the fix the underlying problem and not add-ons which doesn't really fix the real problem.