[condiment]

What's interesting about Twitter's model is that no data actually comes down to the user when they first request a tweet. Twitter builds the page, loads the layout, and initializes the client-side script, which makes a JSON request to pull an individual tweet after everything has loaded.

This means that to get the requested information on first load, the user has to wait for a 2MB download, followed by another roundtrip Ajax request to twitters tweet retrieval API. This results in the perception of a slow page load, even though the tweet itself comes down the pipe in only 100ms.

In my view, Twitter is an excellent case study in some of the pitfalls of thick-client application design. Mainly that ignoring the first-time-use case will result in widespread perception among users that your app is slow, even when every page view after the first is lightning fast.

[abraham]

That is not entirely true. If you are authenticated your home_timeline is embedded in the page for instant rendering. Once Twitter moves away from #!'s individual tweets will be embedded as well.

[dlikhten]

Twitter is heavily optimized for multi-requests. The first is big (analogous to downloading an application) while every other request is miniscule in comparison. Hell, fetching tons of data from someone is tiny because its data only, not JS/CSS/etc

[simonw]

"Twitter is heavily optimized for multi-requests " - Which turns out to not be a very good idea, because it means that clicking on links from other sites to Twitter results in a huge performance hit - even if my browser has cached the assets, it still takes several seconds to execute all of that JavaScript, paint the CSS etc.

[dasil003]

It takes several seconds? How fast is your computer? I primarily use Twitter's web interface and it never felt slow compared to anything else, but then I run Chrome on a 2010 MBP, so I can imagine it would be slower on older hardware and browsers.