Twitter has announced updates to its website which they claim has decreased page load times down to 20% of what they were previously. The old system used the browser to render JavaScript which was groundbreaking at the time. It does have a disadvantage, however, in that it misses out on optimizations only available to the server.

As such, Twitter is bringing some of the front-end grunt work back onto the servers in order to speed up load times. As Twitter says, "To connect you to information in real time, it's important for Twitter to be fast." Part of the change is not using # (hashbang) in the permalink URLs to improve initial load times.

Another update is to decrease the "time to first Tweet." This is where Twitter has managed to decrease page load times to 1/5 of what they were previously. The general, watered down version of how this works is to take the JavaScript out of the equation and render the content on the server. This removes the slowdown from old browsers or slow machines. Twitter explains in more detail:

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.

 

Looking at the components that make up this measurement, 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. The problem is further exacerbated if you do not have a high-specification machine or if you're running an older browser. The bottom line is that a client-side architecture leads to slower performance because most of the code is being executed on our user's machines rather than our own.

 

There are a variety of options for improving the performance of our JavaScript, but we wanted to do even better. 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.

There are many other improvements discussed in the post on Twitter's engineering blog, so I encourage you to check it out for yourself if you are interested. The Twitter blog post can be found on Twitter's engineering blog here.