Small web performance tweaks and optimisations might not make a difference for some of the users: there can be physical barriers that will make it impossible to achieve the fast page load and the smooth browsing. 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. But when the conditions are not ideal on daily basis, what are our choices? In my talk we will chat about the improvements that will have real impact on the user experience for users browsing the web in the harsh conditions. 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.

1. Lead UI Developer
at Field Intelligence
Anna Migas
Google Developer Expert

2. Anna Migas
@szynszyliszys
Web performance
op
ti
misa
ti
ons for the
harsh condi
ti
ons

3. web performance

4. User experience connected to the
web performance

5. User experience connected to the
web performance
as experienced in harsh daily
condi
ti
ons

6. “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

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/
tti
/

12. h
tt
ps://wpostats.com/2018/06/13/zalando-revenue.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. “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

24. h
tt
ps://medium.com/reloading/javascript-start-up-performance-69200f43b201

25. 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/

26. If everything is slow,
what can we do?

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)

32. Take into account digital literacy
• Use simple language
• Discourage damaging ac
ti
ons
• Explain consequences of ac
ti
ons

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.

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

38. 4. Avoid request
chaining and roundtrips
Consider using resource hints.

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">

41. C. Preload
Load late-discovered resources early.
<link rel="preload" href="font.woff2" as="font"
type="font/woff2" crossorigin>

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

45. h
tt
ps://developer.chrome.com/docs/devtools/applica
ti
on/back-forward-cache/
h
tt
ps://web.dev/bfcache/

46. 9. Avoid crea
ti
ng too
many layers
Each layer created by the browser takes
device’s resources.

47. h
tt
ps://blog.logrocket.com/eliminate-content-repaints-with-the-new-layers-panel-in-
chrome-e2c306d4d752/

48. 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
★ Leverage Network Informa
ti
on API

49. Summary
★ Op
ti
mise for back/forward cache
★ Consider using Service Worker if applicable
★ Avoid using too many layers and repain
ti
ng
content

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

51. 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/

52. 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/

53. Anna Migas
@szynszyliszys
Thank you!