JavaScripts gzipped but not sent gzipped

Discussion in 'Bug Reports' started by pcguru, May 11, 2006.

  1. pcguru

    pcguru New Member

    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.
  2. xing

    xing LiteSpeed Staff

    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.
  3. pcguru

    pcguru New Member

    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!
  4. andrewbevitt

    andrewbevitt New Member

    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?
  5. xing

    xing LiteSpeed Staff

    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.
  6. andrewbevitt

    andrewbevitt New Member

    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
  7. xing

    xing LiteSpeed Staff

    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.

Share This Page