5 tips for your PWA | Session

Key Takeaways

[Music] users have high expectations for the apps that are installed on their phone or computer and progressive web apps make it possible for you to deliver on those high expectations i'm pete lepage a developer advocate on the chrome team i want to show you a few tips and techniques that you can use to ensure that you can deliver on those high expectations and how you can use analytics to prove the investments that you made are paying off let's dive in when was the last time you saw an app crash because it was offline or had a crappy connection you probably haven't if you've installed an app you expect it to work at least a little bit no matter what the network connection is like and this is true for installed progressive web apps as well but let's be honest there's a lot to think about when considering what your offline experience should look like what should happen if the user tries to start your pwa without a network connection what if they lose the connection midway through once you've figured out what the behavior should be implementing a full offline experience can take time especially if you're trying to retrofit it into an existing code base one way to jump start your offline experience is to provide a custom offline fallback page that's shown when the user is offline or loses their network connection some sites like the lucas site in germany have even put a game on their offline page to keep users engaged and on their site when the network comes back they're good to go so how do you create a custom offline fallback page first let's take a look at the html for the offline page to keep things as simple as possible inline everything you need for the page css javascript any images anything all of that stuff should be inlined your offline page should also be fairly simple don't include links to other parts of your site unless they'll work offline and skip the links to your social media sites remember the user is offline so sending them anywhere else probably isn't going to work when the network comes back the page should reload automatically so the user can continue what they were doing to do this listen for the online event if it's fired reload the page but because the online event isn't always accurate periodically make a fetch request to check the network state if it returned to 200 reload the page now let's take a peek at the service worker use the install event as an opportunity to cache the offline page because it's self-contained and everything is inlined it's the only file that needs to be cached the fetch event handler is where most of the magic happens but it should only handle navigation events there's no need for it to send the offline page for images css javascript xhr requests or anything else in fact that's why we can use the fetch api in our offline page to check the network it's not a navigation event and it's not handled by this event handler if it is a navigation use respond with to try and get the page from the network but if it fails return the offline page from the cache let's see it in action when i navigate to the page for the first time i see the service workers installed and it has cached the offline page now if i go offline and reload i get the offline fallback page in devtools i can see it periodically making that fetch request to check the network status and when it does come back the page refreshes and i'm back in business there you have it a quick offline fallback page the full code with all the comments and everything you need to literally copy and paste it into your pwa is on web.dev it also includes an important optimization to enable navigation preload one other thing to consider is that the page doesn't have any analytics so you won't be able to measure how often your users are seeing it for that i recommend workbox they're recipes for comprehensive fallbacks and built-in plugins for offline analytics does your app have a few common tasks that users frequently want to jump into for example twitter has added shortcuts to make it easy to compose a new tweet explore what's going on see notifications or send a direct message adding shortcuts to your pwa only requires updating your web app manifest file by adding a new shortcut property for each shortcut you'll need to provide the name that should appear for the shortcut the url that should be opened when the user launches it and optionally an array of icons including the source sizes and type for each icon when you're ready to test things out take a peek in the manifest pane of the application panel in dev tools to verify that everything looks right shortcuts are one of the easiest things that you can do to provide a more integrated experience for your users you can use them on android and windows with more platforms coming in the future there's currently no built-in mechanism for localizing your web app manifest if your users speak different languages and you want to serve a localized experience you're kind of out of luck but not really if you want to localize your app name shortcuts or icons you'll need to create separate manifest files for each language for example to offer squoosh in english and french you'd create two separate manifest files that part's easy enough but how do we tell the browser about the localized manifest file for that i recommend using the accept language http header on the server to decide which manifest to send this way the browser will always ask for the same file name but will get different content depending on the user's preferred language to do this with firebase hosting create a localized files directory and drop the localized manifest files into the appropriate language folders then add an i18n property to the firebase.json file and that's it the server will serve the appropriate file to the user based on their preferred language english gets the manifest from en all and french gets the manifest from fr all the configuration will vary for different servers but the concept remains the same if you want to take this a step further provide a language picker within your app that sets a cookie with the user selection then serve the localized manifest with the cookie taking priority over the accept language http header one advantage of this implementation is that if users change their preferred language later the manifest remains at the same path and in many cases the pwa will be automatically updated based on the user's preferred language to learn more about how chrome handles changes to the manifest and what properties will trigger an update check out how chrome handles updates to the web app manifest one question i'm often asked is how you can measure the effectiveness of your install experience and what methods work best having this data is the first step to improving your install rate let's take a look at how we did it for squoosh and how you can do it for your pwa first let's measure how often users are shown our custom install experience you've seen the before install prompt event before it's fired when the pwa meets the installability criteria when this event is fired it means that we can show our own custom install experience the install source variable will help us to understand where the install came from and how effective each source is it'll also tell us if the install came from the browser or from our custom install experience this is especially important if there are multiple custom install experiences for example a button in the header some kind of promotion that's shown in line with other content and a button that's shown at the end of a critical user journey in the before install prompt event log the event to analytics for consistency all of my install events use the same category pwa install in this case the action is promo shown and i've set non-interaction to true since the event wasn't generated by a user interaction great so now we can measure how often the user shown the custom install experience let's measure how often the user clicks on it and whether they complete the install like i said earlier we want to know where the install came from so we'll set the install source to header button each install element should have its own unique id then as usual call deferprompt.prompt to start the install and show the browser install dialog to the user wait for the user to respond to that dialog then log the event to analytics like before the category is pwa install but now the action is promo clicked use the install source for the label to identify which custom install element the user clicked to start the install and set the event value to either one or zero depending on whether the user clicked accept or dismiss in analytics this will tell us what percentage of users completed the install for that specific element finally we need to listen for the app installed event this tells us when the pwa has been installed including installs from the browser if the user has multiple tabs or windows open the app install event is fired in all of them so to prevent duplicate install events from being logged only log the event if the page is visible next check the install source did it come from one of the elements in our ui or from the browser then log the event let's take a look at the analytics for squeeze to see how this looks under events then top events i'll click on pwa install and it'll show me all the actions for that category i can see the number of times the custom install experience was shown how often one of them was clicked and can dive down to see which element was clicked and how often in the case of squoosh we only have one install button but looking at that event value i can see that after clicking the install button 64 percent of users went on to complete the install and looking at the details for the installed action i can see what percentage of our installs came from our custom install experience versus which ones came from the browser now that you know how effective your install experience is you probably want to know how to differentiate users who have installed your pwa versus those who are using it in a browser tab to measure this in sql i created a user scoped custom dimension called display mode once squoosh is launched i use match media to check the css display mode then set the custom dimension to either browser or standalone this also works for safari users who have added your pwa to their home screen which means you don't need to use navigator.standalone anymore i also want to set the dimension to standalone in the app installed event otherwise after the install those users would still be counted as browser users let's take a peek at what this looks like in analytics i've created a custom report that looks at a few key behaviors for example the number of sessions per user average session duration events per session conversion rate which is how frequently someone downloads a compressed image and a few others next i've broken things down by the custom dimension i created earlier display mode looking at the report i can see users who've installed scrooge are more engaged than users who use it in a tab they come back to scrooge more frequently they spend more time in the app and they have higher conversion rates what counts as a conversion in your app will be a little different so you'll have to adjust the report to suit your needs but the concept is the same there you have it i've shown you how you can provide a custom offline fallback page avoiding the offline dyno and ensuring your pwa remains installable with the new pwa installability criteria that's expected to land in chrome 93. how you can make it easier for users to start common tasks with app shortcuts how you can provide a localized experience for users who've installed your pwa how to measure the effectiveness of your install flow and how you can use analytics to prove to your boss that investing in the web is always a win thanks for watching you can check out these links for more details and the actual code i used in the examples i'll see you soon [Music] you