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" ...
As covered here, GitHub Pages is served with Nginx and automatically gzip's content.
You can confirm gzip compression for your site by checking the HTTP headers with online tools like this one. Enter the URL to a webpage or resource, and type in gzip under "Accept-Encoding" to indicate that the HTTP client (i.e., the online testing tool in this case) ...
Check here: https://stackoverflow.com/questions/9249243/how-to-disable-apache-gzip-compression-for-some-media-files-in-htaccess-file
It's possible, but looks like it will disable gzip for the whole website.
Keep in mind that you are telling PHP not to gzip, but Apache may still be gzipping so this should sort it, but check Apache config.
I have decided to serve only gzipped version of my pages
If you're only serving files that you've compressed using gzip, then using Vary: Accept-Encoding will be of no benefit since there won't be uncompressed copies of the files to serve to clients that don't send Accept-Encoding: gzip in the HTTP request. Most clients these days do send this, so you ...
Why do you want to serve those static assets with a gz extension at all?
Despite being the common indicator for ages, file extensions are actually an inferior and inaccurate mechanism to communicate a MIME type in the first place: ideally, web resources should be entirely agnostic to file extensions and only communicate their content by means of appropriate ...
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 ...
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.
I know this is an old question, but it shows up early on google so I thought I would answer it. You can now enable gzip on GoDaddy by adding the following to the .htaccess in your root directory.
Source - GoDaddy Support
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.
Apache uses deflate which is responsible for compressing the data into gzip formatting and sending it to the client, its important to note that the compress happens as the data is requested and not before. You should familiarize yourself with mod_deflate as well ensure its installed and enabled correctly.
Formats such as MP3 are not ideal for gzip since ...
This is a design limitation:
The file size must be between 1,000 and 10,000,000 bytes.
Compressing files is resource-intensive, so the designers of CloudFront placed an upper bound on the size of files that CloudFront will spend resources compressing on-...
You'll want to look into mod_deflate (http://httpd.apache.org/docs/2.2/mod/mod_deflate.html)
Depending on the operating system, but on most Linux-based systems you can do the following:
edit the configuration file httpd.conf or similar)
if you have a VirtualHost container, add this: SetOutputFilter DEFLATE
you can also set directory-specific compression:
Put these lines in your .htaccess and PageSpeed Insights will see your gzip compression:
It works for my sites.
it seems to me, the archiving procedure lets the tarball grow and if the tarball becomes (together with all other data) bigger then the available place in your booked hosting, the server kills the process. You will be forced firstly to download all of your data, and archive them locally.
Could it be true?
There are no SEO benefits to serving a compressed XML sitemap over serving one that is not compressed.
The advantage of compression is simply to save bandwidth and the time it takes to download. (If your sitemap is huge.)
Note that the limits for the size of the sitemap are the uncompressed size (ie. 50MB uncompressed for Google).
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.
Which option should I choose and why?
Basically you want to compress any text-based content, but not content like images, as these are already compressed.
I have omitted the type="text/css" attributes from all CSS references, as well as the type="text/...
besides Dan's answer, depending on your static-site generators, there can be some plugins that make the compressed .gz-ed version offline while generating the site. By that way, your server can serve those gz-ed pages directly.
For example, Pelican users can use gzip_cache.
For Jekyll, there's jekyll-press,
Quoting @cyberx86 over at ServerFault (who you should go and vote up):
The .xml.gz filetype may be defined as being an xml file (e.g. with forcetype in a filesmatch block) - which would cause Apache to match it to the type above.
I think you can get around that by adding an exception, above it:
SetEnvIfNoCase Request_URI ".xml.gz$" no-gzip dont-...
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 ...
It seems you're not the only one having such problems, look here and here, there are some suggestions on fixes in these threads - have you ruled these out already?
Are you in a multi web server environment? Could one of the servers in the pool have a corrupted copy of the image?
Interestingly it's not limited to the background image, and the corruption ...
GitLab Pages will serve pre-compressed .gz files that exist alongside uncompressed equivalents. A general solution that should work with most static publishing systems is to put this as the last step in the build process in .gitlab-ci.yml:
find public \( -name '*.html' -o -name '*.css' -o -name '*.js' \) -print0 | xargs -0 gzip -9 -kv
You can also easily ...
The first thing I noticed when I looked at your page in Firebug is that some of your images (specifically this one, which toomanyairmiles already posted a screenshot of, and this other one) are simply huge — the first one is 4.2 megabytes!
When I first loaded the page, the huge image was corrupted, more or less like in toomanyairmiles's screenshot. ...
The easiest way to manage Gzip compression in Apache is to add these lines in your .htaccess file:
It works well for my website.
There is no difference between the two ways you describe of gzipping a sitemap.xml for search engines.
The important thing is to just make sure your sitemap.xml is gzipped, to save bandwidth for website servers and search engines, even more if your sitemap.xml file size is big.
If the process is killed partway through, then you either ran out of memory or you ran out of disk space. I'm going to assume disk space. When compressing your entire disk data, assume you'll need the same amount of free disk space left as the total number of bytes all of your data is that is to be compressed.
Your best bet if you want compression is to ...
An better solution might be SCP (Server to server Copy)
scp -pr usernameOldServer@servername.com:/home/location/to/document_root/* /home/location/to/place/files
This page provides simple examples to do so.
Or if you want to stick to tar:
The other answers explain why it gets killed, so I'm skipping that
You are running into problems because you either ...