Time To First Tweet

As delivered at Velocity 2012 by myself and @sayrer

Transcript

1. Time To First Tweet @danwrong @sayrer Wednesday, June 27, 12
2. We work at Wednesday, June 27, 12
3. We’ve been rebuilding .com’s front end Wednesday, June 27, 12
4. http://engineering.twitter.com/2012/05/improving-performance-on-twittercom.html Wednesday, June 27, 12
5. Performance is highly contextual Wednesday, June 27, 12
6. We care about “Time To First Tweet” Wednesday, June 27, 12
7. Time To First Tweet From navigation to the user seeing the timeline Wednesday, June 27, 12
8. We measure this with the Navigation Timing API Wednesday, June 27, 12
9. Navigation Timing API • Supported in: IE 9, Firefox 7 and Chrome • Represents a vast majority of twitter.com users • We capture data from a small % of users Wednesday, June 27, 12
10. •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 Wednesday, June 27, 12
11. Improving the Time To First Tweet Wednesday, June 27, 12
12. Logged Out Pages Wednesday, June 27, 12
13. Loading JavaScript... Wednesday, June 27, 12
14. Profile Page, Median, San Francisco Connect Process Response Render Wednesday, June 27, 12
15. San Francisco Brazil Profile Page, 95th Percentile Connect Process Response Render Wednesday, June 27, 12
16. Home Timeline Wednesday, June 27, 12
17. Home Timeline Hydrated Wednesday, June 27, 12
18. Problem Wednesday, June 27, 12
19. Suboptimal Page Flow 2? 1 3 Wednesday, June 27, 12
20. Templating on the client Hogan.js Mustache.js Pre-compiled Wednesday, June 27, 12
21. Templating on the server Eckersley Mustache.rb Mustache.java Wednesday, June 27, 12
22. Eckersley? C/C++ with Ruby bindings. Wednesday, June 27, 12
23. Template-compatible Evolution Client: Hogan.js Server: Rails Server: JVM Wednesday, June 27, 12
24. Initial HTML Deferred Loading of JS Wednesday, June 27, 12
25. Migrating Away From Hashbang Discover Permalink Events Wednesday, June 27, 12
26. Making JavaScript work for us Wednesday, June 27, 12
27. Loading JavaScript • 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 Wednesday, June 27, 12
28. 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 index-ability, browser compat etc • We can have the best of both worlds Wednesday, June 27, 12
29. In the browser.... On click, if history API supported then intercept link and request the link’s URL via XHR Wednesday, June 27, 12
30. On the server... If request comes via XHR send just the partial update, otherwise send the entire HTML page Wednesday, June 27, 12
31. So...did it work? Wednesday, June 27, 12
32. Chrome, San Francisco Before After Wednesday, June 27, 12
33. Chrome, San Francisco Before After Wednesday, June 27, 12
34. IE 8, San Francisco Before After Wednesday, June 27, 12
35. Cut the 95th percentile in SF by 75% Wednesday, June 27, 12
36. Before After Connect Process Response Render Profile Page, 95th Percentile, San Francisco Wednesday, June 27, 12
37. Before After Connect Process Response Render Profile Page, 95th Percentile, Brazil Wednesday, June 27, 12
38. What’s next? • We aren’t done yet • Replace Rails with an async, JVM-based server • Concurrent data fetches • Chunked body encoding, streamed responses Wednesday, June 27, 12
39. Questions? twitter.com/jobs @danwrong @sayrer Wednesday, June 27, 12