Optimising the RSPB website (2011)
1 like395 views
The document outlines the current state and performance challenges of the RSPB website, including slow load times and outdated hardware, which have negatively impacted user engagement and brand reputation. It discusses the need for optimization through best practices, such as reducing server requests, caching, and improving render times, while presenting current improvements achieved and areas still needing enhancement. The document emphasizes the importance of collaboration within the web development team and suggests further optimizations and hardware upgrades to ensure better performance.
Optimising the RSPB website (2011)
- 2. Where are we? • Very nearly came a cropper over BGBW weekend • Homepage intermittently unavailable • ASP queue overwhelmed • Content Broker overstretched • Community very slow • Website design has it’s roots in 2002 • Hardware at least 6 years old
- 3. How did we get here? • Traffic increasing year on year • Resource-hungry functionality more prevalent • No time set aside for maintenance • No understanding of real-world performance (until late 2009)
- 4. Visits: 2002 to present 300000 600000 900000 1200000 1500000 1800000 2100000 2004 2005 2006 2007 2009 2010 2008 7x New servers January 2004 May 2010
- 5. Does it really matter? • Increased user frustration = brand damage • Higher exit rates = users dissatisfied • Fewer page views = ineffective engagement • Lower conversion rates = wasted ad spend • No spare capacity = can’t capitalise on unexpected traffic • Google now including speed in results algorithm (April 2010)
- 6. Best practice • Follow W3C standards • Use Cascading Style Sheets • Optimise images • Make as few requests as possible • Reduce size of response as much as possible • Optimise render time
- 7. Best practice today • Zip plain text elements • Cache binaries • CSS Sprites • Optimise server config • Minify Javascript & CSS • Compile Javascript • Rendering more efficient • Load Javascript last • Pre-fetch elements • Reduce cookie size • Simplify HTML structure • and plenty more...
- 8. Says who? • Google and Yahoo publish guidelines • The faster your site, the faster they can index it • Some rules apply only to high-traffic sites • Test with Firefox extensions - YSlow and Google Page Speed
- 9. YSlow
- 10. YSlow
- 11. YSlow
- 12. Our homepage E HTTP requests 66 Requests on repeat visits 63 Total size 451Kb Compression None Domains 17 Javascript files 11
- 13. YSlow comparison 0 25 50 75 100 Nat Trust RSPB BT BTO WWF WT BBC YouTube Yahoo Tesco Amazon Google 87 828080 77 7474 6867 6059 56 Scores collected in April 2010
- 14. We’re due a service
- 15. What can we improve? Render complete Response time Connected to server First byte returned Download complete DNS resolved SERVER-SIDE CLIENT-SIDE
- 16. Reduce number of requests • Cache as much as possible (= no request at all) • Combine multiple scripts into one request • Combine multiple CSS files into one request • Combine multiple images into one using CSS sprites • Use CSS3 properties instead of images
- 17. Reduce size of response • Zip plain text elements (shrinks files by 70%) • Minify CSS • Compile Javascript with Google Closure • Reduce size of HTML DOM • Use shorter IDs and Class names • Re-use cached Javascript libraries to keep scripts lean (JQuery)
- 18. Improve render time • Put CSS in the <head> • Use <link> instead of @import • Put Javascript at bottom (or delay scripts until onload) • Smaller HTML DOM • Avoid tables for layout • Use CSS3 properties instead of images
- 19. Server-side changes • All pages cached for 1 hour by default • Redirects managed by IIRF instead of Content Broker • Content Broker Event queries using new trigger table • Minimise objects initialised • Turn off ViewState • Functions compiled into RSPB.Tridion.dll
- 20. Where are we now? • Number of requests per page down 75% on average (down 95% for repeat visitors) • Average size of response down 30% (down 98% for repeat visitors) • Render time as optimised as we can make it • Response times dramatically improved • But applications remain untouched • ...and we still need new hardware
- 25. Our homepage C HTTP requests 66 31 Requests on second visit 63 10 Total size 451Kb 196Kb Compression Partial Domains 17 11 Javascript files 11 5
- 26. YSlow scores 0 25 50 75 100 Nat Trust RSPB BT BTO WWF WT BBC YouTube Yahoo Tesco Amazon Google 87 828080 77 7474 6867 6059 56
- 27. YSlow scores 0 25 50 75 100 Nat Trust RSPB BT BTO WWF WT BBC YouTube Yahoo Tesco Amazon Google 87 828080 77 7474 6867 60 79 56
- 28. YSlow scores 0 25 50 75 100 Nat Trust RSPB BT BTO WWF WT BBC YouTube Yahoo Tesco Amazon Google 87 828080 77 7474 6867 60 91 56
- 29. Vacancies homepage A HTTP requests 16 Requests on second visit 4 Total size 113Kb (6Kb) Compression Yes Domains 2 Javascript files 3
- 30. What else can we do? • Optimise IS-built applications • Reserve hardware for www.rspb.org.uk only • Use pre-fetching for predictable journeys • Create development standards • Creative Services Web Team and IS Web Developers should work more closely - not in silos
- 31. References • High Performance Websites by Steve Souders • Let’s make the web faster http://code.google.com/speed • Exceptional Performance http://developer.yahoo.com/performance
- 32. Any questions? If you think of anything afterwards: graham.bird@rspb.org.uk Extension 3248