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
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
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