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.

1. The Critical Path to Web
Performance
Focusing on User Journeys

2. Today’s Talk
 Performance matters… always?
everywhere?
 The nexus of business performance and
user journeys
 When good transactions can go bad
 The next frontier: real user journeys
 Real user transaction performance:
Keynote’s perspective
Top of the World by Izzard, on Flickr

3. http://www.mit.edu/~velten/press/content/videos/bottlefast.mov

4. Site Performance From the User Perspective
PhysicalPsychological
Keynote Mobile User Study, 2012

5. Site Performance = Business Efficiency
http://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 RUM
60% faster ->
14% improvement in
donation conversions
Average page load for converted
population is 47% faster than the
average for non-converted
2.2 sec reduction in page load ->
15% in download conversions

6. Measuring Speed to Transaction
Keynote Brokerage Performance Index
http://www.keynote.com/keynote_competitive_research/performance
_indices/broker_index/broker.html

7. Broken bridge by Klobetime, on Flickr

8. Cache Header Settings
 The fastest way to load an asset onto a web
page is to not have to make a network
request for it at all
- Cache header settings enable a web browser to use an
element out of the browser cache with confidence that
the copy is still “fresh”
- Without appropriate headers, or with misconfigured
headers, the browser must send a conditional HTTP
request to the server to see if the element can be used
from cache or if a fresh copy needs to be sent instead
 HTTP 304 Not Modified responses are an
indicator that cache headers are harming
page load performance
 A case study
- A site home page loads 8 JPEG images that are used on
other pages on the site
- All are static images served from a very fast server
- If only the Home Page is viewed, the performance of
these images is quite fast
- However, if a site visitor explores the site, these same
images 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. Cache Header Settings
 On a multi-page transaction through this
site, the Features & Options page has two
conditional 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 the
user experience of other content on the page
Home Page
Features & Options

10. Cache Header Settings
 In this case, an image that should be cacheable was accidentally
set with a Cache-Control header “private” and “max-age=0”
- There is nothing special about this image – it is simply a gradient used for
background shading
- This misconfigured header causes unexpected and unnecessary delay
Features & Options

11. Data URIs
 Data URIs are a great way to improve
performance, especially for mobile
websites
- Each asset encoded as a data URI avoids an HTTP
request-response round trip over the internet
- Not only does this avoid latency, but it reduces the number of
bytes transferred in HTTP headers
- In the case of a secure page, the site may avoid having
to establish an additional SSL connection
- The limited number of parallel threads/downloads in the
browser 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 current
inventory
- All were replaced with data URIs in the base page
HTML response
- The performance of the Products page improved, albeit
slightly
- These same thumbnail images, however, were being
used on other pages on the site, including a page that
lets you design a custom version of the products

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 being
loaded 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 critical
Products
New York AT&T
Apple iPhone 4
Data URIs
Products
San Francisco AT&T
Apple iPhone 4

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 made
Customize Your Product
San Francisco Verizon
Motorola Droid X
Customize Your Product
San Francisco Sprint
HTC TouchHD

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 HTML
response
- 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-session
browser cache, is now slower on average
Products
LAN
Customize Your Product
LAN

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 actual
users?
- 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. 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. Better Together
 RUM + synthetic complement each other
- Page performance anomaly detection and diagnosis
- Drill from RUM browser events at the page level to
waterfalls generated by corresponding synthetic tests
- User impact assessment
- Quantify real user population impacted by performance
issues identified in synthetic tests
- Synthetic test optimization
- Identify high usage, low performance pages to monitor
synthetically
- Optimize “agent” locations
- Identify high usage user path variations to monitor
synthetically
Splash! by jfournierphoto, on Flickr

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. Thank You
Aaron Rudger, aaron.rudger@keynote.com / @arudger
Ken Harker, ken.harker@keynote.com
David Azaria, david.azaria@keynote.com