As a web developer I want my projects to accomplish 2 things. I want to exceed the expectations of my client and provide the user with a good experience. A lot of developers get into the mindset of "if it works, I'm done". They don't take the opportunity to make sure the users are going to have a good experience. I don't blame them. It's tedious to test compatibility and boring to make sure your error catching gracefully handles issues that may arise. But, ironically, a slow load time can quickly ruin a users website experience. I break load-time into 2 categories: real and perceived. Real load-time is the actual time it takes all elements and scripting to be 100% loaded and ready. Perceived load-time is the wait-time a user experiences before they can start using a site. A "fast" site optimizes for the former, while exploiting the latter. So, here are 3 things techniques I use to affect page load-time without affecting my coding.

(Image) Size Matters

"I'm a developer, not a graphic designer!" This may be true, but I'm the one building the project. Therefore it is my responsibility to know about ALL facets of the project, including images. I can't draw a straight line, but I know the fundamentals of using images on the web. For me, the most important rule for graphics is: the smaller the better. Each byte the user has to download adds wait time to the user's experience. Users do not come to websites to wait.

My friend Justin, a top-rate designer, explained to me one day that when he is working in Illustrator or Photoshop his raw files could be a GIGABYTE or more in file size. This explains why designers sometimes have no problem sending me images that are 200K. By comparison, it's tiny! But 200K takes time to download. If I could get that image down to 20K (still larger than I would ideally prefer) the download time is dropped considerably, as is the user's wait time.

This is not just about the user either. From the server's perspective, a reduced file-size is less data it has to send to each user. If you remove 180K from one image that savings is multiplied by each time the file gets requested and sent to a browser. This can by thousands or even millions of times over the life of that single image. Now consider that you may reduce the file-size of multiple images and imagine the reduced workload on your server! This simple change makes your pages load faster and frees up the server's overall bandwidth to allow it to handle more requests. This optimization addresses both the real and perceived load-time objectives!

There are several tools and sites that help in shrinking images down. One I like to use is Yahoo's Smush.it. I provide it the URL of the image and it will not only shrink it for me but shows how much space I will be saving.

Load Javascript Last

I know, every tutorial and book shows that javascript should put in the HEAD tag. But think about this: generally speaking, javascript is useless without the elements on the rest of the page! If the page has not loaded, the javascript has nothing to interact with. So why does it need to come first? Because the browser processes HTML in a top-down manner, if javascript is placeed at the bottom of the page, the HTML elements will load and render first. To the user, this means the page appears quicker. When the images and HTML are loaded, the user can begin to read the page and decide upon action. While in the background, the browser continues to process the page and load the javascript. This quick fix does not change the real load-time, but by manipulating the user's perception of how fast the page loads, the user has a more positive experience.

Really, Size Matters

If shrinking the file-size of images reduces load-time, what if I could reduce other components as well? It turns out this can provide a sizable boost to both real and perceived load-times as well! Essentially I want to remove blank spaces and unnecessary markup from any javascript and css files being imported/included in a page. Remember, even a space affects the file-size.

As with images, there are tools and websites you can use to shrink, or minify, your javascript and css. But one small change you can implement while writing these files that can add up to big savings is being mindful of semicolons. Know when semicolons are optional and omit them when possible. Once again, a small change can generate great savings to the server.

Going one step further, I can also remove unnecessary markup and spaces in my HTML to reduce the size of the page request as well. The browser does not need several blank lines between DIVs, it just makes it easier for a developer to read. I can realize a smaller footprint and faster processing by using minimal "developer-centric" text formatting.

These techniques are standard components of my development toolbox and can make the difference between a satisfied client and a happy client.

This entry was posted on January 30, 2012 at 4:18 PM and has received 411 views. There are currently 0 comments. Print this entry.