By Matthew Holloway
Why are some web pages faster than others? How are browsers going to change over the next few years? These are questions that web developers should know the answers to, but often don't.
A little known fact about the popular browsers in use today – Firefox, Chrome, Internet Explorer and Safari – is that they all began almost twenty years ago, in the same two year period of the late '90s, during the .COM boom. The Gecko Engine (Firefox) and Trident (Internet Explorer) both started development in 1997, with Webkit (Safari and Chrome) following in 1998. That was years before Intel shipped consumer multi-core CPUs, before AJAX, before JavaScript was taken seriously, and before anyone expected web pages to achieve 60 frames of animation each second. Fundamental software architecture decisions were made at this time and these fundamentals have proven very hard to readdress despite nearly 20 years of effort.
Making a new browser is a risky engineering challenge. Browsers take years to prototype and many more years to productionise. Even then it still might not succeed. While it's easy to make a toy browser that is faster at one thing, a real browser has to be well-rounded, it has to implement dozens of standards, and it has to be better than existing browsers. Due to these difficulties all popular browsers have instead chosen to optimise their late 1990s legacy, rather than starting anew (and to be fair, this has been successful-for the most part).
But one design decision has plagued all browsers: single-threading,
Being single-threaded means that one part of the browser can delay other parts from running1. If JavaScript takes too long to run it can delay CSS animation, or user clicks and button taps. If a CSS drop shadow takes a long time to compute2, then that can delay JavaScript. This all makes for a sluggish web page. Some of these issues aren't the fault of browsers themselves because they're required by W3C Web Standards, but others are simply browser flaws. There's no good reason why an