Time To First Tweet - Speaker Deck

Slide 1

Slide 1 text

Time To First Tweet @danwrong Thursday, March 21, 13

Slide 2

Slide 2 text

Thursday, March 21, 13

Slide 3

Slide 3 text

Building for the web is hard... Thursday, March 21, 13

Slide 4

Slide 4 text

...not hard like mathematics Thursday, March 21, 13

Slide 5

Slide 5 text

Web applications are a series of trade-offs Shit Crap Thursday, March 21, 13

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

Client-side MVC is the FUTURE Thursday, March 21, 13

Slide 8

Slide 8 text

OBEY JASHKENAS Thursday, March 21, 13

Slide 9

Slide 9 text

“Everything that can be done on the client is done on the client” - Lea Verou Thursday, March 21, 13

Slide 10

Slide 10 text

http://www.youtube.com/watch?v=0T57Ivn5-Pw Thursday, March 21, 13

Slide 11

Slide 11 text

• Infinite scalability • Lower costs • More responsive Thursday, March 21, 13

Slide 12

Slide 12 text

She made all the right trade-offs Thursday, March 21, 13

Slide 13

Slide 13 text

I work at Thursday, March 21, 13

Slide 14

Slide 14 text

We’ve been rebuilding .com’s front end Thursday, March 21, 13

Slide 15

Slide 15 text

http://engineering.twitter.com/2012/05/improving-performance-on-twittercom.html Thursday, March 21, 13

Slide 16

Slide 16 text

• 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

Slide 17

Slide 17 text

Sound familiar? Thursday, March 21, 13

Slide 18

Slide 18 text

Why the hell did we move back to the server? Thursday, March 21, 13

Slide 19

Slide 19 text

“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

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Performance, stability and maintainability Thursday, March 21, 13

Slide 22

Slide 22 text

But what does “fast” even mean? Thursday, March 21, 13

Slide 23

Slide 23 text

Performance is highly contextual Thursday, March 21, 13

Slide 24

Slide 24 text

We care about “Time To First Tweet” Thursday, March 21, 13

Slide 25

Slide 25 text

Time To First Tweet From navigation to the user seeing the timeline Thursday, March 21, 13

Slide 26

Slide 26 text

We measure this (with the Navigation Timing API) Thursday, March 21, 13

Slide 27

Slide 27 text

•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

Slide 28

Slide 28 text

Profile Page, Median, San Francisco Connect Process Response Render Thursday, March 21, 13

Slide 29

Slide 29 text

San Francisco Brazil Profile Page, 95th Percentile Connect Process Response Render Thursday, March 21, 13

Slide 30

Slide 30 text

Loading JavaScript... Thursday, March 21, 13

Slide 31

Slide 31 text

1. Get initial page 2.Get CSS 3.Get JavaScript 4.Get data 5. Render template Rendering on the client Thursday, March 21, 13

Slide 32

Slide 32 text

1. Get initial page 2.Get CSS 3.Get JavaScript 4.Get data 5. Render template Rendering on the client Thursday, March 21, 13

Slide 33

Slide 33 text

1. Get initial page 2.Get CSS 3.Get JavaScript 4.Get data 5. Render template Rendering on the server Thursday, March 21, 13

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

• 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

Slide 36

Slide 36 text

• 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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

http://engineering.twitter.com/2012/12/implementing-pushstate-for-twittercom_7.html Thursday, March 21, 13

Slide 39

Slide 39 text

In the browser.... On click, if history API supported then intercept link and request the link’s URL via XHR Thursday, March 21, 13

Slide 40

Slide 40 text

On the server... If request comes via XHR send just the partial update, otherwise send the entire HTML page Thursday, March 21, 13

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

Did we win? Thursday, March 21, 13

Slide 43

Slide 43 text

Chrome, San Francisco Before After Thursday, March 21, 13

Slide 44

Slide 44 text

Chrome, San Francisco Before After Thursday, March 21, 13

Slide 45

Slide 45 text

IE 8, San Francisco Before After Thursday, March 21, 13

Slide 46

Slide 46 text

Cut the 95th percentile in SF by 75% Thursday, March 21, 13

Slide 47

Slide 47 text

Before After Connect Process Response Render Profile Page, 95th Percentile, San Francisco Thursday, March 21, 13

Slide 48

Slide 48 text

Before After Connect Process Response Render Profile Page, 95th Percentile, Brazil Thursday, March 21, 13

Slide 49

Slide 49 text

Thursday, March 21, 13

Slide 50

Slide 50 text

After Good start. What next? Connect Process Response Render Thursday, March 21, 13

Slide 51

Slide 51 text

After Finagle based, async app server Concurrent data fetches Thursday, March 21, 13

Slide 52

Slide 52 text

After Streaming responses with chunked encoding Send early, start loading CSS Browser gets start of response earlier Thursday, March 21, 13

Slide 53

Slide 53 text

Wish us luck... Thursday, March 21, 13

Slide 54

Slide 54 text

Identify the needs of your users Thursday, March 21, 13

Slide 55

Slide 55 text

Measure them Thursday, March 21, 13

Slide 56

Slide 56 text

Make your own trade-offs Thursday, March 21, 13

Slide 57

Slide 57 text

Client-side is not the future Thursday, March 21, 13

Slide 58

Slide 58 text

Server-side is not the future Thursday, March 21, 13

Slide 59

Slide 59 text

Making appropriate use of all the tools you have is the future Thursday, March 21, 13

Slide 60

Slide 60 text

• HTTP Caching • History API • In Memory Caching • Streaming response bodies • Concurrent data fetches • Lazy loading • and so much more... Thursday, March 21, 13

Slide 61

Slide 61 text

One size fits all is overrated Thursday, March 21, 13

Slide 62

Slide 62 text

Questions? twitter.com/jobs @danwrong twitter.github.com/flight Thursday, March 21, 13

Slide 63

Slide 63 text

https://twitter-flight-night.eventbrite.com/ Thursday, March 21, 13