Why Build Progressive Web Apps: Never Lose a Click-Out!

Why Build Progressive Web Apps: Never Lose a Click-Out!


THOMAS STEINER: Hi. On the Google Chrome
Developers channel we’ve been pushing the
concept of progressive web apps a fair bit. And there have been some
great success stories of companies building PWAs. But you might wonder
what may have worked for any of the
mentioned partners might not necessarily
work for your company. My name is Tom. I am a developer advocate
for the web team at Google. In this new video series called
Why Build Progressive Web Apps?” I want to show you common
use case driven patterns for applying PWA features
that set you up for success. Let’s dive right in. [MUSIC PLAYING] You’ve maybe seen or even used
a comparison site in the past. For example, to find out what is
the cheapest internet provider, or to get the best hotel
offer for your next vacation. Many of these comparison
sites rely on commission based affiliate marketing. When I click out to
a third party vendor and end up converting, the
referring comparison site earns a small fee. In consequence, such sites
want you to click through to the best offer. And under no
circumstances do they want to risk losing a click out. Many sessions with comparison
sites happen on the go, say, when you commute to
work in a bus or train. And while in the majority of
cases you might be connected, there are definitely
situations where you lose that connection,
either in a tunnel, or during situations where
your signal strength drops to just one or two bars, and you
end up being de facto offline. This is the worst. Having a resilient progressive
web app architecture can help in such situations. Let’s think of
possible solutions. In an ideal world you’d
be always connected. Well, in my ideal
world at least. If you imagine a situation
where you spend some minutes during your commute
comparing something online, an internet provider,
hotel prices, whatever, you need to be online by
definition, at least most of the time. So even if it would
be possible, let’s not consider a complete offline
scenario here, but rather short interruptions
of connectivity or the dreaded one bar of 3G. Having an architecture that
gives the network some time to respond, but that gracefully
degrades to cached content or fallback placeholder content
can help improve the user’s experience drastically. So what would this
look like in practice? After I did my own
simple comparison site called AffiliCats with
purely dynamic content, but coming from real API calls. It has a big search bar
on top where you can search for items, like cats. Each item has an
image and a title, as well as offers and a
View Deal button that leads to the third party vendor site. Then we have three tabs
with more photos, reviews, and the location of the item. Each tab’s content is
lazily loaded on demand, with one or multiple
fetch requests. So in each case, the
request can either succeed, time out if
the network is too slow, or fail from the start if
we are entirely offline. In the latter two cases,
we want to respond with fallback content. For example, a nice
looking “Reviews took too long to load” message. When the network comes back,
or the slow request eventually goes through, we
can then dynamically replace the fallback
content with real content. The user can also decide
to press reload and refresh the complete page. This is called
navigation request. If we are offline we can
then show a fallback page. Finally, let’s see
how we can make sure not to lose the click out. What happens if the user
clicks on the View Deal button when they are offline? Notice how most of
the page is disabled. But the money making
button is still active. A precached
forwarding page opens that waits for the connection
to come back to then eventually still realize the click out. If you want to play
with this app yourself, or read the source code, please
find a link to the AffiliCats app in the description
of this video. I hope this has been useful. And you can apply some of these
patterns to your own websites. Thanks for watching. And see you for the next episode
of “Why Build Progressive Web Apps?” where we will look at
push notifications. [MUSIC PLAYING]

12 Comments

  1. Smart idea with the cached forwarding page, good for the WiFi switching or WiFi on/off situation, but I guess most people put the device in standby and coming back later with better connection. When they come back, are they still at the loading/caching point like before or does the entire page load again (personal settings excepted)?

  2. I took the first step and was able to get a basic PWA working. Now I would like to know ow to cache data that I would get from a WebAPI. Data that I could list, modify offline and later send back to the same WebAPI. Also, would need to know when I can connect to that WebAPI.

  3. The example use case made clickouts very relatable, thanks.
    Direct urls https://github.com/googlechromelabs/affilicats/ , and live https://googlechromelabs.github.io/affilicats/

Leave a Reply

Your email address will not be published.


*