Research ▪ Quantify speed (yours and your competitor’s) ▪ Understand key performance metrics □ First paint, visually complete, DOM interactive, etc. ▪ Find potential bottlenecks 6
Tools 1. Browser developer tools □ Waterfall view, network throttling 2. Test in real devices: WebPageTest □ Multiple locations around the globe □ Different network conditions 7
Create a plan ▪ Revisit render-blocking resources ▪ Remove unnecessary redirects ▪ Implement optimised/responsive images ▪ Lazy load content ▪ Make good use of caching 9
Raise awareness 11 ▪ BBC: 10% of users lost for every additional second in load time ▪ Google: 53% of mobile visits abandoned after 3 seconds ▪ AliExpress: 36% reduction in load time increased orders by 10.5% and conversion by 27% (Links and several other reports at wpostats.com)
New mindset 12 ▪ Performance as a feature, not a “nice to have” ▪ Implications on performance are considered at planning stages, not as an afterthought ▪ Performance budget □ «Can we afford this new feature?»
Stick to the plan 14 ▪ Increase visibility of performance results □ Not just developers ▪ If people can’t see it, it’s not their problem □ Make it their problem!
▪ Charts show performance metrics over time ▪ Data from WebPageTest, PageSpeed and Lighthouse ▪ Configurable performance budgets □ Slack/email notifications ▪ No infrastructure (runs from a GitHub repository) ▪ Hackable and customisable (Jekyll + React) SpeedTracker 16
1. Find the problem □ Study performance metrics □ Analyse your site and the competition 2. Fix the problem □ Raise awareness for business implications □ Define a course of action 3. Don’t repeat the problem □ Make continuous performance results easily available □ Use SpeedTracker! 18
eduardoboucas
rdlabo
sansantech
lmi
sajikix
kawagoi
peisuke
minorun365
nwiizo
hfukunak
palark
chiroito
kazuhitotakahashi
pauljervisheath
rasmusluckow
searls
notwaldorf
jacobian
sugarenia
philhawksworth
jennybc
erikaheidi
lara
smashingmag
dougneiner