 Welcome to this talk. This is about progressive web apps, specifically examples out in the wild that I can show you and demonstrate what they're doing and why it's a good idea. So firstly, because I like to have an idea of who I'm talking to, so about how fast I can go. And also just to check that it's the end of the day and you are still awake. We'll do the traditional kind of putting up hands to answer various questions. So who has heard the term progressive web apps before? OK, we can skip through a lot of this. So I guess actually front-end and back-end. The term is all-encompassing. Who thinks they could define what a progressive web app is? OK. Oh, yes. And if you want to follow me on Twitter, then it's at Roan M. And I am a developer advocate at Google, so I focus a lot on web-related things and working with partners to kind of bring some of this early access technology into the real world and prove that it can help make your users happier. A couple definitions then, though. So for us as developers, I feel that PWA is a term that allows us to, and this is the important bit that we'll spend a lot of slides on, quantifiably define what a good modern web experience is. So what this means is that there is kind of a part of the progressive web apps term where you remember in the past, everyone would ask if this was web 2.0 and you'd roll your eyes because you knew that was nonsense. We have a sort of aspect where it's kind of, as a user then, what we want progressive web app to do is allow you to raise your expectations for what is possible from the web. So what we'll do is we'll go through and we'll see what these aspects are and how they can change the way that you interact with websites. And to get a bit more technical then, this is a graph explaining the benefits for your users. So this is happiness up this access, which is, I don't think access makes anyone happy, which is measured in smileys and PWA nests along this access, which is measured out of 100. So as you can see, we have bad websites down here. Then I'm going to show you how we actually split PWAs up. So we sort of bucket them into two categories. There's a baseline PWA, which kind of gets you this much user happiness. And then there's what we kind of call the exemplary PWA. So this is where you go above and beyond to really polish the experience. And that takes you up here. I probably should have swapped those around. I think this guy looks happier than that one. But we won't dwell on that. This is overly technical. So let's actually get into the definition then. So when we talk about PWAs, this is what we mean by the baseline. So the first thing is we say that the site is served over HTTPS. Secondly, this page is a responsive and I'll go into detail about exactly what I mean about these things. We have metadata in for add to home screen. Who has web apps added to their home screen? Wow. Okay. The other thing I like about doing these talks is one, getting distracted from my point and segueing off into something else. And two, I like to try and give you very applicable examples that you can either code right now. In fact, who has like a laptop where they have access to like their own site? Or you don't have to close it. I'm not going to test you. But you know, if like you have stuff hosted in GitHub Pages, then you can actually update this while I'm doing the talk. And you can tweet me afterwards and I can review the pull request or something. Okay. Then we also start to have this aspect where we have an expectation that these sites should be able to work offline. So I'll show you how that works. It's the web, so it should also be cross browser. And then as the capabilities of these pages get more advanced, we also want users to be able to interact with them in a way that makes sense. So transitions between pages shouldn't feel like they're being blocked by having tapped a button and now they simply have to wait to see if the request eventually turns up. And finally, and this is one that has PHP developers you should be more comfortable with rather than JavaScript developers. Each page has a URL. It sounds simple, but people always go to one extreme and suddenly decide that, oh, back in the good old days when your website was a flash applet. Okay. Now, of course, we wouldn't be developers unless we had a tool to automate this. So what we've released is a tool called Lighthouse. You can get this as an extension in Chrome. It's also available in MPM, so you can run it via Node and sort of incorporate it into your Gulp build. You can get it to run with a headless version of Chrome. There are a few caveats to that. But on the whole, you can just install this and you can start testing for baseline PWAs on any site that you visit. You see the subliminal messaging here. Lighthouse and use is highlighted. Use Lighthouse. Good, okay. So let me show you what that looks like. Here's an example of an arbitrary webpage that I selected just to run a Lighthouse test on. So I tap the extension and it lets me generate a report. I'll tap that and it will go off and generate a score out of 100. So you will be able to scroll through here and you can kind of see each of the categories that we talked about and we'll explain what is either missing or what is passing. So you can see with a score of 35 here, this is when you weren't doing very well in school but they didn't want to make you feel bad. They would say, you know, there's room for improvement here. There's low hanging fruit which can actually be taken care of very easily. And hopefully, I want to demonstrate throughout this talk why this isn't simply a case of, oh, I want to tick these boxes because I want to be using the latest technology and it doesn't actually make a difference to my site. Each of these points has a very real effect when it comes to how users interact with your site and how you can have a successful site for whatever purpose you're trying to fulfill. Okay, rule number one. Site is served over HTTPS. Who and not over HTTPS, always and only served over HTTPS. Who's site fulfills this category? Yeah, good, good. So this is an example to show you in practice what's going on here and this is what you should think about applying to your site if you're not already. So if I do a simple curl call for a stripe which is a payment provider on HTTP, I'm going to get back this 301 redirect, redirecting me to the HTTPS version. So this is our sort of default of you just type it into the browser. We want to make sure you go to the right place. Now, if I then curl the HTTPS version of stripe, I get this back. So this, the strict transport security header is an important aspect of making HTTPS the default for your site. So what you get here is a max age. So we're basically saying that we want this to apply for a while. And we want to apply it to the subdomains of that path as well. So this is referred to as HSTS or the HTTP strict transport security. And what that header is doing is it's telling your browser or basically any compliant client that is receiving that request. It's telling it that it should only interact with that domain over HTTPS. And one of the benefits of this is it lessens the risk of some man in the middle and protocol downgrade attacks. There was, when I was looking around for this, there's a good presentation from 2009 from Moxie Marlin Spike where he shows basically how if you take over like a wifi access point then you can just redirect traffic to HTTP all the time. You can play a few tricks so that you can put like a padlock icon in the address bar and so on. But basically by telling the browser that you only want to do HTTPS, you mitigate the risks of being downgraded to that. One of the other things you can do then is if you are returning this header, also go to the HSTS preload.org site because what you can do here is you can submit your domain and that means that browsers will actually use that list of domains to ensure that they only go to the HTTPS version of that site regardless of what the user types into the address bar. So we can see an example of that here. I thought I had some more slides. Maybe someone's man in the middle of my presentation. Okay, so this is what's happening. So inside of DevTools I'm taking a look at the request and what I've done here is I've just typed stripe.com into the address bar and so there's an HTTP request that looks like it's going off but I'm seeing this status code back, a 307 which is a temporary redirect but what is actually happening here is if you hover over that in DevTools you'll see it labeled as an internal redirect so Chrome is actually not making that request out to the server. It is just immediately acknowledging the HSTS header and redirecting you, or sorry, not redirecting you just querying the HTTPS site. Okay, makes sense? Everyone going to go implement a header? No, yes? Right, why is this important? So 150 million is the value of one Bitcoin at the moment or it is the projected average cost of a data breach in 2020. I don't know where this figure comes from but it's a big scary number and if you are looking for reasons to help push your organization to go HTTPS only then being able to explain that this is the cost of not doing it is quite helpful and then as the initial sort of aspect of progressive web apps as well almost all of these other features that are included in the kind of progressive web app bundle are dependent on the site being over HTTPS as well. Okay, second one then. Pages are responsive on tablet and mobile devices. I don't want to spend a lot of time on this one because design is a big topic and I'm a developer, not a designer so these slides are the extent of my creative output but I do want to say a few things about it. So an example of responsive design then is a colleague of mine Sebastian runs the AMP by example site. This is one of my other opportunities to segue into a different topic. Who knows about AMP? Okay, so AMP is Accelerated Mobile Pages which is a sort of a JavaScript framework that we provide or sorry, an open source JavaScript framework that is for building high performance cacheable web pages. So it has a lot of limitations in sort of what CSS you're allowed to use, what JavaScript you're allowed to use but you can still build a functioning responsive site in it. So really the key thing here is that responsive is a goal. I'm not trying to prescribe a specific architecture to you in this, so on AMP by example that is a fully responsive page that is being delivered. It is absolutely fine if you are doing server side responsive so you're looking at the user agent that is coming in and you're returning something different based on the user agent that is coming back. As long as the user is getting functionally equivalent content on the URL that is appropriate for their device then I'm happy. Okay. Next step, adding metadata for the add to home screen functionality. So this is one of those times where in the first Batman film, the first like the 1991, the Joker has poisoned like a load of products and he's threatening the city with them and he has this line about it's like you may be using them already. So that's actually what's going on here. I'm not trying to poison you but you may actually be using add to home screen enabled apps already. So if you go to mobile.twitter.com and open up DevTools then you'll see the, you can go to the manifest tab or sorry the application tab and then manifest in here and it will show you, okay that's a bit better, it will show you the information that is available for that. Now if your site fulfills these criteria that your manifest has provided a name, a short name, a start URL which is where it's going to be launched to and some icons then if you're loaded over HTTPS then Chrome will actually prompt the user to add the app to their home screen. So this is the opportunity where if you want to go to GitHub right now you can add a manifest to your site and you can add it to the home screen. There are also a couple manifest generator tools out there. I mean it is just a JSON file but there are a whole bunch of attributes that you can also add to it. So this is the bare minimum just to describe your sort of your icon. You can also add a number of other things so you can specify like do you want the display to be as a standalone so it looks fully like an app? Do you want it to be minimal UI so that you still have the address bar and so on in there? You can specify the preferred orientation for your app, portrait, landscape, theme color and background color so that when the user is going through the switcher or looking at the address bar you actually get the theme color applied to that as well. And then, and this actually gets me quite excited. I'm not sure if everybody else is, I would hope we're at a web conference, right? You guys are excited by the web, yes? More so than Android apps? Are you excited by Android apps? Are you excited by anything? Okay, so this flag inside of Chrome enable improved add to home screen. If you like fiddling with the flags in Chrome on your mobile device then you can go ahead and enable this. And what will happen is normally what add to home screen does is it's kind of like the equivalent of a turbocharged bookmark, right? It sits on your desktop and when you tap it it launches the URL that was specified. What improved add to home screen does is it actually takes that manifest and in the background kind of mints an APK for it. So it actually installs the app or installs the website as its own app onto your phone. That means that you get things like this. When I tap a link in another app then the website, the web app is available to handle that link. It also means that I can go and look at the app info so I can see how much bandwidth has this site used. How much battery is it responsible for consuming? Basically you get this much more integrated experience with an installed web app. It absolutely is, yeah. So manifest.json, in fact, everything I'm showing you in this presentation is W3 standards. The things that are different are the way various browsers choose to implement them. So Opera does, Opera actually has a gesture because of course Opera has a gesture that you can use to do this. I think it's like you pull down into the left and you can trigger add to home screen for the site. I think Edge is doing some stuff here. Basically these are all W3C standards but surprisingly enough because I work at Google I tend to know more about the Google related implementations. But yes, please don't come away with the feeling that I am pushing you to try and do some kind of Google integration here. This is very much open standards for all of this. So the manifest.json is what controls this and then it's down to the individual browsers as to how they want to interpret that and provide an add to home screen experience. One thing you could do is in the bar later if you want to ask Ben at the front here about WebOS and how web apps can be amazing then that's definitely a good topic of conversation. So yes, this is the point. This is just a normal website. This is not like a titanium or app accelerator or Cordova wrapper. It is just your website. It just happens to be more deeply integrated with the operating system. Okay, and then more big numbers for you to show to business people to suggest why you should be doing this. So this is the alibaba.com site. That is a lot less readable than I expected it to be but that is alibaba.com. They added add to home screen and they saw a forex increase in the amount of engagement. Sorry, the interaction rate that people had from launching it to the home screen. So I think you may have heard this actually from a lot of people is that when they sort of talk about why do you have an app, it's because they want some of that home screen real estate. So a lot of the time the app is not necessarily, in fact I've seen a lot of apps that are literally just the website wrapped up in APK and deployed to the Play Store because it gets a bit more exposure. So we want to be able to make it so that people don't have to do that because it's a business decision. You should be able to make what you feel is technically the right decision. Oh, good question. Oh yes, and actually I'm more than happy for people to just interrupt through this because it's because I've been through these slides quite a bit now so I actually get a little bit bored going through them so if you ask me things. So when you specify the start URL, you can specify any URL. So if you want you can just have like a get parameter or something on there that would allow you to measure like how many people are launching from the home screen. Additionally, when it's launched from the home screen you can also access, I can't remember exactly what it is but it's one of the media queries in the CSS that you can use to determine that this is a home screened app as well. One of the things that I would love to see more of as well is that people tend to do add to home screen as just an analog for kind of saying, oh if I have example.com then add to home screen should just be example.com, right? Just like a bookmark to the top of the site. But what you can actually do is you can specify these manifests throughout the site and you can provide a scope for the manifest as well to say what path it is responsible for and what that would mean is say if you were a hotel booking site you could have a web app that was hotel search but then you could have another one scoped to like slash bookings that was just a web app for displaying your current booking. So you're not limited to say add to home screen must map directly to my top level domain you can map it to any path that you want across the site. Okay, the next rule then is now that we can add stuff to our home screen and they look more like an app to the user, we've actually raised the expectations because now what happens is if I tap on that shortcut what I don't want is the white page of death or the dinosaur game or whatever my offline indicator is. So this means that now that we've installed our web app to the home screen we need to be able to provide some sort of offline experience there. So, I love it, I love it when I get surprised by my own slides. Does anyone, has anyone heard of the physical web? One, okay, so I turned the transmission power up as high as I possibly could on this so I may be cooking some of you in the front row but basically my phone is acting as a beacon and broadcasting a URL out which is this this is the idea of the physical web is that you can attach beacons in various places with URLs to represent what is happening in them. So maybe a beacon in here that provides a link to the schedule for this room for example or a beacon in a restaurant that provides their menu or something like that. So obviously what I have is a beacon that just goes to a little AMP page that is about me. But the important thing to notice here is if you make that request and then refresh that page then inside of the oddly inside of the size column you'll actually see this from service worker request there. So just so I know whether I'm losing people or you're falling asleep, who knows what a service worker is? Oh, okay, actually not that many, okay. So a service worker is basically a piece of JavaScript that is allowed to run in the background for your site. So it is a JavaScript worker. Yeah, but then the service worker is a sort of specific implementation of that. So basically you can have a service worker that again is scoped to a given path by default it's just scoped to the location of the service worker script and what this allows you to do is a service worker can sit there and it controls a number of pages that are linked to it and it can intercept the requests that are coming out from that page and the responses that are coming back. This allows you to do some primary things. It actually allows you to do a ridiculous amount of things because you're basically sitting as a proxy in between your page. So you can transform those requests in any way you want but that's our scope for this talk. The interesting things that we care about is the service worker allows you to do caching, it allows you to receive push notifications which we'll get on to later and allows you to do background sync in the site. So the reason that you're seeing this here and if you go to this page and take a look at the application tab you'll actually see a link to the service worker so you can look at the code in there. Oh, conveniently I put a slide in to explain that. So inside of here you can see that the service worker activated and running. You've got now, service workers do introduce some interesting complexity into development so it is actually very useful to have things like this. You can specify when you're developing the update on reload and bypass for network. We'll just kind of make sure that it is bypassing the service worker when you're not getting a cached version when you've just been busy updating stuff on your development machine. So if I jump into the service worker code then I just want to give you a sort of flavor of this because I have a lot of slides to get through in 35 minutes. So this is just to give you an idea of the functionality rather than to try and explain how service workers work. If you would like to know more then we can do some code labs together after this. But effectively what happens is inside of the service worker you can add various event listeners for the different events that happen. So here we're adding event listener for the install event which is unsurprisingly when the service worker is installed into the browser. And event.wait until just means that the browser will not kill this request before it's done doing what it wants to do. And in this case what it wants to do is it's opening up a cache which is just with an arbitrary name and it's going through and it's adding all of these URLs to the cache. So what that means is that if I'm offline and I make that request then the service worker is actually returning all of this data for me. So my basic site works offline. Now the other thing that you can do here as well is this would also work that say you can't cache the entirety of your site. Not only would that not work it would actually be quite unfriendly for the user. But what you can do is you can detect that you're offline and instead of trying to sit there and go out to the network you can return a status page to the user explaining that they're offline. So that would mean that when I tap your icon from the home screen and I'm in airplane mode you might choose to do something like show me some cache content that I was viewing previously or just show me an indicator that I'm offline at the moment and I should relaunch the app when I have a connection. Does that make sense to people? Yeah, good. Ah, good question. So the service worker does pay attention to the cache headers that you put on those requests but the sort of, both a sort of double-edged sword with service workers is that you are fully in control of that. So what you'll see in these demos is that you are also responsible for clearing the cache as well. And there are a number of ways that you can do that very easily. So the default one is that when a new service worker is installed you tend to just destroy your existing cache and re-initialize it. But effectively, and we, there's a service worker, actually we're updating these but there are some existing service worker libraries that also provide sort of out-of-the-box implementations for a bunch of caching strategies. So you can either do cache first, network first, you can set up a race so that it's cache or network whichever one responds first. And then we could even get into the amazing sort of streaming stuff that you can do with these requests as well. So next bit, site works cross-browser. Hopefully this is not a big surprise for anyone. Does anyone still have to support IE? Yeah? Is this like government work or something? Anyway, so the point that I want to make about this is this bit. This is what we mean by the progressive part of progressive web apps is it's not about saying you must have JavaScript to enable it to browse this page, it's about saying that we will take advantage of the capabilities that your browser offers to enhance and progressively enhance your experience. So just to kind of round that point home I went and took a look at the PHP UK conference site in links, which does work for the info page but doesn't work for the schedule page because that does appear to be popped in via JavaScript. But it gave me enough to make a worthwhile slide here. So hopefully that's made the point. Okay, so the next bit, page transitions feel like they don't block on the network. Now what this means is that if we look at something like Facebook and conveniently I was able to find a section of my Facebook where it was actually just two PHP people in the stream so I wasn't exposing you to anything you shouldn't see. So inside of here you can see that Eli has posted an article and I go to tap on it. So when I tap what I'm getting is I actually get this instant response and I'm getting a loading indicator there before I get into the actual article itself. So this is literally all we mean by this is that when users interact with elements in the page they should get immediate feedback that something is happening. And did anyone, who did like computer science at university or some equivalent thing? So you probably remember spending some UX time on like Nielsen's usability heuristics and so on. Anyway, this is 1993 but this all still applies. What this basically says is that there are these three important time limits for user interactions. So the first is if something happens within 0.1 of a second that's basically instantaneous. You don't need to worry about doing anything. If I tap the button and you know the story is going to display like that you don't need to bother showing a loading indicator. If it's about one second you do want to show some kind of indeterminate spinner or just a little some dots or something like that. If it's going to go to like 10 seconds and above that's when you want to show the user some kind of indicator of progress and preferably also give them a way to cancel out of that and get back. The worst feeling is always when you've tapped on a link and you know now that you're committed you're either gonna wait for this or if you press back the site's not gonna deal with that and it's gonna just leave you in some kind of weird have I added this to my basket? Have I booked a flight? And another important point that I want to make here is part of this is also the browser gives you a lot of stuff for free, right? When you tap a link you get some kind of indicator showing you that like a request is actually going off. Depending on the browser you may even get like an indicator showing that the response is coming back as well. If the user has added your site to their home screen and you've used the standalone mode then you lose all of that browser Chrome that provides that feedback to the user which means that you have to implement mechanisms of making it clear to the user that something is happening. Okay, this one, each page has a URL. I don't think this is controversial in this room unless there are any single page app developers who have snuck in without telling us. But actually on that note though, so this is a single page app. This is pokidex.org and what you'll see is if I go in and tap on one of these then what I'm getting is just the anchor tag here so the hash slash Pokemon. But they've still changed it and you can also then double check that if you just copy and paste this out and paste it into a new tab then you are actually going to come back to this page. So it doesn't matter that it's just a JavaScript anchor tag as far as the user's concerned, they have a link. If they send that link to someone else then that person should be able to see the same thing that they shared. I don't want to send this link and then just get directed to the home page. Okay, and then of course to manipulate this you have the history API which is what allows you to push these new entries into the location bar and it then behaves in the predictable way with the browser so when you press the back button this will also pop that state back out of the stack as well. Okay, that was the baseline experience so now we're also going to accelerate through this and go into the exemplary experience as well. This is the exemplary checklist then so this is the kind of adding on top of what we've done with the baseline. So the first aspect then is the indexability and social side so one of the problems you often see with single page apps where you're using the anchor tags is it's fine for the user when they're navigating around but if I say share that link to Facebook then the Facebook crawler is just getting back either no information or the generic information for the site. So you need to make sure that you do have some form of either server side rendering or you know that the crawlers that are interacting with your pages are capable of interpreting enough JavaScript to get what they need. It's also then important in the world of kind of AMP and other translations and other formats and different mobile versions to make sure that you are specifying what your canonical content is so if this for anyone who isn't familiar with it is you just have the rel canonical links in the header of your document that point back to the original content for that site. User experience so I think I had an example for this. Yes I do, good. Okay so I'm sure people have had the experience of you're trying to load a page and things keep jumping in as they load reflowing the text. You also want to make sure especially in the world now of kind of infinite scrolling through lists that when I press back I want to be taken back to the same location I was not taken back to the top of the list or even worse taken back to a brand new search that's forgotten all the filtering that I did. And finally you also have on mobile devices you do have some JavaScript which I cannot remember at the moment but it does mean that there's also the whole you tap into a field and the keyboard conveniently slides up right over the field that you're trying to type into. You can mitigate this by using the I think it's the scroll interview call as well. So this is the experience that I was talking about is I go here and I want to see more cat pictures who wouldn't want to see more pictures of that cat? So I'm going and I'm going and just as I'm about to tap an ad pops in and instead of getting my cat pictures like this. So I had to use a contrived example here because I didn't really want to single out real websites and just ridicule them in front of you. Anyway, back to the remaining user experience. So this now talks about what happens when we have added to home screen and we've started taking the browser controls away from the user so we also don't give them if they've added to home screen you don't have a location bar I can't just copy and paste the URL to share it with someone else. So this means that you want to do things like provide sharing functionality inside of the site. You want to ensure that again just reiterating the whole this site should work across all devices and all form factors. The app install prompts that you get as well. So inside of Chrome for example, when it does show the add to home screen banner you actually get an event that you can subscribe to because a lot of the time it might not show the add to home screen banner a moment that is appropriate for you. So especially if you have say a very funnel based site where it's kind of I've been browsing I found a product I've added it to my basket I'm about to pay and then it pops up and says add to home screen in the middle of it. That's gonna break the flow of what the user's doing add to home screen will they actually come back to the same location that they were in not too sure but you can capture that and then you once you've got that you can choose to retrigger the prompt at an appropriate time. So for example that's when I have completed my purchase and maybe I get some tracking information that's when you can prompt me hey add to home screen so that you can actually just come back and easily track the status of your order. So this was what Air Berlin did I worked with them last year on this progressive web app that they built out which is actually live now so if you fly with Air Berlin you can actually use their progressive web app to check into your flight. So what they do is they provide a notification when your check-in is ready you tap on that, you come in you fill in your flight details you tap through, you get this, you check in and you get your boarding pass and it was here because your boarding pass is stored offline so this is always available it would be at that point that they prompted for add to home screen so that you can immediately have your boarding pass available to you just off of a link on the screen. Okay, there's a very heavy focus on performance and also caching because what we don't want is for people to go crazy with all the new rich JavaScript functionality and decide that that means it's acceptable for web pages to have like a 30 meg payload when you hit the front page. I was actually at a previous conference where the speaker images were just the images that the speakers had emailed to them and I was on roaming data at the time and I hit the page and it's like one guy who sent like a 20 meg headshot that is just straight up on the site and being downloaded and at that point I had to turn my roaming data off. So make sure that you are concentrating on the fast first load time, the time to interactive and caching appropriately as well. So some more big numbers that you've probably seen you've probably seen these kind of things before especially when it comes to because I think everybody's fairly comfortable with the idea that a faster page tends to increase a lot of other business metrics in positive ways. Housing.com, if you can look at these showcases here that I've linked to, I would also very much suggest if you want to go into more detail on how these were done, a lot of these developers came to Chrome Dev Summit and explained in detail the performance optimizations that they put inside of these apps which goes into a lot of detail about the network sort of setup that they had for delivering the requests and also the JavaScript setup for optimizing for that first view and time to interactive. So housing.com which is a sort of housing a real estate site in India. They got a 30% faster page load time that led to a 40% lower bounce rate, 10% longer average session time and amazingly 38% more conversions. That's the sales bit over. I feel a little bit dirty doing all those numbers at once, okay. Then another example, Flipkart. Flipkart is another Indian e-commerce site. They quite famously went through a stage where they said we are going app only and basically they turned off their mobile website and then a bit later on they're kind of like, oh that was actually kind of a mistake. And so they went back and they redid their mobile website and they really embraced all this kind of stuff. So their site is a very good kind of you can go through and look through developer tools to see a lot of examples of how to do this right. One of the nice things they do is when you go offline then you get this. It grays out, you get a little toast at the bottom saying you are offline. And one of the other iterations they had of this if you were browsing through product lists then products that you had already viewed remaining color indicating that you could actually go back and look at those even if you didn't have connectivity. This is the way you deal with that. So you just use it, you can ask for the navigator.connection inside of JavaScript and that will basically return the connection status to you and you can add an event listener for the change in the type of connection. This will give you more information than just on or offline. This actually starts to try and give you more granular information like are they on wifi? Are they on a metered connection? I think Bluetooth is in there as well for some odd reason. And Ymax as well. Anyway, that's, again, that's our scope for this but there's a lot of good information in there. Then the remainder of the exemplary ones about going into more detail about push notifications. So this is where the other thing we want to avoid is giving all this stuff to web developers and them suddenly acting like native app developers from 1999 where it's kind of like, we can do push notifications? We should do push notifications for everything. Because Chrome in this case is actually a lot harsher because whenever you receive a push notification in Chrome there is always a big button to the site settings where you can just immediately ban hammer that site from sending you any more notifications. So in a way, you are actually forced to be a bit more considerate than a native app would be in terms of sending notifications. You want to ensure that they are actually valuable to your users because it's very easy for them to turn them off. So we've provided a few suggestions on, you know, not being overly aggressive but also making sure that you make it clear what the user is opting into. So weather.com does this. You can, if you're getting bored you can actually try these out on your phone while I'm talking as well. So if you go here and you go into their settings you can go to manage notifications. You flick on the notifications there. Chrome will pop up giving you the permission chip. They're on and the first thing they do is they send you a notification to explain that you have enabled it. So you can see there that site settings one that will allow me to just go in and just manage it for the entire site. You can actually do a lot with web notifications now as well. By default this is the icon from your manifest but you can also send an additional image with it. You can provide additional actions for the notifications as well. So for example, if it was, I don't know, you're doing a site based on watching flight statuses or something you could include a bookmark action inside of here so that you can just acknowledge it from the notification and then come back to the site later. And a super quick, super abridged version of how this works then. Basically inside of the page this is how you would subscribe to a notification so you're asking for this. You're seeing if the service worker is currently ready and then out of the service worker registration you're getting the push manager, you're calling subscribe. That will give you a subscription object that you then send off to your server so that you actually know who you're sending push notifications to. And then the other aspect is in the service worker much like we were listening for the install event on the caching example, here we're listening for the push event. So when a push message comes in then we can use the show notification option and inside of here we can specify, oh that's a typo, we can specify the title and anything else and again, this you can pull this data from the notification as well. So if it is something like, hey that flight to Hawaii is now 500 pounds then you can show that in the notification. Some more numbers about that. I think I promised I wasn't gonna do more sales stuff. Okay, so we actually see a lot of good reception to web push notifications. 24% opt-in rate there, 16% on desktop, 32% on mobile and a 42% open rate. This is obviously dependent on your use case. If you send terrible notifications they are not going to get opened. Okay, the final bits of this, oh we're doing okay for time actually. So I'm quite happy once I sort of finish with the slides to just go and look at random other stuff as well, not like random YouTube videos but relevant to the topic and so on. The kind of end result, these are two new APIs that are coming out. Credential management API basically as the name implies allows you to manage the users credentials within the browser and the web payment request API allows you to request the saved card and address details that the user has associated with the browser into the web page as well. So I wanted to show you, actually this is another bit of homework that you can do or that we can do right now. Do, who, I'm trying to think of a nice way to ask this question. Does anyone not use autocomplete in the forms on their site? At least tell me that no one blocks pasting of passwords. Good, yeah, most developers know that that is not a way to win friends. But this is like a very quick thing. So I assume most of you have seen your browser prompt you to say it can save this username and password for you. The credential manager is basically a way of giving you more access to those saved credentials. But one of the things that's very important and very easy as well is to ensure that you're correctly hinting to your browser which fields are username fields, which ones are password fields. So you can do this, you can do autocomplete equals username. This one is even nicer, autocomplete equals email. I can't, I lose count of the number of times that I've gotten angry with sites because I've gone to try and log in and they asked me to type my email address into a field that one tries to auto capitalize the first letter. The at sign doesn't show up on the phone keyboard without pressing to the additional screen. If you do autocomplete equals email, the keyboard responds intelligently. You have an at sign there. If you have email accounts saved on the phone, the browser normally auto suggests those as well. And finally, one of the other problems with saving passwords to the browser is that it often has like one version of the password saved which is what you did when you logged in the first time. But then people haven't marked up their password change form correctly. And therefore when I change my password, I now have the wrong password saved in there. So you can add this to your password save form. So we can take five minutes while you all do that. Or we can do this at the bar afterwards. So just an example to kind of show you how this works here. You can see on Kayak here that I'm getting the save prompt when I've signed into the site. It's offering me to save that. Now because they're using the credential manager API, I think actually I haven't put more code in for this because I figured you guys would be a little bit tired of code, but I do have code if you want to see it. So what's happening here is this is being saved into the browser. And then what happens is on my phone where I'm logged in with the same Google account across these devices. So the key thing here is that the browser in each locations has the same identity associated with it which means when I come to the site for the first time it automatically signs me in because the mobile site is able to see that I have credentials saved for that. It retrieves them and just takes me straight through the authentication process immediately. So the kind of benefit of this is the whole kind of I'm here, I'm at the office, I'm looking for a hotel, I get part way through booking my hotel and then I realize I need to run for my train so I get my phone out and I just carry on doing that same booking when I come back to the site because I've been automatically signed in and then if you can make sure that on your side you take care of going, well let's just drop you back in at the same place in your session to complete your booking. Another aspect of this, and so I apologize, this bit is a bit googly and not wholly open but who also has or within your organization also has an Android app? Yeah, okay, and do people sign in to the Android app and to the site? Yeah, so what you can do is there's a format called the digital asset links file, it's yet another JSON file that you store on your domain. Inside of here you can specify the Android apps that you want associated with your domain and what that means is that if you use the smart lock library on Android, so this is a good opportunity if you are in a sort of siloed organization where maybe you don't talk to the Android developers that much, this is kind of an olive branch to do like a bypasses and project with them. This means you can get automatic signing across web and native apps. So if I'm on the website and you've given me an app install button I've installed that, when I open the app for the first time you can sign me straight into the app as well. So I think this might be the last number, I keep saying that and I keep lying. The Guardian did this and basically saw a 44% increase in the cross-platform signed in users. So this is actually, I mean, this does have a very measurable return on investment for bringing users back into a signed in experience. Okay. Yeah, what next? So the question there is smart lock only Chrome based. So what's actually happening here is credential manager API is the W3C standard and that means that the browser, so at the moment it's only Chrome that supports this, but I'm hoping that by telling you about it you'll be excited about how good it is and then the other browsers will realize that they should support this as well. But what's happening here is credential manager API is the API for presenting those credentials within the browser. Then if you go to, you can go to passwords.google.com and that will show you all of the passwords or of the credentials that you have saved against your Google account. Then on the Android side, it is smart lock that makes use of that same backend for credential stores to offer them across web and Android. In the long term, there's actually, I have a whole nother talk on this mainly because the internal code name for smart lock was you only log in once or YOLO and there's an ongoing project called Open YOLO which is basically about working with password managers to kind of decouple the way you're storing your passwords versus where you're presenting them. So what next then? Things to think about, the web payments API, this is super new. I do have a demo of this on my phone so if anyone is interested in how to make money on the web, then I can show you how that works afterwards. There's also the web share API. This again, I have a very shoddy looking GitHub pages demo that I can show you of this but what this does is this hooks into your browser again to do native sharing of URLs. So that means I can be on a web page, I can say share and it will trigger the apps on my phone to share that piece of content with them. And of course, the physical web as well if you have this enabled or haven't installed it yet and you're sitting close enough to whatever transmission power that can kick out, you might even see a link to my site. That's it. That's kind of all I really had to say. So it looks like we do have, we've got five minutes for questions. Much like everyone else, I would very much appreciate feedback on the talk. Feel free to say like one nice thing and one horrible thing so I can improve as a person or maybe I can just tell you to improve as a person if it's really horrible. I'm happy to take questions now. I'll also be hanging around at the bar and all of tomorrow. So, yes. One of the original listed baseline components was about URLs and contents, the static nature of the URL and so on. In the Air Berlin example you showed, it was using m.AirBerlin. Yes. How do those two things fit together? So, something I will say once I get back to... Yeah, so the every page has a URL. This is combined with the canonical aspect as well. On the whole, my personal preference would be that you always go to example.com slash content. You don't go to m.example.com slash content. You don't go to touch.example.com and that the browser responds intelligently to those requests. However, as a kind of artifact of a lot of the architectural choices that people have made in the past and ways of serving up these, a lot of the time your desktop site and your mobile site just happen to be separate code bases. There, that's where making sure that you have the rel canonical links in place to ensure that you're still indicating that there is one canonical piece of content, like example.com slash content and then m.example.com slash content contains a link back to that. And that's what also signals to search engines not to index that content multiple times and return the same result. And also depending on the client, for example, it, I could conceivably, if I was sharing like the mobile content, I could always choose to look at the canonical content first and use that for maybe like for metadata for a preview image or something. So yes, on the whole, I would, the other kind of thing I wanted to stress about this is that a lot of people have done PWAs and they've sort of, they've seen PWA as some kind of magical term, which means they kind of go, oh, we need to build a PWA alongside our existing website. The point that I really want to make to you as developers is that I don't view PWA as like a new shiny thing. I regard it as this collection of best practices that you should just be doing for websites anyway. So a lot of these I wanted to include when I was sort of showing you the sites that do this, that is a mixture of people who are incrementally improving their existing site, other people who have built brand new ones. The Air Berlin one was a case where they built a prototype that they deployed to a small number of users first, but the sort of the end goal is that that becomes the default experience down the road. Oh yeah. So where do you see companies that have native app and PDF progressive web apps fitting in? Where does that come in? Considering that PWAs aren't supported with iOS. So with my slide that had progressive on it with all the arrows pointing to it, which I won't spend a hundred years clicking through, a couple of things. One, there is never like one answer to say like, yes, you must build a website and you must build this native app. It's very much a case of making sure that you have the analytics enabled on your site to collect this data, to understand how your users interact with your service. I tend to feel like each of the platforms has their own strengths. So like there's always the kind of native brings you closer to the hardware. So if you're doing something that is about any kind of Bluetooth functionality, there is a web Bluetooth standard coming, but it is definitely not there yet. So if you want to do something Bluetooth related, you're building a mobile app for that. If you're doing something that is like an e-commerce app where it's very much kind of like, I'm presenting content back to the user, then it's kind of like, or even a news site. These things sort of very naturally lend themselves to a web-based approach. The other thing I'd say then as well is very much the progressive aspect. So all of these things that I've shown you, a lot of the, I'll see if I can dig out some of the case studies for this, but the things like the performance improvements, these are across the board. So these are across all browsers, not just browsers that say support service worker or support a certain aspect. If you're sort of, if you're applying these best practices, you're getting the benefit for all of the users. And then of course the other part of it as well is looking at your demographics, right? If your audience is all iPhone users, then there's clearly not much point investing in technology that is not supported in the current setup on the iPhone. So it's very much a kind of, I hope that this has given you tools to do things the right way and put you in a better informed position to solve your specific problem. Anyone else? Nice, well, thank you very much. And yeah, please find me afterwards if you want to chat more. Thank you.