Successfully reported this slideshow.
Your SlideShare is downloading. ×

The secret web performance metric no one is talking about

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 51 Ad

The secret web performance metric no one is talking about

Download to read offline

As presented as JSConf Korea. https://2022.jsconf.kr/en/speakers/anna-migas

Web performance and its impact on the user experience has been a huge topic over past few years. After working for over a year on a project directed towards emerging markets (namely Nigeria and Kenya), I came to realise that the popular web performance metrics are all centred around a specific type of person: someone who is used to the fast and reliable connection. In my talk I want to share my experience on how to look at the overall web performance with the new metric in mind - user’s patience.
During my talk, I want to give an insight on my work with the app that is dedicated towards the users who are working with it in not-so-ideal conditions with an unreliable connection and how to guide them through this experience. I want to chat about the cases when web performance metrics as we know it will not be applicable and what can we do to ensure the user will be able to successfully navigate the app using the well designed information and some performance tricks. I will also share details about the background of users in Africa and how their perception might differ from the users we typically develop for—since these are the fastest growing markets, maybe soon this knowledge come useful to you too

As presented as JSConf Korea. https://2022.jsconf.kr/en/speakers/anna-migas

Web performance and its impact on the user experience has been a huge topic over past few years. After working for over a year on a project directed towards emerging markets (namely Nigeria and Kenya), I came to realise that the popular web performance metrics are all centred around a specific type of person: someone who is used to the fast and reliable connection. In my talk I want to share my experience on how to look at the overall web performance with the new metric in mind - user’s patience.
During my talk, I want to give an insight on my work with the app that is dedicated towards the users who are working with it in not-so-ideal conditions with an unreliable connection and how to guide them through this experience. I want to chat about the cases when web performance metrics as we know it will not be applicable and what can we do to ensure the user will be able to successfully navigate the app using the well designed information and some performance tricks. I will also share details about the background of users in Africa and how their perception might differ from the users we typically develop for—since these are the fastest growing markets, maybe soon this knowledge come useful to you too

Advertisement
Advertisement

More Related Content

Recently uploaded (20)

Advertisement

