I have a pretty big JavaScript file here which I want to embed into my website.
The HTTP server is smart enough to GZIP the file before delivering it to the browser.
However, I tested with Google Chrome and Safari.
On Chrome, it works very well. 400K go down compressed to around 100k:
BUT on Safari compression doesn't work:
The funny thing is, in gz2b.png you can clearly see that content-encoding is set to "gzip".
Note: I already read up on a GZIP-Bug in Safari where files cannot end on ".gz" or Safari won't accept GZIP. Since my file does not end on .gz this problem shouldn't be an issue.
The HTTP headers sent to Safari say it's compressed (It has the Content-Encoding: gzip header, and it says the Content-Length is 119406 bytes) - I'd trust those more than the bold number saying 430.61 in Web Inspector. How it determines both those numbers in the top column, , I don't know.
You can get verification on how many bytes is going over the wire if you sniff the HTTP request with wireshark.
I've run into this problem as well, while trying to optimize the load time of a website on iOS7 Safari mobile iPad.
- Encoded = uncompressed filesize, from server
- Decoded = uncompressed filesize, locally
- Transferred = uncompressed file size + headers sent and received
- Content-Length = compressed file sent, from server
Safari chose a really weird way of representing these numbers in their debugger.
This is a while ago but I just came across a very similar issue or maybe the source of this issue. When you compress data with gzip for safari like this:
gzip jquery.min.js
You will end up with a jquery.min.js.gz which will fail in Safari even when correctly specified as gzip encoded file stream and also when renamed to jquery.jgz as mentioned in a lot of other threads about this issue. This seems to be because the filename is encoded in the gzip file.
If you encode a gzip file like this:
cat jquery.min.js | gzip > jquery.jgz
Then you will have a file that is a few bytes smaller and does work flawlessly with Safari.