April 2, 2020
Summit Report: Building one of Africa’s most successful PWAs (Progressive Web App Summit 2016)

Summit Report: Building one of Africa’s most successful PWAs (Progressive Web App Summit 2016)

[MUSIC PLAYING] ROB DODSON: Hey, folks. Welcome back to the
Progressive Web App summit. I’m Rob Dodson. We’re here in beautiful,
actually sunny Amsterdam today. I’m joined with Andrew MorI. He is the director
of engineering at Konga– Konga is a
Nigerian e-commerce company– and just gave a talk
here at the Summit. And Andrew, I was
kind of curious. So one of the things that you
really focused on in your talk is cost of data in
emerging markets. And I was wondering
if you could just talk through that a
little bit, because I know there’s a lot of folks who
might be in Western markets. They don’t even think
about what it costs to use data on their phone. But how is that
different if you’re in a place like Nigeria or
India or some other market? Could you talk about that? ANDREW MORI: Yeah. Sure. Hello. So originally as a startup,
we started a responsive web– a responsive web app that
sort of worked– it works well on 3G and Wi-Fi connections. But as we started paying
attention to our users, we had a good look at
our metrics in our CDN, and we noticed a
very interesting stat which said that the average
transfer rate of data coming out of our CDN is exiting at
about 250 kilobits per second, which is pretty slow
if you think about it. And then we had a
think about that. And we looked at our current
approach to our mobile web and we noticed how
big our pages were. And the fact of the matter
is that our home page was 2.5 megabytes at a
specific point in time. And if you think
about how long it’ll take at a rate of
250 KB per second, you’d end up waiting 40, 50
seconds to load the home page. And most users in the Western
world would long drop off. But in Africa, we have a
slightly different scenario. The fact is there
isn’t that much choice. You can’t just go to a
brick and mortar shop, so people are pretty persistent. And respect to our users who
have pushed through that, but we owe them some
sort of improvement. And I think one of the
big points that came out of our usability
tests was we’d seen a user searching for a product. And as he’d seen that
search result, as he started scrolling, he said,
hey, I can’t actually do this. This is going to cost
me too much data. And so we realized
and we paid attention to the market and the fact that
it cost quite a bit of money to buy 10, 20 megabyte bundles. And we realized we actually
owe it to our customers to pay attention
to that, and that’s why we chose the Progressive
Web App sort of system– the fact that we can cache all
of this data with a service worker cache and sort of
intercept that network request. And the fact of the matter is
that in Nigeria, specifically in rural Nigeria, there’s
relatively intermittent network statuses. And so in terms of
data and bad networks, we had a really good match
with the Progressive Web App. ROB DODSON: And can you
tell me a little bit about sort of the
data-saving cost that you were able to
achieve, and really like the pieces of technology
that unlock that for you? ANDREW MORI: So we’ve done
a before and after picture. And we basically
recorded how much data it took to complete it. Well, the first thing was
to complete the first load. And we’ve managed to achieve
a 92% improvement, so decrease in the amount of
data it requires to load that home page. And originally the
first technology was simple design optimization. So basic things like instead of
serving massive images or icons like PNG icons or whatever,
we’ve gone with SVGs and we’ve paid some serious
attention to our design on top of the fact
that we simplified it, made it really simple. That would be the first thing. The second way we
optimized for data was– I mean, that first load is
not really the big part of it. It’s more the second load
and subsequent requests. So on that first load,
we’re using our app shell architecture to store all of
that HTML, CSS, and JavaScript, and then it sits there
in the service worker, in the app shell. And the next request
to it, it’s not fetching it from the network,
so there is no data cost. And the second metric
that sort of screams is the amount of data it
requires to perform a checkout. So imagine you’re
going to buy a product. We’ve achieved an 80%
reduction in data cost for that first transaction. And the technology
stack is quite simple. It’s based on service worker
cache and the usage of IDB and sort of all of the
underlying technologies of Progressive Web App. And there are some other
interesting things there, but that is the majority
of it comes from that. ROB DODSON: Very cool. And you mentioned kind of a
web technology stack there. And as we were talking,
an interesting point that you raised was that
the engineering team that you worked on with this is
not exclusively web developers. It kind of cuts across all
sorts of different kind of engineering types. So can you talk about
that a little bit, because I think a lot of
people, when they think about Progressive Web Apps, they
see it as sort of a mutually exclusive thing, where
they’re like, well, I’m going to have to just
drop my native app developers and go with this or something. It’s hard for them to choose. So can you explain a little
bit about that process you all went through there? ANDREW MORI: Sure. So I think it was more about
timing than anything else. It wasn’t an active
decision to say, hey, let’s have the native
engineers build this. It’s more about the fact
that this wasn’t originally part of our road map. We have a very serious
engineering undertaking at the moment, and that’s
all about breaking down our monolithic application
into smaller, independently deployable and
scalable microservices. And that’s where our
efforts are at the moment. So our web devs were kind of
focused on other projects, rebuilding some client-side
front-end components, and the resources
had been booked up. And the only available
resources at the time were the native engineers,
who– we were struggling with our native
apps in any case, so that was the only team
available at the time. And I charged them,
challenged them with switching from
native to web dev, which is a pretty
different field. But they seemed to thrive. Not only did it
provide some variety, people learnt new skills and
the new components of the web, and I think they
did very, very well. And the feedback I got from
them was nothing but positive. Everybody seemed to kind of
grasp Polymer really easily, and that sort of switched to
web development quite easily. You know, all I can
say is, pay attention to some of the documentation
that’s available already on Polymer and
Progressive Web Apps. Go into the examples. Inspect the code. And that was pretty much what
our team did to build this. ROB DODSON: Cool. So Andrew, thank you so much
for being with me today. If you want to
catch Andrew’s talk, you can tune into the Chrome
Developer’s YouTube channel. We’ve got a playlist there
for all the sessions of Day 2 from the Progressive
Web App summit. Also, we’re going to
include some links down in the description
for the Konga showcase on developers.google.com.web. It covers a little
bit more of the story of how they built
the site, and also a few more of the
sort of like stats on where they picked up in data
savings and things like that. Again, Andrew, thank you so
much for being with me today. It’s been great
talking with you. Thank you all for being with us. And stay tuned for more from
Day 2 of the Progressive Web App Summit. See you. [MUSIC PLAYING]

Leave a Reply

Your email address will not be published. Required fields are marked *