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
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
27. Unfortunately, on the majority of smaller devices navigation on a site becomes less obvious
30. Larger devices also have more space for content but don’t hide content completely on small devices
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
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>
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
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
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
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
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
126. As we want to test our site on a slow 3G connection we will use the advanced settings
127. Browser Connection
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?