GZIP compression is a method of compressing data sent over the Internet. Most servers support compression, but some servers don't turn it on by default. To check whether your server supports it, get the URL of a JavaScript file, and load it in Safari. If you inspector the resource using Developer Tools, you can see whether the file is compressed:
The 'Compressed: Yes' tells you whether the file was transferred as a compressed file over the Internet. The 'Content-Length' is the byte length of the file. Comparing this to the Encoded/Decoded/Transferred size will tell you how much your file has been compressed.
If your file is not compressed and you are running a Apache server, add this .htaccess file to the root of your folder. More server configurations to enable GZIP can be found in the HTML5 Boilerplate server config area: https://github.com/h5bp/server-configs
It looks like Photics.com is compressing JavaScript files. It’s not compressing all the files though.
I’m not sure if GZIP is good though. For high traffic sites, compressing files every time they’re requested puts more pressure on a web server. I’m not a system admin, but there might be issues for high traffic sites. Pre-Compression / Caching might be a good idea to save system resources.
I’ve been thinking about this issue. I feel like there’s a lot of room for optimization.
Hype is emerging as a solid replacement for Flash. There is one major issue that might be a problem. A .swf is a single file. A Hype project is lots of files. So, what if a Hype project was merged into a single file?
Theoretically, instead of a Resources Folder, images could be embedded as Base64. (If written as CSS class, an image could be reused but only stored once.)
So instead of downloading dozens of files, only one file is needed. Also, what if the Hype JavaScript file was customized for each project? Example… do I really need the code for every possible scene transition if I’m not using them?
A common issue I’m seeing is that people want to use Hype for advertisement. So, reducing the size of the JavaScript file would speed up loading times and reduce storage space.
For most sites, GZIP will not slow down a site. We use Cloudflare so we don't need to think about it, but only really heavy-traffic sites will see a performance hit from this.
Encoding in Base64 increases the file size, so this would slow things down. But it does make sense for really small images and icons because it decreases the HTTP connections required. I see this sometimes in CSS stylesheets where small arrows and icons are converted to base64. I'd be curious to see a comparison of Base64-encoded small images in CSS (sent using Gzip compression) compared to their non-base64 variants.
