Refocusing our Priorities in Responsive Design

Talk on Refocusing our Priorities in Responsive Design from Over the Air 2015

Transcript

1. Refocusing our Priorities
   in Responsive Design
   Jonathan Fielding @jonthanfielding
   

   View Slide

2. A bit about me…
   • Technical Architect at Beamly
   • Author of Beginning Responsive Design
   • Regular contributor to open source, including
   SimpleStateManager, Echo.js, CriticalJS, FT’s
   Polyfill Service, Doccy among many projects
   • Lover and user of ‘the Twitter’
   

   View Slide

3. Current Responsive Design
   techniques focus on mobile first
   

   View Slide

4. There has not been the same
   focus on either the content
   or the performance of our
   site.
   

   View Slide

5. Our site content
   

   View Slide

6. Bobby Anderson
   Everyday Designer
   “Content is king, it always has been
   and always will be. Content is why
   users visit your site, subscribe to
   your newsletters and follow you on
   social media. Content is the single
   most important aspect of your
   website...”
   http://everydaydesigner.net/design/change-your-focus-and-design-content-first
   

   View Slide

7. Content must work across a
   wide variety of devices
   

   View Slide

8. Device usage (Global averages)
   55% 39% 6%
   source: Statcounter http://gs.statcounter.com/#all-comparison-ww-monthly-201403-201504
   

   View Slide

9. Where possible, don’t rely on
   global statistics, look at your
   own sites usage stats
   

   View Slide

10. Auditing your content
    

    View Slide

11. An audit of your content is
    simply an inventory of what
    you want to include in your
    page
    

    View Slide

12. The audit of our content
    needs to be done before you
    start your UX or Design
    

    View Slide

13. And you should include your
    stakeholders in the auditing
    process
    

    View Slide

14. Prioritising Content
    

    View Slide

15. Content does not have to be
    in the same order on every
    device
    

    View Slide

16. Example: Different content
    priorities for a restaurant
    Small devices Large devices
    Phone number Atmosphere
    Directions Menu
    Booking Booking
    Menu Phone number
    Atmosphere Directions
    

    View Slide

17. So this is how it could
    look on mobile
    

    View Slide

18. and this is how it transforms to larger devices
    

    View Slide

19. To reorder content based on
    the type of device we can use
    CSS Flexbox to handle the
    ordering and target the
    device based on the screen
    size
    

    View Slide

20. 
    
    I am more important on mobile
    
    
    I am more important on desktop
    
    
    

    View Slide

21. @media only screen and (min-width: 768px) {
    .wrapper {
    display: flex;
    flex-direction: column;
    }
    .better-content-for-desktop {
    order: 1;
    }
    .better-content-for-mobile {
    order: 2;
    }
    }
    

    View Slide

22. The limitation here is that not all
    older browsers support Flexbox.
    

    View Slide

23. If you need to support IE9 or
    below you should order your
    content for larger devices in
    HTML and then use the CSS
    on smaller devices to reorder.
    

    View Slide

24. Ensure your content is
    discoverable
    

    View Slide

25. On larger devices navigating
    a site is often really easy
    

    View Slide

26. View Slide

27. Unfortunately, on the
    majority of smaller devices
    navigation on a site becomes
    less obvious
    

    View Slide

28. View Slide

29. View Slide

30. Larger devices also have
    more space for content but
    don’t hide content
    completely on small devices
    

    View Slide

31. View Slide

32. Instead think of ways in
    which you can change the
    functionality to better suit
    the device
    

    View Slide

33. accordion on mobile
    open content on desktop
    

    View Slide

34. new page on mobile
    lightbox on desktop
    

    View Slide

35. simple scrollable
    content on mobile
    parallax on desktop
    

    View Slide

36. How to measure the
    success of content
    optimisation
    

    View Slide

37. Invite your users into your
    office and have them test
    your site
    

    View Slide

38. Go out into the streets and
    ask people to test your site
    

    View Slide

39. A-B test different
    functionality
    

    View Slide

40. Content is King
    

    View Slide

41. Time for a cat break
    

    View Slide

42. Site Performance
    

    View Slide

43. What is performance?
    

    View Slide

