Twitter Rolls Twitter.com Back to a Server-Side Architecture

http://engineering.twitter.com/2012/05/improving-performance-on-twittercom.html

by apievangelist • 14 years ago

131 54 14 years ago

engineering.twitter.com

from what i can tell, they are just rendering the initial page load on the server now.

wahnfrieden2• 14 years ago

Not at all surprising then except that it shows they're confident enough in their choice of clientside rendering to invest more deeply in it (by optimizing the initial load now.) What a misleading title.

akkartik• 14 years ago

To mark this momentous occasion I'm going to go back and reread Steve Yegge on Amazon's SOA.

http://plus.google.com/112678702228711889851/posts/eVeouesva...

sunwooz• 14 years ago

Sorry, but what's the difference between using a web application architecture and using a server side architecture? I'm curious!

bsaunder• 14 years ago

I think the general difference is the location of the controller. On more traditional web frameworks, the controller is typically entirely on the server. The model twitter adopted moves the controller to the browser which just invokes services on the web server via API calls.

Not really sure "web application architecture" unambiguously indicates "client side controller", but it does in this dialog when contrasted with "server side architecture".

wangweij• 14 years ago

By saying "web app", there is an app inside the web browser, while "server side" means the browser only sees the final content.

wahnfrieden2• 14 years ago

Serverside rendering: HTML is rendered on the server and sen to the client to display.

Clientside rendering: data is sent to the client, which uses JavaScript to render templates clientside using that data as input, to output HTML for display (or for mutating the DOM directly).

That's the essential difference.

anextio2• 14 years ago

Are you familiar with Model-View-Controller?

In this case it would be moving some of the controller logic (the parts responsible for rendering views and dispatching events from the UI) to the browser, and using an API to communicate with the model (and the rest of the controller).

So, if I'm going to display a page of 10 tweets, in the classic server side architecture, I load the tweets, render a view template based on a context containing those tweets, and then send the HTML to the browser.

In an API-based web application architecture like this, I _always_ send the same HTML, which is cached in memory and is almost a no-op to send to the browser, then the client side scripting looks at the URL of the page and makes a call to a JSON or XML API that will result in those 10 tweets. These tweets are then rendered on the client side by the browser.

This is beneficial in a few ways:

* You can re-use the exact same API and expose it to third parties, who can then write apps with all the functionality of your webapp, and you've one less thing to test.

* Rendering a template can be a (relatively) time-consuming operation that may require some I/O. On a single-threaded platform like Node.js, where you simply want to dispatch an event (request) as fast as possible and move on, rendering a template takes a lot of time.

* If the time is going to be spent rendering that template anyway, you may as well crowdsource it and let the browser handle it. The browser is probably only processing one page load at a time, whereas your servers could be processing thousands or millions.

The cons of using this system are related to the benefits:

* The API you use is likely to suffer from Abstraction Inversion[1], or if that's intentionally avoided, a Leaky Abstraction[2]. The reason for this is that there may be some pages to be rendered that require more complex, or less abstract, queries on the data. On the server you could easily issue a JOIN query, but it may not make sense to expose such a thing directly via a RESTful interface. Therefore your application may end up firing numerous API requests and joining the results manually in order to complete a request. If you DO expose this functionality, it will probably end up looking very out of place and very specific.

* The extra time spent by the browser may not be suitable in all cases. It poses a number of accessibility and performance problems on certain devices. I may not be able to use a certain website with a screen reader because of this, or I may not be able to view it on an ancient version of Opera running on a shitty old phone over 3G. Even on a modern smartphone, the time taken from seeing a Twitter page's header and background with the loading indicator to actually seing the content was a pain in the ass.

* Depending on your application and architecture, you may be able to deliver even better performance by caching rendered templates than by offloading it to the browser. For example, I believe Reddit pretty much prerenders and caches every single page on the site, which is why most stuff loads instantly, but at peak times it takes a while to load the message inbox, or the 80th page of posts. This might be made even worse by extra API calls and client side rendering.

[1] http://en.wikipedia.org/wiki/Abstraction_inversion [2] http://en.wikipedia.org/wiki/Leaky_abstraction

mark_story• 14 years ago

That was a really great explanation :D

dansingerman• 14 years ago

A lot of that could be described as "lessons I have learned on recent projects". I wish I had read (and grokked) this post 18 months ago.

harichinnan• 14 years ago

I wonder if this could be remedied by using a front end Web App Server consuming the JSON API. So you would have a JSON API server and a front end Web App say in Node using the API as a database. You would have the advantages of building a SOA architecture, letting the API server do the heavy lifting. And you could reuse a well tested API for Mobile Apps. I would think a Meteor.JS like front end would be an ideal solution for low traffic websites(Not twitter!)

