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