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

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

4. 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

22. https://medium.com/reloading/javascript-start-up-performance-69200f43b201

23. Secret web
performance metric:
Patience

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.

45. https://blog.logrocket.com/eliminate-content-repaints-with-the-new-layers-panel-in-
chrome-e2c306d4d752/

46. 9. Minimise website
repaints
While interacting with the page, a lot of
interactive resources can force browser to
repaint content.

47. https://web.dev/simplify-paint-complexity-and-reduce-paint-areas/

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

51. Anna Migas
@szynszyliszys
Thank you!