Establishing Performance Contexts

Segmenting your site to target specific user performance contexts

Transcript

1. Establishing performance contexts Ian Feather - @ianfeather
2. Performance at ! !
3. We don’t know how important speed is to our users at a given time
8. It’s not that hard to get fast
9. It’s not that hard to get fast
10. It’s not that hard to get fast
11. It’s not that hard to get fast
13. You can use these techniques to optimise (to a certain extent)
15. Total: weight: 674 KB ! 
 Until you scroll down the page…
17. !
18. Performance vs Design is all about compromise
19. Performance vs Design is all about compromise
20. You can only get as fast as the design allows
21. Performance Contexts
22. We have to accept there are things we don’t know
23. We are constantly required to make assumptions…
24. Assumption 1: Users on mobile devices want a different experience to those on desktop
25. Assumption 1: Users on mobile devices want a different experience to those on desktop Viewport !== context
 Viewport !== network
26. Assumption 2: Users want every site to load within X seconds
31. Assumption 2: Users want every site to load within X seconds Users want a site to load in-line with their expectations
32. Serving the same experience across multiple unknowns is a compromise
33. Currently we don’t have the tools to do anything about this
34. But… ! The Web is for everyone
35. How can we determine a user’s performance context?
36. Why not ask them?
37. Hostel Mode
38. http://blog.chriszacharias.com/page-weight-matters
40. “We even burned through our monthly data plans in 40 minutes.”
41. Light
 Mode Default
42. Segmenting in to two ‘modes’ can be very powerful but…
43. Are we still making assumptions?
45. Did we ever ask users with retina screens if they want a slower experience?
46. And are we still compromising?
47. We can’t leverage the best of the platform… whilst limiting page weight.
49. Light
 Mode Default
50. Light
 Mode Default Enhanced
51. Segmenting allows us to design focused User Experiences
52. Asking the user
56. How could this look?
61. Implementation Advice
62. Don’t build three different websites!
63. Abstract out the development complexity
64. if('querySelector' in document && 'localStorage' in window && 'addEventListener' in window && 'classList' in document.documentElement && 
 lpHostelMode() !== "light") {
 } Global feature switches
65. <div class=“my-module”> <h1>{{ moduleTitle }}</h1> {{ img_tag(moduleImage) }} <p>{{ moduleContent }}</p> </div> Authoring must stay the same
66. def img_tag(image_url, opts={}) return if @hostelMode ! image_tag(image_url, opts) end Use helpers to abstract switches
67. Stateless vs Stateful
68. Consider the preloader
69. Future: Could the browser expose these user options?
70. Recap
71. You can only get as fast as the design allows
72. Your application may be entirely inaccessible to parts of the world
73. Segmenting the user experience can be very powerful
74. Don’t guess. Ask.
75. Don’t do it at the expense of complexity
76. Thank you Ian Feather - @ianfeather
77. Creative Commons ! ! ! Arrano : https://flic.kr/p/4WjZDf Patrick Quinn-Graham (thepatrick): https://flic.kr/p/Tk4Ha Leonardo Rizzi (L1010913): https://flic.kr/p/cVRiZm