Scripts.Indisguise.Org - a hobbyist's blog and scripts archive

As I mentioned last week, I’ll be talking about a few of my favorite techniques for making websites load faster–the rules and practices that I find interesting and intriguing as a web developer obsessed with a dash of challenge. ;)

One of the best ways to speed up website performance is by reducing the number of HTTP requests the website makes — it’s the first rule in YDN’s Best Practices for Speeding up your Web Site and YSlow, which is arranged according to what technique would have the most impact on your page’s performance. This rule can be quite tedious to do when optimizing a current website/layout, so the best case, really, is to start a project with this in mind.

The article explains it well, so I’ll just quote them (italics mine):

80% of the end-user response time is spent on the front-end. Most of this time is tied up in downloading all the components in the page: images, stylesheets, scripts, Flash, etc. Reducing the number of components in turn reduces the number of HTTP requests required to render the page. This is the key to faster pages.

The use of CSS sprites has been around for quite a while now, and is the best way to reduce the number of HTTP requests to your server. A CSS sprite is basically multiple images combined into one single, larger image, which is then positioned into your HTML elements via CSS.

Can you imagine the conversation between the browser and the server for either case?

Browser: Give me the background for the Index menu item.
Server: Here you go, it will take around 1 second.
Browser: While I’m getting that, can you also get me the background for the Blog menu item?
Server: Here it is, another second for that.
Browser: And let’s not forget the background for the About menu item, too.
Server: Of course, here you go, you’ll get it in a second.
…

As opposed to when you use a CSS sprite for your menu items:

Browser: Give me the background image for the navigation menu items.
Server: Here you go, it will take a bit less than 2 seconds.

Short and sweet.

Note, however, that if your visitors are predominantly dialup users, this might not be a good rule for you to follow — mostly because you really can’t stuff any more data into that pipe than that pipe can handle. It will take longer for them to download the image, which will affect their perception of the website, as opposed to an image that gets downloaded faster and shows up on their browser faster. Remember those old-school rules about slicing header images? That’s basically rooted in that scenario: dialup can only download so much, so give them a couple parts of the header to download and see immediately. What’s best for your website depends on your target visitors.

There are a couple of CSS sprite tutorials and generators around:

• CSS Sprites Generator - a simple generator, giving the sprites in PNG and GIF and giving background positions for each image
• Website Performance’s CSS Sprite Generator - contains a lot more extra configuration options for sprite generation if you want finer control, allows you to choose what image format to generate
• A List Apart’s CSS Sprites: Image Slicing’s Kiss of Death article
• CSS Sprites: What They Are, Why They’re Cool, and How To Use Them
• Image Sprite Navigation With CSS

…to name a few. If you’re just getting started with spriting, I’d suggest you create your sprite manually in your preferred image editing application before trying one of the generators and work on something simple like navigation or lists with icons for the first few times. This should give you a better grasp of what happens with a sprite.

Something to keep in mind: sprites will add complexity to maintaining your design. Adding another image to an existing sprite, updating your CSS code to reflect that (and possibly impacting current CSS rules on other images using that same sprite) is slightly more time-consuming than just uploading a new image and a new CSS rule to use that single image. And of course, the more images on a single sprite, the more difficult it is to keep that image and the accompanying CSS rules maintainable. One of the ways to combat this is to organize sprites according to use. As opposed to one über-sprite containing everything and the dust on the coffee table, a sprite for navigation and a sprite for list items separately is easier to maintain and organize.

Good luck with minimizing your HTTP requests!

One of the things I’ve realized when I started working for Yahoo! is the importance and “interesting-ness” of website performance optimization. In an industry where things can get repetitive (how many <p> tags can you code in one day?), the challenges brought about by ensuring a website is properly optimized in terms of performance and page load is welcome and quite engrossing.

With high-speed Internet, a lot of times we tend to forget about the size of the files we put up on the Internet on our websites, much less worry about how long someone takes to load our website. It’s easy to forget, but when you’re on a crappy dialup or using your mobile phone as a model (er, like me while transitioning houses!), or you’re, say, a trouble-checker for one of the fanlisting networks out there, the wait for websites to load can take its toll, and feel painful on the pocket.

