Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Time To First Tweet

danwrong
March 20, 2013

Time To First Tweet

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

danwrong

March 20, 2013
Tweet

More Decks by danwrong

Other Decks in Technology

Transcript

  1. 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
  2. “Everything that can be done on the client is done

    on the client” - Lea Verou Thursday, March 21, 13
  3. • 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
  4. “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
  5. “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
  6. Time To First Tweet From navigation to the user seeing

    the timeline Thursday, March 21, 13
  7. •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
  8. 1. Get initial page 2.Get CSS 3.Get JavaScript 4.Get data

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

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

    5. Render template Rendering on the server Thursday, March 21, 13
  11. 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
  12. • 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
  13. • 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
  14. 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
  15. In the browser.... On click, if history API supported then

    intercept link and request the link’s URL via XHR Thursday, March 21, 13
  16. On the server... If request comes via XHR send just

    the partial update, otherwise send the entire HTML page Thursday, March 21, 13
  17. 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
  18. After Streaming responses with chunked encoding Send <head> early, start

    loading CSS Browser gets start of response earlier Thursday, March 21, 13
  19. Making appropriate use of all the tools you have is

    the future Thursday, March 21, 13
  20. • HTTP Caching • History API • In Memory Caching

    • Streaming response bodies • Concurrent data fetches • Lazy loading • and so much more... Thursday, March 21, 13