CG16 - Perceived performance

Website performance is important. It can be the difference between making a sale and losing a client. Luckily there are quite a few things we can do to enhance the user’s perception of a site’s performance. We’ll go through some nifty tricks that can improve the user experience of a website with waiting time.

Transcript

1. UMBRACO CODEGARDEN ‘16 PERCEIVED PERFORMANCE June 15th 2016
2. RASMUS LYNGGAARD  rlynggaard  rasmus.lynggaard@kraftvaerk.com KRAFTVAERK A/S
3. PERCEPTION OF TIME
4. WHAT IS TIME?  Time can be approached from two angles  The actual time  The perceived time
5. THE ACTUAL TIME  Can be measured with a clock  Often measured as TTI (Time To Interact)  Sverage: 5,2 sec  Only 14% at 3 sec. or less  Time is money  Firefox reduced page load with 2,2 sec. and increased downloads with 15,4%
6. PERFORMANCE BUDGET 10 1 0,1 Instant Immediate Attention span
7. Weber-Fechner / JND  JND – Just Noticeable Difference  20% rule of thumb  Your site loads in 8 seconds  You’ll have to cut off 1,6 seconds before any improvement is noticed by the user
8. Weber-Fechner / JND  Your site loads in 5 seconds  Your competitors loads in 2 seconds  According to JDN your site should load in 2,4 seconds  If you were able to do that – you would have, right?
9. CHASING THE LEADER  If your competitors site is faster  Geometrisk mean = √(A × B)  The user will experience a difference in performance, but it won’t have an effect when choosing a service  Everything else is equal – Quality, service and usablity makes a bigger difference
10. “Time is measured objectively but perceived subjectively, and experiences can be engineered to improve perceived performance.” Ilya Grigorik
11. THE PERCEIVED TIME  The perceived time often differs from the actual time.  The perceived time is a mix of many factors – eg.  User expectations  Usability  The actual time  Active or passive – People will rather be active while waiting than passive  If (passiveWait) { var overEstimationOfActualWait = ActualWait * 1.36; }
12. STATUS INDICATORS
13. STATUS INDICATORS  Status indicators can work very well.  Status indicators shows the user, that the site is working and their action is being handled.  Use a spiner (or another simpel indicator) for actions taking between 1 and 5 seconds (Using a progress bar, will make the action seem slower than it actually is)  Actions taking longer than 5 seconds a progress bar is usable.  A status indicator with percentage indication should only be used on actions taking 10 seconds or more.
14. STATUS INDICATOR – PROGRESS BAR  Progress bars which gives an illusion of spinning left, can reduce the perceived performance with as much as 10%  Pulsating progress bars, which increases the frequens is perceived as being faster.  Progress bars, which increases its speed has a positive effect on users.
15. SKELETON SCREENS  Skeleton screens is becoming widely used  Can advantageously be used on sites where the content is structured in a reasonable fixed grid  Load and render grid => async load of content
16. BACKGROUND PLACEHOLDER SKELETON SCREENS
17. PROGRESSIVE IMAGE LOADING Baseline Progressive
18. Waiting for fonts.googleapis.com
19. WEB FONTS PERFORMANCE
20. WEB FONT USAGE Kilde: httparchive.org
21. WEBFONT USAGE 394 KB
22. FONT LOADING 100 MS 200 MS 300 MS 400 MS 500 MS 600 MS 700 MS HTML
23. FONT LOADING 100 MS 200 MS 300 MS 400 MS 500 MS 600 MS 700 MS HTML CSS
24. FONT LOADING 100 MS 200 MS 300 MS 400 MS 500 MS 600 MS 700 MS HTML CSS
25. FONT LOADING 100 MS 200 MS 300 MS 400 MS 500 MS 600 MS 700 MS HTML CSS Start font loading FONT A FONT B
26. FONT LOADING 100 MS 200 MS 300 MS 400 MS 500 MS 600 MS 700 MS HTML CSS Start font loading FONT A FONT B Font A is rendered
27. FONT LOADING 100 MS 200 MS 300 MS 400 MS 500 MS 600 MS 700 MS HTML CSS Start font loading FONT A FONT B All fonts are rendered
28. 600 MS 500 MS FONT LOADING 100 MS 200 MS 300 MS 400 MS 700 MS HTML CSS Start font loading FONT A FONT B All fonts are rendered
29. FOUT vs FOIT
30. FOUT FOIT Start request Content loaded Webfonts loaded Start request Content loaded Webfonts loaded
31. CSS FONT-DISPLAY @font-face { font-family: My Font; src: url(myfont.woff); font-display: auto|block|swap|fallback|optional; }
32. CSS FONT-DISPLAY @font-face { font-family: My Font; src: url(myfont.woff); font-display: auto|block|swap|fallback|optional; }
33. CSS FONT-DISPLAY Coming Soon Still no browser support Use Javascript
34. FONT FACE OBSERVER var openSans = new FontFaceObserver(”Open Sans”); openSans.check().then(function() { //font is loaded )};
35. OPTIMISTIC ACTIONS
36. MAKE IT LOOK LIKE….  It works – event though it’s not  An action performed  Register a user action and perform the actual work later  The user click ”Like”. We enable the button and the action is queued. When a connection is reestablished we can save the action.
37. ANTICIPATE USER ACTIONS  Do we have long running operations, which can be started up front?  If you are engaged in an upload dialogue, in which meta-data must be filled, start upload as quickly as possible - even before there are clicked on submit  Do I know which page the user will visit next?  Use resource hints to retrieve resources even before they are needed
38. RESOURCE HINTS When Example dns-prefetch Early DNS resolve Image hosts, CDNs, Analytics, 3. party scripts preconnect Like dns-prefetch, but alsop TCP handshake and TLS negotition Image hosts, CDNs, Analytics, 3. party scripts prefetch Low priority – fetch resources in the background CSS or javascript (that might be needed later) prerender Render an entire page in the background Login page – next page is probably the ”logged in” page preloading (Chrome =>50 Opera => 37) Fetch individual resources with ressource priority CSS or javascript <link rel=”prefetch” href=”MyFont.woff”>
39. Buttons on mobile devices
40. BUTTONS ON MOBILE DEVICES  300ms wait on tap – waiting for double tap.  Ideal responsetime er <=100ms  Chrome (32+) og Firefox removed this delay
41. BUTTONS ON MOBILE DEVICES <meta name="viewport" content="width=device-width, user- scalable=no">
42. BUTTONS ON MOBILE DEVICES <meta name="viewport" content="width=device-width, user- scalable=no">
43. BUTTONS ON MOBILE DEVICES We can make it seem like something is happening instantly – add an active state to the button. button:active { /* Change the styling */ background-color: rgba(0,0,0,0.5); }
44. BUTTONS ON MOBILE DEVICES Some mobile browsers require some javascript to get the active state to work document.addEventListener(“touchstart”, function(){}, true);
45. BUTTONS ON MOBILE DEVICES Some browsers have their own default styling of active buttons. Remove those by using these rules -webkit-tap-highlight-color: rgba(0,0,0,0); -webkit-tap-highlight-color: transparent;
46. BUTTONS ON MOBILE DEVICES  This wont remove the 300ms delay, but it’ll make a better userexperience  There are polyfills, which removes the 300ms delay  FastClick - https://github.com/ftlabs/fastclick
47. MOMENTUM SCROLLING
48. MOMENTUM SCROLLING -webkit-overflow-scrolling: touch;
49. MOMENTUM SCROLLING
50. HTTP/2
51. ?