Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Refocusing our Priorities in Responsive Design

Refocusing our Priorities in Responsive Design

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

Jonathan Fielding

September 25, 2015
Tweet

More Decks by Jonathan Fielding

Other Decks in Technology

Transcript

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

  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’
  3. Current Responsive Design techniques focus on mobile first

  4. There has not been the same focus on either the

    content or the performance of our site.
  5. Our site content

  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
  7. Content must work across a wide variety of devices

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

  9. Where possible, don’t rely on global statistics, look at your

    own sites usage stats
  10. Auditing your content

  11. An audit of your content is simply an inventory of

    what you want to include in your page
  12. The audit of our content needs to be done before

    you start your UX or Design
  13. And you should include your stakeholders in the auditing process

  14. Prioritising Content

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

    on every device
  16. Example: Different content priorities for a restaurant Small devices Large

    devices Phone number Atmosphere Directions Menu Booking Booking Menu Phone number Atmosphere Directions
  17. So this is how it could look on mobile

  18. and this is how it transforms to larger devices

  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
  20. <div class="wrapper"> <div class="better-content-for-mobile"> I am more important on mobile

    </div> <div class="better-content-for-desktop"> I am more important on desktop </div> </div>
  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; } }
  22. The limitation here is that not all older browsers support

    Flexbox.
  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.
  24. Ensure your content is discoverable

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

  26. None
  27. Unfortunately, on the majority of smaller devices navigation on a

    site becomes less obvious
  28. None
  29. None
  30. Larger devices also have more space for content but don’t

    hide content completely on small devices
  31. None
  32. Instead think of ways in which you can change the

    functionality to better suit the device
  33. accordion on mobile open content on desktop

  34. new page on mobile lightbox on desktop

  35. simple scrollable content on mobile parallax on desktop

  36. How to measure the success of content optimisation

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

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

    your site
  39. A-B test different functionality

  40. Content is King

  41. Time for a cat break

  42. Site Performance

  43. What is performance?

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

    or function”
  45. In relation to a website, performance is the measure of

    how long it takes to deliver the content to the user
  46. There are three key types of performance that are important

    to a website
  47. Render performance - The time it takes for the browser

    to start rendering the page
  48. Page load performance - The time it takes to fully

    load a page and be fully interactive
  49. Perceived performance - the perception of the user of the

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

  52. A responsive site is expected to work on a wide

    variety of internet connections
  53. and from a financial point of view, it can affect

    your business
  54. Amazon found every 100ms delay in loading a page cost

    them 1% in sales
  55. Google found an extra 500ms delay in loading of search

    results decreased traffic by 20%
  56. The trend of the past few years however is for

    pages to increase in weight
  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
  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
  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
  60. What steps can I take to improve site performance?

  61. Create a performance budget

  62. A performance budget relates to the size of the assets

    in our page
  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/
  64. At the start of your project you need to understand

    the metrics you want to achieve
  65. As we are building a responsive site, today’s example will

    aim to start rendering in 5 seconds on a slow 3G connection
  66. To start with we need to define ‘slow 3G’

  67. WebPageTest defines this as 96 kilobytes per second

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

    seconds…
  69. 96KB x 5secs = 480KB

  70. We can then split 480KB across our assets

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

    360kb
  72. If we then decide we want to add web fonts

    to our website we then adjust our budget
  73. Budget we defined HTML CSS JavaScript Images Fonts 30kb 40kb

    50kb 300kb 60kb
  74. These figures seem very ambitious when we compare them against

    the industry averages but it is achievable
  75. Calculate your budget yourself using www.performancebudget.io

  76. Optimise how you load your assets

  77. Provide different images for different viewport sizes using the <picture>

    element
  78. <picture> <source srcset="large.jpg" media="(min-width: 1200px)"> <source srcset="medium.jpg" media="(min-width: 600px)"> <img

    src="small.jpg" alt="Picture element"> </picture>
  79. None
  80. To use the picture element on your site you will

    need to include the polyfill which is called “picturefill”
  81. Defer loading of both image and video to improve the

    initial page load
  82. The most common content to defer loading is images

  83. In cases where loading assets was deferred, it is important

    to ensure a suitable placeholder is in place
  84. In deferring the loading of our content only those images

    immediately visible to our users contribute to our page budget
  85. Defer loading of content

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

    all content is created equal
  87. Lets look at an example of how Metro defer the

    loading of related content
  88. None
  89. None
  90. None
  91. Another example where content is deferred is Facebook

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

    of their page
  93. The biggest danger of deferring content is that if JavaScript

    fails to load the content that is deferred will not be loaded
  94. None
  95. We should therefore be careful with what content we choose

    to defer loading
  96. The biggest implication about deferring content is that we are

    able to reduce the size of what we initially deliver to our users
  97. Optimise how you load your JavaScript

  98. An average site uses 354Kb of JavaScript

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

    of JavaScript
  100. Therefore we need to either lose 304Kb of JavaScript or

    change how we load it
  101. To do this, we can separate our JavaScript into two

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

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

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

    the page
  106. Show states which let the user know something is happening

    while we still wait for Main JS to load
  107. Trigger loading of the Main JS when the rest of

    the page has loaded
  108. Then we have our main JavaScript,

  109. Fire any events that had been deferred

  110. Replace the deferred event listeners with the real ones

  111. Include all the rest of the functionality required for the

    site to function
  112. How this works in practice

  113. None
  114. None
  115. So how do I do it?

  116. Use a library called CriticalJS

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

  118. <script src="../src/criticaljs.js" data-deferredjs="scripts/main.js"></script> Load the CriticalJS library Tell it where

    your main JavaScript is
  119. <button data-deferred=“click”> Click Me </button> Add data attribute specifying what

    events are to be deferred
  120. Then in your main JavaScript

  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
  122. Measuring Performance

  123. Regularly measure performance against your performance budget

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

  125. None
  126. As we want to test our site on a slow

    3G connection we will use the advanced settings
  127. Browser Connection

  128. None
  129. None
  130. Need for speed

  131. In Summary

  132. When building a responsive site we should spend time focusing

    on the content and performance
  133. Our content should be prioritised and discoverable

  134. And the perception of our site to our users should

    be that it loads fast
  135. Full examples of everything we have talked about can be

    found at www.jonathanfielding.com/talks/ reimagining-responsive-design/
  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.
  137. Thank you, any questions?