 Hello, everyone, and welcome back to the state of the web. My guest is Tom Steiner. He's a developer advocate at Google. And today we're talking about the state of progressive web apps, also known as PWAs. Let's get started. [?]. Tom, thank you for being on the show. Thanks for having me. So let's start by defining some of the key terms here. When we talk about a progressive web app, what does the progressive part mean? Like, what is the baseline from which we're progressing? So I think there's essentially two ways of defining it. So one is more the technical angle, where you come from different APIs that are available or not on a browser. So you can think of the progressiveness, like in the sense of progressive enhancement, where your test does a certain browser support a certain API that you want to use, like does it have to service worker APIs. And the second take of it would be more like progressively developing from just being a website to being an actual application. So you start with maybe navigating to a site. You start using it. And then the more you use it, the more it does feel like an application, something that you actually wanted to use more frequently, something that you would actually might want to install on your home screen. So I think this is more of the slowly developing into being an app progressiveness. OK. So in the second part of that, the web app part, is there a distinction between that and a website? So I think it's more, as I said, about developing from just being a website into being an actual application. And this is also what's confusing a lot of people. Like PWA, the A part, is it an app in the sense of I go to an app store, I go to the play store to install it? Or is it an app in the sense of, yeah, just as we defined before, something that slowly becomes an app by just being more useful, being more app-like in its behavior. And yeah, so I think this is the core distinction here. Gotcha. So are PWAs more discouraging some of the old ways of making websites? Or is it encouraging some of the latest and greatest APIs? It's more like, yeah, progressively being more useful and doing things that until before only native applications could do. So let's take the example of being able to work offline or under heavy network situations where you don't really predictably know is the network going to be there at all, like in a subway, where you sometimes have a network, sometimes you don't. Sometimes the phone says you do have network, but actually you don't because whatever, networks hate you as Alex Russell puts it. So yeah, I think it's more about how you work under these circumstances. And if you can then still reliably deliver an app-like experience. So I think it's more about encouraging new ways of thinking like a paradigm shift already that you start with having a website, but then how can you turn that into an app-like experience? How are developers progressifying their websites? What kinds of tools are they using? So first I would say from a functional angle, you have something as simple as maybe adding push notifications to maybe improve your app re-engagement rates. You have people who add service worker support so that your app can work offline. It might just be as simple as storing some central components of the application in the cache. It might also be a complete offline strategy. When it comes to actual tools, I think it's the full range of people having vanilla JavaScript service workers to people who use third-party SDKs. Like they could have push notifications delivered from a vendor. So they just install the SDK and be good. And then of course you have copy and paste style recipe service worker sites like this pwabuilder.com. They can just say, this is my site. You enter a URL. It spits out after several checkboxes that you can check or uncheck. It spits out a ready-made service worker that you can then just put on your code or on your site. And then eventually we have libraries like Workbooks.js that help abstract away a lot of the technical complexities of service worker programming and make almost a jQuery of service worker a lot of tasks a lot easier. So you've also been doing some work recently to build a new report on HTTP archive for PWAs. What kinds of stats are you seeing there in relation to the adoption of progressive web apps? I think as soon as you want to do something at scale, so you want to look at not just one website that you can of course examine to the deepest details, it's more like how do you on a technical angle approach this? So in my study I had essentially three approaches. The first one was I looked at a table in the HTTP archive that looks at lighthouse data. So lighthouse is a tool where you can run some audits for your website and then just get a score on different rates. Like for example, progressive web app obviously, then also performance, SEO, accessibility and so on. So I looked at progressive web app report part of this and then just looked at how the scoring in lighthouse works. So there's essentially a PLBA checklist where there's a set of machine testable things that lighthouse as a tool can test. And then I looked at how many of these applications sites in the HTTP archive hit a certain minimum threshold or what score did they get? And then looked at the median scores to then finally say something about like how many of these websites could actually hit the bar of being a progressive web app. The second approach that I took was I looked at something that in Chrome the browser is called use counters. So use counters are special features that trigger when something in the browser fires. And there's one use counter that is called service worker control page. So essentially whenever the page load of a page was controlled by a service worker, this use counter would fire and we can see this in a table as well. So I essentially just looked at the archive again and checked when and under what circumstances did this thing fire. And you can then chart of course the different findings that you see. The third approach was more like looking into the response bodies. And this is like the hardest one actually because there's just so much data. So you have all the response bodies in the tables and you sort of parse with regular expressions which you should probably never do in production. On HTML especially. Exactly, you parse HTML and try to figure out that this website try to register a service worker then you can get the file name by parsing like between parenthesis and the quotes and so on. The URL path then you try to see if you find this URL in the tables and it can use another query to then get the actual code contents of the service worker scripts to then see what kind of events does the service worker listen to. So right now published we have the first two. So the use counters and the Lighthouse one. But yeah, maybe if this continues we can also try to see if there's a way to publish the third one as well. The charts have shown that the PWA score from Lighthouse, the median is about 62%. And if I recall correctly, the service worker controlled page use caters less than 1% but the chart is actually showing a steep incline or a growth of service worker usage. Could you explain the 62% like what does that number mean in relation to Lighthouse and PWAs on the web? So it's a little bit what even makes a PWA. If you ask this from people, you get different definitions. With our baseline PWA checklist, we try to just make a checklist of things that you must match to actually be called a PWA. And for each of these, I think it's 14 points out of which 11 are machine testable. You get a score. And you then look at all these different scores until you hit a certain threshold where you can say this is a PWA that you can install to the home screen. Some of the things that are machine testable is something as simple as does the site serve over HTTPS, which is one of the core requirements of even being able to use the service worker APIs. And then you also have more advanced things like do all the URLs load in an offline experience. And this is hard because what is even all the URLs that you can come up with in an application? Lighthouse tries its best to figure out like the core start URL, for example, in the manifest. Does it have a manifest in the first place? It's another test. And yeah, so you have these different checklist checks, obviously, and then we try to figure out which ones are checked to then see can we make any statements about this is a PWA or not? When you look at the use count as you can see the curve is really going up, which is a good signal. When you look at absolute numbers, it's really, really low still. So PWA are in its infancy. Something to be noted is obviously, this is when you look at HTTP archive, this is the Alexa one million by now. So there's a big corpus, but it's definitely not the entire web but still representative enough corpus. And in this corpus, we do see that there's like a hockey stick would be exaggerated, but there's definitely strong growth when it comes to PWA and service workers. It is early days, but are you able to see any type of correlation with performance? Like are PWAs actually improving the performance of these sites? I think there's two angles to this question. So performance is something that you can relatively easily measure by just saying you define a metric like first content for paint, for example, that's something you can measure with the machine. Something that is out of our control is some of the core business metrics that a vendor would care for, a company would care for. So when we try to make people build progressive web apps, one thing we can of course say is look, if you do this and that, this will improve your first content for paint, whatever. What the vendors always ask is, well, but does it have any impact on our conversion rate? Do we sell more? Do we, whatever, do we get more subscriptions by implementing this and that? So, and this is where it's a little bit more opaque. So in a sense, this is a bit of the holy grail of the entire, do we go PWA or not? We do have some case studies to be published. The problem a bit with these case studies sometimes is, in many cases, they modified more than one variable. So they did not just purely add service workers or PWA features in general, but they might also have modified the site design or maybe the products change. So there's just different things that play a role in this equation so that sometimes we can't really reliably say, this is completely attributable to PWA. Sometimes it might just have been to a big part as well, a redesign, for example. And it's not just as easy as implementing a PWA, it's also how you implement it. For example, it's one thing to have push notifications, but it's another thing when you overload the user with notifications and requests to do things as soon as the page loads. So it's also a function of implementation as well, right? Right, so especially with push notifications, you can easily overdo it and a lot of companies actually have. So when you ask for push notification permission right from the start, like right at the load event of the page, people don't have the context, like why should they even sign up for it? Whereas when you wait until something has happened, like for example, you have ordered something at a shop, this shop might ask, do you want to get a push notification once the item is ready for shipping? So that you actually have a context, like if I sign up, this is what I can expect. The rate of happiness of people who sign up for these push notifications will be way higher. The downside a bit of like, why do people still aggressively from the start ask for push notifications is, it might have a positive impact in the short term because people just do anything to get the stupid dialogue away. So they might just click yes to make the dialogue go away. But then when the first notification comes in, they will just block it or in the worst case, they will even look for a setting in their browser that would block push notification prompts from the start. So if this happens and Firefox have made this blog post where they kind of highlighted this feature in the browser, that's of course a really bad thing to happen for the entire ecosystem because if some sites overdo it and people block the browser from asking for push notification permission, they are completely out of the game for the entire feature. So yeah, I think definitely it comes down to when do you send push notifications, when do you ask for push notifications, the right frequency, should you push anything, it should always in my opinion be something where it's meaningful, timely, so that you actually get a real value out of signing up for push notifications. And speaking of push notifications and web APIs, the web APIs are constantly evolving. What kinds of things can developers expect with the future of PWAs? There's a lot of APIs right now that are not available everywhere. So when you look at PWA set of features, we have service workers that are now available across the board, but within service workers there's different like sub APIs that you can use, for example things like navigation preload or background fetch or background sync that are not available everywhere. So for example Safari, they implemented service workers, they say, but in Safari you can't use push notifications or you can't use background sync. So I think when it comes to the future, hopefully we can make more browser vendors implement more of these APIs so that more and more people can really rely on these APIs being in all the browsers no matter what application they run. Could you briefly explain what background sync is? So background sync essentially allows it to fire and forget. So what it can do is, for example, pile up your analytics requests that then would just fire at some point when the browser is back online. So in many cases navigation can still happen while you're offline because sites might be cached. Vendors are always interested in tracking these events like did people actually use my app while I was offline. So background sync allows you then to kind of replay all these different API requests. It can also be used for more from a user point of view more user friendly features. Like for example, if you have a chat application you can send a chat message even if you're offline and then just rely on the fact that whenever you go online again the browser would send your message no matter the network situation at the point of sending it. So just like if you have a native application like Facebook Messenger or WhatsApp you can compose messages offline and then just rely on the fact that at some point the browser would send them. So on the web with background sync we do have this feature as well. So as the web capabilities get stronger and stronger there seems to be more overlap with native applications like iOS and Android. How do you see this playing out with how users actually use applications be it natively or on the web? So I think we have trained as an ecosystem at all we have trained users to actually look at app stores first when it comes to applications. So you want something, you have a brand that you engage with where you do your grocery shopping for example you might look on an app store first nowadays so to download the app. So I think it's a little bit of how can we retrain users to go web first when they want to have something. In many cases when nowadays you go on a website the first thing the website asks you is do you want to install the app? In most cases it's no, I just want to use the websites that's why I came here. So I think it's more of a matter of re-educating people to thinking web first. So when you think back Steve Jobs when he introduced the iPhone in 2007 in the keynote speech the one last thing was actually web apps. So I think we need to go back there a little bit. So 2008 was then when the app store was introduced. So this is where it all started where every butcher shop needed their own native application and we're realizing more and more a lot of these applications are very expensive to maintain very expensive to build in the first place. You have a very strong burden in getting people to download them. Just imagine your car sharing app for example. You arrive at an airport in a different country roaming is super expensive. You just want to cap and the first thing the cap application or web app asks you to do is download the native application. So you're like no I don't want to download 100 megabytes just to order a cap. You just want to use the web app and just be good. And if the web app can do everything the native application can do then yeah why have a native application in the first place. But that being said this is not about killing native. There's a lot of very good use cases where it would still want native applications. It's just more a matter of thinking what is the right measure that you want to use right now for having a certain functionality because in the end people don't really care about how something is implemented. They want a cap. They want to buy something. They want to get a hotel. So you have all these different use cases that are catered for by native applications or web apps. Regular users who are not developers they wouldn't really notice the difference if it's if the web applications are well made. And users might be going to app stores and installing web apps directly right. So we have seen for example Microsoft do this where they put PWAs in their I think it's a Windows store or Microsoft store I never can remember. So you can actually download for example the Twitter PWA on Windows as a desktop PWA and just install it and it works super well and regular users don't even notice the difference just because it's really well made. So I think it's a matter of how do you place all these different applications in front of the user. And in the case of the Windows app store it seems to work pretty well. So if you look at all the benefits that you get from app stores as well you get star ratings, you get reviews. So you can see this is an application worthwhile installing. Do you have any closing words of wisdom for developers who might be building their first PWA? So when it comes to building the first PWA I think it's breaking down your own site into use cases. Like what use cases does my site even offer. If you are a newspaper, if you are a publisher if you are a hotel comparison site or so you need to think what are my use cases. And then you go through the different PWA features that you have and then you think step by step where can PWA add value to my particular use case. When you're a publisher maybe you can start with push notifications when breaking news events happen so that people get steered back to the application when breaking news happen. When you are a hotel site you can think of well it's probably a pretty big application so how can I make sure that it loads quickly? How can I maybe even allow the app to work in some cases offline so that you can have something like a hotel voucher so that you can just show up at the place and say look this is my reservation. Even if you're maybe in a foreign country without roaming so that in your app you would still have your booking details stored. So I think it's breaking down PWA's into features and not thinking of like this entire PWA thing as one opaque block but breaking it down and then just in general shipping less JavaScript is I guess a good advice that generally holds true. Well Tom thank you again for being here. If you'd like to learn more about PWA's check out the links to the documentation in the description and share your PWA experiences in the comments below. Thanks for watching and we'll see you next time.