Front-End Ops - jQuery Conf Chicago 2014

1. Front-End Ops Alex Sexton | 2014
3. A little under a year later…
5. Naming Things #hardCSproblems
6. Regressive Enhancement
7. Polyfill
8. Prollyfill
11. Parlayfill
12. Mollyfill
13. ANYWAYS
14. Front-End Ops Alex Sexton | 2014
15. FEO
16. UGLY (in spanish)
17. FeOps
19. Iron Ops catchy
20. I pay the Iron Price for lower latency
21. What is Front-End Ops?
23. “Some weird terms you invented to describe things that don’t exist.” - John Edgar, Digital Ocean
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
31. HTML &ENTITY; CONF
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.
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.
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 wire.
55. Speed is the metric that we measure by.
56. Speed of app.
57. Speed of tools.
58. Speed of development.
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 invaluable.
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 happen.
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 though)
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 work.
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.
118. Let’s make fast, measurement driven, easily-maintained web applications the starting point.
119. Thanks @slexaxton