3 ms·

I think the post is relavant (today) considering Dan (the author) was instrumental in removing the hashbangs. Twitter's Engineering Blog Post from today: http

I think the post is relavant (today) considering Dan (the author) was instrumental in removing the hashbangs. Twitter's Engineering Blog Post from today: http://engineering.twitter.com/2012/05/improving-performance-on-twittercom.html http://engineering.twitter.com/2012/05/improving-performance...

mattmanser 14y ago
Weird thing they seem to have completely misidentified the reason why their architecture was slow: 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. From a brief look I had at it a few months ago they were sending a 1.5Mb javascript file which contained a template for every single action you could ever perform on twitter. Because it was squished I assume it got invalidated a lot as they made any tweak to their UI. That seemed to be the greater problem rather than these mysterious execution times. Seriously, who has ever had a performance problem transforming a bit of JSON with something like jQuery.tmpl or mustache? They ultimately seem to have thrown the baby out with the bath water. Then again we had this discussion about client v server rendering when 37signals posted their new architecture, I understand there are advantage of doing the template transforms serverside.
- simonw 14y ago
  "Seriously, who has ever had a performance problem transforming a bit of JSON with something like jQuery.tmpl or mustache?" Mobile devices. Just parsing and executing a big chunk of JavaScript (like the jQuery library itself) can take the best part of a second on many mobile phones.
- acdha 14y ago
  Searching through ShowSlow.com provides more visibility: http://www.showslow.com/details/92778/http://twitter.com/#!/yellowblog http://www.showslow.com/details/92778/http://twitter.com/#!/... That's 1,887 ms to render anything and almost a full second of JavaScript execution time. Waterfall graphs show a similar story: they pushed everything past the document load event so the monitoring tools are a bit off: http://www.webpagetest.org/result/120414_9W_3Z15P/ http://www.webpagetest.org/result/120414_9W_3Z15P/ shows an acceptable 1.4 second start of render, which isn't great but acceptable, but looking at the actual video shows that's merely how long it took to render a tiny part of the page - displaying the content which the user actually wanted about took over 8 seconds! http://www.webpagetest.org/video/view.php?id=120414_2a4075f2852e67c72bfc9ffa1733406476e11845 http://www.webpagetest.org/video/view.php?id=120414_2a4075f2...

mattmanser 14y ago

Weird thing they seem to have completely misidentified the reason why their architecture was slow: 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. From a brief look I had at it a few months ago they were sending a 1.5Mb javascript file which contained a template for every single action you could ever perform on twitter. Because it was squished I assume it got invalidated a lot as they made any tweak to their UI. That seemed to be the greater problem rather than these mysterious execution times. Seriously, who has ever had a performance problem transforming a bit of JSON with something like jQuery.tmpl or mustache? They ultimately seem to have thrown the baby out with the bath water. Then again we had this discussion about client v server rendering when 37signals posted their new architecture, I understand there are advantage of doing the template transforms serverside.

simonw 14y ago
"Seriously, who has ever had a performance problem transforming a bit of JSON with something like jQuery.tmpl or mustache?" Mobile devices. Just parsing and executing a big chunk of JavaScript (like the jQuery library itself) can take the best part of a second on many mobile phones.
acdha 14y ago
Searching through ShowSlow.com provides more visibility: http://www.showslow.com/details/92778/http://twitter.com/#!/yellowblog http://www.showslow.com/details/92778/http://twitter.com/#!/... That's 1,887 ms to render anything and almost a full second of JavaScript execution time. Waterfall graphs show a similar story: they pushed everything past the document load event so the monitoring tools are a bit off: http://www.webpagetest.org/result/120414_9W_3Z15P/ http://www.webpagetest.org/result/120414_9W_3Z15P/ shows an acceptable 1.4 second start of render, which isn't great but acceptable, but looking at the actual video shows that's merely how long it took to render a tiny part of the page - displaying the content which the user actually wanted about took over 8 seconds! http://www.webpagetest.org/video/view.php?id=120414_2a4075f2852e67c72bfc9ffa1733406476e11845 http://www.webpagetest.org/video/view.php?id=120414_2a4075f2...