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

Front-End Ops - jQuery Conf Chicago 2014

7ea369b9b67a85f638af2e0f5d708d2d?s=47 Alex Sexton
September 13, 2014

Front-End Ops - jQuery Conf Chicago 2014


Alex Sexton

September 13, 2014

More Decks by Alex Sexton

Other Decks in Technology


  1. Front-End Ops Alex Sexton | 2014

  2. None
  3. A little under a year later…

  4. None
  5. Naming Things #hardCSproblems

  6. Regressive Enhancement

  7. Polyfill

  8. Prollyfill

  9. None
  10. None
  11. Parlayfill

  12. Mollyfill


  14. Front-End Ops Alex Sexton | 2014

  15. FEO

  16. UGLY (in spanish)

  17. FeOps

  18. None
  19. Iron Ops catchy

  20. I pay the Iron Price for lower latency

  21. What is Front-End Ops?

  22. None
  23. “Some weird terms you invented to describe things that don’t

    exist.” - John Edgar, Digital Ocean
  24. None
  25. First Of All

  26. More Importantly…

  27. That’s the whole point.

  28. Serving webpages is really hard.

  29. that’s why we have conferences for this stuff (jQConf, FEOpsConf)

  30. Conferences That Don’t Exist


  32. SundayMorningConf

  33. Front-End Ops is the collection of things you can do

    to make serving webpages easier. opposite of harder
  34. So you can focus on your product.

  35. None
  36. Mature FEOps benefits the people who don’t have time to

    think about this stuff.
  37. Lots of folks agree!

  38. So really what is it?

  39. The App Everything Else

  40. The App Everything Else FEOps™

  41. Article Recap

  42. “Front-End Ops Engineers are the bridge between an application’s intent

    and an application’s reality”
  43. Why?

  44. We’re collectively insane.

  45. None
  46. Why now?

  47. Application logic is being deferred to the client side.

  48. Performance Testing

  49. Error Logging

  50. Lifecycle Logging

  51. Measurement over time

  52. A Front-End Ops Engineer enables long-term progress

  53. Performance is the foundation on which user experience is built.

  54. A UX in the DOM is worth two on the

  55. Speed is the metric that we measure by.

  56. Speed of app.

  57. Speed of tools.

  58. Speed of development.

  59. None
  60. (all of these can be measured and tracked)

  61. (all of these can be measured and tracked) ((but it’s

    important to read the data right))
  62. Speed of app.

  63. Speed up your app In 5 Simple Steps How To

  64. Step 1 forget everything you know because it’s wrong

  65. Step 2 it’s probably the network

  66. Step 3 Probably Read Ilya’s book

  67. Step 4 measure

  68. Step 5 measure

  69. 1) Forget everything 2) It’s probably the network 3) Ilya’s

    book 4) Measure 5) Measure Recap
  70. Chrome DevTools Flame Graphs, CPU Profiles, and Repaints/Reflows info are

  71. The limiting factor of your system should be the speed

    of light. Assuming you have Fiber
  72. 0 50 100 150 200 THEORETICAL GRAPHS

  73. OS X Android iOS Blackberry 1200ms 0ms

  74. 1200ms 0ms

  75. 1200ms 0ms

  76. Distribution of Load Time

  77. Desktop Mobile

  78. Two distinct loading curves

  79. What you see when you add them together.

  80. ಠ_ಠ

  81. Measurement

  82. Measurement

  83. If I had to pick one part that was most

    important to FEOps, it’d be all of it
  84. but #2 would be MEASUREMENT

  85. Measure twice. Optimize once.

  86. Make a dashboard.

  87. Things you can put in a dashboard

  88. Speed Index Over Time

  89. Speed Index Over Time And then draw lines where commits

  90. Speed Index Over Time And then draw lines where commits

    happen. And then link to the diff between tests
  91. image is of speedcurve.com

  92. Things you can put in a dashboard

  93. Page Weight Over Time

  94. Page Weight Over Time gzipped/ungzipped

  95. Page Weight Over Time gzipped/ungzipped Broken down by filetype

  96. Requests Over Time 0E+00 2.5E+01 5E+01 7.5E+01 1E+02

  97. Errors There are lots of great companies that will help

    you do this these days.
  98. Build Time Over Time

  99. Speed of tools. usually build

  100. Rule #1

  101. The time between making a change, and seeing it in

    your app must approach 0.
  102. Rule #2

  103. Never do anything twice.

  104. AKA “Cache Everything”

  105. (feel free to do two things at the same time

  106. Speed of development.

  107. Speed of development. AKA Developer Happiness

  108. Spare no expense.

  109. Take the time to make source maps work.

  110. There should be one easy command to get everything to

  111. There should be one easy command to get everything to

    work. Vagrant can help with environments
  112. Turn on LiveReload

  113. Implement Lifecycle Logging

  114. Set a calendar reminder to update your dependencies

  115. Have a rigorous Style Guide that everyone follows, and that

    robots yell about. Lint!
  116. If we take care to build robust tools around these

    FEOps ideals, ! developers will need to master less, and will be able to focus on users more.
  117. None
  118. Let’s make fast, measurement driven, easily-maintained web applications the starting

  119. Thanks @slexaxton