Performance optimizations aside, and even if you concatenate all your JS files into a single file, you still have to load the library into the browser after the request has been made, and you can’t do anything with it until that has finished loading.

Wouldn’t it be so great if the browser had a copy of YUI or jQuery or Dojo or Prototype or GWT in memory at all times? Then your library using decision would not be influenced by the size of the library but by its speed and performance, and perhaps features and functionality provided. I mean you don’t go loading new fonts and new plugins every single time you go to a new page right? Then why do we have to download the same 5 or 6 JS libraries over and over all day long as we browse the web? And if this was an option how many companies would spend time rolling out their own rather than adopting one?

I understand there would be tons of politics involved and it will probably never happen in a million years but it is worth a try. Perhaps at least a FF only version could be done through an add-on that loads the latest major version of all these libraries and checks for updates on startup, similar to how other plugins get updated in FireFox today. The browser would have to namespace the libraries to avoid confusion. Developers would then just do a test to see if the browser has a required library in memory, and if not then make a server call for it as a fail safe.

It would take lots of collaboration and standardization. JavaScript was the sleeping giant that was brought to center stage with the success of frameworks and libraries that have fueled its standardization and resulting wider adoption. Why not give those libraries some credit and package them into your browsers?

What we knew so far about Chrome

• Uses V8 JavaScript engine which supports Classes and compilation. There is a V8 JavaScript benchmark suite that gives FireFox 3 a score of 83, while giving Chrome a score of 1213! Safari 3 gets a score of 128. Judging by this alone, V8 blows away the competition.
• Uses Webkit rendering engine.
• Tabs run as independent processes which can be managed.
• Lots of other features.

First Impressions

• Installation was a breeze and imported FireFox settings.
• No status bar, You only see the status bar when you hover over a hyperlink.
• The Task Manager (Shift + Escape) updates in real time and shows memory, CPU and network usage for each tab, each plugin, and the main Chrome process separately. There is also a link to Stats for Nerds with lots more gritty info.
• The Flash plugin is extremely CPU usage intensive and causes sluggishness when scrolling. I just loaded a popular flash website and noticed my machine came down to a near halt. It seems to happen more with Flash files that contain infinite loops, using as much as 70% of the CPU.
  
