Advertisement
Advertisement

More Related Content

Advertisement

Secret Web Performance Metric - DevDayBe

  1. Lead UI Developer at Field Intelligence Anna Migas Google Developer Expert
  2. Anna Migas @szynszyliszys
  3. Anna Migas @szynszyliszys The secret web performance metric no one is talking about
  4. “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. web performance
  6. User experience connected to the web performance
  7. User experience connected to the web performance from a perspec ti ve of an average user in Africa
  8. Why should you care? Africa is far.
  9. 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 op ti mise
  10. Most web performance metrics and resources are developed with a privileged user in mind.
  11. h tt ps://web.dev/tbt/
  12. h tt ps://wpostats.com/2020/11/05/revelry-bounce-rate-conversion.html
  13. For some users, the good web performance is not achievable at all.
  14. “At a high level, there are two primary performance bo tt lenecks on the web: 1. Networking - the round-trip ti me to acquire an asset or data payload from a remote server 2. End-user Device Compute - the amount of computa ti onal overhead required on the end-user's device” h tt ps://www.webperf. ti ps/ ti p/cached-js-misconcep ti ons/
  15. “At a high level, there are two primary performance bo tt lenecks on the web: 1. Networking - the round-trip ti me to acquire an asset or data payload from a remote server 2. End-user Device Compute - the amount of computa ti onal overhead required on the end-user's device” h tt ps://www.webperf. ti ps/ ti p/cached-js-misconcep ti ons/
  16. “At a high level, there are two primary performance bo tt lenecks on the web: 1. Networking - the round-trip ti me to acquire an asset or data payload from a remote server 2. End-user Device Compute - the amount of computa ti onal overhead required on the end-user's device” h tt ps://www.webperf. ti ps/ ti p/cached-js-misconcep ti ons/
  17. “At a high level, there are two primary performance bo tt lenecks on the web: 1. Networking - the round-trip ti me to acquire an asset or data payload from a remote server 2. End-user Device Compute - the amount of computa ti onal overhead required on the end-user's device” h tt ps://www.webperf. ti ps/ ti p/cached-js-misconcep ti ons/
  18. Latency Latency is generally considered to be the amount of ti me it takes from when a request is made by the user to the ti me it takes for the response to get back to that user. h tt ps://developer.mozilla.org/en-US/docs/Web/Performance/
  19. Latency in most parts of Africa is really high. High latency means long Time To First Byte (TTFB).
  20. Latency in most parts of Africa is really high. High latency means long Time To First Byte (TTFB).
  21. “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 h tt ps://csswizardry.com/2019/08/ ti me-to- fi rst-byte-what-it-is-and-why-it-ma tt ers/
  22. “At a high level, there are two primary performance bo tt lenecks on the web: 1. Networking - the round-trip ti me to acquire an asset or data payload from a remote server 2. End-user Device Compute - the amount of computa ti onal overhead required on the end-user's device”
  23. Devices used “The country [Nigeria] is considered a mobile- fi rst market where infrastructure and online usage development skipped wide-ranging desktop PC adop ti on and went straight to mobile internet usage via inexpensive smartphones instead.” h tt ps://www.sta ti sta.com/sta ti s ti cs/183849/internet-users-nigeria/
  24. “Time spent in Parse/Compile can often be 2–5x as long on phones as on desktop.” — Addy Osmani h tt ps://medium.com/reloading/javascript-start-up-performance-69200f43b201
  25. h tt ps://medium.com/reloading/javascript-start-up-performance-69200f43b201
  26. Secret web performance metric: Pa ti ence
  27. How long are you willing to wait for the website to load, before you decide it is broken? Pa ti ence metric:
  28. If everything is slow, what can we do?
  29. 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 ti me.” h tt ps://www.nngroup.com/ar ti cles/ten-usability-heuris ti cs/
  30. 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 ti me.” h tt ps://www.nngroup.com/ar ti cles/ten-usability-heuris ti cs/
  31. Make sure to give user informa ti on as fast as possible: • What is going on • How long it can take • Once error occurs (and what can be done)
  32. Take into account digital literacy • Use simple language • Discourage damaging ac ti ons (“Do you really want to navigate out and stop the ongoing download?”) • Explain consequences of ac ti ons (for example “pull to refresh”)
  33. 2. Render ini ti al informa ti on ASAP Make sure there is some ini ti al content visible le tti ng user know what is going on quick.
  34. 3. Leverage Progressive Enhancement Make it possible to achieve the most crucial ac ti on fi rst, add extra features and fi reworks on top of that.
  35. 4. Avoid request chaining and roundtrips Consider using browser hints.
  36. A. Preconnect Eliminate many costly roundtrips from your request path (for example establish connec ti on 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 naviga ti on. <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. 5. Lazy load resources that are not cri ti cal 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. 6. Op ti mise images you ship Images are usually the heaviest resources on the web.
  41. Op ti mise image loading • Use correct and modern formats • Use tools to op ti mise size: • h tt ps://jakearchibald.github.io/svgomg/ • h tt ps://squoosh.app/ • h tt ps://imageop ti m.com
  42. Op ti mise image loading • Add size / aspect ra ti o to avoid layout shifts .img-class { aspect-ratio: 16 / 9; } .img-class { width: 100px; height: 20px; }
  43. 7. Learn about network resource hints Network Informa ti on API helps web applica ti ons to access informa ti on about the user's network. navigator.connection.saveData h tt ps://developer.mozilla.org/en-US/docs/Web/API/Network_Informa ti on_API
  44. 8. Limit third party resources Third party resources can delay ini ti al load of the page. <script async src="external.js"></script> <script defer src="external.js"></script>
  45. 8. Limit third party resources h tt ps://partytown.builder.io/
  46. 9. Test for back/forward cache If a user clicks on a naviga ti on item by mistake, it can minimise the ti me to navigate back.
  47. h tt ps://developer.chrome.com/docs/devtools/applica ti on/back-forward-cache/ h tt ps://web.dev/bfcache/
  48. 10. Consider using Service Worker If you expect your page to be visited on regular basis, you can cache resources be tt er. h tt ps://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API
  49. 11. Avoid crea ti ng too many layers Each layer created by the browser takes device’s resources.
  50. h tt ps://blog.logrocket.com/eliminate-content-repaints-with-the-new-layers-panel-in- chrome-e2c306d4d752/
  51. 12. Minimise website repaints While interac ti ng with the page, a lot of interac ti ve resources can force browser to repaint content.
  52. h tt ps://web.dev/simplify-paint-complexity-and-reduce-paint-areas/
  53. Summary ★ Let user know what is going on ★ Load ini ti al informa ti on early ★ Progressively enhance your website ★ Avoid request chaining and use resource hints ★ Lazy load content below the fold ★ Op ti mise images ★ Leverage Network Informa ti on API
  54. Summary ★ Limit third party resources (and if you need them use async loading) ★ Op ti mise for back/forward cache ★ Consider using Service Worker if applicable ★ Avoid using too many layers and repain ti ng content
  55. Resources • MDN: Understanding latency h tt ps://developer.mozilla.org/en-US/docs/Web/Performance/ Understanding_latency • Interac ti ve map of network speed worldwide h tt ps://www.cable.co.uk/broadband/speed/worldwide-speed- league/ • The African web ecosystem - a paper h tt ps://www.caida.org/catalog/papers/ 2018_exploring_analysing_african_web/ exploring_analysing_african_web.pdf
  56. Resources • web.dev: Establishing early connec ti ons with resource hints h tt ps://web.dev/preconnect-and-dns-prefetch/ • web.dev: Preloading cri ti cal assets h tt ps://web.dev/preload-cri ti cal-assets/ • web.dev: Loading third party assets h tt ps://web.dev/e ffi ciently-load-third-party-javascript/
  57. Resources • The psychology of web performance h tt ps://blog.uptrends.com/web-performance/the-psychology-of- web-performance/ • Designer's guide to perceived web performance h tt ps://marvelapp.com/blog/a-designers-guide-to-perceived- performance/
  58. Thank you!
  59. Vote for your fav session
Advertisement