Updated answer for 2017: Yes.
The size column in the Network tab in Chrome Developer Tools has both the compressed and uncompressed size, for gzip, brotli and whatever comes in future. Eg:
Here the compressed size is 242 KB, the uncompressed size is 1.1 MB
To see both, ensure you have Devtools showing large request rows. It's the first icon in "View" ...
Google makes reference to gzip and image/binary files at Minimize payload size
Don't use gzip for image or other binary files.
Image file formats supported by the web, as well as videos, PDFs and other binary
formats, are already compressed; using gzip on them won't provide any
additional benefit, and can actually make them larger. To compress
Yes, Amazon Cloudfront can now serve GZip'ed / HTML Compressed content to end users fairly easily. This used to be rather hard, but Amazon added this to Cloudfront around November 2010.
What you are looking for is called "custom origin". The gist of it is:
You set up your own web server, and configure this server to correctly compress content for ...
The first thing to keep in mind is that compression checkers sometimes lie for various reasons, so take their warnings with a grian of salt. As a few people have recently said on Stack Overflow ySlow is not gospel (but I do like it myself).
What I would suggest doing, rather than employing zlib.output_compression in php, is to enable mod_deflate in Apache. ...
Another way to accomplish this is with cURL:
curl -i -H "Accept-Encoding: gzip" http://someurl.com | wc -c
curl -i http://someurl.com | wc -c
The number shown after each command is the number of bytes that crossed the wire.
Download Firebug and install Google's Page Speed plugin and or Yahoo!'s YSlow plugin both of these will help you optimise around the background image.
Also read Yahoo's Best Practices for Speeding Up Your Website
You can add it to the existing .htaccess file your Wordpress creates for SE friendly URLs. If you don't have an htaccess file from Wordpress then you can create your own with the GZIP code in it and it won't break Wordpress at all.
Compress resources with GZIP
This is another one of those things where new technology is being shoved into our faces and some companies and/or tools aren't setup to handle it (such as the Google page speed insights). After looking at the new compression info, it seems only newer web browsers support it.
A large number of tools and web servers still ...
Enabling compression is almost universally a good idea. You might not save much data on very small pages, but you also won't waste very much CPU compressing them.
An even better idea, if you're trying to ensure your site is fast and reliable, is to put a caching service like CloudFlare between your users and your server. Having a good intermediary will ...
Put these lines in your .htaccess and PageSpeed Insights will see your gzip compression:
It works for my sites.
Does CloudFlare gzip resources?
Yes, CloudFlare gzips resources that pass through our network. We also gzip items based on the browser's useragent to help speed up page loading time.
If you're already using gzip we will honor your gzip settings as long as you're passing the details in a header from your web server for the files.
Interesting case, since the page is fairly simple. Firstly, I'd agree with closetnoc's comment that your page is already pretty fast - it's clear you've spent some time working on speed, so any further gains will be micro-optimizations at best. (Faster DNS would certainly help though, as you said.)
My pages are served gzipped and I flush the buffers ...
You're talking about the benefits to your bandwidth costs, but then also comparing the performance of the page load in a browser. They're two different things.
Anytime you gzip a request, something has to actually do the compression (in your case, the F5) and the client (or technically proxies) has to handle the decompression. This can add more latency to ...
This may be a problem if there is a server in between which is decompressing the content, such as a load-balancer, CDN, or proxy. If the content is sent encrypted on localhost, it will be sent encrypted to you unless there is a client in between which does not have the Accept-Encoding:gzip header in the request.
The best way to check for compression is to ...
It's a good question and there is no one size fits all answer. However with the rise of mobile networks the answer is almost always compress as much as possible. In the long run uncompressing on the client will always use less energy than using more bandwith.
Gzip is very lightweight but it can become an overkill when:
the compression level is set to too ...
Data compressed with gzip contain all the information needed to decompress the data. This means an attacker can simply decompress the data, same as the browser. So this is no more secure than plain text. And the compression level in gzip is actually irrelevant for decompression since it only says how much efforts will be done in finding common pattern in the ...
Lossless VS Normal Compression
Looks like you're getting your wires mixed, Google insights refers to lossless compression, not the JPEG encoder. jpegoptim, jpegtran, jpegrescan, mozjpeg1, mozjpeg2 and so on are all lossless compression tools, not JPEG encoders such as Guetzli.
What this means is it takes an already compressed file and makes it even smaller ...
That's exactly it - the file gets smaller because the colors are combined into fewer, more prominent colors. For example, multiple shades of blue living next to each other will combine to display as fewer, more uniform shades, in the process making the image file less heavy. Each time you run your software, it'll find places to optimize this process, though ...
Your files will be smaller if you minify them before using gzip.
Gzip isn't perfect compression. It doesn't remove remove all the redundancy that minifying does.
Gzip is lossless compression. At the very least that means it has to preserve information such as the number of indentations on each line. It may only take a byte or two for preserving that ...
Won't work with IE6 browsers, but here's how WordPress users do it.
They show you how to detect for browsers that won't work and keep an ...
The question here is why you would need to minify html, gzip should be fine on its own, the biggest single cost in front end speed is http requests at the server end and images in terms of pure bandwidth. HTML is so small it's barely worth the effort.
I would suggest using tools like Google Page Speed or Yahoo!'s YSlow (and reading Yahoo!'s research on the ...
GZIP offers superior compression in most instances, but XML sitemaps just aren't that large to begin with. I would say that you shouldn't worry about it.
Unless you have some very sizable sitemaps (ie: Approaching the 50,000 URL limit), I would say that the server's compression should be sufficient - at least to avoid the hassle of manually compressing them ...
All Gzip decompression programs can decompress any of the levels. The compression level doesn't change the format of the output at all.
The compression level is good for managing load on your server. Gzip will spend many more CPU cycles trying to compress the data better when you specify a higher compression level.
In my experience the benefits of ...
No.... image sprites are not good for photos and complex pictures.
This is because the file size would simply become far to big and would delay the page from loading and increasing the time it takes for users to see any content.
Sprites are good for basic template styling images that get reused across the site, this for many reasons is because it becomes ...