Hot answers tagged compression
Yes, there is almost no reason I can think of to not use GZIP at all times. It's like getting free bandwidth, and it is universally supported. Always have it on! The only possible downsides are If you are on a shared host with very limited CPU resources, as the compression is done on the server and it does take a tiny bit of server CPU. The server would ...
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 ...
By far the easiest method is to use an online tool. GIDZipTest shows you plenty of detail: the original size, compressed size and compression percentage. However, it is possible in Chrome with a bit of effort. (Updated for latest Chrome, Sept 2011.) In the Developer Tools, go to the "Network" tab and reload the page. You will see a list of all the files ...
Is it good practice to use gzip or not? Depends upon your webserver's environment. If your server is running low on idle CPU time, adding GZIP deflation could actually slow down the rate at which your server responds to requests. If you're not presently dealing with a CPU bottleneck, however, GZIP deflation is a great idea but only for plain-text files....
It is unlikely that the compression level affects the decompression time. The tradeoff is in how much time/memory is spent in compression searching for the smallest way to express the input data — more compression isn't just extra layers of processing on both ends (that would be a good way to make the data larger). Once the data is compressed, decompressing ...
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 ...
This is absolutely worth doing, even for sites with average to low traffic levels. Although it will reduce your bandwidth (with a slight increase in CPU usage), the real benefit is to your users. Even on broadband you can notice a performance improvement when accessing compressed pages, but your users on slower network speeds and newer smartphones will ...
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
The quickest thing I can think of is Google's mod_pagespeed for Apache. I've used it on my Magento store and didn't have any issues with the combination of the JS and CSS, though did run into some issues with the caching and what have you, but you can turn those off pretty easily. With mod_pagespeed, you want to use these filters in you pagespeed.conf: # ...
PNGCrush is the first that comes to mind. Trimage is a bit more comprehensive as far as toolset, and has a GUI also.
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. ...
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.
Put these lines in your .htaccess and PageSpeed Insights will see your gzip compression: <IfModule mod_deflate.c> <FilesMatch "\.(html|php|txt|xml|js|css)$"> SetOutputFilter DEFLATE </FilesMatch> </IfModule> It works for my sites.
I use the following in the .htaccess on my bluehost account (as recommended by a friend) <Files ~ "^[^\.]+$"> ForceType application/x-httpd-php SetOutputFilter DEFLATE </Files> <FilesMatch "\.(js|css|html|htm|php|xml)$"> SetOutputFilter DEFLATE </FilesMatch> ExpiresActive on ExpiresByType image/png "access ...
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 ...
No, in fact it could make things worse. From Yahoo's Best Practices for Speeding Up Your Web Site: Image and PDF files should not be gzipped because they are already compressed. Trying to gzip them not only wastes CPU but can potentially increase file sizes.
Source While using BlogEngine.net you may run into “content encoding error” “The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression” this error, to resolve this, find <add name=”CompressionModule” type=”BlogEngine.Core.Web.HttpModules.CompressionModule, BlogEngine.Core”/> in ...
Minify seems to be the standard. Here is a blog post with an explanation of how to use it.
I found this from searching for a couple of minutes, looks like it may do the trick for you!
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 ...
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 ...
Another way to accomplish this is with cURL: curl -i -H "Accept-Encoding: gzip" http://someurl.com | wc -c versus curl -i http://someurl.com | wc -c The number shown after each command is the number of bytes that crossed the wire.
This isn't a tool for Chrome specifically, but I use Fiddler when checking HTTP traffic/header information. It's a great tool, works on any browser and it's free!
Only top voted, non community-wiki answers of a minimum length are eligible