Site-Speed That Sticks

Transcript

1. site-speed that sticks
3. hi, i’m harry
5. five key topics
6. 1. metrics 2. localhost 3. backstops 4. monitoring 5. playbook
7. 1. metrics 2. localhost 3. backstops 4. monitoring 5. playbook
8. 1. metrics 2. localhost 3. backstops 4. monitoring 5. playbook
9. 1. metrics 2. localhost 3. backstops 4. monitoring 5. playbook
10. 1. metrics 2. localhost 3. backstops 4. monitoring 5. playbook
11. 1. metrics 2. localhost 3. backstops 4. monitoring 5. playbook
12. metrics
13. not all metrics are born equal
14. different metrics for different people on different occasions with different levels of disclosure
15. kpis, enablers, predictors
16. kpis
17. definition + target
18. what are we working toward?
19. of interest to the business
20. core web vitals
21. ‘which number on which dashboard of which service?’
22. “We want a one-second improvement in Largest Contentful Paint.” — My Client
26. enablers
27. metrics that directly influence kpis
28. of interest to engineering teams
29. ttfb, input delay
30. predictors
31. signals of good/bad performance
32. highly quantitative
33. of interest to engineers
34. bundle size, long tasks, blocking css
35. great for root-causing and reverse engineering
36. localhost
37. localhost is: seldom live-like, pretty dang fast, un-bundled
38. know your tools inside out
41. csswz.it/perfnow25
42. one weird trick…
44. // plugins/delay.server.ts export default defineNuxtPlugin(async () => { await new Promise(resolve => setTimeout(resolve, 900)) })
47. <head> <link rel=stylesheet href=https://slowfil.es/file?type=css&delay=800> </head>
48. core web vitals are too big for localhost
49. if you’re working locally, measure locally
50. bare-metal metrics
54. 1 2
55. 1 2 3
56. 1 2 3
60. 1 2
61. 1 2 3
62. 1 2 3
63. external: 1842ms inlined: 1250ms
65. these are very private metrics
66. backstops
67. …and budgets
68. what is the worst possible performance we will accept?
69. set it to the worst reading in the last release cycle
71. this is where synthetic testing comes into it
72. synthetic testing; real user monitoring
73. when to fail a release
75. predictors as tripwires
77. budgets versus targets
78. budgets are backstops; targets are ambitions
79. target == kpi
81. monitoring
82. the m in rum stands for monitoring
83. “Insanity is doing the same thing over and over again and expecting different results.” — Rita Mae Brown
85. 🎉
86. ?
91. it’s the exact same file
93. you’re monitoring variation in tests
95. only alert on your kpis
98. 0.9952409649
101. always follow the numbers
102. playbook
103. “Fighting regressions took priority over optimizations […]” — Michelle Vu, Pinterest
105. it’s all for nothing if you don’t have a plan
106. response = f(severity, duration)
107. severity
108. acceptable: <10%
109. moderate: 10–25%
110. severe: 25–50%
111. critical: >50%
112. duration
113. temporary: 24–48hr
114. sustained: >48hr
115. long-term: >1 release cycle
116. unresolved: many release cycles
117. a kpi regression of over 10% for one week requires remediation in the next sprint
118. a kpi regression of over 100% for one hour requires rollback immediately
119. a kpi regression of over 25% for one day requires remediation in the current sprint
120. an enabler regression of over any% for any time needs the team’s attention over the next sprint
121. a predictor regression of over any% for any time needs my attention over the next sprint
122. you need a framework to fill in these blanks
123. early triage
124. who, what, when, where, and why?
125. what?
126. what has regressed?
127. when?
128. when did it start? is it still like that?
129. where?
130. is it a business-critical part of the site?
131. who?
132. who owns the problem?
133. why?
134. can you conduct early triage?
141. key takeaways
142. increase confidence
143. use the right tool for the right job
144. have a plan of attack
145. agree; commit
146. thank you
147. harry.is/for-hire