Time To First Tweet

As given at SF Wrb Perf Meet up on 03/20/13

Transcript

1. Time To First Tweet @danwrong Thursday, March 21, 13
2. Thursday, March 21, 13
3. Building for the web is hard... Thursday, March 21, 13
4. ...not hard like mathematics Thursday, March 21, 13
5. Web applications are a series of trade-offs Shit Crap Thursday, March 21, 13
6. Web applications are a series of trade-offs Shit Crap Passable We need to know the web and make trade-offs Thursday, March 21, 13
7. Client-side MVC is the FUTURE Thursday, March 21, 13
8. OBEY JASHKENAS Thursday, March 21, 13
9. “Everything that can be done on the client is done on the client” - Lea Verou Thursday, March 21, 13
10. http://www.youtube.com/watch?v=0T57Ivn5-Pw Thursday, March 21, 13
11. • Infinite scalability • Lower costs • More responsive Thursday, March 21, 13
12. She made all the right trade-offs Thursday, March 21, 13
13. I work at Thursday, March 21, 13
14. We’ve been rebuilding .com’s front end Thursday, March 21, 13
15. http://engineering.twitter.com/2012/05/improving-performance-on-twittercom.html Thursday, March 21, 13
16. • Removed JavaScript (Hashbang) routing • Render all content on the server • Endpoints deliver rendered HTML • Defer loading of JavaScript What we’ve done Thursday, March 21, 13
17. Sound familiar? Thursday, March 21, 13
18. Why the hell did we move back to the server? Thursday, March 21, 13
19. “I'm not happy with the new path of twitter, is a retro-revolution managed by an anti-SPI engineer” “Next, twitter will optimise by rendering HTML from PostgreSQL prepared statements.” “Client-side apps, templating engines and CPUs get faster. The only way to reduce latency to the server is to increase the speed of light.” Why can't u make it so the tweets can be longer? “Sanity prevails! @Twitter are ditching the "#!" and reducing JavaScript! #win #DoingItRight” Thursday, March 21, 13
20. “I'm not happy with the new path of twitter, is a retro-revolution managed by an anti-SPI engineer” “Next, twitter will optimise by rendering HTML from PostgreSQL prepared statements.” “Client-side apps, templating engines and CPUs get faster. The only way to reduce latency to the server is to increase the speed of light.” Why can't u make it so the tweets can be longer? “Sanity prevails! @Twitter are ditching the "#!" and reducing JavaScript! #win #DoingItRight” Thursday, March 21, 13
21. Performance, stability and maintainability Thursday, March 21, 13
22. But what does “fast” even mean? Thursday, March 21, 13
23. Performance is highly contextual Thursday, March 21, 13
24. We care about “Time To First Tweet” Thursday, March 21, 13
25. Time To First Tweet From navigation to the user seeing the timeline Thursday, March 21, 13
26. We measure this (with the Navigation Timing API) Thursday, March 21, 13
27. •Connect: navigation to connection open •Process: connection open to first byte •Response: first byte to last byte of response •Render: last byte until tweet shown* * Measured with a JS timestamp embedded in timeline Thursday, March 21, 13
28. Profile Page, Median, San Francisco Connect Process Response Render Thursday, March 21, 13
29. San Francisco Brazil Profile Page, 95th Percentile Connect Process Response Render Thursday, March 21, 13
30. Loading JavaScript... Thursday, March 21, 13
31. 1. Get initial page 2.Get CSS 3.Get JavaScript 4.Get data 5. Render template Rendering on the client Thursday, March 21, 13
32. 1. Get initial page 2.Get CSS 3.Get JavaScript 4.Get data 5. Render template Rendering on the client Thursday, March 21, 13
33. 1. Get initial page 2.Get CSS 3.Get JavaScript 4.Get data 5. Render template Rendering on the server Thursday, March 21, 13
34. 1. Less to send over the wire 2.Less variance across browsers/devices 3.Less tests to run across multiple browsers 4.Less hard to track down errors Less code running on the browser Thursday, March 21, 13
35. • Consume the REST API • Less hardware required • Less data over the wire • Faster navigation once app has loaded But if we render on the client-side... Thursday, March 21, 13
36. • Consume the REST API • Less hardware required • Less data over the wire • Faster navigation once app has loaded But if we render on the client-side PJAX and caching Thursday, March 21, 13
37. Layering on pushState support • We want fast in-app navigation • Avoid full page refreshes for newer browsers • Ability to keep assets/former pages in memory • Keep simple indexability, browser compat etc • We can have the best of both worlds Thursday, March 21, 13
38. http://engineering.twitter.com/2012/12/implementing-pushstate-for-twittercom_7.html Thursday, March 21, 13
39. In the browser.... On click, if history API supported then intercept link and request the link’s URL via XHR Thursday, March 21, 13
40. On the server... If request comes via XHR send just the partial update, otherwise send the entire HTML page Thursday, March 21, 13
41. Wrestling control of JavaScript loading • We moved to modules (CommonJS via AMD) • Decouples loading from evaluation • Build tool spiders dependencies and make bundles • Now we can play with the loading without changing the code • Lazy loading, Parallel loading, different bundles...needs its own presentation Thursday, March 21, 13
42. Did we win? Thursday, March 21, 13
43. Chrome, San Francisco Before After Thursday, March 21, 13
44. Chrome, San Francisco Before After Thursday, March 21, 13
45. IE 8, San Francisco Before After Thursday, March 21, 13
46. Cut the 95th percentile in SF by 75% Thursday, March 21, 13
47. Before After Connect Process Response Render Profile Page, 95th Percentile, San Francisco Thursday, March 21, 13
48. Before After Connect Process Response Render Profile Page, 95th Percentile, Brazil Thursday, March 21, 13
49. Thursday, March 21, 13
50. After Good start. What next? Connect Process Response Render Thursday, March 21, 13
51. After Finagle based, async app server Concurrent data fetches Thursday, March 21, 13
52. After Streaming responses with chunked encoding Send <head> early, start loading CSS Browser gets start of response earlier Thursday, March 21, 13
53. Wish us luck... Thursday, March 21, 13
54. Identify the needs of your users Thursday, March 21, 13
55. Measure them Thursday, March 21, 13
56. Make your own trade-offs Thursday, March 21, 13
57. Client-side is not the future Thursday, March 21, 13
58. Server-side is not the future Thursday, March 21, 13
59. Making appropriate use of all the tools you have is the future Thursday, March 21, 13
60. • HTTP Caching • History API • In Memory Caching • Streaming response bodies • Concurrent data fetches • Lazy loading • and so much more... Thursday, March 21, 13
61. One size fits all is overrated Thursday, March 21, 13
62. Questions? twitter.com/jobs @danwrong twitter.github.com/flight Thursday, March 21, 13
63. https://twitter-flight-night.eventbrite.com/ Thursday, March 21, 13