3 Tips for a better mobile User Experience
Download as PPTX, PDF0 likes327 views
This document provides tips to deliver fast performance on mobile web. It discusses how network, browser, and server-side factors can impact page load times. It also provides recommendations like preloading critical resources, reducing payload sizes through image optimization and code splitting, and implementing a service worker for caching to improve performance for returning users. The goal is to help developers understand how to optimize the user experience on mobile.
![self.addEventListener('fetch', function(event) {
event.respondWith(
caches.match(event.request)
.then(function(response) { // Cache hit - return response
if (response) { return response; }
return fetch(event.request);
})
);
});
var CACHE_NAME = 'my-site-cache-v1';
var urlsToCache = [ '/', '/styles/main.css', '/script/main.js' ];
self.addEventListener('install', function(event) { // Perform install steps
event.waitUntil(
caches.open(CACHE_NAME)
.then(function(cache) {
console.log('Opened cache');
return cache.addAll(urlsToCache);
})
);
});](https://image.slidesharecdn.com/3tipsforabettermobileuserexperience-slideshare-160915120503/85/3-Tips-for-a-better-mobile-User-Experience-67-320.jpg)
3 Tips for a better mobile User Experience
- 1. 3 Tips to Deliver Fast Performance Across Mobile Web Stefan Baumgartner @ddprrt Klaus Enzenhofer @kenzenhofer
- 2. Who we are
- 3. 4.5 sec 15 sec Why?
- 4. Network Same Page 4.5 sec 15 secSanity Check Browser CheckChrome 49 Chrome Mobile 33 Server Side Local WLANLocal WLAN Only difference is Browser & Device
- 5. Why did they look at the performance on the mobile device?
- 6. Google - Mobile Friendliness Campaign?!
- 7. Change in their compensations plan!
- 8. Contract SLA: Average Response Time < 3 sec User on Desktop + Mobile
- 9. Good idea?!
- 10. Let’s talk about response time
- 11. Network Same Page 4.5 sec 15 secSanity Check Browser CheckChrome 49 Chrome Mobile 33 Server Side Local WLANLocal WLAN
- 12. 4.5 sec 15 sec UserDeveloper Operator
- 14. Let‘s take a look at the timings! Navigation Start: 0 ms Domain Lookup End: 269 ms Connect End: 330 ms Response Start: 517 ms Response End: 518 ms Dom Loading: 519 ms Dom Interactive: 519 ms DomContentLoaded Event End: 520 ms Dom Complete: 520 ms
- 15. 0.5 sec 0.5 sec Developer
- 16. User Operator
- 17. User
- 19. DNS Lookup Initial connection TTFB (HTML) Download Life of an URL request
- 20. Starting here, we are able to control …
- 22. <script src=“angular.js”> blocking! <script src=“main.js”> blocking!
- 23. <script src=“angular.js”> blocking! <script src=“main.js”> blocking! start render
- 24. <script src=“angular.js”> blocking! <script src=“main.js”> blocking! start renderresponse time
- 25. The impact of a JavaScript error
- 26. <script src=“angular.js”> blocking! <script src=“main.js”> blocking! start render?
- 27. Important content first Everthing else is an enhancement
- 28. Single page application frameworks are aware of this trend - As long as you have valid routes (= URLs), you have the ability to render the state on the server - The first two requests are the document and the styles of your application - Then the JS framework kicks in
- 30. Browser App ServingassetsAPIServer GET /app JavaScript payload GET /api/users JSON payload GET /api/posts GET /api/pages JSON payload JSON payload Send index.html Request JS application
- 31. Browser App UniversalrenderingAPIServer GET /app JavaScript payload GET /api/users JSON payload GET /api/posts GET /api/pages JSON payload JSON payload Initial render HTML + CSS Request JS application
- 35. 4.5 sec 6 sec UserDeveloper Operator
- 36. Operator
- 37. The CDN bill exploded!
- 38. 285 Resources for an initial Page Load 151 CSS and 121 JavaScript files
- 39. ~200 Resources had larger Header than Body
- 40. User
- 45. Back Home
- 46. Back Home
- 47. HTTP Archive – Transfer Size Trend http://httparchive.org/trends.php Average Size ~2 500 KB By 1.6 € per 100 KB 40 € to get started!!!!
- 48. 2. Page weight
- 49. There’s lots of ways to reduce the payload
- 52. <img src=”screenshot-600.png” srcset="screenshot-200.png 200w, screenshot-400.png 400w, screenshot-600.png 600w, screenshot-800.png 800w, screenshot-1000.png 1000w, screenshot-1200.png 1200w, screenshot-1400.png 1400w, screenshot-1600.png 1600w” sizes="(min-width: 900px) 50vw, 100vw" alt=”Super screenshot of our product.">
- 53. <img src=”screenshot-600.png” srcset="screenshot-200.png 200w, screenshot-400.png 400w, screenshot-600.png 600w, screenshot-800.png 800w, screenshot-1000.png 1000w, screenshot-1200.png 1200w, screenshot-1400.png 1400w, screenshot-1600.png 1600w” sizes="(min-width: 900px) 50vw, 100vw" alt=”Super screenshot of our product."> These sources are available. For each “width unit” there’s a reduced version of our original screenshot The sizes define which source to choose from. Retina screens are also checked A low-res fallback image for browsers that don’t know srcset
- 54. Reduce styles
- 56. Tree shaking
- 60. 4.5 sec 6 sec UserDeveloper Operator
- 61. 3. Now for the returning visitor
- 62. Service worker
- 66. if ('serviceWorker' in navigator) { navigator.serviceWorker.register('/sw.js') .then(function(registration) { // Registration was successful console.log('ServiceWorker registration successful with scope: ', registration.scope); }).catch(function(err) { // registration failed :( console.log('ServiceWorker registration failed: ', err); }); }
- 67. self.addEventListener('fetch', function(event) { event.respondWith( caches.match(event.request) .then(function(response) { // Cache hit - return response if (response) { return response; } return fetch(event.request); }) ); }); var CACHE_NAME = 'my-site-cache-v1'; var urlsToCache = [ '/', '/styles/main.css', '/script/main.js' ]; self.addEventListener('install', function(event) { // Perform install steps event.waitUntil( caches.open(CACHE_NAME) .then(function(cache) { console.log('Opened cache'); return cache.addAll(urlsToCache); }) ); });
- 69. 2 sec 2.5 sec UserDeveloper Operator
- 70. 4.5 sec 15 sec UserDeveloper Operator UserDeveloper Operator How to? 2.5 sec2 sec
- 71. 4.5 sec 15 sec UserDeveloper Operator UserDeveloper Operator How to? 2.5 sec2 sec Happy Developer != Happy User Your user might travel and mobile data is expensive The returning user will appriciate your caching strategy
- 72. You don‘t know how happy your users are? https://www.dynatrace.com/trial/
- 73. Thank you! Stefan Baumgartner @ddpprt Klaus Enzenhofer @kenzenhofer
Editor's Notes
- #3: Austrians that love Performance Were sitting together in the same classrooms at University
- #4: Gleiche Bedingungen. Only difference: Device and Browser! HTTP2 vs HTTP1 More Calculation Power …
- #5: Gleiche Bedingungen. Only difference: Device and Browser! HTTP2 vs HTTP1 More Calculation Power …
- #7: https://www.google.com/webmasters/tools/mobile-friendly/
- #8: https://www.google.com/webmasters/tools/mobile-friendly/
- #10: https://www.google.com/webmasters/tools/mobile-friendly/
- #11: Response Time story: What does < 3 sec response time mean? Does it mean your app’s complete, or does it start loading. User Exerpience vs Developer Experience. SLA fulfilled Truth is: Most SPAs kick in after “on load” the ”fun” starts here. 0 sec Response time blank screen What if JS does not load Your app depends on stable connection and high JS computational power Solution: Progressive Rendering. Server side first. JS kicks in later Two resources to load: Critical CSS file (Styles for main view), Finished HTML Suddenly Response time is important again Everything then is Async and highly questionable
- #12: Gleiche Bedingungen. Only difference: Device and Browser! HTTP2 vs HTTP1 More Calculation Power …
- #13: Gleiche Bedingungen. Only difference: Device and Browser! HTTP2 vs HTTP1 More Calculation Power …
- #17: Gleiche Bedingungen. Only difference: Device and Browser! HTTP2 vs HTTP1 More Calculation Power …
- #18: UX vs DX
- #19: Alright Klaus, let’s take a look at the user first… why is the user still wearing his sad face even though our SLA seems to be fulfilled.
- #20: Well it’s most likely due to the fact the user is seeing something like this. Can you figure out what this application should do? No? Me neither… That’s because it’s missing one vital part to be of use: The content. So why is this happening?
- #21: Let’s see how an URL request is constructed. You all have seen this before. We do a DNS lookup to see where we get our resources from, connect to the server, let the server handle the response and download the resource. Usually, the first request you’re doing is to an HTML page that contains all the markup and references to the content we want to display.
- #22: So once this first HTML file is downloaded, we have the ability to control what’s happening in the front-end.
- #23: With a single page application framework we usually do something like this: Downloading the framework’s JavaScript file! Resulting in a blocking request until we get some content on screen.
- #24: We’re also downloading our own application of course, resulting in much likely a more longer request than before. Still blocking until we get some contents on screen. On mobile, this takes even longer because of network latency. Every request adds several round trips until you get to an actual response. And I’m just counting the response time of the resources here, not the time it needs to actually interpret and execute the JavaScript code that we just downloaded.
- #25: Once this is done, we finally see the content rendered. This can take up to several seconds. If you follow the guidelines of your framework, you load the JavaScript files and the end of your application, and most likely asynchronous and deferred. Which means that those requests don’t add up to the response time.
- #26: The actual response time of your application triggers when the original HTML file is downloaded! Resulting in this huge gap between response time and perceived render time.
- #27: Even worse… there’s the possibility that some of your code might break. Or imagine having a flaky internet connection, where some requests just get cancelled and won’t get transferred at all. This can happen on mobile. More often than we like. The result? Your user triggering a 500 mill response time but waiting for ages to actually see something.
- #28: So why not use the first request and try to get the most important thing out there before we request the application: Content for the visitor.
- #29: Deliver the most important content with the first request, everything that comes after that is just an enhancement.
- #30: This is a trend all major single page applications frameworks are aware of. Every framework now uses routes, which are de facto URLs, to keep the state of the application. With those routes, they also have the opportunity to render said state on the server. So the first request that you receive on the client is actually a server-rendered version of the state the JS app would deliver once it’s loaded. Just then, the JavaScript framework and application is loaded and kicks in.
- #31: Let’s take a look into that in detail.
- #32: Usually, we request the app, it delivers a static HTML file, we request the JavaScript application, and after that’s rendered, we make calls to an API server. Classic SPA.
- #33: With server side rendering we want to make the first response count. Deliver everything that is needed to actually see content and allow the user to interact with the application. Then the JavaScript application loads and takes over. Perfect idea of progressive enhancement with single page applications!
- #34: There are lots of solutions already out there. If you use Ember, having server side rendering comes for free. You install Fastboot, and fastboot does everything for you.
- #35: It’s a little more complex in the React ecosystem. As usual, you have lots of choices which are all varying in the details. Also, there’s no switch-on solution, you have to do a lot by yourself. On the plus-side: There are solutions that work with other server environments than Node.js.
- #36: Angular 2 also has a server side rendering solution called “Universal Angular 2”, which is pretty much in the vein of Ember’s fastboot.
- #37: So with that, we make our user somewhat happier... But we still have a sad operator
- #38: UX vs DX
- #50: 1. Bandwidth topic and dataplan 2. “Klausi did a Journey”. Australia story 4$ per MB 3. What does my site cost www.whatdoesmysitecost.com 4. Roaming??? 5. Local: Income vs data plan 6. Header vs Payload HTTP1 Problem Solutions: Reduce to essentials Tooling Uncss, Treeshaking, Do I need this fancy pop-up?, Responsive Images
- #51: You know that already, there’s lots of ways to reduce the payload we’re sending to the client. Running your images through ImageOptim, minifying and gzipping your CSS and JavaScript, all things that are by the book. So let’s what else can we do and what’s directly geared towards mobile web.
- #52: First, there’s responsive images.
- #53: The idea of responsive images is that you have a ton of different screen sizes, why download the same image to all those varying screens. Why not tailor the payload of an image as well as the content of an image to the screen at hat. The Responsive Images Community Group did an outstanding work in specify a standard. There’s a lot to this standard, including new elements and new browser algorithms, but I want to show you a quick example that’s sort of a quick win with Responsive images.
- #54: So.. This is a spiced up image element. The colored parts are brand new. You see a property called “srcset” and one called “sizes”, and they all feature different values.
- #55: The srcset property features a list of images that are defined for a certain “width unit”. I call it width unit because it’s not pixel on Retina screens. So this is the set where the browser can choose the images from. The sizes property define the rules which image to choose. First we start with the exception, which says that at a minimum resolutin of 900px, take a screenshot that’s at least half the width of the viewport. For all other cases, take one that’s at least 100% of the viewport. The browser evaluates those rules, gets a width unit value, and selects one of the images defined above. If the browser doesn’t know those properties, he still falls back to the original src attribute. As easy as that. Quick win for reducing the payload on smaller screens.
- #56: Next, reduce styles. The advanced edition. Not only can you reduce stylesheets by minifying and gzipping them, but there’s also a nice tool out there that allows us to filter styles that aren’t used.
- #57: It’s called UnCSS and is super helpful if you use frameworks like bootstrap. Bootstrap comes with a gazillion of components, but most sites only use roughly 20% of it. This tool checks which parts of this framework are used on that page, the rest is removed.
- #58: Last, but not least, there’s a new technique out there called tree shaking, which is something like UnCSS but for JavaScript, especially if you use the new ES16 standard.
- #59: Take a look at the code. With ES16 you are able to do modules, and export various functions from a module. The code on the upper left is a “math” library. In our application code in the lower left corner, we just import one function from this library, namely “cube”. The output on the right is a bundle created through tree shaking. Instead of including the whole “math.js” file, we just include the part that we need. This can reduce your application code significantly. And all major frameworks are going to build up on that. Which means even more reduced application files in the future!
- #60: Tools that support tree shaking already are things like Rollup.js
- #61: And Google’s Closure compiler… this godfather of JavaScript minifying tools is also the one that’s being used in AngularJS 2.
- #62: Alright, … so we came down to reducing the costs and the requests and the payload. User is happy because he’s getting a fast app, and the operator is getting a much smaller bill than before.
- #63: But this is just for the first view.. Let’s do something for the returning visitor to pump our game up even more. You know by now that you should find good cache headers and aim for leaving as much content on the client, rather than requesting in further and further… but there’s one new thing that you can use which ups your offline game even more, and especially on mobile.
- #64: It’s called service worker… let me show you quickly how this works:
- #65: Su, usually the browser is request a resource from the world wide web. That’s the blue arrow. The response delivers this resource to the client, and the client stores it in the cache.
- #66: With service workers, you have a man in the middle which can check each request and can help you modifying it. So instead of talking to the web server directly, the service worker passes each request through, and checks if it should do something with it. A typical call is browser does a request… service worker analyises this request and passes it to the webserver. The response is getting stored into a cache by the service worker and delivered to the client.
- #67: So… let’s assume the web server is down... Or not reachable because your client is offline. In that case, the service worker sees that the connection is not there, and will request the resource from the cache instead from the web. The biggest benefit compared to existing solutions: This works offline. No internet connection required!
- #68: Here’s some sample code. I don’t want to get too much into detail given the time, but registering a service worker is done with the appropriate call… A service worker is nothing more than a JavaScript file that uses certain APIs. This service worker now is getting installed and is avaiable to the client.
- #69: The upper portion of the code creates a cache on install. It also tells the cache which resources to store. The second portion of the code listens on each fetch request. Everytime a resource is requested, the service worker checks if there’s something in store, otherwise it will pass it to the network. This adds offline functionality to your app!
- #70: This is of course just a basic scenario. If you need more, I highly recommend going to the service worker toolbox. It provides a great API and lots of recipes for advanced use cases
- #71: Gleiche Bedingungen. Only difference: Device and Browser! HTTP2 vs HTTP1 More Calculation Power …
- #72: Gleiche Bedingungen. Only difference: Device and Browser! HTTP2 vs HTTP1 More Calculation Power …
- #73: Gleiche Bedingungen. Only difference: Device and Browser! HTTP2 vs HTTP1 More Calculation Power …
- #74: Gleiche Bedingungen. Only difference: Device and Browser! HTTP2 vs HTTP1 More Calculation Power …