Twitter Eliminates 'hashbang', Reduces "time to first tweet", Introduced CommonJS Modules

Twitter rolled out the re-architected version of one of its most visited pages across the site, the Tweet permalink page to boost the performance of the Twitter.com site. "Once our pages are running on this new foundation, we will do more to further improve performance. For example, we will implement the History API to allow […]

Twitter rolled out the re-architected version of one of its most visited pages across the site, the Tweet permalink page to boost the performance of the Twitter.com site. "Once our pages are running on this new foundation, we will do more to further improve performance. For example, we will implement the History API to allow partial page reloads in browsers that support it, and begin to overhaul the server side of the application," explains Dan Webb, Engineering Manager, Web Core team.

"We'll continue to roll out this new framework to the rest of the site in the coming weeks, so we'd like to take you on a tour of some of the improvements," stated Webb.

"To improve the twitter.com experience for everyone, we've been working to take back control of our front-end performance by moving the rendering to the server. This has allowed us to drop our initial page load times to 1/5th of what they were previously and reduce differences in performance across browsers," Twitter said.

"On top of the rendered pages, we asynchronously bootstrap a new modular JavaScript application to provide the fully-featured interactive experience our users expect. This new framework will help us rapidly develop new Twitter features, take advantage of new browser technology, and ultimately provide the best experience to as many people as possible," Webb said.

Webb notes, the first thing that you might notice is that permalink URLs are now simpler: they no longer use the hashbang (#!). "When you come to twitter.com, we want you to see content as soon as possible. With hashbang URLs, the browser needs to download an HTML page, download and execute some JavaScript, recognize the hashbang path (which is only visible to the browser), then fetch and render the content for that URL. By removing the need to handle routing on the client, we remove many of these steps and reduce the time it takes for you to find out what's happening on twitter.com," Webb explains.

He said they've also reduced "time to first tweet" -- "We discovered that the raw parsing and execution of JavaScript caused massive outliers in perceived rendering speed. In our fully client-side architecture, you don't see anything until our JavaScript is downloaded and executed[…]We took the execution of JavaScript completely out of our render path. By rendering our page content on the server and deferring all JavaScript execution until well after that content has been rendered, we've dropped the time to first Tweet to one-fifth of what it was," he said.

Loading only what we need:

"Now that we're delivering page content faster, the next step is to ensure that our JavaScript is loaded and the application is interactive as soon as possible. To do that, we need to minimize the amount of JavaScript we use: smaller payload over the wire, fewer lines of code to parse, faster to execute. To make sure we only download the JavaScript necessary for the page to work, "we opted to arrange all our code as CommonJS modules, delivered via AMD," explained Webb.

"Modules let us separate the loading and the evaluation of our code. This means that we can bundle our code in the most efficient manner for delivery and leave the evaluation order up to the dependency loader. Our JavaScript bundles are built programmatically by a tool, similar to the RequireJS optimizer, that crawls each file to build a dependency tree. This dependency tree lets us design how we bundle our code, and rather than downloading the kitchen sink every time, we only download the code we need -- and then only execute that code when required by the application," he concludes.