Twitter Gets Performance Dose

Back in 2010 Twitter made a huge revamp both in the front end UI and the architecture that they used previous to the update. The architecture adapted broke a new path and opened a few others for the micro-blogging site to use new features and functionality that came across as a result. But that also meant that while the front end JS was able to interact with the Twitter REST APIs directly (just like the mobile clients), it presented a few optimization roadblocks that could only be handled at the server end.

So, it seems Twitter finally decided to move  some control back to the server so as to have more control of rendering the pages to the back layer as opposed to what it is now. This change in control as Dan Webb talks about in his post here, allows them to gain some speed in loading the pages; thus making them load 5 times faster then they were before the changes were done. This is as he says is across the browsers, so no partiality :).

Apart from the control moved to the servers at the back of the show, a modular JS application seems to have been introduced. This change will allow Twitter to provide its users with a fully featured interactive experience. This will also help them quickly provide some features to their users apart from take advantage of the rapid changes in the browser technology. The changes have started to roll out starting with the re-architecture on their most visited Tweet permalink page. The features and performance enhancements will continue to roll over the next weeks, while we leave you with the details of the changes as described by Dan Webb on his blog post:

Twitter removes hashbangs

No More #!

The first thing that you might notice is that permalink URLs are now simpler: they no longer use the hashbang (#!). While hashbang-style URLs have a handful of limitations, our primary reason for this change is to improve initial page-load performance.

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.

Reducing time to First Tweet 

Before starting any of this work we added instrumentation to find the performance pain points and identify which categories of users we could serve better. The most important metric we used was "time to first Tweet". This is a measurement we took from a sample of users, (using the Navigation Timing API) of the amount of time it takes from navigation (clicking the link) to viewing the first Tweet on each page's timeline. The metric gives us a good idea of how snappy the site feels... Read more

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 needed to get a firm grip on our dependencies... Read more

What's Next

We're currently rolling out this new architecture across the 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... Read more