• The built in JavaScript console looks like a combination of FireBug and Web Inspector.
• There is a built in JavaScript Debugger (Alt + `)
• Passes the Acid 2 test.
• Chrome gets a score of 78 on the Acid 3 test, which is higher than FireFox 3 at 57, Safari at 72, and Opera at 45.
  
• Omnibar – this is the URL/location bar in Chrome that has some fuzzy logic built in to suggest “smart” autocompletes. This is the current order of the drop down in the auto complete list. There seems to be no way of changing this ordering as of now. Would be nice to be able to customize them.
   
  
   
  1. Search Google for FOOBAR
  2. FOOBAR/ (I’m not sure how useful this one is really)
  3. Link to the FOOBAR Wikipedia page
  4. Link to I’m Feeling Lucky URL for term FOOBAR. This item gives you the ability to search within the URL. For example if you type in Amazon in the Omnibar and select the amazon.com option using the down arrows, you will see “Press Tab to Search Amazon”. See below instruction on implementing this search functionality for your website.
  5. Search Google for FOOBAR ANOTHER TERM
  6. Search Google for FOOBAR ANOTHER TERM
  7. A page in your history pertaining to FOOBAR
  8. Link to history search for pages about FOOBAR

Cool Developer related stuff in Chrome

Google Chrome User Agent String:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.X.Y.Z Safari/525.13.

Chrome has a menu option called “Create application shortcuts…” that uses Google Gears to create a shortcut to your webapp. Users can choose to place the shortcut to your webapp on their Desktop, on the Start menu and even the Quick launch bar in Windows. This is a pretty powerful feature. When a user clicks this icon, Chrome opens up without the Omnibar, and your website will appear in an “Application” format. You can customize how Chrome creates these shortcuts using meta tags. These tags are named: application-name, description, application-url, and shortcut icons in both 32×32 or 48×48 formats. The favicon is used if not specified. For example you can use the following HTML code in the head of your document. Note that with the Mozilla added support which is used in Chrome, you can use any supported graphic format as your favicon, and not just the old school favicon.ico file.

<head>
  <meta name="application-name" content="Gmail"/>
  <meta name="description" content="Google's approach to email"/>
  <meta name="application-url" content="http://www.gmail.com"/>
  <link rel="icon" href=gmail_32x32.png sizes="32x32"/>
  <link rel="icon" href=gmail_48x48.png sizes="48x48"/>
</head>

To open a new tab from your webapp in a separate process using JavaScript you can do this in Chrome.

var w = window.open();
w.opener = null;
w.document.location = "http://differentsite.com/index.html";

Chrome lets users search your website from its ominbar. To enable and include your website’s search in Chrome you have to create an OpenSearch description document (OSDD).
For example you can create something like this:

<?xml version="1.0" encoding="UTF-8"?>
 <OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/">
   <ShortName>Web Search</ShortName>
   <Description>Use Example.com to search the Web.</Description>
   <Tags>example web</Tags>
   <Contact>admin@example.com</Contact>
   <Url type="application/atom+xml"
        template="http://example.com/?q={searchTerms}&amp;pw={startPage?}&amp;format=atom"/>
   <Url type="application/rss+xml"
        template="http://example.com/?q={searchTerms}&amp;pw={startPage?}&amp;format=rss"/>
   <Url type="text/html" 
        template="http://example.com/?q={searchTerms}&amp;pw={startPage?}"/>
   <LongName>Example.com Web Search</LongName>
   <Image height="64" width="64" type="image/png">http://example.com/websearch.png</Image>
   <Image height="16" width="16" type="image/vnd.microsoft.icon">http://example.com/websearch.ico</Image>
   <Query role="example" searchTerms="cat" />
   <Developer>Example.com Development Team</Developer>
   <Attribution>
     Search data Copyright 2005, Example.com, Inc., All Rights Reserved
   </Attribution>
   <SyndicationRight>open</SyndicationRight>
   <AdultContent>false</AdultContent>
   <Language>en-us</Language>
   <OutputEncoding>UTF-8</OutputEncoding>
   <InputEncoding>UTF-8</InputEncoding>
 </OpenSearchDescription>

Fore more tips read the Google Chrome FAQ for web developers page.

ps. Don’t use the Google gears Chrome download page which gives a JavaScript error!

_GU_SetupOneClick is not defined
onload(load )

arguments itself returns an object that looks like an array (but not really an array) of the arguments passed to the function.

Prior to JavaScript 1.4 the Function object also had a similar arguments property, which is now deprecated.

However the Function object comes with a few other useful properties that we can still use to get argument related data.

function callTaker(a,b,c,d,e){
  // arguments properties
  console.log(arguments);
  console.log(arguments.length);
  console.log(arguments.callee);
  console.log(arguments[1]);
  // Function properties
 console.log(callTaker.length);
  console.log(callTaker.caller);
  console.log(arguments.callee.caller);
  console.log(arguments.callee.caller.caller);
  console.log(callTaker.name);
  console.log(callTaker.constructor);
}
 
function callMaker(){
  callTaker("foo","bar",this,document);
}
 
function init(){
  callMaker();
}

For demonstration purposes, you can run the init function above and view the logs in FireBug.

arguments object and its properties

arguments returns ["foo", "bar", Window, Document]

arguments.length returns 4

Note: even though our function has a signature with 5 arguments, length returns only 4 here. This is because the caller sent us only 4 arguments. See below for how we can use Function’s length property to find the number of expected arguments.

arguments.callee returns callTaker(a, b, c, d, e)

Note: callee shows us the signature of the currently executing function and is useful when trying to make recursive calls to a function within its own body.

arguments[1] returns bar

Note: arguments can also be set for functions in an array like format. For example you can set the second argument like this: arguments[1] = 'moo';

Function object and its argument related properties

callTaker.length returns 5

Note: This is the expected number of arguments.

callTaker.caller is the same as arguments.callee.caller and returns callMaker()

Note: we can go up the stack trace and get the caller of the caller etc. For example we can find the function that called callMaker using arguments.callee.caller.caller which returns init().

callTaker.name returns callTaker

callTaker.constructor returns Function()

Note: Since we have not modified the basic behavior, we see the built in function that creates an object’s prototype for our function, which is the Function object.

Basic Usage Sample

var dataArray = ["One", "Two", "Three", "Four"];
 
var lister = function createList(list) {
 if(arguments.length == 3){
  var result = "<" + arguments[1] + ">";
  for (var i = 0; i < arguments[2].length; i++){
   result += "<li>" + arguments[2][i] + "</li>";
  }
  result += "</" + arguments[1] + "l>";
  document.getElementById(arguments[0]).innerHTML = result;
 }
}
 
function makeList(){
 lister("list_HTML","ul",dataArray);
}

Run the sample

References:
JavaScript Stack Trace
Function
arguments

Web Inspector Overview

To get started open Web Inspector by going to Safari 3.1/Develop/Show Web Inspector and you will see the new window open up. The initial window is split up into a top row with navigation buttons and search box. The navigation buttons take you the the next and last actions you make within Web Inspector and come in handy when debugging. The left navigation lets you view and inspect the loaded web resources including Documents, StyleSheets, Images, Scripts, WebFonts, Databases and Other files, as well as buttons to load the Console and Network details. Ajax request and responses show up under the Other file category. If any errors are found, the number of errors are placed on the file name in the navigator. For example here, Safari has found 1 bug in the file diggthis.js The main content area shows you the web source details for viewing. JavaScript errors are marked with an orange pop, while HTML and CSS errors have a red color. If you want to attach Web Inspector to the bottom of your Safari Window click the small box on the bottom left corner of the window. I found this this to be a more usable placement.

DOM Editing

Clicking on any HTML Document on the left loads the source on the right. Documents can also be viewed as a DOM resrouce by clicking ont he DOM button on the top nav. (Note you have flip between DOM and Source view for HTML files.)

Searching supports DOM and CSS elements and you can nest your DOM element searches to filter out exactly what you’re looking for. For example #page a returns all anchor tags in the div with the page id. The corresponding display element in Safari is highlighted as you select DOM elements.

The right pane displays Styles, Metrics and Properties for seleted DOM elements. Styles show you both the computed style as well as all the defined style rules for that object. Like FireBug you can edit your CSS rules in real time in the Styles boxes for each CSS rule. To edit any CSS property double click the name or value and an edit box opens allowing you to type in your changes. This is great for testing out new ideas on the fly.

The metrics pane shows you the layout rules including offset, margin, border, padding, width and height for the element. Finally the Properties pane lists all of the DOM object properties that apply to the selected element.

Downloadable Web Fonts

If you are using downloadable web fonts the Fonts file group shows you a rendering of all the fonts that are loaded into the user’s browser.

Client Side Databases

Also if you are using the client side database features of HTML5, the Databases category will let your explore the databases loaded in the client along with the all the tables and rows in each client side database. From here you can also execute SQL queries against the databases.

The Console

The console feature lets you type in JavaScript commands and view JavaScript errors, along with HTML and CSS rule errors. Clicking on any error jumps to the file, but unfortunately doesn’t go the corresponding line. The console has an input area for testing out JavaScript and DOM commands on the bottom. There is in fact a console object and my tests showed that Safari supports only a few of the functions for the console object. Here is a list of the FireBug console methods of which only a few are supported in Safari namely log, info, warn and error.

Supported methods:
log info warn error
Unsupported methods:
debug assert dir dirxml trace group groupEnd time timeEnd profile profileEnd count

Network

The network tab is actually quite nicely designed and show you what the transfer time or the transfer size for each resource and in total for the page. The capsule graph is color coded and breaks down the file types by Docs, CSS, Images, Script and Other. You can switch between time or size from the drop down. Web Inspector makes some suggestions as well for improving speed, for example here we see a recommendation to use file compression to save bandwidth. (I don’t really use this method now since IE6 is buggy with gzip deflation.) Click on any file to see the HTTP request and response header for that file.

Snippet Editor

The Snippet Editor is a little utility that allows you to enter blocks of HTML and CSS and have it rendered on the fly. It is quite useful for testing out your CSS and Layout in little chunks.

Note: While using the Web Inspector and Snippet Editor, I came across numerous little annoying bugs and usability issues here and there. Also lots of features that I would expect are not there. For example you can not click on elements to inspect them, you can not add new style rules if they don’t exist already, and you can’t edit rules for CSS files loaded using @import. I would have to say that FireBug is a superior tool at this time for professional debugging, but Safari is about half way there.

Developer Menu

The first thing you will notice is the addition of the “Develop” menu (Preferences/Advanced/Show Develop menu in menu bar) item with the following tasks:

Open Page with: (Other browsers installed on your system including FireFox, Internet Explorer, Opera)

User Agent: Set you user agent from the list of options, or enter your own user-agent. Finally! This was previously part of the hidden debug menu and you had no way of specifying a custom user-agent. The other exciting additions here are the ability to set your user-agent as Mobile Safari 1.1.3 for either iPhone or the iPod touch.

You can also pull up the Web Inspector, Error console, Network Timeline and a Snippet Editor. Lastly the Developer menu allows you to disable various browser features such as Caches, Images, CSS Styles, JavaScript, Runaway JavaScript Timers, and Site-Specific Hacks. You can now also edit CSS in the Web Inspector. More on these in a later post.

Standards Support

Support for CSS 3 web fonts using CSS @font-face rules. check out what can be done with downloadable fonts in these working samples here, here, here, here, here, and here. The CSS and a sample web font are show below. If you are using Safari 3.1 you should see a cool font.

@font-face {
  font-family: "Acorn Initials";
  src: url(http://www.domain.com/Acorn___.ttf) format("truetype");
}

Safari 3.1

Support for CSS transforms and transitions. Below are some demos of these.

Here is a sample of the -webkit transform CSS which is now supported by Safari 3.1. Click on the Safari logo to rotate it 1440 degrees.

The following Safari logo is skewed 35 degrees using -webkit-transform: skew(45deg, 0deg).

The following image changes its scale using -webkit transform:scale() to zoom in 30% when you mouse over it.

Support for HTML 5 <video> and <audio> elements. Watch out Adobe and Flash. Here is a demo of the video tag. There is also added support for SVG images in <img> elements and CSS images and SVG advanced text.

Support for offline storage for Web applications in SQL databases. That means you can now store your databases locally on the client’s machine. Here’s some sample JavaScript to do the client side databases. Check out this demo that shows you how it works.

database.executeSql("SELECT * FROM test", function(result1) {
   // do something with the results
   database.executeSql("DROP TABLE test", function(result2) {
     // do some more stuff
     alert("My second database query finished executing!");
   });
});

 
Running the CSS3 Selector tests reveals that Safari 3.1 has full support for CSS3 Selectors while FireFox 2 and IE 7 are still playing catch up.

Performance Improvements

Apple claims that Safari 3.1 “executes JavaScript up to 6 times faster than Internet Explorer 7 and up to 4 times faster than Firefox 2″. Performance measured in seconds. Testing conducted by Apple in March 2008 on a 2.4GHz Intel Core 2 Duo-based iMac system running Windows XP Professional SP2, configured with 1GB of RAM and an ATI Radeon HD 2600 with 256MB of VRAM. HTML and JavaScript benchmarks based on VeriTest’s iBench Version 5.0 using default settings. Testing conducted with a beta version of Safari; all other browsers were shipping versions. Performance will vary based on system configuration, network connection, and other factors.” I tested IE7, FF2, and Safari 3.1 with 3 JavaScript performance testers and the Acid 3 test kit. The tools used are
1. Acid3 tests.
2. JavaScript speed test written by Jason Orendorff
3. SunSpider test kit from WebKit.org
4. slickspeed test from Mootools.net

Here are the results in milliseconds from the tests which seem to agree with the results found by Apple. You can see that Safari 3.1 does in fact have a much more efficient JavaScript processing engine, and is three quarters of the way there when comes to passing the Acid3 tests.

Detail links at SunSpider:   IE7     FireFox 2.2     Safari 3.1

Microsoft Windows

• Improves Back/Forward performance
• Supports signed Java applets
• Shows Caps Lock icon in password fields
• Adds support for showModalDialog
• Localized in 16 languages
• Adds support for International Domain Names
• Improves handling of Japanese, Chinese, and Korean text
• Contextual menu now allows opening a link in a window or tab
• Improves pop-up blocking to work with plug-ins

Other Improvement

• Double clicking on the Tab Bar opens new tab
• Includes URL metadata when images are dragged or saved from browser
• Opens Download and Activity window in current Space
• Supports trackpad gestures for back, forward, and magnify on MacBook Air and compatible MacBook Pro computers
• Shows Caps Lock icon in password fields
• 13 Security Fixes
• Increased site compatibility
• Improved application stability

Then I discovered something interesting in Google Analytics.

Google Analytics tracks and stores connection speeds for your visitors as part of the Network Properties category. The data provided includes Connection Speed and this corresponds with Pages per visit, Average time on Site, Percentage of new visits, and the Bounce rate. But how in the world does Google compile this data? It appears that people are guessing that Google uses the visitor’s IP address or hostname to do a lookup in an IP database or a reverse lookup, and then makes a guess based on what ISP that IP address belongs to. But Google also loads a small .gif file with each urchin request. This article explains a little trick for using time stamped image loading and log analysis which seems related.

So if your IP belongs to RoadRunner, then we can assume you are on a cable connection and file you under that category. This can sometimes get somewhat hairy and lead to ambiguity as evidenced by the Unknown category shown in Google Analytics. It is also interesting to note the Unknown category is the single largest category in my case with 36% of the total data collected. What happens if you are on AOL or EarthLink? Will the database contain the accurate information to pinpoint if you are on dial-up or broadband? How often is the database updated with new information? What about edge cases, for example if you work in an office where you have a “broadband” connection but share it with a large group of people?

The good news is that with Analytics the work happens without interfering with the user experience and no additional HTTP connections are needed. The bad news is, it is not done in real time. So if you are looking for a real-time test this will not work for you, unless you build your own seriously fast IP database web service that you can use asynchronously. The other option is to use the binary image payload test, but that also makes life hard for your users.

So, If you are looking for general statistics for a webapp over a date range then Google Analytics might be the way to go. Keep in mind you will end up with a chunk of Unknown data. As for making snap decisions, you can sniff user bandwidth while they surf with payload testing. Here is another sample page at AOL where they put up a simple fork page and determine your bandwidth speed using JavaScript image loading and setting a user cookie. I can think of a dozen reasons why this is a bad idea but I won’t go into that here.

PS. It is worth mentioning that Internet Explorer supports a built in behavior called clientCaps, which provides information about features supported by Microsoft Internet Explorer, as well as a way for installing browser components on demand. The connectionType property of clientCaps returns either lan, modem or offline. Since this only works in IE and doesn’t offer too much granularity, it might be a good test if you are only trying to test IE users specifically.

Mozilla/5.0 (Aspen Simulator; U; Aspen 1_2 like Mac OS X; en-us) AppleWebKit/525.7 (KHTML, like Gecko) Version/3.1 Mobile/5A147p Safari/5525.7

This means if you load up sites that only look right on the iPhone they won’t render correctly on the Aspen Simulator. An example of this is the Yahoo Ajax Flickr website designed specifically for the iPhone. This page renders correctly if you’re on an iPhone, but will show you the basic mobile version if it doesn’t see iPhone in your user-Agent. Next version of Aspen will hopefully have an option to easily edit the user agent string of the Safari browser. For reference the mobile Safari app is located in this folder:

/Developer/Platforms/AspenSimulator.platform/Developer/SDKs/AspenSimulator1.2.sdk/

if (window.console && window.console.firebug) {
  alert("found Firebug");
}else{
  alert("can't find Firebug");
}

Demo: Sniff for FireBug

You may have noticed this message in your Gmail homepage recently:

The reason for that is Firebug by default logs all XMLHttpRequests made for all the websites you visit. The problem is that the data that is logged never gets disposed of or cleared out. Therefore, FireFox having to collect and store that information and the memory for Firefox will eventually get large enough that will cause your computer to start using paged cache. This will then make Gmail seem like you are swimming through molasses. Gmail by default seems to make 22 XMLHttpRequests when I load the main page. It then makes a new XMLHttpRequest every 30 seconds, to check for new emails, so in the span of 1 hour you will have 120 new Ajax calls tacked on. This is a nice feature of Gmail which makes life simple for its users (Notice there is no “Get new mail” button anywhere). But now every new Ajax call is another 1kb of data which adds to the memory usage and tacks on more CPU and RAM consumed by Firebug.

No need to worry though since, another nice feature of Firebug is that you can disable it on a domain name basis.

To turn off Firebug for mail.google.com first open Firebug by hitting the green icon or F12. Click on the bug icon in the top left and choose the second option labeled “Disable Firebug for mail.google.com”. Now Firebug will be turned off and the green icon will be changed to a silver icon for this domain. You should notice a smoother and faster Gmail experience. You can also turn it back on by clicking on the link “Enable Firebug for this website”.

The other and better method of speeding up your Firefox and still keeping Firebug around, is to disable Firebug all together and enable it for specific sites that you are working on. To disable Firebug, again you click on the Bug icon and this time choose the first option “Disable Firebug”.
Now visit any site that you would like to use Firebug on and then “right click” on the silver icon on the bottom and choose “Allowed Sites…” From here you can add the domain name for any sites you want to override. This makes your life easier and makes general surfing faster in FireFox, yet allows for using the powers of the almighty Firebug when needed.

If your application is similar to Gmail where XMLHttpRequests are called in a loop you may want to use the sniff script to warn users to disable Firebug for your domain as well.

var XMLHttpArray = [
        function() {return new XMLHttpRequest()},
        function() {return new ActiveXObject("Msxml2.XMLHTTP")},
        function() {return new ActiveXObject("Msxml2.XMLHTTP")},
        function() {return new ActiveXObject("Microsoft.XMLHTTP")}
];
function createXMLHTTPObject(){
        var xmlhttp = false;
        for(var i=0; i<XMLHttpArray.length; i++){
                try{
                        xmlhttp = XMLHttpArray[i]();
                }catch(e){
                        continue;
                }
                break;
        }
        return xmlhttp;
}////
function AjaxRequest(url,callback,method){
        var req = createXMLHTTPObject();
        req.onreadystatechange= function(){
                if(req.readyState != 4) return;
                if(req.status != 200) return;
                callback(req);
        }
        req.open(method,url,true);
        req.setRequestHeader('User-Agent', 'My XMLHTTP Agent');
        req.send(null);
}////
function AjaxResponse(req){
        var respXML=req.responseXML;
        if(!respXML) return;
        var respVAL=respXML.getElementsByTagName('family')[0]
.getAttribute('result');
        document.getElementById("status").innerHTML += respVAL;
}////
function ClearResponse(){
        mdiv=document.getElementById("status");
        mdiv.innerHTML = "";
}////
function MakeRequst(){
        AjaxRequest("ajax.xml",AjaxResponse,"get");
}////

And our sample XML file looks like this:

<?xml version="1.0" encoding="utf-8"?>
<family result="successful ajax request &amp; response!">
 <parents>
 <father name="Mike" last="Brady" />
 <mother name="Carol" last="Martin" />
 </parents>
 <children>
  <sons>
   <son>Greg</son>
   <son>Peter</son>
   <son>Bobby</son>
  </sons>
  <daughters>
   <daughter>Marcia</daughter>
   <daughter>Jan</daughter>
   <daughter>Cindy</daughter>
  </daughters>
 </children>
 <maid name="Alice" />
</family>

Here is a working sample of this code.

Ajax Request Reset

Some things to note are:

I’m using a GET here, but yo can easily change that to a POST in the call to AjaxRequest.

The URL passed to AjaxRequest can contain parameters as needed.

You can handle other readyStates(0,1,2,3) and HTTP status codes as you wish using the onreadystatechange handle.

I am sending null since I am not posting anything back to the server, but you can swap that with your own Post data if you wish. To set that up you have to also add this line of code before you call send to set the proper request headers.

req.setRequestHeader('Content-type' , 
'application/x-www-form-urlencoded');

The responseXML property is only available when the request is made to an XML document, so If you are using other document types (HTML,Text,CSV,JSON) you will not have access to this property. If you use anything other than XML data you will have access to the responseText property instead.

Once you have the handle to the responseXML property, you can traverse through the XML DOM like you would with any other DOM object and you can use all the DOM element methods, properties and events that you already know.

For example to get a list of all the sons in the family we can do:

respSONS=respXML.getElementsByTagName("son");
respSonVals = "";
for(x=0; x<respSONS.length; x++){
    respSonVals += " " + respSONS[x].firstChild.nodeValue;
}

Try Get Son Names

1) Validate your code

Although JavaScript can be very forgiving when it comes to error handling, sloppy coding will come back to haunt you in the long run. So the first step is to validate your code. I use JSLint which scans JavaScript code for syntax errors and common mistakes and recommends fixes. JSLint piggy backs on Rhino which is an implementation of JavaScript written in Java from Mozilla. You can either use the online version or download and run the scanner locally. I prefer this local method which utilizes the java runtime.

To use JSLint locally:

1. Download and unzip Rhino to a folder on your computer. You need js.jar
2. Download and save the JSLint library file jslint.js
3. Run JSLint in the Rhino Shell passing it a JavaScript file to scan. Here is the command I use assuming js.jar, jslint.js, and MYBIG.js are all in the same directory.

java -classpath js.jar 
org.mozilla.javascript.tools.shell.Main 
jslint.js MYBIG.js

You will then see a list of errors found by JSLint and suggestions for fixing your code. Some of the most common items are:

• Missing end of line semi-colon delimiters ;
• Not using dot notation to reference DOM objects (ex. form['name'].input.value instead of form.name.input.value )
• Using == instead of === for comparing with null, undefined, booleans, zero and “”
• Variable scope issues caused by declaring variables inside of loops instead of declaring them first in functions definitions.
• Not using curly braces in your conditional blocks. So make a point to always do If(x){doX();}else{doY();} even if you have one liners.
• Stay away from using eval() or with(). eval is evil
• Create your arrays using literal notation [] instead of new Array()
• Create your objects using {} instead of new Object()
• Avoid using javascript:function() in URLs
• You can read more suggestions in the JSLint docs.

2) Join your files

If you have five separate CSS files and three different JavaScript files, your server has to answer 8 HTTP requests per client. Each request requires additional processing and slows down your page loading. By concatenating your CSS and JavaScript files to only 2, you should see page load time improvements, especially when client requests are coming from distant networks.

Another tip that I have seen is to move your JavaScript include tags to the very bottom of the page, right before the </body> tag. This will allow the browser to draw the DOM before loading your library files and the page will appear to load faster.

So after your various source files are nice and lint free, and combined into a single library file you are ready to start shrinking.

3) Shrink your library

Before shipping your code, shrink it. JavaScript and CSS files are not compiled and they contain lots of wasted whitespace which are nice to have when you’re coding but serve no benefit to the user of your website. There are four different tools you can use to filter out the unnecessary bits from your JavaScript and CSS files, and for the most part they are doing the same thing. I personally use ShrinkSafe which is a happy safe medium. The reason is that this tool does not mangle your code so that its API will stay in tact. If you choose to use a decryption based method to obfuscate your code, it can have harmful side effects. First, the size of the encrypted file can in some cases actually be larger than the original! Second, your scripted API can get mangled, forcing you to update all external pointers to your code. If you have any clients who use your API via JavaScript, you should obviously take great caution in using encryption methods.

Caution: As always, backup your code before making changes to them using these tools! There is no undo!

JavaScript Shrinking

1. JSMin removes extra white-space and comments. It also reduces the line count by increasing the maximum line width. The result a bit uglier and harder to read and debug but also a bit smaller. Unlike ShrinkSafe, though JSMin does not edit your function arguments. You can download it in a variety of flavors. Here is a DOS executable version and the command to run it.

   jsmin <big.jsb >min_jsmin.js "(c)2007 CORP"

2. ShrinkSafe removes extra white-space and comments, but keeps one statement per line which is easy on the eye if you decide to edit your shrunk file. It also shrinks function arguments by replacing them with consecutive _## values which tends to reduce the files size some more. Download the jar file here and run it as follows:

   java -jar custom_rhino.jar -c big.js > 
   min_shrinksafe.js 2>&1

3. Packer has a few options you can choose to minify your scripts. The normal option removes extra white-space and puts the entire file in one super long line. You can also choose to shrink function as well as encode your script using a base62 algorithm. You can try it online. Although your file size is considerably smaller, depending on the complexity and cleanliness of your code (see JSLint above) using the two options in Packer might introduce errors with your code. In my case I had no problems with them.
4. MemTronic – Hardcore shrinkers out there can try this online tool which produces the smallest file size in my tests. Be warned that this is only for the braveheart coders, has some known issues and may have some side effects.

I have run Prototype.js against these 4 tools and the results are shown below. The results show that you can save at least 20% on your file size without compromising much stability.

CSS Shrinking

1. Clean CSS – This tool creates the best results, reducing the files size while maintaining a nicely formatted and readable CSS file. It has a plethora of options to choose from as well. For example, you can sort the properties of all the selectors which is a godsend for neat-freaks like me. It will also compress your css by converting possible properties to use shorthand notations. You can choose to save your comments.
2. CSS Optimiser – This tool only has one option which is to remove line breaks or not. Does a good job however the final file size does not decrease much if you don’t pick that option, which makes the css tough to read.
3. Icey CSS Compressor – Here is another powerful tool with lots of options to go around. Here are a few of them: Convert colors to hex, combine identical rules, combine properties, combine selectors, remove useless padding and margin. It also outputs in a nice colorful format for you. However there is no option to keep line breaks in tact so you get the output all in one line, and in my case this actually created an error.
4. Flumpcakes Optimiser – This tool has a few useful options such as combining backgrounds, fonts, lists, borders, and style which appear in multiple places. It can also convert RGB to hex and absolute to relative.

I ran the CSS from EarthLink ReaDeR through the top four tools and the results are shown below.

4) Compress your files

The HTTP implementation covers accept-encoding and content-encoding in detail and most browsers today support these methods. Basically when a browser sends a request, it tells the server it would like to have the file back in a compressed format such as gzip or deflate. The server then compresses the file and sends it back, and the browser decompresses the file and renders it in the browser. The most common format used today is GZip. Here is how to setup GZip in two popular web servers.

1. Apache & mod_gzip – If you are running on Apache and have already compiled it with mod_gzip you can easily configure gzip compression by adding these lines to an .htaccess file placed in your web root or your http.conf file.

   mod_gzip_on Yes
   mod_gzip_item_include file \.php$
   mod_gzip_item_include file \.html$
   mod_gzip_item_include mime ^text/html$
   mod_gzip_item_include file \.txt$
   mod_gzip_item_include mime ^text/plain$
   mod_gzip_item_include file \.css$
   mod_gzip_item_include mime ^text/css$
   mod_gzip_item_include file \.js$
   mod_gzip_item_include mime ^application/x-javascript$
   mod_gzip_item_exclude mime ^image/

   If you don’t have access to your .htaccess file but do have php compiled with the zlib module you can rename your javascript files to .php extensions and add this to the top of your file.

   <?php ob_start("ob_gzhandler");
   header("Content-type: text/javascript;charset:UTF-8");
   header("Cache-Control: must-revalidate");
   $offset = 60 * 60 * 24 * 365; // one year
   $ExpStr = "Expires: " .
   gmdate("D, d M Y H:i:s",
   time() + $offset) . " GMT"
   header($ExpStr);
   ?>

2. JBoss and Tomcat – To enable compression in a J2EE environment running Tomcat within JBoss, you can now enable compression by editing your server.xml that sits in the tomcat.sar folder. Just add these attributes to the Connector node:

   <connector port="8080" compression="on" 
   compressionMinSize="300"
   noCompressionUserAgents="gozilla, traviata"
   compressableMimeType="text/html,text/xml,text/css,
   text/javascript, application/x-javascript,
   application/javascript" />

The Results

Finally, here are two pages that use the compressed versions of prototype.js and reader.css, one with gzip compression enabled, and the other without gzip compression enabled. Using the Net tab in FireBug we can easily see that the gzipped version of both the CSS and JavaScript files actually result in less network traffic and faster loads times.

We cut our total throughput by 44 KB or 70%! Also the total load time is cut by 521ms or 51%, basically reduced from 1 second to half a second. If we do some quick math, for a website that gets 1,000,000 unique visitors per day, this is a daily savings of 44GB of bandwidth, and a total of about 145 precious hours saved.

Size in KB	CSS	JavaScript	Total
No Compression	12KB	51KB	63KB
Gzipped	4KB	15KB	19KB
Reduction	8KB 67%	36KB 71%	44KB 70%
Savings for 1 mil uniques/day			44 GB

Time in Milliseconds	CSS	JavaScript	Total
No Compression	281ms	741ms	1022ms
Gzipped	110	391	501ms
Reduction	171ms 61%	350ms 47%	521ms 51%
Savings for 1 mil uniques/day			145 Hrs.