[…] Net Tab: Find the download performance of your page. […]
[…] How to Optimize Your Site with GZIP Compression Compression is a simple, effective way to save bandwidth and speed up your site. I hesitated when recommending gzip compression when “speeding up your javascript”:http://betterexplained.com/articles/speed-up-your-javascript-load-time/ because of “problems”:http://support.microsoft.com/kb/837251 “in”:http://support.microsoft.com/kb/823386 “older browsers”:http://schroepl.net/projekte/mod_gzip/browser.htm. But it’s 2007. Most of my traffic comes from modern browsers, and quite frankly, most of “my users”:http://instacalc.com are fairly tech-savvy. Google and Yahoo use gzip compression. A modern browser is needed to enjoy modern web content and modern web speed – so gzip encoding it is. Here’s how to set it up. h2. Wait, wait, wait: Why are we doing this? Before we start I should explain what content encoding is. When you request a file like http://www.yahoo.com/index.html, your browser talks to a web server. The conversation goes a little like this: 1. Browser: Hey, GET me /index.html 2. Server: Ok, let me see if index.html is lying around… 3. Server: Found it! Here’s your response code (200 OK) and I’m sending the file. 4. Browser: 100KB? Ouch… waiting, waiting… ok, it’s loaded. Of course, the actual headers and protocols are much more formal (monitor them with “Live HTTP Headers”:http://betterexplained.com/articles/how-to-debug-web-applications-with-firefox/ if you’re so inclined). But it worked, and you got your file. h2. So what’s the problem? Well, the system works, but it’s not that efficient. 100KB is a lot of text, and frankly, HTML is redundant. Every , and
tag has a closing tag that’s almost the same. Words are repeated throughout the document. Any way you slice it, HTML (and its beefy cousin, XML) is not lean. And what’s the plan when a file’s too big? Zip it! If we could send a .zip file to the browser (index.html.zip) instead of plain old index.html, we’d save on bandwidth and download time. The browser could download the zipped file, extract it, and then show it to user, who’s in a good mood because the page loaded quickly. The browser-server conversation might look like this: 1. Browser: Hey, can I GET index.html? I’ll take a compressed version if you’ve got it. 2. Server: Let me find the file… yep, it’s here. And you’ll take a compressed version? Awesome. 3. Server: Ok, I’ve found index.html (200 OK), am zipping it and sending it over. 4. Browser: Great! It’s only 15KB. I’ll unzip it and show the user. The formula is simple: Smaller file = faster download = happy user. Don’t believe me? The HTML portion of the yahoo home page goes from 101kb to 15kb after compression: h2. The (not so) hairy details The tricky part of this exchange is the browser and server knowing it’s ok to send a zipped file over. The agreement has two parts * The browser sends a header telling the server it accepts compressed content (gzip and deflate are two compression schemes):
Accept-Encoding: gzip, deflate * The server sends a response if the content is actually compressed: Content-Encoding: gzip If the server doesn’t send the content-encoding response header, it means the file is not compressed (the default on many servers). The “Accept-encoding” header is just a request by the browser, not a demand. If the server doesn’t want to send back compressed content, the browser has to make do with the heavy regular version. h2. Setting up the server The “good news” is that we can’t control the browser. It either sends the Accept-encoding: gzip, deflate header or it doesn’t. Our job is to configure the server so it returns zipped content if the browser can handle it, saving bandwidth for everyone (and giving us a happy user). In Apache, “enabling output compression”:http://httpd.apache.org/docs/2.0/mod/mod_deflate.html is fairly straightforward. Add the following to your .htaccess file: […]
[…] I’ve been on a web tweaking kick lately: how to speed up your javascript, gzip files with your server, and now how to set up caching. But the reason is simple: site performance is a feature. […]
[…] Speed Up Your Javascript Load Time | BetterExplained (tags: firefox Web) Posted by ovo60 Filed in Uncategorized […]
[…] Speed Up Your Javascript Load Time | BetterExplained (tags: JavaScript optimization performance compression development Web) […]
[…] Link […]
[…] Speed Up Your Javascript Load Time […]
[…] Speed Up Your Javascript Load Time […]
Excellent , thanks
Hi Abdullah, glad you liked it.
[…] Speed Up Your Javascript Load Time | BetterExplained (tags: javascript optimization performance programming web webdev) // Used for showing and hiding user information in the comment form function ShowUtils() { document.getElementById(“authorinfo”).style.display = “”; document.getElementById(“showinfo”).style.display = “none”; document.getElementById(“hideinfo”).style.display = “”; } function HideUtils() { document.getElementById(“authorinfo”).style.display = “none”; document.getElementById(“showinfo”).style.display = “”; document.getElementById(“hideinfo”).style.display = “none”; } […]
I just installed Java…What will it do? I need it to speed up my browser. Will it do that? If not, what?
Peace
Dirk
Hi Dirk, Java and Javascript have similar names but actually aren’t related (it’s often a big source of confusion).
I’ve been using Opera (http://www.opera.com) as my browser – it’s really fast and you may find it fits your needs.
[…] Net Tab: Find the download performance of your page. […]
[…] ET AL. There are many more ways of improving load times: 1. Compress the javascript file. There are umpteen ways of doing that. Refer to my previous post. 2. Check this link out: Speed Up Your Javascript Load Time - BetterExplained […]
Microsoft to Force Upgrade IE6 to IE7 on Feb 12. So you may turn compression on 
Good point… although I think there may be some other ancient browsers in the “gzip not welcome” list too
response to “Should I Gzip It?” paragraph:
You CANNOT ignore old browsers. It shouldn’t even be an option unless you re making an intranet app for a specific browser. As a (web) developper, it’s YOUR JOB to make it work for everyone. Any other mindset and you might as well just go sell peanuts…
while I agree that efforts should be taken to support older browsers, who elected you to decide what his job is? Do you still support NCSA Mosaic 1.0?
Mosaic 1.0 is only 15 years old, IE 5 is 9 years old, IE 5.5 is 8 years old. When is something so outdated that you don’t support it anymore? Or is the web developer supposed to shoulder all the burden when the browser vendor doesn’t provide proper patches for their browser or the consumer runs a buggy browser?