The main reason for Javascript being used to progressively enhance the user experience rather than be a fundamental ‘requirement’ is cited as making the site accessible to as many people as possible. Importantly, many mobile devices don’t fully support Javascript (Smart Phones tend to, but I’m talking true mobile phones here) and screen readers certainly don’t support Javascript. Realistically, the percentage of visitors falling in to the ‘browsing on a mobile device’ or ‘using a screen reader’ will be low, and often low enough for a client (or yourself) to make the judgement “we’re not going to bother”. It is important to consider that there are advantages to graceful degradation other than making the site as accessible as possible:

Google, Bing, and A.N.Other search engines – search engine spiders are still fairly basic creatures. If your site navigation doesn’t load a new page but instead loads new content in using Ajax when you click the ‘About’ link, how are search engines going to find and index your ‘About’ page content if the site is not navigable without Javascript? It’s quite simple to make things like this degrade; if Javascript is disabled the link should go to index.php?page=about rather than nowhere. Importantly, many clients think that google is the most important visitor; if they’ve forced you to put lots of keywords at the bottom of the site despite your pleas for them not to then they wouldn’t be very pleased to find out that the search engines can’t get any further than your home page.

Application Design – Designing the application so that it works without Javascript and then adding Javascript afterwards often makes the system architecture much more understandable and ‘rigid’. In fact, if done correctly, this can speed up the Javascript implementation process. Looking back to our previous example, index.php?page=about will load a completely new version of the page with header, footer and all the bells and whistles. How about, if you click the ‘About’ link with javascript enabled, it will load index.php?page=about but through AJAX? Using HTTP_X_REQUESTED_WITH we can detect that it was requested through AJAX and serve just the ‘meaty’ bit of the page; ie the content that is changing, rather than the whole page. Does this really add much time to the development process? In my opinion, no it doesn’t!

Of course, the user experience will not be identical without javascript, but in my view it is still important to support users with no support for the language on their device, or even those that choose to browse without it. It is my view that you can treat support for when Javascript disabled in the same way as many designers treat support of Internet Explorer 6: The site should work, but it doesn’t necessarily have to be perfect. Sticking to this general guideline will not add huge amounts of time to the development time of a project, and if it does… you should take a look at how the system is designed, because it really shouldn’t.

• 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:

http://code.google.com/apis/ajaxlibs/

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.

Images

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.

CSS

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!