Performance Analytics Path of Samurai
summary
Claims concrete wins: measure controller response time and measure controller response time end-to-end, track how many users cancel mid-load and track cancel rate, and react to spikes (example: 350 ms baseline jumping to 420 ms = 70 ms spike). Tools actually used: Firebase network monitoring, Charles, VPNs, New Relic/AppDynamics and image-resizing services. Built and released: a timing library called Pulkovo that records elapsed blocks in debug and is a no-op in release. Test on low-end Samsung and 3G to see real failures.
AI-written summary · about
chapters (20)
- 0:00Start
- 0:12Ivan Aliakskin
- 2:26CLASSIC IMPROVEMENTS
- 4:50YOU HAVE NOT HAPPYU
- 6:35RULES TO ANALYZE APP BI
- 8:13UNDERSTAND USER'S PAIN
- 10:26EXPERIMENTS
- 13:19CRITICAL PARAMS
- 16:04WHAT SHOULD BE MEASU
- 20:48FIREBASE NETWORK
- 22:14MAKE ANALYSIS FOR STRA
- 24:23SIMULATE BAD NETWORK
- 25:32CHECK USER BEHAVIOR W
- 28:03TOOLS ARE USEFUL
- 28:39TYPICAL MISTAKES
- 30:11THE PLAN IS
- 34:04COLLECT ALL "MARKERS"
- 35:19SYSTEM THEORY
- 35:31IMPLEMENT ADJUSTMENT
- 37:26ANALYZE USERS REACTION
related talks
29mA New Kind of Analytics: Actionable Performance Analysis
17mAchieving Highly Performant Angular Apps
32mChasing performance issues methodically
18mWebsite performance from user perspective
50mWeb Performance APIs You (probably) Didn't Know Existed
44mPerformance Testing for Modern Apps
41mMeasuring the Moving Parts of User Experience in Java/.NET applications
06mMeasurement is Not Enough: Rise of Performance Analytics