Two reasons why optimizing websites — even if you’re not Yahoo! — are:

1. You keep visitors longer, because the wait time is less, and people like things faster than you can chug them out. It’s all about instant gratification these days.
2. You save on bandwidth! Something smaller by even 10kb can mean megs or gigs of bandwidth savings in the long run. If you pay for hosting and you have a fairly popular website, this is a big deal.

A lot of this work is done on the frontend side of things. After all, once the server has cobbled together the page, the bulk of serving the page code and objects rely on the user’s connection. The HTML code is just one part of what’s served out to people, but images, stylesheets and other media are downloaded all after the source is available. And these are the things that users see and perceive. The image below shows around a third of Firebug’s Network tab on one of my websites:

Building and serving out the page takes up only 715ms. But the rest of the objects on the page are then loaded, and I end up with a 4.08-second load time. That isn’t so bad, but all the rest of the objects on that page form the bulk of the load time that users have to endure. If we save a few milliseconds from each object, overall we can get a snappier load time for the whole page.

In The Psychology of Web Performance, Andrew King highlight a few interesting results of bloated load times, in case you’re still not convinced:

• Google found that moving from a 10-result page loading in 0.4 seconds to a 30-result page loading in 0.9 seconds decreased traffic and ad revenues by 20% (Linden 2006).

• Tests at Amazon revealed similar results: every 100 MS increase in load time of Amazon.com decreased sales by 1% (Kohavi and Longbotham 2007).

Over the next Frontend Fridays, I’ll talk a little more about some ways to optimize frontend performance. I’ll mostly be going through the rules Yahoo! has published, but I will probably cherry-pick and talk about the ones I like most, the ones I like doing. Stay tuned :)

We all know about EXIF data in photos we take with our digital cameras, which is one type of metadata that can be present in images. This metadata provides additional information about the picture, and for photos taken with digital cameras it can include the make of the camera, shutter speed, aperture, and various other information. There are other formats like IPTC and XMP.

This metadata provides good information, but how important is that information when porting images on the web? Metadata is information enclosed in the file, hence any metadata adds to the file’s total size. This is good, except when we’re talking about, say, a preview/thumbnail metadata of a thumbnail image for your photo gallery. Redundant much?

I actually have been hit by this quirk–I kept wondering why my newly installed Photoshop kept giving me 100×100 jpegs that were 100kb in size! (Yes, I was making Livejournal icons.) I found out (after a week or so of confusion whenever I’d try) that I was including previews in my saved files because of a default setting. I got my 100×100 jpegs down to 39kb, from 100kb+. That potentially saves me ~61kbs of bandwidth per image fetch!

Stripping this metadata can be done via several methods. One is via the use of IrfanView, which I’ve heard around, but as it’s Windows-only I haven’t tried it out. I also found jhead, which is a free, open source program that runs on multiple platforms. It’s all command-line though, so if you like GUI, you might better stick with the former.

I did try out jhead, and I’m quite satisfied. It’s a quick, no-nonsense program which has a lot of capabilities, but it also does the job I want quickly: remove all metadata.

To use jhead, you should download an appropriate release from the website, save it somewhere, then open up Terminal (or the Command Prompt) and change the directory to where you downloaded jhead. If you’re using Linux/Unix/OSX, remember to set the executable bit if you downloaded the pre-built executable files by typing CHMOD +x jhead at the prompt.

For my case, I did a test with a background pattern I’m using at Seasonal Plume:

 $ ./jhead -purejpg stripped.jpg
Modified: stripped.jpg

And that resulted in an image that was 8kbs smaller.

This is a quick, painless way to help you save on bandwidth costs and have your websites load faster. I’ve recently gone through a Site Integrity Seminar at work and this is one of the things that I came away with that’s easily done to speed website performance. Given the fact that I did encounter this problem not too long ago, I hope this week’s Frontend Friday was helpful ;) and that you can use it for your own websites.