By Mark Cipolla

Front-end Optimization from the Get-go, Part 1

By Mark Cipolla

When it comes to making your website display blindingly quick, there are a number of steps you can take. These steps can be split into two categories: front-end and back-end optimization. Although important, back-end work tends to yield less noticeable results for the average site (with the exception, of course, of very large, high-traffic sites where every millisecond counts). In this post we’re going to go through the common issues that crop up in web performance; in subsequent posts we’ll focus on some simple steps that can make your site run observably faster.

The Nature of Requests

A web page will make many requests. The first is for the HTML of the page you’re viewing. From that, your browser will request more resources to display the page. A single request has two phases: your browser asks for a file–be it an image, a CSS file, or a JavaScript file–and waits to hear back; then it downloads what the browser sends. Therefore, there are two optimizations that can be made: by decreasing the number of requests, you reduce the amount of time the browser spends waiting to hear back from the server; and by limiting the file sizes of the objects being requested, your browser downloads less information to display a page.

Let’s say you have a web page with two style sheets, a jQuery library file, another JavaScript file with your scripts in it, and four images. That’s eight requests to display your content (in addition to the HTML). You might think that your browser is surely fast enough for you to avoid having to worry about it.


There are two factors here. First, there’s concurrency. Your browser can only make a limited number of requests at one time, so until a free slot is open, all the remaining objects in the download queue just have to wait. Internet Explorer and Firefox range from two to six concurrent connections (depending on network speed for IE and browser version for Firefox), and there are four concurrent connections for Safari, Chrome, and Opera.

Second, there’s latency. This, unfortunately, is the killer. It isn’t uncommon to have latency times of two or three hundred milliseconds (a third to a half a second or more, depending on the server), where the server idly waits before it starts to download anything.

What can we do to help this? Well, there are a few things we can try:

Reducing Requests

By lowering the number of items to download, the browser is able to render a page faster, so the page appears faster to the end user. The largest cause of numerous requests is multiple CSS files, JavaScript files, and images. Luckily enough, there are approaches and techniques to handle all three.

Concatenating CSS and JavaScript

By reducing the number of CSS and JavaScript files, we can make vast improvements. The easiest method is to concatenate them–that is, roll them into as few files as possible.

CSS is typically much easier to roll into one or two files, as it is usually served from the same location as your website. By moving the contents into a single file, significant waiting times are saved.

JavaScript usually will be a few files (assuming you’re using a library framework and some scripts). By concatenating the files where it makes sense, you speed up your page. (Personally, I consider it fine to have one or two library files, and one file for my code.) Serving advertisements, and using Google Maps tools and some JavaScript tools will add extra requests, and as JavaScript files typically aren’t served from your server, you’re unable to do much to them. I think it’s fine to accept the small speed hit in exchange for the benefit the file brings, such as displaying ads or maps.

Image Sprites

Image sprites evolved from the early computer games, where space–both in file size and memory–was limited. Essentially, sprites are multiple images combined into a single image.

On the Web, CSS controls which image in the sprite is to be displayed (the background CSS style). It’s a technique used widely, and some of the larger sites (Yahoo, Amazon, Google) go to great lengths to squeeze every millisecond of performance from it.

It’s commonplace to have a few sprites on your site, as not every image should be grouped together; backgrounds may require different layouts of sprites (images that are repeated vertically should be kept together, and the same for those repeated horizontally), while icons tend to be easiest to manage when they’re all arranged together.


In the next few posts, I’ll go through some techniques in depth on how to plan and work using code with optimization in mind. These steps are also handy for making established sites run faster, so it could be worth your while to check them out.

  • biswa

    I am waiting for your second part as I believe that you have come with more technique.All developer must know these core system.

  • Hey Great topic! I’ve been building sites (professionally) for about 12 years and I’ve gleaned a lot of info over that time but I’m always looking for new info on optimizing for speedy page loading.

    I’ve been a culprit of multiple stylesheets or script files in the past and I was pretty sure that concatenation would be a good way to beat that so it’s nice to get some info to reinforce that position.

    Mark, can you comment about how effective browser caching is in reality for situations where you’ve used various css/image backgrounds for rollovers or you have a complex image background treatment and it weighs 50k or so? I have always been under the impression that the browser cache is your friend but I’m interested in more info if you have any. Thanks!

    • Mark Cipolla

      Browser caching IS your friend (but you have to keep it in line)! Essentially, the browser tries to save as much as it can, so when a user heads back to a page, it doesn’t have to download the same files over and over again. So when a user comes back, they only have to download the different content; an empty cache versus primed cache, which I’ll go into in the next few posts.

      Of course, there are pitfalls to be had. There will be times when you have to cache-bust files (because you’ve changed the files, but the browser doesn’t recognise the difference, and hence will use the old files, and possibly break your layout), and handling mobile caches, etc…

      But I’m rambling. Stay tuned for the next few posts; I’ll cover these topics!

  • biswa

    1. I would like to add HTML minify + compress, this will help upto 30% fast.
    2. Can use Ajax.
    3. Settings ETA tags
    4. Add Expire header for CSS + Javascript etc…………………..

  • chocoholic

    I began testing different types of documents and web page stylesheets to determine which eats up the least amount of bandwidth. I included images with thumbnails and maps, .pdf s, office documents and .txt files. All hotlinked. Including a partial <!DOCTYPE statement is a lot worse than having no <!DOCTYPE statement at all. Or the wrong one. url s are next, followed by sloppy source codes. Having more than one entry for one document that are all different. Mixing single and double quotes with no quotes at all. Tables eat up file space and bandwidth. Setting the image as a background in an entire page full of tables with images knocks out 45% – 80% of the source code instantly. These hotlinks I mentioned were to a server in Virginia and I am in Los Angeles, CA.

  • Brian R Cline

    Good post. offers a little more detailed information for the more junior web developer.

Get the latest in Front-end, once a week, for free.