44. – Google
    “the action or process of
    performing a task or function”
    

    View Slide

45. In relation to a website,
    performance is the measure
    of how long it takes to deliver
    the content to the user
    

    View Slide

46. There are three key types of
    performance that are
    important to a website
    

    View Slide

47. Render performance -
    The time it takes for the
    browser to start rendering
    the page
    

    View Slide

48. Page load performance -
    The time it takes to fully load
    a page and be fully
    interactive
    

    View Slide

49. Perceived performance -
    the perception of the user of
    the performance of our site
    

    View Slide

50. View Slide

51. Why should I care about
    the performance of the
    site?
    

    View Slide

52. A responsive site is expected
    to work on a wide variety of
    internet connections
    

    View Slide

53. and from a financial point of
    view, it can affect your
    business
    

    View Slide

54. Amazon found every 100ms
    delay in loading a page cost
    them 1% in sales
    

    View Slide

55. Google found an extra
    500ms delay in loading of
    search results decreased
    traffic by 20%
    

    View Slide

56. The trend of the past few
    years however is for pages to
    increase in weight
    

    View Slide

57. Average page weight has been increasing
    year on year
    Average Page Size (kB)
    0
    550
    1100
    1650
    2200
    September 2012 September 2013 September 2014 September 2015
    Data from http://httparchive.org/interesting.php
    

    View Slide

58. Scripts
    Fonts
    Video
    Images
    Stylesheets
    HTML
    Other
    0 350 700 1050 1400
    4
    56
    69
    1,350
    209
    107
    354
    Data from http://httparchive.org/interesting.php
    

    View Slide

59. The average time to start rendering is also
    increasing
    Render start (ms)
    0
    1150
    2300
    3450
    4600
    March 2014 August 2014 March 2015 August 2015
    Data from http://httparchive.org/interesting.php
    

    View Slide

60. What steps can I take to
    improve site performance?
    

    View Slide

61. Create a performance
    budget
    

    View Slide

62. A performance budget
    relates to the size of the
    assets in our page
    

    View Slide

63. Tim Kadlec
    “The purpose of a performance
    budget is to make sure you focus
    on performance throughout a
    project. The reason you go
    through the trouble in the first
    place though is because you want
    to build a site that feels fast for
    your visitors.”
    http://www.timkadlec.com/2014/11/performance-budget-metrics/
    

    View Slide

64. At the start of your project
    you need to understand the
    metrics you want to achieve
    

    View Slide

65. As we are building a
    responsive site, today’s
    example will aim to start
    rendering in 5 seconds on a
    slow 3G connection
    

    View Slide

66. To start with we need to
    define ‘slow 3G’
    

    View Slide

67. WebPageTest defines this as
    96 kilobytes per second
    

    View Slide

68. So as we want to load our site
    in 5 seconds…
    

    View Slide

69. 96KB x 5secs = 480KB
    

    View Slide

70. We can then split 480KB
    across our assets
    

    View Slide

71. Budget we defined
    HTML CSS JavaScript Images
    30kb 40kb 50kb 360kb
    

    View Slide

72. If we then decide we want to
    add web fonts to our website
    we then adjust our budget
    

    View Slide

73. Budget we defined
    HTML CSS JavaScript Images Fonts
    30kb 40kb 50kb 300kb 60kb
    

    View Slide

74. These figures seem very
    ambitious when we compare
    them against the industry
    averages but it is achievable
    

    View Slide

75. Calculate your budget
    yourself using
    www.performancebudget.io
    

    View Slide

76. Optimise how you load
    your assets
    

    View Slide

77. Provide different images for
    different viewport sizes using
    the element
    

    View Slide

78. 
    
    
    
    
    

    View Slide

79. View Slide

80. To use the picture element on
    your site you will need to
    include the polyfill which is
    called “picturefill”
    

    View Slide

81. Defer loading of both image
    and video to improve the
    initial page load
    

    View Slide

82. The most common content to defer
    loading is images
    

    View Slide

83. In cases where loading assets
    was deferred, it is important
    to ensure a suitable
    placeholder is in place
    

    View Slide

