This document discusses establishing performance contexts for websites by segmenting user experiences. It suggests that websites make assumptions about what users want that may not be accurate for all users and contexts. To build a more inclusive web, the document recommends asking users about their preferences and needs rather than guessing, through techniques like feature flags and a "hostel mode" to provide lighter experiences for constrained devices or network conditions. It cautions that segmenting user experiences still requires compromises and not overcomplicating development.

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. Authoring must stay the same
<div class=“my-module”>
<h1>{{ moduleTitle }}</h1>
{{ img_tag(moduleImage) }}
<p>{{ moduleContent }}</p>
</div>

66. Use helpers to abstract switches
def img_tag(image_url, opts={})
return if @hostelMode
!
image_tag(image_url, opts)
end

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
!