Why we need HTTP Compression

HTTP compression isn't something you put in your code. Instead, check with your sys admin to see if it's installed (or can be) on the server that's dishing out your site's pages.
What does it do? HTTP compression accelerates the transmission of pages from server to surfer. It allows for server-side HTML compression so server apps (like Apache or Microsoft Web Server) can compress the source code of your page before sending it out over the wires.

HTML compression works on almost every browser these days, but the code is savvy enough to dish out un-compressed files to unsupported browsers. Compression alone improves the download size of pages by up to 300%. (Exclamation mark.)
Other nuggets in the HTTP compression nougat include persistent connections (between server and client) and pipelining (which allows the server to rattle off files without waiting for a client's "uh-huh, got that one, next please" response). Crackin' good stuff, all of it. The only negative thing we can say about HTTP compression is that it's probably already installed on your server, seeing how it's well-adopted now (for obvious reasons). Still, if you suspect your hosting company is slow-with-the-program, it couldn't hurt to ask.

Link Prefetching

Link prefetching is a feature in some browsers which makes good thrift of a browser's idle time by downloading files that aren't on the current page but might be needed a page or two down the road. Don't worry - link prefetching doesn't slow pages down. The extra downloads don't kick in until after the current page has finished loading and the browser doesn't have any pressing matters to attend to.
If you had a photo gallery, for example, with Previous and Next navigation links by each picture, you could add a prefetch link tags pointing to both of those destinations. That way, while the user is staring at one amazing travel picture, two other pages are downloading in the background. If the user does click either the Previous or Next links, those pages will already have been downloaded, and the content will display instantaneously. More technically speaking, "Guy clicks the link, see, Bada-bing, Bada-boom, it's the next page, already. Aow!"
Link prefetching isn't automatic - it relies on you, the developer, to encode hints as to what files are likely to be needed next. (Browsers aren't prescient, but good webmasters understand a site's traffic flow.) You can encode prefetch hints in either the HTTP header or the page's HTML. There are a number of allowed variations on how to code a prefetch, but a simple HTML  link¢ tag with a relation type of "next" is small, easy, and our favorite. Like these:

Cache In

Network (or Proxy) Caching
We previously discussed how browser-side caches store commonly-used images on the users' hard drives, but it's important to note that similar caches exist all alongside the highways and byways of the internet network. These "Network Caches" make websites appear more responsive because information doesn't have to travel nearly as far to reach the user's computer.
Some webmasters are leery of network caches. They worry that remote caches might serve out-of-date versions of their site - an understandable concern, especially for sites like blogs that update frequently. But even with a constantly-updating site, there are images and other pieces of content which don't change all that often. Said content would download a lot faster from a nearby network cache than it would from your server.
Thankfully, you can get a site "dialed in" pretty nicely with just a basic knowledge of cache-controls. You can force certain elements to get cached days on end while keeping other elements from being stored at all. META tags in your document won't cut it. You'll need to configure some HTTP settings to make caching really work for you.
Every Bit Counts
Alrighty. So you've done the big stuff - dropped bit depths on your every PNG, cranked up the HTTP compression, and taken a (metaphorical) weedwhacker to your old, convoluted table layouts. Yet you're still obsessed with how small, how fast, and how modem-user-friendly you can make your site. Ready to jump into some seriously obsessive-complusive optimization?
You know those TV commercials where they zoom in on a supposedly "clean" kitchen counter, only to reveal wee anthropomorphic germ-creatures at play?
Well, you can similarly clean every extraneous detail from a site's layout, and still have some nasty, nasty cruft living in the source code. What's the point of novel-length meta keyword lists and content tags? C'mon, do you still believe that search engines care about that stuff? Not in this millenium. You'll get better search referrals by thinking carefully about the real content on your pages and building an authoritative site that's linked to widely.
Streamlining the  head¢er section of unneeded meta keyword/author/description content, and likewise junking giant scripts makes a bigger impact, kilobyte-per-kilobyte, than sacrifices made elsewhere on the page. Having a short  head to ¢ to your document ensures the initial chunks of data the user receives contain some "real" content, which gets displayed immediately. That's another notch for "perceived speed" improvements.
Of course, there are plenty of regular  body¢ bytes still worth tossing. Start with HTML comments, redundant white space, and returns. Stripping all these invisible items from your source code yields extra kilobytes of space savings on the average.

URL Abbreviation

Ever spot how links on the Yahoo frontdoor are generally just a few characters long? Go to the site and move your mouse over some of the news links near the top. You'll see they all start with http://yahoo.com/s/ and then list a string of six numbers. Links, generally, run on much longer than that, especially if they include redirect codes or CGI variables. Put enough normal links on a page, (viz. the Yahoo frontdoor, again) and a sprinkling of kilobytes (and seconds of download time) is also added to the code.
So what's Yahoo doing with those funny links, anyway? They're abbreviating their URLs, using the mod_rewrite Apache module, so that a link like "/s/882142" redirects to "mysite.com/content/unregistered/News". Implementing this requires getting your hands dirty with some server configuration. Specifically, you need to get mod_rewrite installed and poke around with the srm.conf file. Dirty work for many of us, but the payoff is worth several solid kilobytes on a link-heavy page.