Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to The secret web performance metric no one is talking about
Similar to The secret web performance metric no one is talking about (20)
More from Anna Migas
More from Anna Migas (11)
Recently uploaded
Recently uploaded (20)
The secret web performance metric no one is talking about
- 1. Lead UI Developer at Field Intelligence Anna Migas Google Developer Expert
- 2. Anna Migas @szynszyliszys The secret web performance metric no one is talking about
- 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
- 5. User experience connected to the web performance
- 6. User experience connected to the web performance from a perspective of an average user in Africa
- 7. Why should you care? Africa is far.
- 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. Most web performance metrics and resources are developed with a privileged user in mind.
- 10. For some users, the good web performance is not achievable at all.
- 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. “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. “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. “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. 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. Latency in most parts of Africa is really high. High latency means long Time To First Byte (TTFB).
- 17. Latency in most parts of Africa is really high. High latency means long Time To First Byte (TTFB).
- 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. “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. 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. “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
- 24. How long are you willing to wait for the website to load, before you decide it is broken? Patience metric:
- 25. If everything is slow, what can we do?
- 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. 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. 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)
- 31. 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”)
- 32. 2. Render initial information ASAP Make sure there is some initial content visible letting user know what is going on quick.
- 35. 3. Avoid request chaining and roundtrips Consider using browser hints.
- 36. 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>
- 37. 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">
- 38. C. Preload Load late-discovered resources early. <link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>
- 39. 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">
- 40. 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
- 41. 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>
- 42. 7. Test for back/forward cache If a user clicks on a navigation item by mistake, it can minimise the time to navigate back.
- 43. https://developer.chrome.com/docs/devtools/application/back-forward-cache/ https://web.dev/bfcache/
- 44. 8. Avoid creating too many layers Each layer created by the browser takes device’s resources.
- 46. 9. Minimise website repaints While interacting with the page, a lot of interactive resources can force browser to repaint content.
- 48. 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)
- 49. Summary ★ Optimise for back/forward cache ★ Avoid using too many layers and repainting content
- 50. 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