During this talk, she will give an insight on her 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. We will 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. She 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, it is possible that the audience will stumble upon these issues sooner than later.
11. For some users, the
good web performance
is not achievable at all.
12. “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/
13. “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/
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. 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/
17. Latency in most parts of
Africa is really high.
High latency means long
Time To First Byte
(TTFB).
18. Latency in most parts of
Africa is really high.
High latency means long
Time To First Byte
(TTFB).
19. “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/
20. “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”
21. 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/
22. “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
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
ti
me.”
h
tt
ps://www.nngroup.com/ar
ti
cles/ten-usability-heuris
ti
cs/
28. 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/
29. 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)
30.
31.
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.
39. 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>
40. 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">
42. 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">
43. 6. Op
ti
mise images you
ship
Images are usually the heaviest resources on
the web.
44. 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
45. 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
;
}
46. 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
47. 8. Limit third party
resources
Third party resources can delay ini
ti
al load of
the page. Load them asynchronously
whenever possible.
<script async src="external.js"></script>
<script defer src="external.js"></script>
48. 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.
50. 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
51. 11. Avoid crea
ti
ng too
many layers
Each layer created by the browser takes
device’s resources.
55. 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
56. 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
57. 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
58. 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/
59. 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/
