Attract More Traffic to Your WordPress Blog Using Pinterest
6 July 2014Cloud Computing and the Opportunities for Small Businesses
8 July 2014One of the easiest, simplest and efficient ways of saving a bandwidth as well as speeding up your site is by compression. I was a little hesitant to recommend Gzip compression in attempting to improve JavaScript due to some problems in older browser versions.
Nevertheless, we are in the twenty-first century and, frankly speaking; my traffic mostly comes from up-to date browsers and my favorite users are comparatively tech-savvy. I would not want to drag all and sundry else down given that someone is gulping along on Windows 95 and IE 4.0. Matter of fact, both Yahoo and Google utilize GZIP compression. It is, however, imperative to have a modernized browser so you can enjoy up-to date website contents as well as speed up modern web. The best way to do this is in using Gzip encoding. So, here is how the set up goes.
First, why do this?
Before we commence down this path, I would like to explain what it is to content encode. Suppose you request a file such as http://www.yahoo.com/index.html, there is usually a communication line between your very browser and the website server. The conversation trend follows a path like this:
- Browser: Hello, Get me this /index.html
- Server: Alright, let me check if the /index.html is close around
- Server: Got it! Here is the response code (200), Okay, and now send you the file.
- Browser: 100kb? Oops!…waiting….waiting… alright, I’ve loaded it
Indeed, the real headers and protocols are very formal. You can as well monitor those using HTTP Headers if you are very liable. However, it worked, and you finally have a file with you.
What then could be the problem?
Insomuch as the system works, it could be that it is not as efficient as you had anticipated. 100KB is an augmented text, and sincerely, HTML is very superfluous. All <html>, <div> and <table> tag includes a closing tag that looks very similar. The words are repetitively done via out the document. Regardless of how you slice it, HTML – alongside its very beefy cousin XML – is not inclining.
Moreover, how do you go about it, if the file seems too big? Simply Zip it!
Suppose we send a zipped file to the browser (index.html.zip) rather than a plain old index.html, we would absolutely save on download time and a bandwidth. What the browser does is that it downloads the zipped file, extracts it, and finally reveals it to the user, who would be in moderate since the pages get loaded quickly. The conversation in the browser could take such a format as this:
Compressed http response
- Browser: hello, can I get index.html? I will prefer a compressed version if you have it.
- Server: let check the file….yeah, it right here. Moreover, you would prefer a condensed version. Amazing.
- Server: All right, I have found the index.html (200KB) and am sending it over after zipping it.
- Browser: Wonderful! It is only 10KB. I will get it zipped and then reveal it to the user.
The formula is a natural one: Smaller file= Faster Download= Contented User.
Finding it hard to believe? The very Html portion for the yahoo homepage runs from 101KB to 10KB immediately after compression.
Documents (1 file) 15 KB (101 KB uncompressed)
http://www.yahoo.com/index.html 15KB (101 KB uncompressed)
No hairy details
The trickiest part in the entire exchange process is in the server and browser knowing it is appropriate to send over a zipped file. The tie has two sections.
- When the browser sends a header communicating to the server that it accepts compressed conten – Gzip and deflate are the most common two compression formats. Accepting-encoding: Gzip, deflate.
- The server sending response to the browser if in actual sense the content is indeed compressed. Content – Encoding Gzip.
Failure to address the content –encoding response header by the server would mean that the files are not in a compressed format (mostly the default format of many Servers). The ‘Accept-Encoding’ is simply a request from the browser and not necessarily a demand. If it is that the server does not want to send back a compressed content, the browser has not alternative but have to make do with its regular heavy version.
The server setup
We simply cannot control the browser, and that is fantastic news. It will neither send the Accept-encoding: Gzip, deflate header or it will not.
Our primary purpose is to simply configure the server in order for it to return zipped content in case the browser can handle it, which in turn saves the bandwidth for all while resulting in a happy user.
When it comes to IIS, enable the compression in the settings platform. While in Apache, enabling output compression is relatively straightforward. Simply add the following to your .htaccess file:
# compress text, html, JavaScript, css, xml:AddOutputFilterByType DEFLATE text/plainAddOutputFilterByType DEFLATE text/htmlAddOutputFilterByType DEFLATE text/xmlAddOutputFilterByType DEFLATE text/cssAddOutputFilterByType DEFLATE application/xmlAddOutputFilterByType DEFLATE application/xhtml+xmlAddOutputFilterByType DEFLATE application/rss+xmlAddOutputFilterByType DEFLATE application/JavaScriptAddOutputFilterByType DEFLATE application/x-JavaScript# Or, compress certain file types by extension:<files *.html>SetOutputFilter DEFLATE</files>
Apache comprises two compression alternatives:
- Mod_deflate that is very easy to set and is standardized.
- Mod_Gzip that seems more powerful: you can as well pre-compress any content
I prefer deflate since it is quick and works efficiently, but you could use mod_Gzip in case the other floats your boat. In both cases, Apaches check confirms if the browser sent the ‘Accept-Encoding’ header and proceeds to the compressed or regular version of the same file. Even so, older browsers may experience some, trouble and there are some special directives that can be added to rectify this.