The secret web performance metric no one is talking about

  1. 1. Lead UI Developer at Field Intelligence Anna Migas Google Developer Expert
  2. 2. Anna Migas @szynszyliszys The secret web performance metric no one is talking about
  3. 3. “Web performance refers to the speed in which web pages are downloaded and displayed on the user's web browser“ wikipedia.org/wiki/Web_performance
  4. 4. web performance
  5. 5. User experience connected to the web performance
  6. 6. User experience connected to the web performance from a perspective of an average user in Africa
  7. 7. Why should you care? Africa is far.
  8. 8. It is a problem for anyone: 1. Using an old device 2. Located in a rural area 3. Using an enterprise app that is hard to optimise
  9. 9. Most web performance metrics and resources are developed with a privileged user in mind.
  10. 10. For some users, the good web performance is not achievable at all.
  11. 11. “At a high level, there are two primary performance bottlenecks on the web: 1. Networking - the round-trip time to acquire an asset or data payload from a remote server 2. End-user Device Compute - the amount of computational overhead required on the end-user's device” https://www.webperf.tips/tip/cached-js-misconceptions/
  12. 12. “At a high level, there are two primary performance bottlenecks on the web: 1. Networking - the round-trip time to acquire an asset or data payload from a remote server 2. End-user Device Compute - the amount of computational overhead required on the end-user's device” https://www.webperf.tips/tip/cached-js-misconceptions/
  13. 13. “At a high level, there are two primary performance bottlenecks on the web: 1. Networking - the round-trip time to acquire an asset or data payload from a remote server 2. End-user Device Compute - the amount of computational overhead required on the end-user's device” https://www.webperf.tips/tip/cached-js-misconceptions/
  14. 14. “At a high level, there are two primary performance bottlenecks on the web: 1. Networking - the round-trip time to acquire an asset or data payload from a remote server 2. End-user Device Compute - the amount of computational overhead required on the end-user's device” https://www.webperf.tips/tip/cached-js-misconceptions/
  15. 15. Latency Latency is generally considered to be the amount of time it takes from when a request is made by the user to the time it takes for the response to get back to that user. https://developer.mozilla.org/en-US/docs/Web/Performance/
  16. 16. Latency in most parts of Africa is really high. High latency means long Time To First Byte (TTFB).
  17. 17. Latency in most parts of Africa is really high. High latency means long Time To First Byte (TTFB).
  18. 18. “While a good TTFB doesn’t necessarily mean you will have a fast website, a bad TTFB almost certainly guarantees a slow one.” — Harry Roberts https://csswizardry.com/2019/08/time-to-first-byte-what-it-is-and-why-it-matters/
  19. 19. “At a high level, there are two primary performance bottlenecks on the web: 1. Networking - the round-trip time to acquire an asset or data payload from a remote server 2. End-user Device Compute - the amount of computational overhead required on the end-user's device”
  20. 20. Devices used “The country [Nigeria] is considered a mobile- first market where infrastructure and online usage development skipped wide-ranging desktop PC adoption and went straight to mobile internet usage via inexpensive smartphones instead.” https://www.statista.com/statistics/183849/internet-users-nigeria/
  21. 21. “Time spent in Parse/Compile can often be 2–5x as long on phones as on desktop.” — Addy Osmani https://medium.com/reloading/javascript-start-up-performance-69200f43b201
  22. 22. https://medium.com/reloading/javascript-start-up-performance-69200f43b201
  23. 23. Secret web performance metric: Patience
  24. 24. How long are you willing to wait for the website to load, before you decide it is broken? Patience metric:
  25. 25. If everything is slow, what can we do?
  26. 26. 1. Visibility of system status “The design should always keep users informed about what is going on, through appropriate feedback within a reasonable amount of time.” https://www.nngroup.com/articles/ten-usability-heuristics/
  27. 27. 1. Visibility of system status “The design should always keep users informed about what is going on, through appropriate feedback within a reasonable amount of time.” https://www.nngroup.com/articles/ten-usability-heuristics/
  28. 28. Make sure to give user information as fast as possible: • What is going on • How long it can take • Once error occurs (and what can be done)
  29. 29. Take into account digital literacy • Use simple language • Discourage damaging actions (“Do you really want to navigate out and stop the ongoing download?”) • Explain consequences of actions (for example “pull to refresh”)
  30. 30. 2. Render initial information ASAP Make sure there is some initial content visible letting user know what is going on quick.
  31. 31. 3. Avoid request chaining and roundtrips Consider using browser hints.
  32. 32. A. Preconnect Eliminate many costly roundtrips from your request path (for example establish connection with CDN used later) <link href="https://cdn.domain.com" rel="preconnect" crossorigin>
  33. 33. B. Prefetch Fetch resources and store them in cache. Use for resources that might be needed for next navigation.
 <link rel="prefetch" href="/images/big.jpeg">
  34. 34. C. Preload Load late-discovered resources early. <link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>
  35. 35. 4. Lazy load resources that are not critical Don’t force user to download resources they might never discover. <img src="image.png" loading="lazy" alt=“alt text” width="200" height="200">
  36. 36. 5. Learn about network resource hints Network Information API helps web applications to access information about the user's network. navigator.connection.saveData https://developer.mozilla.org/en-US/docs/Web/API/Network_Information_API
  37. 37. 6. Limit third party resources Third party resources can delay initial load of the page. Load them asynchronously using async/defer whenever possible. <script async src="external.js"></script> <script defer src="external.js"></script>
  38. 38. 7. Test for back/forward cache If a user clicks on a navigation item by mistake, it can minimise the time to navigate back.
  39. 39. https://developer.chrome.com/docs/devtools/application/back-forward-cache/ https://web.dev/bfcache/
  40. 40. 8. Avoid creating too many layers Each layer created by the browser takes device’s resources.
  41. 41. https://blog.logrocket.com/eliminate-content-repaints-with-the-new-layers-panel-in- chrome-e2c306d4d752/
  42. 42. 9. Minimise website repaints While interacting with the page, a lot of interactive resources can force browser to repaint content.
  43. 43. https://web.dev/simplify-paint-complexity-and-reduce-paint-areas/
  44. 44. Summary ★ Let user know what is going on ★ Load initial information early ★ Avoid request chaining and use resource hints ★ Lazy load content below the fold ★ Leverage Network Information API ★ Limit third party resources (and if you need them use async loading)
  45. 45. Summary ★ Optimise for back/forward cache ★ Avoid using too many layers and repainting content
  46. 46. Resources • MDN: Understanding latency • Interactive map of network speed worldwide • web.dev: Establishing early connections with resource hints • web.dev: Preloading critical assets • web.dev: Loading third party assets • The psychology of web performance • Designer's guide to perceived web performance • The African web ecosystem - a paper
  47. 47. Anna Migas @szynszyliszys Thank you!

×