lazugod• 14 years ago

Most websites create the webpage on the server. Once your browser receives it, it parses and displays it once. Compare it to a salad - most restaurants prepare their salads in the kitchen. The waiter takes one trip to deliver your plate, and all you have to do is eat.

What Twitter was experimenting with was a thick client. The initial page load would contain little more than the basic Twitter architecture and a URL, and this architecture would send off more requests (individual tweet, profiles, responses, lists) based on the contents of the URL, updating the page to fit what it gets back each time.

In a salad bar, you don't get one plate. There's a whole barrage of vegetation to select from, and you have to walk around yourself to get any of it. You also have to spend time deciding what you want. Metaphorically, the salad-eater is your web browser, and that time it takes to send and receive more requests, as well as make decisions and display the results, turns a 140-character message into a slowly loading behemoth.

kijin• 14 years ago

There's still a shebang in the URL. If I enter a URL without a shebang, it redirects to one that contains a shebang. Since the browser won't include the fragment in the request, how does the server know which page to send back without using JavaScript to make another request? So it's not really "server side", not even the initial page load.

garindra• 14 years ago

They can technically look at the referrer header value and look at the URL path of the referring page.

ryannielsen• 14 years ago

If you read Twitter's actual announcement (http://engineering.twitter.com/2012/05/improving-performance...), they've only rolled out the described changes to the tweet permalink page. Other pages will see these changes over the coming weeks.

grampajoe• 14 years ago

The client-side approach would work great if they didn't try to cram in so many features.

DanI-S• 14 years ago

Twitter is used in a lot of developing countries, through a lot of outdated browsers, on a lot of slow computers. I'd imagine that this plays into their choices somewhat.

demetris• 14 years ago

Here is the original post, by the Twitter engineers:

http://engineering.twitter.com/2012/05/improving-performance...

staunch• 14 years ago

Maybe a mod will swap it for the blogspam. nod

n8agrin• 14 years ago

I posted it immediately after it was announced. It got ~20 quick up votes but never landed on the home page: http://news.ycombinator.com/item?id=4040049

tnash• 14 years ago

I think this is great. The browser isn't an OS, it's a portal. It's already running on an OS. It didn't work for mobile (remember Apple was all about the web apps back in the day), it shouldn't work for desktop.

bceagle2• 14 years ago

It is always a little misleading reading articles like this because they don't get into many of the details. At the end of the day, you need to build to meet the requirements of your target audience. It doesn't really make sense to think that just because Twitter does something, then you should do it. The optimizations they are talking about may be so specific that they don't even apply to the common mid-sized web app. I think that the overall client-side architecture has broken new ground and does provide benefits that make sense for a lot of sites. I wouldn't think twice about not using the client side architecture just because of Twitter making a change.

Also, as some people already noted, Twitter didn't abandon client side rendering. If you go on the site now, you will still get redirected to the #! page.

jsprinkles2• 14 years ago

This entry doesn't get into details because it's blog spam, submitted by the blogger himself.

You want this: http://engineering.twitter.com/2012/05/improving-performance...

apievangelist2• 14 years ago

You guys are the blog detail. Your comments are the reason for short post.

bceagle2• 14 years ago

Ah, yes, I did not see that. Well, after reading the article on the Twitter Engineering site, I think this answers my question about the reasons for the switch:

------- 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. ------

My original point is still valid, though. Twitter is dealing with a situation where they have a lot of code, a boat load of users and the need to squeeze every bit of optimization out of the site. The initial download of the JavaScript is a one time hit that would not make a bit of difference for most sites. More than likely they were also concerned about the proliferation of API calls due to increased functionality over time. I still think that if your combined and minified JS is < 1MB and you are able to keep your API calls relatively simple, the client side architecture is still pretty powerful.

Besides, in many cases I think you can fix performance issues on a one off basis where a page that gets too slow because of heavy JS and/or API proliferation could move server side if that makes sense while the rest of the app rendering stays client side. It doesn't have to be all or nothing.

swah• 14 years ago

