Petty Cash at Huffington Post

given at Velocity New York, September 2014

Transcript

1. Mike Adler HUFFINGTON POST
2. THIS GUY?
3. 115 MILLION! UNIQUE VISITORS
7. TYPICAL DESKTOP WATERFALL • 300 total requests • 180 3rd party requests • 30 3rd party scripts • 65 3rd party domains
8. NAME THE FIRST PERSON TO SURVIVE A RIDE OVER NIAGARA FALLS?
9. ANNIE EDSON in 1902 at age 63
11. YOURS TRULY
13. Websockets because we can
14. AWSHeet AWS provisioning inspired by State Senator Clay Davis https://twitter.com/Senator_C_Davis
15. Check for this
16. http://www.moviri.com/2012/06/moviri-at-velocity-conference-2012-day-2/
18. SYSTEMIC CONFUSION • product team • business team • editorial team • tech team • leadership
19. http://www.webperformancetoday.com/ 2014/06/09/can-third-party-scripts- take-entire-site-slides/ Tammy Everts Webcast
20. 3RD PARTY PROBLEMS • service degradation without explanation • behavioral changes without notice • the browser provides scant instrumentation or isolation • 3rd parties will invite 4th parties
21. Petty Cash
23. PETTY CASH, THE ALGORITHM 1. load the page in WebPagetest unmodified 2. load the page while blocking all 3rd party scripts compare metrics between unmodified and blocking-all for the total impact of all 3rd party scripts 3. iterate over each 3rd party scripts detected in step 1 A. load the page while blocking all 3rd party scripts except one compare metrics between blocking-all and blocking-all-but-one for the impact of each 3rd party script
24. load time
25. SpeedIndex
26. bytes downloaded
27. requests
28. cpu usage
29. PETTY CASH DETAILS • for example, we block http://platform.twitter.com/widgets.js and this prevents the subsequent request for avatars at https://pbs.twimg.com • every 2 hours, we analyze the most popular page on several editions • to minimize outliers we use 3 or 5 runs in WebPagetest and compare the median results • 9 editions, 15-30 3rd party scripts, every 2 hours -> one wpt run every 7 seconds
30. –Me “This simple thing is having a noticeable impact”
31. AFTER • Business team has data about both risk and rewards • We can engage partners with specific performance questions • The worst performers are mitigated or replaced. • Optimizing for overal outcome BEFORE • Business team has detailed data about revenue from ad sales and partnerships, but no actionable data about performance impact of deals • “local optimization” leads to deals with slow partners
33. h/t @littleidea
34. AFTER • responsibility is clearly indicated • tech team can be heroes when they solve tough problems that they did not create BEFORE • editorial team sometimes publishes extremely heavy content • tech team is implicitly blamed for other people’s choices, which is frustrating
36. DISCOVERED A PROBLEM • an earlier optimization had switched images to be “lazy” loaded after onLoad event • all content begun before onLoad would therefore block the lazy loaded images • less important 3rd party content was blocking some images Start Image 3rd Party Script onLoad Lazy Loaded Image
37. RESOLUTION • Petty Cash showed one particular script was having a big impact • vendor would not admit it was even possible for “async” scripts to affect page load • the initializing script was moved to after load event and RUM page load averages sped up by 2 seconds. • sounds obvious, but only in retrospect • your interests != their interests
38. RISKY MATHS Even when you have good service time latency (e.g. 99.95% of all requests are OK), as you scale up the number of request you will soon experience poor overall performance. 2.5% 4.9% 1.3% 25 requests 50 requests 100 requests 0.05% 1 request
39. http://research.google.com/people/jeff/latency.html
40. PROGRESS
41. IMPACT
42. PEOPLE
43. SPACE
44. CULTIVATE
45. –Me “Does anyone have easy questions?”