Why Build Progressive Web Apps: Never Lose a Click-Out!—Video Write-Up

(This is the write-up of the first episode of my new YouTube show “Why Build Progressive Web Apps.” If you prefer watching, the video is embedded below.)

(Also check out the the write-up of the second episode and the write-up of the third episode, or watch the second episode video and the third episode video.)

On the Google Chrome Developers YouTube channel, we have been pushing the concept of Progressive Web Apps (PWA) a fair bit, and there have been some great success stories of companies building PWAs. But you might wonder, what may have worked for the mentioned partners, might not necessarily work for your company. In my 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. In the first episode, I look at affiliate sites and how they can manage to never lose a click-out.

You have 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 you click out to a third-party vendor site 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, on the commute to work. And while in the majority of cases you might be connected, there are definitely situations where you lose your connection, like in a tunnel or when your signal strength drops to just one or two bars, and you end up being de facto offline. 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.

In order to demonstrate how to deal with such situations, I have created my own sample comparison site called 🐈 AffiliCats with purely dummy content, but coming from real APIs like the Wikimedia API, the Google Static Maps API, the Random Number API, the Bacon Ipsum API, and the Place Kittens API.

The app 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’s 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 request. So in each case, the request can either succeed, time out if the network is too slow, or fail from the start if we’re entirely offline.

In the latter two cases, we want to respond with fallback content, for example, a “reviews took too long to load” message, or a timeout image. When the network comes back, or the slow request eventually goes through, we can then dynamically replace the fallback or placeholder content with real content. The user can also decide to press “reload” and refresh the complete page. This is called “navigation request”. If we’re offline, we can then show a fallback page with skeleton content.

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, and once online again, it then eventually still realizes the click-out, and drops our imaginary affiliate cookie… 💸

You are invited to play with this app yourself and read the source code. I hope this has been useful, and maybe you can apply some of these patterns to your own websites. Thanks for reading, and see or read you for the next episode of “Why build Progressive Web Apps,” where we will look at push notifications.

In order not to miss it, subscribe to our Medium Dev Channel, the Chrome Developers YouTube channel, follow @ChromiumDev on Twitter—and if you like, I am @tomayac almost universally on the World Wide Internet.