The Critical Path to Performance: User Journeys

1,752 views

Published on

Presented at Velocity conference, Santa Clara, 2013. Understand web performance from the user journey perspective. Case studies explore performance issues unique to multi-step or multi-page web transactions, and measurement approaches for identifying issues and monitoring ongoing performance. Synthetic and RUM discussed.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,752
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

The Critical Path to Performance: User Journeys

  1. 1. The Critical Path to WebPerformanceFocusing on User Journeys
  2. 2. Today’s Talk Performance matters… always?everywhere? The nexus of business performance anduser journeys When good transactions can go bad The next frontier: real user journeys Real user transaction performance:Keynote’s perspectiveTop of the World by Izzard, on Flickr
  3. 3. http://www.mit.edu/~velten/press/content/videos/bottlefast.mov
  4. 4. Site Performance From the User PerspectivePhysicalPsychologicalKeynote Mobile User Study, 2012
  5. 5. Site Performance = Business Efficiencyhttp://kylerush.net/blog/meet-the-obama-campaigns-250-million-fundraising-platform/http://blog.mozilla.org/metrics/2010/04/05/firefox-page-load-speed-%E2%80%93-part-ii/ SFSV WebPerformance Group 20120216 - Walmart RUM60% faster ->14% improvement indonation conversionsAverage page load for convertedpopulation is 47% faster than theaverage for non-converted2.2 sec reduction in page load ->15% in download conversions
  6. 6. Measuring Speed to TransactionKeynote Brokerage Performance Indexhttp://www.keynote.com/keynote_competitive_research/performance_indices/broker_index/broker.html
  7. 7. Broken bridge by Klobetime, on Flickr
  8. 8. Cache Header Settings The fastest way to load an asset onto a webpage is to not have to make a networkrequest for it at all- Cache header settings enable a web browser to use anelement out of the browser cache with confidence thatthe copy is still “fresh”- Without appropriate headers, or with misconfiguredheaders, the browser must send a conditional HTTPrequest to the server to see if the element can be usedfrom cache or if a fresh copy needs to be sent instead HTTP 304 Not Modified responses are anindicator that cache headers are harmingpage load performance A case study- A site home page loads 8 JPEG images that are used onother pages on the site- All are static images served from a very fast server- If only the Home Page is viewed, the performance ofthese images is quite fast- However, if a site visitor explores the site, these sameimages are used in the design of other pages- The cache header settings are not set properly- Conditional requests are made- The browser ends up using the elements out of cache
  9. 9. Cache Header Settings On a multi-page transaction through thissite, the Features & Options page has twoconditional HTTP requests- Result in HTTP 304 Not Modified responses- Caused by cache header problems- In this case, the two assets load early in the page,so the extra delays are potentially impacting theuser experience of other content on the pageHome PageFeatures & Options
  10. 10. Cache Header Settings In this case, an image that should be cacheable was accidentallyset with a Cache-Control header “private” and “max-age=0”- There is nothing special about this image – it is simply a gradient used forbackground shading- This misconfigured header causes unexpected and unnecessary delayFeatures & Options
  11. 11. Data URIs Data URIs are a great way to improveperformance, especially for mobilewebsites- Each asset encoded as a data URI avoids an HTTPrequest-response round trip over the internet- Not only does this avoid latency, but it reduces the number ofbytes transferred in HTTP headers- In the case of a secure page, the site may avoid havingto establish an additional SSL connection- The limited number of parallel threads/downloads in thebrowser can be used to load other assets more quickly A case study- Products page had been loading 17 PNG image files- Small thumbnail images of products in currentinventory- All were replaced with data URIs in the base pageHTML response- The performance of the Products page improved, albeitslightly- These same thumbnail images, however, were beingused on other pages on the site, including a page thatlets you design a custom version of the products
  12. 12. Changes to the Products page The structure of the Products page changed significantly in March- Although the overall number of assets on the page has not substantially changed, most page content is now beingloaded in data URIs returned in the initial base page response- One external PNG and one Omniture call load separately- Ensuring the consistency of the ASPX response time is now criticalProductsNew York AT&TApple iPhone 4Data URIsProductsSan Francisco AT&TApple iPhone 4
  13. 13. Customize Your Product Page Was Not Changed The structure of the Customize Your Product page changed significantly in March- Prior to March 22, there were only five new HTTP requests- Most page content (including the 17 PNG image files) was already in the in-session browser cache- Starting on March 22, with the change to the Products page, many new HTTP requests now have to be madeCustomize Your ProductSan Francisco VerizonMotorola Droid XCustomize Your ProductSan Francisco SprintHTC TouchHD
  14. 14. Data URIs – Tradeoffs We can see the tradeoff in the high-speed, low-latency network connection data- Many small product thumbnail images were loaded as data URIs, encoded directly in to the base page HTMLresponse- This has improved the performance of the Products page- However, the Customize Your Product page, which was using many of the same images directly out of the in-sessionbrowser cache, is now slower on averageProductsLANCustomize Your ProductLAN
  15. 15. Real Users Aren’t Robots Synthetic tests have draw-backs- Fixed number of “agent” locations and browser types/versions- Last mile performance measurement can be expensive- Website visitors take detours- What are the most common paths being traversed by actualusers?- What is the performance of those paths?- When an issue is identified, its impact to actual users is unknown- Scripts can only generate a limited variability of interactions- Scripts need maintenance
  16. 16. Real User Monitoring to the Rescue! Browser RUM can help fill in the gaps- Reveals actual user impact when slow downs occur- Last mile performance, across all browsers used- Inclusive of all the variations in visitor paths and behavior- No scripting! Not so fast…- Noise- Resource level detail
  17. 17. Better Together RUM + synthetic complement each other- Page performance anomaly detection and diagnosis- Drill from RUM browser events at the page level towaterfalls generated by corresponding synthetic tests- User impact assessment- Quantify real user population impacted by performanceissues identified in synthetic tests- Synthetic test optimization- Identify high usage, low performance pages to monitorsynthetically- Optimize “agent” locations- Identify high usage user path variations to monitorsyntheticallySplash! by jfournierphoto, on Flickr
  18. 18. Keynote’s Approach Hybrid Synthetic + RUM- Browser-based real user monitoring- “Model” transactions- Real user paths- Fuzzy logic pattern matching- Comparative analysis- Demo: Real User Perspective
  19. 19. Thank YouAaron Rudger, aaron.rudger@keynote.com / @arudgerKen Harker, ken.harker@keynote.comDavid Azaria, david.azaria@keynote.com

×