84. In deferring the loading of
    our content only those
    images immediately visible to
    our users contribute to our
    page budget
    

    View Slide

85. Defer loading of
    content
    

    View Slide

86. The content is the heart of
    our site but not all content is
    created equal
    

    View Slide

87. Lets look at an example of
    how Metro defer the
    loading of related content
    

    View Slide

88. View Slide

89. View Slide

90. View Slide

91. Another example where
    content is deferred is
    Facebook
    

    View Slide

92. Facebook choose to defer loading the
    majority of the content of their page
    

    View Slide

93. The biggest danger of
    deferring content is that if
    JavaScript fails to load the
    content that is deferred will
    not be loaded
    

    View Slide

94. View Slide

95. We should therefore be
    careful with what content we
    choose to defer loading
    

    View Slide

96. The biggest implication about
    deferring content is that we
    are able to reduce the size of
    what we initially deliver to
    our users
    

    View Slide

97. Optimise how you load
    your JavaScript
    

    View Slide

98. An average site uses 354Kb
    of JavaScript
    

    View Slide

99. In our performance budget
    we set a target of 50Kb of
    JavaScript
    

    View Slide

100. Therefore we need to either
     lose 304Kb of JavaScript or
     change how we load it
     

     View Slide

101. To do this, we can separate
     our JavaScript into two
     distinct types
     

     View Slide

102. Critical JavaScript is the
     JavaScript required to
     initialise our page.
     

     View Slide

103. This includes any JavaScript
     that is required to layout the
     page
     

     View Slide

104. View Slide

105. Add events which track how
     user tries to interact with the
     page
     

     View Slide

106. Show states which let the
     user know something is
     happening while we still wait
     for Main JS to load
     

     View Slide

107. Trigger loading of the Main
     JS when the rest of the page
     has loaded
     

     View Slide

108. Then we have our main
     JavaScript,
     

     View Slide

109. Fire any events that had been
     deferred
     

     View Slide

110. Replace the deferred event
     listeners with the real ones
     

     View Slide

111. Include all the rest of the
     functionality required for the
     site to function
     

     View Slide

112. How this works in practice
     

     View Slide

113. View Slide

114. View Slide

115. So how do I do it?
     

     View Slide

116. Use a library called CriticalJS
     

     View Slide

117. Download CriticalJS from
     https://github.com/jonathan-
     fielding/criticaljs
     

     View Slide

118. 
     Load the CriticalJS library
     Tell it where your main JavaScript is
     

     View Slide

119. 
     Click Me
     
     Add data attribute specifying
     what events are to be deferred
     

     View Slide

120. Then in your main JavaScript
     

     View Slide

121. var button = document.querySelector('button')
     var clicked = criticaljs.deferred(button, ‘click’);
     var ev = function(){
     alert(‘clicked’);
     }
     if (clicked) {
     ev.bind(button)();
     }
     button.addEventListener(ev);
     Check if the event
     has been triggered
     Handle deferred
     user interaction
     Attach the real
     interaction
     

     View Slide

122. Measuring
     Performance
     

     View Slide

123. Regularly measure
     performance against your
     performance budget
     

     View Slide

124. The simplest tool for
     measuring performance is
     www.webpagetest.org
     

     View Slide

125. View Slide

126. As we want to test our site on
     a slow 3G connection we will
     use the advanced settings
     

     View Slide

127. Browser
     Connection
     

     View Slide

128. View Slide

129. View Slide

130. Need for speed
     

     View Slide

131. In Summary
     

     View Slide

132. When building a responsive
     site we should spend time
     focusing on the content and
     performance
     

     View Slide

133. Our content should be
     prioritised and discoverable
     

     View Slide

134. And the perception of our
     site to our users should be
     that it loads fast
     

     View Slide

135. Full examples of everything we have
     talked about can be found at
     www.jonathanfielding.com/talks/
     reimagining-responsive-design/
     

     View Slide

136. A special thanks goes out to to Charlie
     Fielding, Kate Montgomery, Phil Nash,
     Callum Macrae and everyone at Beamly who
     helped me with putting these slides together.
     

     View Slide

137. Thank you,
     any questions?
     

     View Slide