01 4 / 2008
JavaScript is a performance killer – so says the team at Apple [web/performance/tests]
Apparently, Apple’s Webkit team (the Superstars behind Safari) discovered something so fundamental, I’m actually thinking of naming my second child “Apple”, if that’s all right with Gwenth Paltrow?
After running some tests on the Wall Street Journal’s home page, they noted that external calls to JavaScript prevent the full parallel load of information to a web browser. While JavaScript is loading, web users are subject to waiting, just as other packets are waiting to connect to the browser. All browsers load packets in parallel instead of sequentially, but JavaScript uses the DOM method document.write, to add more XHTML, HTML, images, etc to the web page after it has been displayed. Because of this, the browser waits until the JavaScript has completed it’s document.write call which all but negates the parallel load process.
From an average users perspective, this latency issue is subtle, and since most of all web users have high bandwidth connections, it’s almost a none issue. Just take a look at this graph.
We (web users) have become accustomed to pages that are somewhat slow, but stocked full of GUI goodness. It’s like a big treat for us; the longer we wait, the better the eye candy – or at least it seems.
In my QA frame of mind – this latency issue is a note worth keeping in my trusted notebook. White box testers can keep this in mind if checking that JavaScript is compressed, or all compiled into one file, or embedded in the HTML – which would considerably improve this latency issue – but is highly unlikely to become the catch all solution. And if you’re conducting a load, or performance test, here is another possible cause (excuse).
Apple’s Webkit team are already hard at work building a solution that can allow JavaScript to stick with the ebb and flow of HTML. Hopefully, their improvements may make our broadband move as fast as Comcast mice.
