$30 off During Our Annual Pro Sale. View Details »

Pragmatic Performance with Third-Party JavaScript

Pragmatic Performance with Third-Party JavaScript

Presentation for Twitter at Open Web Camp 2012, in San Jose, CA. Covers a chunk of what we've learned over the years in building JavaScript for off-network usage, with aggressive performance optimisations.

Ben Ward

July 14, 2012
Tweet

More Decks by Ben Ward

Other Decks in Programming

Transcript

  1. Pragmatic Performance with 3rd Party JavaScript

    View Slide

  2. Ben Ward http://benward.me

    View Slide

  3. Ben Ward @benward

    View Slide

  4. View Slide

  5. Tweet

    View Slide

  6. “3rd Party Javascript?!”, you exclaim.

    View Slide

  7. SlowBlockingBandwidthEatingRequestIncreasing…

    View Slide

  8. View Slide

  9. Back right up. Why do these even exist?

    View Slide

  10. Back right up. How do they work?

    View Slide

  11. Widgets are products.

    View Slide

  12. Widgets are products for publishers.

    View Slide

  13. Widgets are products for developers.

    View Slide

  14. Widgets are products for people.

    View Slide

  15. Four stakeholders, delicately balanced.

    View Slide

  16. Provide features for mutual benefit.

    View Slide

  17. Share more of your links. Share more links.

    View Slide

  18. Easily quote Tweets. High quality Tweets.

    View Slide

  19. We take responsibility for technical costs.

    View Slide

  20. All stakeholders benefit from page performance.

    View Slide

  21. What’s in a page?

    View Slide

  22. View Slide

  23. View Slide

  24. The article itself.

    View Slide

  25. Publisher’s assets; images, scripts, analytics.

    View Slide

  26. Advertising. Publisher’s gotta eat.

    View Slide

  27. Other third parties sharing the page.

    View Slide

  28. Twitter for Websites; a suite of features.

    View Slide

  29. Tweet, follow, #hashtag and @mention buttons.

    View Slide

  30. Embeddable Tweets.

    View Slide

  31. Programmable JavaScript Events and Web Intents.

    View Slide

  32. Easy, as in fast to integrate.

    View Slide

  33. Fast, as in performant in the page.

    View Slide

  34. Performant, as in responsive to the environment.

    View Slide

  35. Responsive, as in embracing of the web.

    View Slide

  36. What expenses? Loading, rendering, bandwidth.

    View Slide

  37. DNS Look-up.
    HTTP(S) Request.
    Download.
    Parse/Execute.
    Render.

    View Slide

  38. DNS look-ups are a tax on every domain you use.

    View Slide

  39. Most of these visitors are not your users.

    View Slide

  40. Minimise unique domains, and use prefetching.

    View Slide





  41. View Slide

  42. HTTP Requests also add up.

    View Slide

  43. Need fast responses, use a worldwide CDN.

    View Slide

  44. View Slide

  45. 6 simultaneous requests to the same domain.

    View Slide

  46. Only 2 in the old browsers.

    View Slide

  47. platform.twitter.com/
    platform1.twitter.com/
    platform2.twitter.com/
    platform3.twitter.com/…?
    platform∞.twitter.com/…?

    View Slide

  48. Ugh, more DNS requests.

    View Slide

  49. Even slower 3-step handshake over SSL.

    View Slide

  50. Users lack upload bandwidth. Requests go up.

    View Slide

  51. Make fewer requests.

    View Slide

  52. Bundle JavaScript, styles, HTML.

    View Slide




  53. Twitter Tweet Button
    /* minified stylesheet */


    Tweet

    <br/>// minified JavaScript<br/>


    View Slide

  54. Use CSS3, and data: URI images.

    View Slide

  55. .btn {
    border-radius: 6px;
    background: linear-gradient(top, white, #DEDEDE);
    text-shadow: 0 1px 0 rgba(255, 255, 255, .5);
    }
    .btn:hover,
    .btn:focus {
    box-shadow: inset 0 0 10px #000000;
    }

    View Slide

  56. View Slide

  57. data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAC0AAAAoCAYAAABq13MpAAAGcklE[…]

    View Slide

  58. 1 HTTP request.
    Tweet

    View Slide

  59. Download smaller responses.

    View Slide

  60. Minify JavaScript with uglify-js or Closure.

    View Slide

  61. 85KB 45KB
    uglify

    View Slide

  62. Gzip all the things.

    View Slide

  63. 85KB 20KB
    gzip

    View Slide

  64. 85KB 20KB
    uglify gzip 14KB

    View Slide

  65. JS Frameworks are bigger than our product.

    View Slide

  66. But consider your goals, audience, and capability.

    View Slide

  67. Write tiny modules for LoadRunner & LoadBuilder

    View Slide

  68. Carefully organise bundles for lazy loading.

    View Slide

  69. We lazy load XDomain, JSON2, some rendering.

    View Slide

  70. Tailor build files to known environments

    View Slide

  71. We’re in 28 languages. Separate builds save 6KB.

    View Slide

  72. Loading from JS, so you have the information.

    View Slide

  73. Retina displays, data/png support, small screens…

    View Slide

  74. Download nothing at all.

    View Slide

  75. Render on the client to share cached templates.

    View Slide

  76. Cache aggressively, download once for all time.

    View Slide

  77. Hash filenames for and dependencies.

    View Slide

  78. Avoid ?query=params, use #fragment=params.

    View Slide

  79. Blocking, and other ways to break the web.

    View Slide


  80. View Slide

  81. View Slide

  82. A script source times out, the page is left waiting.

    View Slide

  83. It could happen to any of us.

    View Slide

  84. Wherever possible, use non-blocking script code.

    View Slide


  85. View Slide

  86. !function (doc, script, id) {<br/>var js,<br/>first = doc.getElementsByTagName(script)[0];<br/>if (!doc.getElementById(id)) {<br/>js = doc.createElement(script);<br/>js.id = id;<br/>js.src = "//platform.twitter.com/widgets.js";<br/>first.parentNode.insertBefore(js, first);<br/>}<br/>}(document,"script","twitter-wjs");

    View Slide

  87. Doesn’t block and avoids duplicate downloads.

    View Slide

  88. We use this almost everywhere.

    View Slide

  89. Use script.js, lab.js, or loadrunner on your sites.

    View Slide

  90. The fastest JavaScript is no JavaScript.

    View Slide

  91. Embed codes are links to supported endpoints.

    View Slide

  92. We call them Web Intents. (Which is unfortunate.)

    View Slide

  93. View Slide

  94. Follow Ben Ward

    View Slide

  95. They accept the same parameters as the widgets.

    View Slide

  96. They’re there if something bad happens.

    View Slide

  97. They’re there if you don’t want our script at all.

    View Slide

  98. All major Twitter actions represented by .

    View Slide

  99. Progressive enhancement at the product core.

    View Slide

  100. The entire product is an enhancement.

    View Slide

  101. We build for the web.

    View Slide

  102. Thank you.

    View Slide

  103. Photo credits: http://flic.kr/y/nLCZEt

    View Slide

  104. Questions. Also, answers.

    View Slide