 Hi. On the Google Chrome Developers channel, we've been pushing the concept of progressive web apps a fair bit, and they've 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'm 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 PWAs features that set you up for success. Let's dive right in. 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 you 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 progress of web 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? I've created my own simple comparison site, called AffiliCats, with purely dummy content, but coming from real API calls. It has a big search bar on top that 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 you're 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're offline, we can then show a fallback page. Finally, let's see how we can make sure not to lose the clickout. What happens if the user clicks on the view deal button when they're offline? Notice how most of the page is disabled, but the money-making button is still active. A pre-cached forwarding page opens that waits for the connection to come back, to then eventually still realize the clickout. 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 imply 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.