Reliable Experiences - PWA Roadshow

Key Takeaways

your progressive web app needs to load instantly and reliably never showing the downer saw even under uncertain Network conditions let's take a look at how service workers allow you to do that hello I'm Mary Coe I want to start with a user scenario for a typical app let's say I'm sitting at a park and I'm humming to myself and suddenly thinks that's a great lift I could totally use that in the song so I open up my voice memo app to decode myself unfortunately my phone doesn't work in this park and my web-based app fails to load users have learned not to expect the same reliability from the web platform as they to others users expect it to work instantly regardless of where they are what they're doing or what the local connectivity is like and unfortunately this isn't just about no connection slow and intermittent connection affects users just as much because of the way web pages are typically constructed a slow connection can increase the time that a page takes to load on top of that mobile phones sometimes are not online even when your phone says you have four bars they might not have a live connection in order to become reliable we need instant loading and offline to be part of the web platform experience because remember as we said in previous video after three seconds 53% of users abundant sites users are not willing to wait globally over 60% of mobile connections use 2g we need to do something we need to be able to build a reliable sites and apps for users when connectivity doesn't exist or when it's low it's clear that we need to stop relying on the network the key to building instant loading an offline capable web app is a literally new technology called service workers in an earlier video we talked about how a service worker is a programmable proxy sitting between the network and the browser but it's more than that when the page register a service worker it as a set of event handler to respond to things like Network requests push messages and updates to the service worker because it's event based it doesn't have to be written in memory unless it's handling one of those events I'll say it again because I think it's important it's not consuming any system resources until it's been woken up to handle one of those events in fact even if the browser is closed the OS can wake up a service worker we are no longer limited to the model where web app must be loaded in an active tab to be useful this is important because it introduced an app like lifecycle for websites and web apps when a service worker is first registered it fires an install event which we can then use to prefetch the resources we need for our app and catch them locally this is like install as you go in effect we are learning a fully scriptable install much like native app no bulky zip files we have file level control over what is fetched how it's cached and how it's updated once the serviceworker has been activated we now have a full control over how the system serve your apps resources we can inspect network requests rewrite them get a response from the network or respond with something from the cache we can even synthesize our own response all of this is completely transparent to the user in fact well-constructed service worker can act as a very smart caching system and be transparent to the last of your app it is just a progressive enhancement of the network and cache choosing smarter ways to respond to the requests it gives us the appeal need to make our app reliable even when the network isn't because we have full control over the response service workers our progressive enhancement it's important to understand that the first time you load the page it's still going to load from the network the initial page has already been retrieved from the network and the page resources will be loaded normally the service worker will come into play only on the second request though there is one caveat to that I'll cover that in the moment let's dive in and take a look at lifecycle of a service worker when the page is first loaded it latest as a service worker for a specific scope for now sync of the scope as the set of page that service worker will handle an install event is then fired and the code in your install handler is executed then the service worker goes to idle essentially sitting there quietly when the page is Li loaded or you hit another page covered by the service worker the service worker is activated they need to handle all of its events at the same time the browser also makes an asynchronous request to the server to see if the service worker has changed since it was last retrieved once the service worker has handled all of the events it goes to idle and eventually it's terminated they need to spin up again when any new events come in let's keep going with our previous example and see how a service worker gets updated since we've already been to the page the service worker is already installed and immediately activated then just like before the browser checks with the server to see if the service worker has changed and this time it has the new service worker is downloaded and installed but goes to idle and the little service worker is activated and still handling requests in fact our little service worker will remain active until all the clients using it has been closed or until you skip waiting and clients claim will dive into those more in a second this is important to the member as you are working on your own service workers this isn't a problem for users but as a developer you may find yourself with multiple service workers installed and waiting because the original one hasn't been terminated yet enough Siri let's take a look at how to implement our own Service Worker the first step is littering a service worker in the web page in now HTML page we will place a small piece of glottic first we check if the service worker API is available in the browser then if it is we call navigator the service worker the register to register the service worker with the llevaron Stu the location of the service worker javascript file next we need to handle the install event which is fired after the service worker javascript file has been downloaded and parsed let's start with something basic remember earlier I mentioned that when a service worker is installed the first time it doesn't take immediate control of the page you have to wait for the page to be reloaded well there is a way around that calling self dot skip waiting tells the service worker you want it to skip waiting and go right to work we'll use the install event to prefetch the resources we need and catch them in the local cache ensuring that the files can be loaded instantly and literally in effect this install event handler is your opportunity to have a fully scriptable install process just like native app you have absolute control over what resources are pre fetched and how they are cached first let's open up a cache object reference by cache name then we'll use cache thought at all to retrieve the Lea sources we've listed and filed to cache and store them in a browser cache in a Leo implementation you to make sure that you take care of any exceptions here if one of the files were to fail while downloading the entire event fails and the Service Worker wouldn't be activated and finally once everything has been added we want to call self dot skip waiting so that our service worker takes control immediately there's one other thing I want to point out we wrap that whole code block in event dot wait until this makes sure that the service worker isn't terminated or go to idle while we were waiting for the embedded promise to complete once everything has been cashed and our service worker has been activated it's a good idea to clean up the cache for example remove any outdated resources from the cache there are plenty of ways to do this but in this case we it'll aid over the list of keys from the cache then delete any casts that don't match the current cache name and there is one more thing we need to do by calling self clients don't claim we tell the browser that we want this service worker to take control of all the clients that means we don't have to wait until other service workers are terminated we are ready to go immediately but at this point if you were to go find them you still get that dreaded offline dinosaur but why we haven't added a fetch event handler yet which allows us to the spawn to the network requests that are made by our page let's assume that all of the required resources for our app are already in the cache but if it's not we'll just go out to the network to fetch it when a network request is made from our web page our service worker wakes up and the fetch event gets triggered next we check to see if the requested resources is in the cache if it is we return the version from the cache otherwise we'll request it from the network and return that we now have a reliable experience that loads almost instantly our app will work whether we are online offline and it will load extremely quickly because we've eliminated any potential Network latency our last step is to let the page know that the service worker is now lizard and ready to go this is helpful if you want to indicate to the user that the pages offline capable earlier I mentioned the Scopes one of the cool thing about serviceworker is that you don't need to register it on every page you want to use it you only need to register it once and any page within the scope will be handled by the serviceworker the easiest way to define a scope it's simply based on where the serviceworker is served from I recommend that you serve your serviceworker from the server loot that means every resource requested will be handled by the serviceworker if you put it in your script directly only resource is served from there will be handled by the serviceworker in this case unless the page registering the serviceworker is also in script likely it won't be handled by the serviceworker putting the serviceworker in your server loot gives you the first chance at responding to any network requests and helps to ensure your app is reliable and loes almost instantly the magic a serviceworker provide is that you are in control you get to decide what gets cached how its cached and how it should be returned to the user I've shown you the cache first with Network fallback strategy it provides a fast reliable experience for users there are several different caching strategies and depending on your app scenario you might want to use different one or even multiple strategies for different kinds of requests let's take a look at some of the different strategies the cache first with Network fallback strategy we laid out it's pretty straightforward always go to the cache first and if the request matches the cache entry response with that otherwise try to fetch the resources from the network this option is good for resources that don't change often it will give you a very fast response since response came out of the cache directly but it doesn't update on the negative side if an item is not in the cache it is not added after its retrieved from the network network first and falling back to cache means you give online users most up-to-date content but all find users get an older cached version if the network request succeeds you're most likely you want to update the cache and however this Meza has flaws if the user has an intermittent or slow connection they'll have to wait for the networks to fail before they get the content that is already on their device this can take an extremely long time and it's frustrating user experience cache first then network requires the page to make two requests one to the cache and one to the network the idea is to show the cache to data first then update a page when or if network data are lives sometimes you can just replace the current data when new data lives things like game leaderboard but that can be destructive with larger piece of content don't make something that user may be leading or interacting with disappear with the generic fallback strategy le quest is made first to the cache then the network and if both of them fail a second request is made to the cache for a generic page this is ideal for secondary imagery such as avatars failed post quest and unavailable while flying page one of my favorite use for this is a newspaper that gives you a close word puzzle to play while you are frying and of course there are more cache only network only serviceworker templating just to name a few but the core point here is that when it comes to caching strategies you are in complete control over how to respond to the quests you can manage the network and the cache so that you can build a consistently reliable and performant solution because you have so much control over the network it can seem quite daunting to get started and to debug experience luckily there are a number of tools that can help you the chrome dev tools have added new set of tools to help you work with service workers in the tools you will find application tab in application tab you can inspect the service worker and latest or it force it to update simulate offline behavior and more we'll talk more about these in the tooling video and of course Firefox Opera and other browsers have similar tools for debugging service workers dev tools let you inspect not only application storage like indexdb but also inspect cache storage in the past we used to recommend people use incognito windows when developing service workers because it made it easy to start fresh when you need to but the nuclear storage pane simplifies things tremendously I use this one a lot next we have a tool that can speed up your serviceworker development walk box is a collection of libraries to help you develop PWA if you remember the code for a cache first service worker from earlier it was a bit cumbersome to write with work box SW this turns into simple decorations for caching strategies on multiple resources but you are still in control of your site it's just a set of package loadings and strategies so I hope this has given you a good understanding of service workers and how they provide the core of instant and reliable experience for progressive web apps thank you [Music] [Music]