BD Conf: Visit speed - Page speed is only the beginning

How can we beat the speed of light and make visits faster? Pre-fetching is one way we can make resources available before they're needed. This talk explores challenges in mobile visit performance and discusses the design of a generic pre-fetching system.

Transcript

1. Page Speed is Only the Beginning VISIT-SPEED 1
2. WHO AM I? WHO CARES IF VISITS ARE SLOW? WHY ARE VISITS SLOW? PRE-FETCHING: Making Visit Faster In this presentation: RESULTS & DISCUSSION 2
3. WHO AM I? WHO CARES IF VISITS ARE SLOW? WHY ARE VISITS SLOW? PRE-FETCHING: Making Visit Faster RESULTS & DISCUSSION 3
4. Peter McLachlan chief architect & co-founder of Mobify 4
5. HUGE IMAGE WHERE I INTRODUCE MYSELF 5
7. WHAT IS VISIT-SPEED? 7
8. • More than just a single metric. • How your visitors interact with your website. • We’re talking about all the waiting time that exists: 1. within pages, while visitors wait for interactive elements to finish loading. 2. between pages, such as when visitors traverse a checkout flow. VISIT-SPEED IS... 8
9. THERE’S A LOT MORE TO USER ENGAGEMENT THAN PAGE SPEED! User engagement is about the experience. • experience crosses the page boundary! We need a heck of a lot more UX research on this subject. • but you’re not here for a UX talk! For now, an appeal to intuition: doesn’t it seems intuitive that people care about the speed of the entire experience? • first load is just one step along the way. • rough guess: I’d say it’s 1/3rd of the puzzle or less. 9
10. WHO AM I? WHO CARES IF VISITS ARE SLOW? WHY ARE VISITS SLOW? PRE-FETCHING: Making Visit Faster RESULTS & DISCUSSION 10
11. You do. You just don’t know how much yet. 11
12. If your users spend 8s waiting for a page to load instead of 2, here is the impact: 1,992 hours/yr 19,920 hours/yr 199,200 hours/yr How many pageviews do you get in a month? 100,000? 1,000,000? 10,000,000? ... or about a quarter of a human lifetime 12
13. 73% of mobile internet users say they’ve encountered a website that was too slow to load. Loading... 13
14. 73% of mobile internet users say they’ve encountered a website that was too slow to load. Data source: kissmetrics.com Loading... 13
15. 73% of mobile internet users say they’ve encountered a website that was too slow to load. Data source: kissmetrics.com Loading... 27% of internet users are LIARS 13
16. A 1 second delay in page response can result in a 7% reduction in conversions. If an e-commerce site is making $100,000 per day, a 1 second page delay could potentially cost you $2.5 million in lost sales every year. 14
17. A 1 second delay in page response can result in a 7% reduction in conversions. If an e-commerce site is making $100,000 per day, a 1 second page delay could potentially cost you $2.5 million in lost sales every year. Data source: kissmetrics.com 14
18. 15% 16% 16% 20% 30% 3% 16-20 seconds 1-5 seconds 11-15 seconds 20+ seconds 6-10 seconds > One second Data source: kissmetrics.com PATIENCE OF MOBILE WEB USER 15
19. WHO AM I? WHO CARES IF VISITS ARE SLOW? WHY ARE VISITS SLOW? PRE-FETCHING: Making Visit Faster RESULTS & DISCUSSION 16
20. Two words for you: Ilya Grigorik (https://twitter.com/igrigorik) • http://www.igvita.com/2013/01/15/faster-websites-crash-course- on-web-performance/ But let me briefly recap: 1. Too many HTTP requests 2. High request latency 3. Too many bytes 4. Poor resource cache settings 5. Laggy interactions LETS START WITH THIS: WHAT MAKES PAGES SLOW? (especially on mobile) 17
21. 0Mbps 20Mbps 40Mbps 60Mbps 80Mbps 3Mbps 21Mbps 42Mbps 75Mbps 3G HSPA+ HSPA+ LTE What’s interesting about this 18
22. 0Mbps 20Mbps 40Mbps 60Mbps 80Mbps 3Mbps 21Mbps 42Mbps 75Mbps 3G HSPA+ HSPA+ LTE What’s interesting about this ABSOLUTELY NOTHING 19
23. AND HERE’S WHY ... Source: Ilya Grigorik 0 1000 2000 3000 4000 1mbps 3mbps 5mbps 7mbps 9mbps 0 1000 2000 3000 4000 240ms 200ms 160ms 120ms 80ms 40ms 0 Page load time (ms) as latency (RTT) decreases Page load time (ms) as bandwidth increases 20
24. Why do we care a lot about latency on mobile? 21
25. Mobile phone radio behaviour 22
26. WHO AM I? WHO CARES IF VISITS ARE SLOW? WHY ARE VISITS SLOW? PRE-FETCHING: Making Visit Faster RESULTS & DISCUSSION 23
27. Pre-fetch verb \preeˈfech\ To fetch web related resources before they are required, the activity of which is to be accomplished while the web browser is not otherwise occupied, outside of the critical rendering path of the page. 24
28. •When other performance optimizations have already been applied •When your site has a flow •When you use different resources on different pages of your site • Of course this implies that you DON’T bundle all your JS into a single file and deliver it in one go to the visitor WHEN TO PRE-FETCH 25
29. Here’s what we need to think about How should I implement pre-fetching? What should I pre-fetch? PRE-FETCHING? Do’s, Don’ts and Test results 26
30. WHAT SHOULD I PRE-FETCH? 27
31. PRE-FETCHING What should we pre-fetch? There are a number of assets available to choose from: HTML, Images, CSS & JavaScript HTML, Images Most large sites have thousands or tens of thousands of pages & images. Hard problem to solve, bad worst case scenario behavior DNS, JavaScript & CSS This makes a lot of sense. Most sites have just a few CSS files and less than 100 externally referenced JavaScript 28
32. HTML & IMAGES • HTML • would be great to pre-fetch - but many sites have uncacheable content embedded in page HTML or poor caching rules • complexity of overcoming CMS / eComm platform defaults prohibitive • Images • Most sites have lots of them • Images are 65% of bytes on the average web page • Seems like a great target, but which ones should you send to the visitor? • Machine learning may help us here • But you better have great data on your site usage • Maybe there’s lower hanging fruit... 29
33. DNS • DNS is great to pre-fetch • There’s usually less than 50 DNS entries to resolve for an entire website • The OS will cache these entries • All DNS entries are cacheable, at least a little bit • Not many sites with < 1 minute DNS cache times, most are considerably longer • There’s even a nice easy bit of markup we an use to do it: • <link rel="dns-prefetch" href=”...”> 30
34. CSS & JAVASCRIPT • CSS is blocking • Definitely great to pre-fetch it! • But a lot of sites use a single CSS file anyway • So just make sure you have good caching rules on this • If you do have multiple CSS files for different parts of your flow: definitely pre-fetch them • JavaScript: often this is also blocking • I think JavaScript is the “holy grail” of pre-fetching • With JS pre-fetch we have the possibility of significantly unblocking parts of a visit flow • You shouldn’t have too many JS files in your site (right?) 31
35. The winners: DNS, CSS & JAVASCRIPT • OK, now how to select which items to pre-fetch? • For DNS and CSS you can probably just “get all the things” • DNS resolution is cheap with good caching behavior • CSS should be relatively small • JavaScript: you need a short list of items most likely to be useful during normal visit flows 32
36. mobify.com @mobify hello@mobify.com Pre-fetching 33
37. HOW SHOULD I IMPLEMENT PRE-FETCHING? 34
38. HOW SHOULD I IMPLEMENT PRE-FETCHING? Fully integrated into webapp •You can fully integrate pre-fetching into your platform / app •An introspection service can analyze log data, URL visits •Inject pre-fetching directives directly into the HTML 35
39. Pros •You can introspect your environment •Data sources: filesystem, web server log files, content database, platform (CMS, ecomm etc) APIs •Lots of CPU power at your disposal HOW SHOULD I IMPLEMENT PRE-FETCHING? Fully integrated into webapp Cons •If you have a complex environment with a CDN, multiple caching layers, databases, web platforms, this is a serious undertaking. •Requires integration directly into your platform, typically this means risk and cost. 36
40. Client side generic ( With servier-side service) HOW SHOULD I IMPLEMENT PRE-FETCHING? • What if I want to create a completely generic service • It has no knowledge of my specific app or platform • But it can still make good recommendations • In this model clients: • collect information about resources they see and report back • inject requests for resources during periods of low activity 37
41. Client side generic (With server-side service) HOW SHOULD I IMPLEMENT PRE-FETCHING? • What if I want to create a completely generic service • It has no knowledge of my specific app or platform • But it can still make good recommendations • In this model clients: • collect information about resources they see and report back • inject requests for resources during periods of low activity 38
42. Client side generic ( With servier-side service) HOW SHOULD I IMPLEMENT PRE-FETCHING? Pros • You get accurate information on what resources visitors are actually using • Server-side service is independent of all the rest of your architecture, plays nicely with SoA • If it breaks, your site still works Cons • We’ll get to this! 39
43. DO’S, DON’TS AND TEST RESULTS 40
44. PRE-FETCHING: THE DETAILS • Caching: • Divining cache content • Aging out pre-fetched items • edge cases • Recommendation engine • Considerations • Mystery time! • What I’m working on 41
45. CACHING: DIVINING CACHE CONTENTS Unfortunately we cannot inspect the browser’s cache • (yes, there are ways to make guesses) But we can just use localStorage directly, especially for JavaScript and CSS that have relatively few bytes. 42
46. CACHING: DIVINING CACHE CONTENTS Unfortunately we cannot inspect the browser’s cache • (yes, there are ways to make guesses) But we can just use localStorage directly, especially for JavaScript and CSS that have relatively few bytes. ... uh-oh .... How fast is localStorage? Doesn’t it: • block the rendering thread? • have unbounded worst case performance? 42
47. Yes, and you should use it anyway. Details at: http://www.mobify.com/blog/smartphone-localstorage-outperforms-browser-cache/ 43
48. CACHING & AGING • You will need a mechanism to manage cache eviction • LRU looks to be a good simple algorithm to implement here • Perhaps augmented to provide preferential treatment for smaller objects 44
49. CACHING: EDGE CASES • Whoops. You just did a full site refresh... • Dynamically generated resources: • susan.js, bill.js, steve.js, candace.js ... 45
50. RECOMMENDATION ENGINE • Could use a very simple algorithm: • Collect all the things • Return truncated list based on frequency seen • How big a list? • “empirically derived” = “make wild assed guess” • ... and test. • Site wide / global • More sophisticated modifications: • ML algorithm such as K-nearest neighbor • Weight by inverse resource size • Resources must decay • simplest solution is probably correct 46
51. MYSTERY TIME! Who can tell me what else we should worry about with pre-fetching? 47
52. MYSTERY TIME! Who can tell me what else we should worry about with pre-fetching? 47
53. SO, WHAT ARE YOU WORKING ON? • Service will provide: • a data collection endpoint for resources to generate recommendations • a recommendation engine for resources • As visitors browse your site, refines preferences for which resources to pre-load • The pre-fetch library provides client-side support for • collecting information about the page • recommendation engine • auto optimizing JSONP resource retrieval service • auto-caching system using localStorage with correct cache eviction behavior Pre-fetching recommendation as a service 48
54. WHERE AM I AT? • Beginning “clinical trials” • Recommendation engine still under consideration • Testing hand-curated recommendations in field trials on production sites 49
55. WHO AM I? WHO CARES IF VISITS ARE SLOW? WHY ARE VISITS SLOW? PRE-FETCHING: Making Visit Faster RESULTS & DISCUSSION 50
59. ETHICAL CONSIDERATIONS 54
60. • Network bandwidth, CPU & battery are all resources with scarcity on mobile • So don't use them recklessly • That's a good reason to focus on JS & CSS • if your site has megs and megs of JS and CSS... • what the heck are you doing!? Stop! • limit your pre-fetching to one or two steps ahead • Remember that using the radio when it's warm and then letting it sleep is going to be better for battery than waking it up repeatedly PRE-FETCHING CONSUMES RESOURCES 55
61. • Prefetching for HTML, images • Much harder problems • But solving them will have significant payoffs WHAT’S NEXT? 56
62. @mobify | mobify.com | hello@mobify.com @b1tr0t peter@mobify.com 57
63. Image credit: XKCD - “relativistic baseball” No problem, we’ll make the speed of light faster 58