Demystifying Web Performance
•
2 likes•1,031 views
"Measure first, then optimise" is an oft-cited maxim for developers. But you can't optimise without first understanding what factors influence a given measurement. Only then is it worth your time to start digging around in your code and infrastructure. Join Atlassian engineer Ian Grunert as he outlines the measurements exposed by the browser about the request lifecycle, and the areas of your web application contributing to each section. He'll also show you how the Confluence team uses Bamboo, Bitbucket (including Stash), Confluence, and JIRA to track the impact of performance improvements and reduce the chance of shipping performance regressions.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (12)
Similar to Demystifying Web Performance
Similar to Demystifying Web Performance (20)
More from Atlassian
More from Atlassian (20)
Recently uploaded
Recently uploaded (20)
Demystifying Web Performance
- 1. IAN GRUNERT • SENIOR DEVELOPER • ATLASSIAN • @IANGRUNERT Demystifying Web Performance
- 2. Application Performance Index Divide by the count Good job! This request didn’t break user flow. 1/2 point for tolerating This request broke user flow, but they didn’t get frustrated by it. 1 point for satisfied Now you have your Application Performance Index, Apdex for short.
- 5. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. DONALD E. KNUTH, STRUCTURED PROGRAMMING WITH GO TO STATEMENTS “ ”
- 8. Navigation Timing Redirects Unload DNS TCP Request Response Download & Parse On Ready Server Processing
- 10. Redirects cause roundtrips Browser Confluence GET /wiki/ 302 /wiki/dashboard.action GET /wiki/dashboard.action 200 /wiki/dashboard.action
- 11. Read the access logs Tips and tricks Make the server do the work Reduce latency to server Site logo linked to /wiki/, change to link to site home These are golden for finding the worst offenders for redirects Output the final destination in the href The closer you are to the server, the faster the roundtrips are
- 13. TLS Handshake cause roundtrips Browser Confluence SYN SYN ACK ClientHello ServerHello ChangeCipherSpec ChangeCipherSpec
- 15. TCP SERVER PROCESSING DOWNLOAD Navigation Timing SERVER PROCESSING REDIRECT PARSE + ONREADY
- 16. You should reduce your server response time under 200ms. PAGESPEED INSIGHTS, GOOGLE “ ”
- 17. Optimise Time To First Byte Browser Confluence GET /wiki/ Flush <head> with resources Flush rest of response
- 19. Measure application render time Browser Network Hop Network Hop Measure this!
- 20. TCP REDIRECT SERVER PROCESSING Navigation Timing PARSE + ONREADY DOWNLOAD
- 21. CDNs are magical
- 22. In HTTP/1.1, use batching to avoid waterfalling
- 25. We’ve saved over at the 85%-ile 880ms
- 26. TCP PARSE + ONREADY SERVER PROCESSING DOWNLOAD Navigation Timing REDIRECT
- 29. Resource ordering matters, not just for download!
- 30. We’ve saved over at the 85%-ile 500ms
- 32. Setting Goals Velocity-based Great high-level performance measure. Hard to move. High percentiles The frustrating requests are the ones that are most memorable. Apdex Much easier to set goals after time has been spent to establish velocity.
- 33. • Big cool statistic • 2,56 9 • Add-Ons in Marketplace Graphs to monitor progress
- 34. • Big cool statistic • 2,56 9 • Add-Ons in Marketplace Generate a backlog
- 35. • Big cool statistic • 2,56 9 • Add-Ons in Marketplace Tracking Results
- 36. • Big cool statistic • 2,56 9 • Add-Ons in Marketplace Preventing Regressions
- 37. • Big cool statistic • 2,56 9 • Add-Ons in Marketplace git-ratchet + Atlassian Connect for Bitbucket
- 38. • Big cool statistic • 2,56 9 • Add-Ons in Marketplace Be Agile!
- 40. Thank you! IAN GRUNERT • SENIOR DEVELOPER • ATLASSIAN • @IANGRUNERT