But Twitter.com is slow (like a couple seconds to load twitter.com/#!/someone) even if you're using the latest Chrome browser - it can't be just fault of the client side architecture...

If the initial JSON was coming bundled with the page, the only reason for the slowdown is parsing JS? I thought that was what browsers were good at those days...

InclinedPlane• 14 years ago

On a cold load you'd have to transfer 2 megs of mostly JS over the wire, and only after all that was done could JS start rendering. Even with a fast 10 megabits/s line that will still take upwards of 2 seconds just to get to square 1.

callumjones• 14 years ago

I wouldn't call it a rollback completely, but an improvement on the first time load. The whole Twitter page is rendered initially server side but then any subsequent request is made by JSON calls and rendered client side -- probably the best approach given the time it took for Twitter.com to load.

joshfraser• 14 years ago

I'm glad to see this. While it was an interesting experiment for Twitter to undergo, their front end performance really took a hit. I expect they'll see their usage numbers on twitter.com start going up again as they fix things.

SCdF• 14 years ago

Thank the creator. It was a blindingly unnecessary fashion statement that caused more problems than it solves, and I wish it safe passage on its way to the closet of failed experiments.

j45• 14 years ago

Seeing as the web is more service oriented than object oriented..

Are we surprised to see a step towards SOA (presumably from OO that was also at the service layer)?

For me Web / mobile apps that are architected from a primarily OO perspective can turn out very differently (often with unique OO bottlenecks) than apps architected from a service-first perspective, using OO to fulfill services.

parasubvert2• 14 years ago

This isn't a rollback of the API-oriented architecture, it's a rescue of a bunch of wrong-headed design mistakes, like forcing the rendering of individual status pages through a JavaScript function, using a hash-bang URI.

One of the major drivers behind the constraints in a RESTful architecture is user-perceived response time. Routing all content through "code on demand", which is effectively what you're doing when you force a JavaScript function to do all the rendering, instead of the browser itself, is not taking advantage of the fast, incremental rendering nature of plain old HTML generated by the server.

One can still design good API-oriented URIs with a server-side approach, you're just providing different serializations of the same resource (a nice HTML one and a JSON one for API access).... so there's nothing fundamental that Twitter has lost or abandoned here. They're just using the web better.

stdbrouw3• 14 years ago

HTML is HTML. Why would it be any easier for the browser to render server-generated HTML incrementally, versus client-generated HTML?

parasubvert2• 14 years ago

Not easier... just faster.

Server-generated HTML: the browser GETs it and renders it as it streams through.

Client-generated HTML: the server GETs an HTML page with a JavaScript link, then GETs a JavaScript .js, then executes it, the jS GETs the JSON, then translates that into HTML at the DOM level.

The latter is arguably something that will lead to a better user experience once the page is in a "steady state", i.e. all dependent representations are loaded into the browser and rendered. But relying on it for "first render" makes for a slow experience when (e.g.) clicking on a link to an individual Twitter status.

Semaphor• 14 years ago

Probably because the browser doesn't have to generate the HTML before he can render it?

And generally from a user perspective you merge the steps "show site" & "show content" back to "show site with content". So even if the server takes just as long to generate the HTML (and I don't think that's the case) the perceived speed will be higher when the site loads and that's it compared to loading, showing something and loading again to show the rest.

edit: parasubvert was faster and said the same thing with fancier words;)

look_lookatme• 14 years ago

On the initial request, Twitter has no way of knowing what resource was intended to be rendered when it's prefixed by a fragment identifier in the URL. There is no reason why having javascript render the page has to be perceptibly slower than shipping down the page in HTML. Hashbang URLs are the sole issue here, not javascript.

jemeshsu• 14 years ago

Twitter is doing the best approach which is a mix of both client-side and server-side. It is not an either or situation.

halayli• 14 years ago

I feel they were doing it wrong. If they preloaded the page with bootstrapped data + templates then it should be as fast.

chintan• 14 years ago

2011-02-11: "We've made a tradeoff, however, in making twitter.com into an application using the hash, which is that it now cannot be both an app and a site at the same time."

http://www.adequatelygood.com/2011/2/Thoughts-on-the-Hashban...

ComputerGuru• 14 years ago

I am so proud of twitter right now, that I feel words will fail me, so I shall keep this short and to the point:

It takes serious balls to admit you were wrong after you kicked off an entire avalanche that has been breaking the web ever since. Yes, a lot of us knew then it was a ridiculously bad idea and we all said so; but for them to actually take this advice after going so out of their way to go completely client-side is just fantastic. Kudos, twitter folk!

marknutter• 14 years ago

For some web apps, namely ones that don't get linked to often like Twitter or ones that are truly trying to behave like desktop applications, hash-bang urls are really the only option for maintaining state in browsers that don't support HTML5 push states yet. I think the backlash against Twitter's and Gawker's use of them is warranted, but not the hyperbole that hash-bangs, no matter the context, "break the web."

kamweti• 14 years ago

I welcome this but sticking with the fastest twitter client yet - their mobile site. i use it even on desktop plus they recently made improvements on it

http://news.ycombinator.com/item?id=2977580

Twitter Rolls Twitter.com Back to a Server-Side Architecture

Related Stories