Some simple steps on the “front end” to reduce web page download time

A few years ago, page download time was a big focus for most web developers, as the majority of people connected to the internet were accessing through “dial up” connections, which we all remember for their awful connection noises and the horrific download speeds.  But with the development of faster internet connections in the developed world, the focus on page load times has been sacrificed for nice looking graphics, chunky javascript libraries and massive CSS files.  But there are some quick, simple steps that can be taken to keep all of the improved functionality and look of a web site but reduce the page load time a little.

Before I get in to the tips themselves, here are a few basic rules of web site optimisation:

  • HTTP requests are expensive in terms of time.  Reducing the number speeds page load time.
  • Browsers can – and do – cache effectively.  Inline CSS and Javascript can’t be cached for later page requests.
  • Images can be optimised on the web without any major loss in visual quality.

Javascript Files

Minify Them!

Firstly, remember that if you are including libraries such as jQuery, there are a few ways in which you can do so.  They offer a “minified” or “compressed” version, which is at least half the size in KB of the uncompressed version.  Given that you are extremely unlikely to need to ever modify the jQuery core, I don’t see any argument for including the full version of the library, and would choose to include the smaller, minified version every time.

If you have your own javascript files that are particularly hefty, you can minify those for production sites too, by using tools such as JSMin.  The only problem with doing this is you tend to need to maintain two versions of the file.  The minification process tends to be irreversible so you will need to keep a “development” copy of the javascript, just in case you need to make changes or additions in the future.

Use a Content Delivery Network for your javascript libraries!

If you want to go one step further, you can include libraries such as jQuery from “Content Delivery Networks”.  Here is what wikipedia defines a CDN as:

A content delivery network or content distribution network (CDN) is a system of computers containing copies of data, placed at various points in a network so as to maximize bandwidth for access to the data from clients throughout the network

Put simply, CDNs are probably much more capable of delivering the javascript files to the web browser accessing your page quickly and reliably than your own server.  Additionally, remember that this means that the CDN is taking some of your bandwidth costs away – at least 50kb per new visitor.  An additional strange secondary advantage is that it is possible that the user has previously visited a page including the javascript library from the same CDN earlier in their internet browsing session, so it will already be cached in their machine, and will not need to be loaded for a second time.

If you are looking for a quick link to the Google Javascript CDN,  you can access it here:

Include them only when they are needed!

Imagine that you have a “google map” page on your web site that integrates with the Google Maps API.  You have a fairly chunky 15kb Javascript file that handles your personal Google Maps integration, as well as including Google’s own API file for the maps.  Why would you want this javascript on every page of the site?  A lot of web developers and designers are guilty of putting the javascript in every single page of the site, which means that the request and corresponding bandwidth associated with the maps integration would be used even if the visitor never viewed that area of the site.


This section is going to be quite short, as it isn’t really my department, but my main understanding is:

  • Adobe Photoshop has a save for web feature. Use it.
  • Application specific META data is not needed in images on the web (I understand that Adobe Photoshop again can be a devil for this). Remove it if you can!
  • If you have “hover” states on buttons or navigation items, use CSS Sprites rather than two separate images.  The reasons why are explained in the link supplied, but mainly revolve around making the hover work immediately, and reducing the number of HTTP requests.


There are two situations here, really.  The majority of the time, most of the CSS will be used on all of the pages of the site, so it makes sense to make this one external cacheable file.  It is important that the CSS isn’t included in <style type=”text/css”></style> tags in the document itself, as this information is not cacheable and will be individually reloaded on the following page.

A lot of sites will include two or three CSS files. One for the site itself, and one for a plugin such as “lightbox” or “slimbox” or something similar.  If lightbox/slimbox is used on most pages, why not combine the CSS files in to one slightly larger one?  This will reduce the number of HTTP requests and put all of the CSS in to a single cached file.

There is an argument, also, that if there is a particularly complicated section of the web site that takes up 10kb of a CSS file all by itself, then that 10kb of the CSS should be split out in to a separate css file and included only in the complicated section, where it is needed.  This kind of optimisation will need to be assessed on a per-case basis!

Finally, remember that css itself can be written efficiently.

Compare these two blocks of code, which do the same thing, and you will see what I mean!

margin-top: 10px;
margin-bottom: 15px;
margin-right: 5px;
margin-left: 2px;

margin: 10px 5px 15px 2px;

In conclusion, the steps above often take less than an hour to implement on a well built web site, and can save a couple of seconds per page load, and a fair amount of bandwidth costs.  With google’s recent introduction of a small focus on page load time in terms of a web site’s ranking, these kind of improvements have more benefits than just making the site appear faster, and are worth paying some attention!

Leave a Reply

Your email address will not be published. Required fields are marked *