aving html available Fetching some data and then actually having something rendered on the screen And like I said like this is like the like what we think of today is the the app shell model And this is one of the ways that we're asking developers to build applications is using the application shell We know the application shell works really really well for building certain types of for building different types of experiences But it's not necessarily the only way that you'd want to build a progressive web application But it's an interesting model because one of the things that you can do Is that you can focus on your content get your you know get everything out as a rendered So you can focus on your content at least with the app shell model get your content out rendered in that first request And then like you've probably been doing in a lot of applications is then start to incrementally take over the experience So this is just a simple thing where you know if you click on the link inside your application You'll So if you click on a link inside your application, you'll go normally navigate to a different url Now that's good, but inside like that whole kind of white page refresh model Is something that which is a detraction I get detraction from the user experience, especially in the kind of the web versus app world So what you normally do and you're probably all familiar with this is that you intercept the click Then go i'm going to load some content and then check that content back in that's a perfectly reasonable way of doing it But one of the things that we're trying to look at to the Right now is that We want you to think about the you do the page load so you get the content out You're still using the app shell model where you incrementally take that over and if Like sadly said, sorry, I'll go back one slide if you think about this model where you kind of intercept the content Or it's intercept the link click and load the content you've probably been doing this already in the past Which is quite a good thing because when you go to this kind of progressive model We still want you to go and do that, right? So if you have a service worker behind the scenes intercepting all the requests and kind of loading the content You have a number of different choices about how you serve that you can still do the incremental load So you can basically say not the incremental load So you can still get the html pass it as you go through render on the server And if you watch jeff's talking a little bit he's going to dive into that kind of universal kind of JavaScript Render inside of things where you can render on the server And push out to the content But we're doing that progressive render the web has got 20 years of being able to kind of progressively Like progressively render content To the browser We shouldn't kind of just throw that away because we want to get to that nice model of App shell and then load the content in we definitely do encourage you to Think about the app shell model Render the content with it and then start to kind of tactically replace that like once you know that you're inside The browser you can do a bunch of different things with the service worker You can fetch Jason data endpoints and kind of have them cashed and pulled through or you can just keep doing kind of full on page Request server rendering push it out and then kind of pass out the content and load load it There's lots of different models And I think this kind of progressive rendering approach at least anyway And the flexibility that you get with service workers helps So the thing I do want to say is like app shell is a model that we definitely know works Like it's been used for a long long time already We know it works well But there are many different tactics and strategies that you would use and I definitely encourage you to look at jake Jake archival service worker cookbook because I stole a whole bunch of his code to get my blog working Like my blog is definitely not an application, but I want that resilience from a service worker I want it to be available whenever the user goes back to it But more importantly if the user goes to any other page inside my site or refresh the page is available instantly It's not an application. It's a content delivery system In this point for me and I just chose basically a stale while revalidating method for actually kind of Fetching my content So the request comes in I'll pull the dates back from the cache always but always then go At the same time go fetch the latest content and then subsequent requests will then refresh like refresh When user refreshes the page with subsequent requests that'll load my new content because like it's already been kind of cached That worked for me in a model like as a model for kind of making my site resilient and work offline And I definitely encourage you to have a look at the different models that you can have to build an experience where You know the service worker is there to enhance the experience rather than actually say we have to push everything to an app shell The other area and I know I went talked about this a little bit earlier on is kind of push notifications Now this this whole section is We can we can talk about a little bit as well It's kind of interesting because the push notifications api is incredibly powerful It's supported across a number of browsers, but it's not on like a like on a relatively large number of different Operating systems and like it's not on ios basically at the moment And that's another question that we get is like well, I want to do push notifications But it's not on these experiences like so what do I do? Well, you know the first natural thing you want to do is you just want to check the support right? You can easily check the service worker We you checked via a service worker to see whether you can support push notifications And then you can say well, we haven't got push We just won't do anything with it But like that's the problem right is that we're not going to do anything with it There are a number of different tactics that you can use at the time So actually say we can do and give the user more compelling experiences Even if they don't have push notifications, we can keep the user up to date with important information Now there isn't like a little analogy that we've got is that Like there's like the transport kind of eco like the transfer the transport structure that you'd have in kind of any major city There's a destination that you want to get to you start a desk your point a you want to get the destination You know point b There are many different ways that you can do that You can take the tube or the metro the overground railway system or bus or bike Lots of different ways to get there But the result is the same that you know you've got that destination I think that analogy works quite well for what we like we talk about in some of these experiences at least anyway Because like there are many different ways and tactics that you can actually start to integrate these integrate different experiences The biggest thing about push notifications, uh, and this is kind of like you probably saw this from From owens talk you want to be relevant timely and accurate The the three different main areas that you want to focus on the timely bit is important Right because it's not you don't want to you want to get in contact with your user But you don't want to get in contact with the user all the time basically It's not your primary mechanism of getting in contact with the user So you want to think about how you want to use notifications notifications normally are kind of most like most relevant when you have a timely based Kind of action that has to happen You send the request to the server the user gets it and then you want the user to action it pretty much straight away So there are a number of different I can't use this There are a number of different questions that you want to ask right many businesses like I give you've already got a business or a Site there are a number of different ways that you're actually starting to think like you're already in kind of contact with your users, right? You that's right is one of my ear words. I say right Great dead powerful. So every time you hear me saying that it's me trying to think about what I'm going to say next sometimes But you have a number of different ways of actually kind of contacting your user Well, you know, you might already have their email address and you might already have like have a regular communication outbound communication with them You might already have their phone number, right? So if you have their phone number like if you have to send important relevant information You might want to send an sms system and like an sms to them And like you have other different ways via twitter and facebook I don't think those have ever really taken off in terms of private direct communication It might change when you know the the messenger ecosystem and messenger bots kind of come out a little bit more But the important thing that you have to make is like push notifications aren't the answer to everything And it doesn't matter if they're not supported in every single browser if they're supported It's great You can do really cool things with it in terms of like hey timely information You can send it to them get into action it But at the same time you can do other nice things as well So the first one is like native notifications Like like everyone knows that native notifications drive re-engagement and uses back into their experience And it's normally targeted through a single device at the same time Which is great because at most like especially in a major markets Most people are focusing on their phones at the time The current moment Now there are a number of different things that you can do where you can have contextual actions The important thing here for the native is like after that your After your site is or your application is on the user system Like having notifications is incredibly low friction and that's why we see huge amounts of re-engagement So if they already have the native app installed you might not want to actually send them push notifications But more importantly many people have email outbound proactive email communication with their users And one of the things that we see is that we don't necessarily use email in the way that we think we could use it So like you have Different way like you know who the user is like is an example Right, so you're sending an email to an already signed in user Who has already been using your system because of some important action that has happened on their site Like you know the context of when what you've sent to the user so that you can use that context in subsequent web requests We know that when a user like email is a massive driver of web traffic, you know, especially on mobile So when the user clicks on that email like you can do things like send them into the important kind of area of your site It's a really nice way of like engaging with your user Where in the past you might have used push notifications to say hey this action is really important go back into your account Use this information like because we know who you are to actually then go and complete the action Like email is still just as valuable and probably more valuable than notifications to some extent And then things like sms and like I don't think social is the right one to focus on at the moment But things like sms as well Like you can send push like they are nearly real-time push notifications They can get through to nearly any device irrespective of whether like of kind of complete network connectivity Now I think this is really important because you can embed links in there and then you can get the user to go out So if you're targeting a whole bunch of ios users who don't have things like push notifications But you know who they are and you know their phone number Then you know things like push notifications Oh, so sms are really good ways to keep engaging with your users And I know people say an sms is dying and it kind of is starting to get replaced for a lot of message apps But these type of experiences are great And then finally once you get the experience I want once you get the ability to do those ap like uh, sorry once you get the ability to Make notes make calls or sorry Refresh it once you get the ability to send notifications because you know that the device supports the ability to do it Then you need to make a decision at that point about how you treat your users Like if if you're kind of already sending the messages via sms Do you replace that experience and you have to be really careful because you don't want to bombard all your users Now re-engagement is one bit from push notifications The other bit is the the other area of re-engagement is and this is one of the really powerful areas What progressive web apps is that you have the user being able to install your experience on the home screen And when that experience is on the home screen They expect a certain number of things to happen from their side of things They expect it to be always be available and instant loading like once you're on the user's home screen You're kind of permanently on their real estate. So you have to provide the best experience And that's why I'm going to talk about the install phase at the moment Like this install step is one of those areas where We've had things like add to home screen for a long time, but it's not Worked as well as we thought so like I think in 1997 or maybe it was safari 3 at the time iOS brought us the ability to add our experiences to the home screen and steve jobs at the time said Hey, like this is the way that we think you should be building applications and experiences for our phone That you should go off and use the web platform to be able to deliver this We could make it work offline we can make it installable like the whole bunch of the things we we know history played out a little bit differently But fundamentally we've always had this ability on iOS at least to be able to get an experience onto the user's home screen And on android it was incredibly hard right like android hated the web it seems at the time They're trying to get experiences onto the home screen was nearly impossible We made it a little bit better in chrome Like there was only like seven steps rather than 12 steps to get something on the home screen But like it was still a bad experience right and that was until we started to kind of like change the whole model And like where we are now with progressive web applications and a whole bunch of other stuff Like that's like it's it's everything started to change But the really interesting thing for me anywhere in this space is that everything was controlled by meta tags There was information inside your page that would allow the browse to say hey This is how we think this is should this experience should like look and operate on the user's device um So the good thing once you could get the experience onto the home screen like you could say hey I want my application to be kind of like a full screen application Via one simple meta tag and then when the user kind of press the button It would go into the home screen you could choose whether you wanted to be a full screen experience Like a native application or like a browser experience right but the problem was it was not standardized And it was on every single page You had to kind of litter your whole site up with a whole bunch of meta tags just to get things working Even worse it was completely broken right like the whole space around this is like When you have an application or a site like you like an application You always launch into one specific point into the application like the entry point into your experience Add to home screen was bookmark this page and store it in the home screen So if you weren't on already on the home mix like the entry point into your application Like you would go into like a leaf page like imagine adding google plus I mean imagine adding google plus or anyone's home screen, but like Like imagine you're on like like one of my pages inside of google plus and you add that to home screen You don't want to keep going back to my content although i'd like it right because i write great stuff I'd like you to be able to kind of go to the entry point of google plus Add to home screen with the meta tags. You would never give you that you could never get back to the home screen It was a really hard way to manage things and then it was even broken even further from that Like if you didn't navigation inside the window rather than say hey I'm going to replace the current page with the new content that's behind this other url That is part of my application It would just go okay It's going to open a new window and the new tab it completely break you out there overall experience Um, so to kind of recognize that the other day I actually wrote it was like what can I write for this talk? And I wrote a spell on mistake as well it fixes Oh my god, that's terrible Uh, basically you have the ability to actually fix the way that ios works It means that you have to emulate a number of different things and introduce a new meta tag Called microsoft it's a microsoft meta tag ms application start url But fundamentally this polyfill essentially will say hey We know that you've got the all these meta tags in place But we want to fix the ios experience We want to make it so that it matches like opera's experience androids experience Chrome's experiences firefox experiences I've actually getting onto the home screen So it does a number of things like click jack or hide or it does click jack in so that it says Hey, we know that you're still in the experience like refresh the page content rather than redirecting you out One of the interesting things is that It's really hard to manage state on ios and this this kind of should get around it But the really great thing is until kind of ios starts supporting things like manifest then Like this is a nice model and there are a number of other people starting to think about how you can actually make The ios at the home screen experience a lot better and that's if you want compatibility right at the moment You might not actually want to say You know what ios or whatever browser it is doesn't support it and that's fine if you don't want to do it The modern way is to use the manifest and like jake talked about the manifest a little bit earlier The manifest is a way of describing what to launch how to launch it and how it should appear on the user system And when you meet all the criteria and i'm going to talk briefly about the criteria You get this let's pop up that says hey add to home screen add to home screen And you get this nice kind of installed full screen experience if you want it Now there are a number of things that we do and the whole number of different checks that we have to make sure that you don't Kind of get the prompt when you when you don't really it's not deserve it But when you you're not actually offering a great experience One of the things that we want to try and do is we want to make sure that if you launch from the home screen You get an online experience all the time like you never get the offline of source Which is why we force like we enforce the kind of service worker restriction And we need the manifest because if you're launching again into that non home screen experience Then you're not giving the users a great kind of like app like experiences Especially when it's launched from the home screen The big question is can we bring ios in line with the manifest And its own use of metatags and I think we can but I will say maximally Maximiliano furman he's done a really great blog post in the past couple of days About all the different things that you have to try and do to actually say we want to have a compatible experience There's a number of issues that you have with icons And differences between the two platforms, but there are ways to work around it But the interesting thing at least anyway is that we have all the information that we need There's a secret metatag apple mobile web app name Which kind of maps to the the manifest attributes of name and short name Obviously, we get all the icons and those type of things which is really good It's kind of nice We can say that we want to launch in standalone mode, right? We want it to launch like a native application if we don't have Apple mobile web app capable then it launches like a normal browser tab Which is another option in the display manifest We don't have complete full screen, but we have some good compatibility with the two parts of the platform And we kind of have some emulation around the theme color, right? You can say I want to get rid of the top bar by saying black translucent That's pretty nice. There are other bits which are broken like the splash screen. It doesn't work anymore Which is a bit unfortunate, but it's it was still kind of not too far off now I think that's kind of interesting But the thing that I don't want people to have to do is have to then Like work out exactly which metatags that you need to install now There are a number of different polyfills. This is the one that I've written There are a number of different ones coming through as well Where if you can basically know that you've got a web app manifest on the page You drop a small piece of javascript in and then it goes and works out what the exact best tags are to use And then it'll make sure that you offer the best kind of compatible Add to home screen experience. I think it works pretty well. This is just a demo that I've written There are another good couple of ones out there And finally and I know I'm over time at the moment is the offline section Luckily, I think Jake has covered most of the offline story that you need to kind of think about But there was one thing again is that when we talk to a lot of developers out there is like well The servers work on i work on ios and right now the answer is no and like I said before it's the wrong question to ask Right, we don't need to build experiences that absolutely rely on service worker But the thing is people still want offline as one of their core features So the first thing that they do and ask is Well, I can use apcache right like so who's built a site with apcache 20 people How was the experience? Was it a good experience? No Okay, cool I mean, there are a number of different issues with apcache I like if you were building an experience there with a like a new progressive web app Say you went away and I'm going to build a progressive web app and I need to make it work offline We still need to come up with the exact, you know case business case Why you should kind of skip the apcache section But I do think you should bypass apcache the interesting thing if you've already got a site that uses apcache and Matt's going to talk about it later You can like add a service worker in and then there will be no conflict between the two because the service worker will take over So there's a nice migration path off apcache But if you're thinking about building the experience, I would just say bypass apcache completely There's a number of different problems that it has It's hard to do good server rendering with it And then if you update you're kind of manifest and you've been to 100 different URLs Which you've kind of all kind of had cached and it like this atomic update system is going to It basically re requests every single URL. It's a bit of a nightmare to manage a lot of different problems So I would just bypass it completely. It's a decision that you have to make But I think you should do it The one thing I would say is that there are a number of different strategies that you can take You can build for resilience in the client first If you're offline and someone has a window open quite frequently They don't bother to reload it because they know there's an issue The worst thing that you can do is break the experience, right? So build for resilience inside the client handle an xhr network failures cache data locally And if you look at the firebase platform And a bunch of other ones as well They do that like they know that they can cache data locally to synchronize when there's some data connection Back in when there's some data connection that comes back And finally you can start to then layer in things like service workers and extra enhancement to give you that resilience as you need So that's my thought is I just kind of stay away from apcache at least anyway Now there are a number of different like one of the pieces of criticism that we've had is that there are a number of different Issues in terms of information and knowledge Sam Thoregood on my team has launched this always be progressive where we're trying to start to think about Hey, we have all these different pieces of technology. How can we actually get you to think about building systems which are Progressive or at least if you want to kind of polythink polyfill things through as well So we have this nice little resource We're going to keep updating it to actually give you the guidance that you need to actually build these experiences If you fundamentally require some of these features, which is quite nice One of the other things I would say is that we'd have a nice That was my killer slide. I've gone too far too far with it Is we have and we're starting to build out and flesh out our developer portal as well So on developers google.com slash web Like we want to make sure that you have all the tools that you need to build fast secure and performant experiences With a great user experience Like they're the fundamental core tenants of what we want to try and get from the web at the moment And then if you kind of start to knit all those things together We're hoping that like a good progressive web application experience that comes out the back of that as well And that's when you're kind of building in service work on this extra resilience Now the thing that I will say is that I know and every single business that we speak to They can't always completely redo their entire site And I think a lot of this is about being pragmatic You can integrate all these different components in like if you want push notifications Like that's a great thing to add into anyone's anyone's individual experience You don't have to base your entire experience off the back of that and you can provide value to A large subset of your users rather than have to think about providing the same experience to all of them But there are a number of different strategies that you can take and I think that's a really powerful way to think about it Is like you start with a good base getting the content out and delivered to the user And then think about how you can kind of enhance that experience as you go along And that was me and I know I've run out of time. So thank you very much Up next you know what I've been telling everyone you've got to introduce the next speaker Right, it's the thing that you have to do because we don't have like jaco or paul doing like the nice compare thing And I was about to walk off stage, but I'd like to introduce Matt scales I was going to talk about the tools that you can use to build these Hey everyone Okay, so hi as paul was meant to say i'm matt scales On the on google's web developer relations team And i'm here to talk to you about tools and libraries for building progressive web apps Now part of what makes progressive web apps possible now is a shift in the way that the platform itself is being developed So on the old web we got custom designed high-level features for achieving the things that w3c thought web developers wanted to do So developers want images. So we'll give them an image tag developers want to lay things out on tables So we'll have a table tag Now the new idea is this thing called the extensible web and it says that rather than building simple apis for specific things We should be getting low-level deep powerful apis that enable a much broader range of things So rather than a tag for images, let's have a tag for arbitrary graphics Rather than a tag for tables. Let's have css properties that let thing let us lay things out however we want And this is great and allows us to upgrade our pages into apps But there's this gap between the level the platform gives us and the level we'd like to work at And we can fill that gap with libraries Now in the extensible web the community is given the responsibility of providing Simple easy to use libraries to handle the specific things that developers actually want to do And this is great because it's much easier to iterate in the api of a library than it is to iterate the web platform itself And this means that even as we speak someone is out there solving hard problems so that you don't have to So today i'm going to talk about libraries and tools for service workers I'm going to talk about the new web app features in chrome dev tools And i'm also going to try and answer the question of is the thing that i built actually a progressive web app? And is there anything else i need to do? So obviously the most important new technology as far as progressive web apps concerned is service workers So just quick recap service worker is a background thread for your application that opens up new features like offline push messaging and background data sync And for the offline use case it acts as a network proxy right in the client So whenever your page requests a resource The service worker gets a chance to respond To that request it gets a chance to get in the way and do whatever it wants And also just to remind you this isn't about working offline necessarily it's about Because even being online can be a terrible experience if you have li-fi or if you just have a slow connection Maybe you're connecting to hotel wi-fi or maybe you're somewhere where data costs a lot of money What you really want is network independence You want the experience of your app to be great regardless of the network situation But in order to achieve that Complex apps are going to require pretty complex service workers There'll be a lot of code and there's a lot of new apis to learn So we're going to help with that with a library we built called service worker toolbox or s2v toolbox And this was created by by our team at google to abstract away the common patterns for connectivity independence So here's a pretty simple Example of a service worker written with service worker toolbox You import the script from wherever Wherever it's residing And that gives you a global object called toolbox that exposes the api Here we call toolbox.precache And we pass in a list of resources this says that when our service worker is installed Go ahead Fetch all these things stick them in a cache so that we know that whenever our service worker is running It has access to these resources and you use this for your app shell and perhaps any Really common small resources for it throughout your your app and then we use a toolbox.router to say to match Different behavior to different parts of our application So here we're going to set a default we're going to say that the default behavior for any route will be something called toolbox.fastest Which we'll get to in a moment And then here you can see just an example of a more specific route This is based on express js routing For anyone who's built a server in node toolbox.router.get And then there's a url pattern slash api slash followed by anything and then the behavior here will be toolbox.network first Uh, so let's talk about toolbox.fastest toolbox.network.network first So these methods are what we call strategies these are So typically you need to think pretty carefully about exactly what behavior what you want for different parts of your application So you need to choose a different strategy for each route or You know potentially Unless the toolbox comes with five built-in strategies Fastest network first cache first cache only and network only So let's go over what they are So with the fastest strategy request comes in And we race the network and the cache whichever one is going to come back first is going to return to the page So in this example the cache is going to come back first, which is probably pretty obvious Though obviously it will go to the the network will win if it wasn't in the cache in the first place Um, if and when the network ever does succeed updates the cache so the next time this happens Even if it goes to the cache, it's a slightly fresher version of the resource So this is good for stuff that you want to be fast, but is allowed to be maybe a little bit out of date Uh and just as a note because this one always uses the network if your goal is to save your user's data plan This is obviously not necessarily the best thing to do for all your resources Network first Request comes in First of all, we try the network and we give that time to succeed or fail And only if it fails do we then go to the cache? Um and return that to the page now if the network request does succeed that updates the cache Even though we're not coming from the cache this time around so that the next time we try it when we're offline or whether the network times out We get a more up-to-date cached version And so you can imagine like fastest and network first are good for slightly different things So if you imagine a twitter client Then when you first load your application You're most your highest priority is getting stuff on screen so the user has your application Uh, so perhaps you use fastest to load the latest tweets because it's better to show old tweets than show no tweets Whereas when the user does a pull to refresh that's a pretty strong signal They actually want the freshest data so go to the network and only go from the cache If you can't use the network There's an important extra option to this one because it turns out that on mobile devices that network timeout can be two minutes So if you have li-fi and your network your device is absolutely convinced it has a connection But it doesn't really then you can uh have some sort of action and it can be two minutes before you even decide to try the cache So we added an option for the network first Uh strategy that lets you say Give a more reasonable timeout. So here we're saying after five seconds I don't care about what's on the network. I'd rather show something Uh cache first um go to the cache only if it's not there. Do we go to the network? Sort of the opposite of network first Um again the network will update the cache But the one of the important things to realize here is that once that network request has succeeded once It will be in the cache and so the cache will be consulted every time and it will never be updated Um, so this is still pretty good for some cases if you have versioned URLs If you have some resource where the url will change whenever the content changes This will work fine for that And this might be for things that are uh That you want to be able to cache the things that don't change but aren't part of your application shell So the example I've been using is uh blog posts You don't want to download 10 years with a blog post the very first time someone comes to your blog But if they have been to your site and downloaded a few posts, it's reasonable to uh keep them around Cache only so this is uh go to the cache and if it doesn't if it's not in the cache fail Um, this is good for the stuff that you pre-cached because you know it's there And then network only go to the network and if it fails it fails This is what you got without service worker And the only real reason to use this is that if you've overridden the default with something like toolbox.fastest This allows you to go back to the original behavior just for one route And if those don't do everything you need to do you can also define your own strategies So here we have a uh A function i've created called fallbackish image. So What this does is it takes a request And it will try and fetch that request from the network And if it fails it will respond from the cache, but it won't try and respond with that A cache of that specific request it will always respond with this fallback dot jpeg So you can use this for example if you have hundreds of profile images on a page somewhere Perhaps it's not actually that important to have that in your offline experience. You don't want to fill the user's device with those images Um, so you have a single image that uses a fallback instead And to make this useful you have to make sure you've precached the fallback image And then set up a route that actually uses it. Uh, so it's just the same as before except instead of using toolbox dot whatever We've used a fallback image And finally on toolbox, uh, you you can get fine control of the cache as well So by default when you call precache or when you use, uh, cache only or fastest or whatever The cache that it uses is shared Over everything in your whole application. It's a default cache that sdo toolbox creates for you And you can on an ad hoc basis say for this route I want to use a different cache for whatever reason so here We've passed in an option called cache and we've set a name So that it will be a different named cache that it uses and now we can set options on that cache So that this cache can only have up to 500 entries And entries can only be in there for up to five days And sdo toolbox will go in and clean up periodically Now something we've kind of glossed over there with sdo toolbox is that that precaching step is actually trickier than it looks there There are a few problems One is that in order to get a new install event You need to change the service worker script not something that service worker script imports But the actual original service worker script so you have to remember to actually update that every time you update Every time you do a release that changes some of the resources Even if the service worker itself the logic doesn't need to change Another problem is that when that uh when the install event happens sdo toolbox will take all those resources And just download them all again even if none of them have actually changed And then you also have to maintain a list of which resources need to be precached It'd be quite easy to miss something out of that array And then find that in your next release your offline experience is slightly broken because a file didn't make it into that So we created a tool to help with this called sdo precache Now what this does is it takes a few simple options and it writes a service worker for you It's something you can stick in your build step You tell it which files you want to cache It will take a hash of each file along with the file name and write those directly into the service worker So if any of your resources change the hash will change the service worker itself will change and you'll get a new install It also means that when that install event fires The service worker has a list of every resource with its hash So it can compare it to what it already has and only download things that have changed or are new Now this can be used as a command line tool uh installable via node Um, and then you call s to run the sdo precache And here's the the simplest um option setup you say where the root of your application is and it will just precache everything in that folder You can also use it as a node module so you require an sdo precache you call precache dot write You say which service worker file you want to write and then you can pass in some options So here we've said we're going to use this glob pattern To say which static files we actually want to cache And if you're wondering whether that means that we're now lost the ability to do that dynamic Caching that sdo toolbox gave us there are actually two ways to bring it back The first is with this runtime caching option You pass in an array of objects which Specify those routing rules that you had in sdo toolbox So you have the url pattern and then you have which which strategy to use And you can even pass in options. So we have the network timeout seconds option Um, and this is great for most simple cases, particularly if you're only using the built-in strategies And if you want to do something a bit more fancy if you want a bit more control You can just say that you want to import a service worker script that you've written yourself So you could let sdo precache handle all of the static resources for your app shell And then do the dynamic caching using a service worker toolbox script that you wrote yourself And it will inline that into your service worker And this also allows you to add in things like push notifications and background sync into sdo precaches service worker as well Now service worker doesn't work everywhere as paul said and serve and appcache does So Just to reiterate should i use appcache and a new project? No, because it's terrible and doesn't do what you want and the more you can talk your application to try and fit appcache The more you find that it's still not going to work and you have to contour it even more And it has security problems and is just it's generally bad Can't stress that enough However, if you've already got an appcache for your application We have a tool that will help you transition. So sw appcache behavior is this little library we've created What it does is you you import the library Into a service worker script This would be could be your entire service worker script if you wanted You create a fetch handler and you just say in that fetch handler I want to respond with whatever the legacy appcache behavior would be Essentially What this will do is it will get your appcache manifest Pause it work out what the correct thing to do for an appcache would be and then do that But it also allows you to get around some of the security issues and some of the things like Never getting into a state where the appcache is never updated service worker won't actually allow you to do that Now sw appcache behavior is just one of a set of things that we're hoping there were that were Releasing as part of our sw helpers repo As an example of something else we're doing there's offline analytics So this was written for last year's google.io website and Was used again this year What this does is you set up a route for any analytics requests that uses that The strategy function that's provided by the library And whenever one of those analytics requests fails It will stash it away somewhere queue it up And then when the user comes back online again, it will replay it and add a parameter so that it Correctly attributes the event to the correct the time actually happened And we're hoping to add many more things to this repo over the next coming months So that was service worker. What are the tools? What are the things that can we help with? So no talk about developer tools is going to be complete without talking about chromes developer tools And there are some great new progressive web app features coming In the next release So almost all of this is only available from chrome 52, which is currently in beta But it's moving towards stable in a few weeks So first up the application panel has been renamed Sorry, the resource panel has been renamed to application to better reflect that this is now where you go to look at things to do with a web app This first panel is It allows you to debug your manifest So it lists what the browser has as detected as the name of the application what icons to use what theme color to use What the start URL is things like that and also gives you this add to home screen Button that allows you to trigger the on before install prompt So you can test code to do with delaying the install prompt Service worker panel has been redesigned To hopefully be a lot clearer The all of the service workers for the current application will be shown in a list Which I should probably have got a screenshot of But it will be less confusing about which one's active and what you can actually do to each of those service workers It has all of the same features that it did before but it has some extra ones too So at the top here, there are these three check boxes Offline is a shortcut to the same thing in the network panel that says you want the network condition to be offline So that allows great for testing the offline Behavior of your application and to make sure that your service worker is working correctly Update on reload means that whenever the The origin is refreshed it will check for a new service worker and potentially do an install if it's changed Do the whole service worker install dance Regardless of how long it has been since it last checked And bypass for network says that the service worker should load The install and activate events should happen It should still be called for push and background sync, but the fetch event should never be fired Whenever any request comes in it should not it should not try the service worker to resolve it And this is good if you've got your save and refresh workflow going on For a resource that would be cached for a long time by service worker allows you to just To go back to your normal workflow in development the clear storage panel So as a consumer of chrome, you've probably seen the feature of clear private browsing data No, that was you to get rid of cookies and things like that For a period of time you say I want to get rid of cookie private browsing data from a day ago Last week or forever was this is a bit more developer oriented This is for the current origin only I would like to clear these things and the options that it gives you are things like service worker cash Index db and things like that that a developer might be more interested in And I also want to call out a feature that's actually been there a while but people don't necessarily know about Which is down here is this cache storage viewer That lets you see what things are actually in the The cache api cache that you're using with your service worker So this can help you debug issues with precaching or When a request is failing for something you think should be in the cache So finally I was going to talk about the The question of is my thing actually a progressive web app Now I don't think we can really answer that question because it's a bit of an open question But we can try and get a bit further there One of the things that we call here is if we had a button we could click that would just like Tell me is is it a progressive web app? Am I there yet? So the chrome team built one and we called it lighthouse This is both a chrome extension and a node-based command line tool Which has a whole bunch of different tests in it That it runs on your site and gives you advice on things that you might be missing And it also has this very cool professional looking logo So as a chrome extension you load up your page You click the button And then it will reload the page a few times connect with the The remote debugging protocol Gather a whole bunch of metrics and then spit out this report It'll give you a score Which you Which will give you a vague idea of what it thinks of your your application And it will tell you anywhere that it thinks that you might have missed something And also has this best practices section that is things that it's not going to score you on Maybe you don't actually need to do these things, but if you do you should check on them It just gives you a bit of a guide You can also run it as a command line tool Just for anyone who's thinking of typing in URLs they see on the screen air hona.com makes a noise Give this talk at io and about 30 seconds after this slide came up, so it was like From the audience So you run it on the command line and it will output By default the output pretty printed to the console But you can also output jason that you can pause yourself Or the same html that the extension gives you And it's also requireable as a node module So you can say Lighthouse and then the url and then that returns a promise which results with the jason that you would have got From the command line tool and obviously the cli and node module Ways are both good ways of adding lighthouse to your regular tests or continuous integration I'd like to draw attention to the big alpha in the corner here I just want to be clear that this is early stages. None of the rules are final I'm sure there's a lot of discussion to be had about what the rules say and whether they're good rules If you would like to contribute to that discussion or better yet contribute pull requests You can find us on github And I'd also like to point out that this currently only works in chrome 52 plus, which is currently in beta So to recap progressive web applications are made possible by the extensible web They're made practical by libraries and tools There are a whole bunch of service worker libraries out there from google and from others with more coming Chrome dev tools is awesome as always And lighthouse Attempts to tell you when you're done. It's probably a bit too definite in this slide Okay, thank you very much. I hope that was useful And now jeff is going to come up Show you how to use some of these tools to turn your existing web app into a progressive web app. Thank you Everybody just bear with me a second as I switch laptops We're switched and there we are so thanks matt and Hey folks, my name is jeff posnick and i'm a member of the web developer relations team at google So As you've heard um you can go on a journey So everybody who's watching this either in person or watching via the live stream We care about building truly progressive web apps And the thing is many of us have put time and effort into our current projects So building a progressive web app doesn't mean starting from scratch there as developers what we need is a device And about like areas from improvement and different like tactical fixes That we could apply to our existing code base And in that spirit let's set sail on a journey together And what we're going to do is little by little we're going to transition an existing single page web app into a progressive web app All right, so this is our starting point We've got this web app Something I put together it uses the iFixit API to access repair guides. Okay pretty straightforward Um the initial implementation Is a single page web app that uses client side rendering Okay, and while this project uses react The concepts we're going to talk about really apply to any framework or vanilla javascript. It just so happens I was using react for this project So, uh, let's take a quick look at the initial experience of running this in let's say firefox Let me just confirm. I have my static dev server running right now Go up here Put open Okay, see some repair guides Click around a bit You know, it's it's all doing some client side rendering You know, maybe not the fastest in the world, but it works you could view your content Um, let's take a look at something else. Let's take a look at what the experience is in Safari and this happens to be safari with javascript disabled Some users have javascript disabled some users aren't browsers that don't support javascript. Um, You know, this this is an issue And this is what they say for a single page web app not great Um, and you know, again, this is a function of being client side rendered and relying on javascript So Let's see We could do now that we have a feel for what the app does. Let's try to figure out how we can improve on the current implementation And what we're going to do is use that tool that Matt just talked about called lighthouse to automate a whole suite of diagnostic tests covering areas important for progressive web apps So what we're doing right now at our starting point is kind of running into establish a baseline And it's going to give us an idea of what's working well and areas that we can improve So we're going to start the test via a chrome extension in this case But you know as mentioned, there's also this command line tool that has the same functionality if you prefer that And the tests are actually really cool. They use the chrome debugging protocol And they simulate a host of different real world conditions to see how your web app actually responds So let me pull that up Do this in chrome canary I am kind of old school and just like doing everything in incognito windows whenever i'm working with anything so Let's get our current version loaded The lighthouse is ready to go over here and we could generate a report and you can actually see it's Doing its Job it's using like the dev tools ability to simulate this viewport widths of different things and all sorts of other stuff and We can get our scores. Hopefully this is big enough for folks to read You know and we're at 30 out of 100 Okay, um, you know, it's giving us some nos here and it's giving us some things that might be areas where we can improve Service workers not there Meaningful pain times not great. You know, we have this missing Content when scripts are not available. We have a bunch of other things that we could improve So, you know, the main thing is that we have a really good starting point. We know What we need to focus on Before we really dive into the results and interpreting them. Uh, I just want to make this point then Lighthouse will help us identify areas improvement, but it's not our end destination You know, it's not the ultimate source of truth as to whether something is or is not a progressive web app Ultimately, you know, what matters is the experience that your web app provides to your entire user community So in addition to running the lighthouse to test what we're going to do Is try web apps across a wide range of browsers operating systems and different network conditions And you know, I recommend that everybody does that as part of their normal testing and release process Don't just rely on lighthouse Sorry, so we have those results here are opportunities for improvement Um, you know, our speed scores could be better and there's no counterfeit on our page when javascript is disabled And what we can do for both of those is introduce server side rendering Uh, second, it looks like our web app won't respond to it offline. So no surprise. We could add in a service worker And you know, finally, there's missing metadata about our application as per the lighthouse report And that could all be addressed by adding in a web app manifest And also adding in thoughtfully chosen meta tags to accompany that So we've got three concrete steps we can take and we're going to walk through them each now Using lighthouse and cross browser testing to measure how effective our work is as we go All right, so let's first look into server side rendering what that's what that's all about Um, you know, what it's going to mean is that our browser gets a fully populated functional page As part of the initial a should be response rather than relying on multiple requests to get content on the screen And equally important it means that our web app will work in browsers in which javascript is unsupported or just switched off entirely So not every web app is going to be able to run with full fidelity with javascript disabled But you know in our case we should be fine It's a fairly straightforward to add in server side rendering to our react application using a universal javascript And that means that we get to share a lot of code between the client and the server. So not too much work Um, and we're going to use express which is a node based web server and it plays really nicely with the react router So while we're talking about react now again Other frameworks like angular and ember have their own solutions for server render javascript. So definitely check those out as well If you happen to use those All right, so let's take a look at the actual changes that we're going to make in order to implement that So I happen to have a handy Um github diff open. So this is the real code and make this a little bit bigger So folks you'd say and just scrolling up a bit um Not too much that it should surprise most folks have done this sort of thing before You know we're adding in a serve task that's going to bring up our server and You scroll down a little bit this stuff is important, but we can't really focus on it right now what i'm going to scroll down to is um The part that actually implements like our routing and figuring out what to return to the client And this is very lightly adapted based on kind of like the react router canonical example so You know what we're going to do is just take our existing routes So we're already using on the client side and we're going to match against those with the incoming request URL on the server We have a few things to handle different error conditions and um What we're then going to do is just make the requests the ifixit api From the server It's going to figure out what data we need and the server is going to make those requests and Provide it to the client immediately without the client having to get anything else And we have a little bit of code down here once all the data fetching is complete. We just have our initial Uh component that we're going to then kind of render to string using this react dom server helper method and we are going to also take all that initial state that we have on the server and Turn it into something that's serialized that we can then deserialize on the client and kind of just have a nice Experience where the client takes over once that initial payload comes down And finally just a pretty straightforward um index uh template that just has placeholders for like a state and for the react HTML and that's the right thing All right, so that is what's changed in the step And All right, so what we're going to actually now do is run that new code And confirm make sure that our changes have the effect that we wanted in both in lighthouse and in actual browsers All right, so let me just switch back over here And It's not really live coding, but it's kind of close. So we're going to actually run our build process again Um get to see that'll go and our new server is going to start up. Um and this time We're going to be on ports 8080 Once that's done So, okay, let me just start this up again and we'll test again firefox Things look good. You know, it behaves the way we want it to behave That's great. We didn't break anything at least But let's actually go So that safari that has uh javascript disabled still and see what the experience is like there And we actually have content this time. So that's great. Um, it's a net win for those users We click around a little bit And see, you know, it's not the same smooth transitions and other things you get if you did have javascript enabled But you know, we're building an application to view this content and our users Subset of our user population can now view it. So, you know, we should definitely consider that win All right, and let's also go And rerun lighthouse should just Close this down start this up again Generate another report and you know, hopefully we'll actually be able to You know assign a number and and measure some of the impacts that that chain had change had and see in our lighthouse results Okay, so, you know, we're at 30 out of 100 we're up to 44 out of 100 is progress um And you know, most importantly, we see the changes where we kind of expected to like we have our Page contains some content when scripts are not available is now a yes So that's a win. Um, you know, we actually also see an improvement in The performance. It's actually, you know, the page load performance as fast test is actually pretty significantly better um, you know, we were going from 2.4 seconds down to you know 647 milliseconds for the first meaningful pain So, you know service side rendering was a win for that. So we're in the right direction That all is cool All right. So next up Let's try adding a service worker to address some of the lighthouse feedback about speed and offline functionality So first important reminder I've heard a lot today We need to treat service worker as a progressive enhancement Not all browsers support service workers yet And you know, we want to be careful that we don't do anything to degrade the experience on browsers that don't support it And it's also important to keep in mind even in browsers that do support service workers The very first time your users visit your page the service worker won't be installed yet So having a good experience, you know for that case is super important All right with that out of the way What we're going to do is use that app shell plus dynamic content model that's been Mentioned a few times and you know, this is something that happens to work really well with single page Applications we're starting with a single page application. It's kind of natural to adopt it in this particular case um, and what it's going to do is take the shell which is all the local HTML javascript and css that we need to render kind of like the outline of our application And make sure that it gets loaded directly from the cache whenever possible And completely bypassing the network And taking the network out of the critical path for getting things on the screen is the surest way to get consistent fast performance So that's super important And what we're next going to do is take a runtime caching strategy to handle the requests for our dynamic Excuse me dynamic content. Um, you know in our case this is coming from the iFixit API So it's going to populate that after the shell is loaded And under the hood not surprisingly we're going to use a tool That match is talked about called swp cache and it's going to generate our service worker For us and it's going to implement all the caching strategies too. So You know not too much code that we have to write in in this particular case But what we really do have to do is understand what our network traffic is and understand You know what we're actually requesting And um, you know, this is important because we have to actually set up those routes and can't just put in arbitrary URLs for that you need to know what's going on Um, you know, I always turn to the dev tools in chrome to do this. There are other Browsers that have fantastic dev tools as well But let's just go to chrome for a second now And we're going to do this again in a fresh incognito window And we open up dev tools here Let me go a little bit bigger Go to network Let's just see what happens You know, I do this all the time. This is just part of what when i'm approaching Just a new application new service worker. You really need to understand What's going on in your network because you are replacing this basically this this is crucial You have to make peace with this so you can see Some of the requests going on, you know, this is basically like our app shell stuff. This is our local css This is our local html and then starts making requests to you know in this case It's stuff from cloud front dot net and the images that are being displayed on the screen And lots of images we load in some javascript and things like that and let's click around a little bit It ends up happening not surprisingly is it makes a request the iFix API on the client this time So, you know that the initial iFix API request was made on the server, but now it's the client's taking over And it's just making requests to pull in that information About that guide So, you know, that's being pulled in more images things like that Okay, kind of have a feel for what's going on now So let's take a look at how we actually implemented the service worker in this particular case So, all right, I think This is the appropriative All right, so this is what's changed. We're pulling in You know our swp free cache library and we added a task to our build process, you know, in this particular case We're using gulp. So, you know, we're using the syntax for that But there are other ways of using sw free cache folks who really like, you know npm scripts You could put this all as a command line or read and config the adjacent You know, we're we're pretty agnostic when it comes to that and Some boilerplate, but it's kind of the interesting bits for what we're doing over here So first of all static file globs This is a bunch of patterns that match all the local static files And these are the things that kind of get requested as part of our app shell So we just need to tell sw free cache where to look and you know, if we end up adding in anything If you make any changes to our javascript if we add in extra images later on It'll just automatically be picked up as part of the build process, which is great Less for us to worry about Next, we have this dynamic url to dependencies section and this is This unfortunately a mystery to some folks. Um, it definitely could do a better job of explaining it So here's my attempt to do a better job to explaining it Um, you can You can pretty easily figure out when something that's local on disk has changed You know, if you have an image if you have css file, that's in a local directory You could just like calculate the hash it didn't figure out it's changed What we're doing is, um, you know, taking these dynamic urls These are not things that correspond to like actual html files on disk And one example of that in this case is slash shell, which is a url We're using for our app shell And you know, this is effectively server rendered. It's kind of A composite of a bunch of different things. There's some javascript. There's some css There's the actual you know underlying template for The overall structure and all of those things go into uniquely Determining what the content is for slash shell So in order to make sure that we actually have a cache that's automatically kept up to date For slash shell we need to tell sw free cache take a look at all these local files if any of them change consider that this slash shell Cache content is basically invalidated and refatch it and make sure that we have the latest So, you know, again, if you're not doing stuff that has like server side rendering It's not as important. You can get away with not doing it, but it's actually a pretty good solution for this pretty common use case And very closely related to that is the next section. Um, this kind of implements A brute force service worker routing. Um, it's kind of like Trisometric trisomorphic javascript sort of because we have like the Server that has to know about routing we have the client that has to know about routing and we also have The service worker in this case that has to know about routing Because you know once you navigate to some Random url with your initial navigation like slash guide slash one two three four five or whatever You know, that's not a real url that the service worker knows about And we don't want to just panic and give up and pass on to the server We want to say hey actually whenever you see something like that Which is a url that you don't have explicitly in the cache I would like you to fall back to this cache content Of slash shell So it's basically doing real you know brute force routing We might improve this in the future and have a little bit more flexibility, but for now We're just gonna route everything to shell And finally, um as mentioned previously you can use sw toolbox strategies for dynamic Caching within your sw pre cache config. It just kind of saves having to maintain Things in two separate places. Um, and you know, we went through the process already of looking in the network Panel and dev tools and we figured out what our dynamic traffic is. You know, we have these I fixed api requests. That's what they look like And let's use the faster standard, which is basically stale while we validate For all those and for the images Let's do something a little different. We're going to use cache first His chances are an image with the same url at this remote server is not going to change. It should be safe At least for our case And we have the dedicated cache. We're using that max entries there. Um, this is super important You know, it's something you can't actually get just with The service worker primitives right now We had to build on top of those primitives and use like index db to keep track of all the entries In your service worker cache and then allow you to you know expire the ones Once you reach that limit And definitely think about it, you know folks don't have to use service worker toolbox And i have to use free cache. You could definitely do vanilla Service workers if you want, but please keep this in mind like if you are building something and you're just caching things as you go You really do need to think about your user's cache eventually filling up so And then we just have this default Over here of network for us. Let me have a little bit more Poor little play that we add in Task and finally, you know Kind of making sure that we're only attempting to register our service worker if there actually is service worker support So, okay, so that's what's changed And let's start up Modified version at step three now and as part of This process you actually see that like the service worker generation. So sw precache will log a bunch of Output telling you what it's caching and what like the expected size of the precache You know initial payload is so See that extra output over here And our server is running again All right, so We're going to just confirm that in chrome right now. You can remember see all this This was the previous version It's fetching stuff from the network It's again kind of close things out Start fresh And in this particular case Very first time Everything is still coming from the network and you know, this is because the service worker is not in place yet so that's expected and The next time though that I end up You know reloading the page for instance Do do do Don't think that dev tools is happy right now Boo Try closing this out All right, I think chrome canary crashed Which is one of the joys of demoing things in chrome canary Let's just start that up again Open the network panel Okay, and we see our initial Stuff coming from the network. We're going to you know reload And now we see what we expect so we actually see over here from service worker So this is how we could confirm just you know visually in in dev tools that things are behaving as they should Our app shell is coming from the service worker. You could actually see the best fastest strategy in practice over here where it's Pulling in an additional copy from the network in addition to returning it from the cache So, you know, you are making a network request, but most of the stuff is just coming directly from The service worker, which is great And let's see how Lighthouse feels about that So unfortunately kind of lost our previous reports, but I think we were at like 44 out of 100 and Hopefully we're a little bit higher now All right, so we moved up a bit we're up at 59 out of 100 so we are making progress in the right direction and You know again importantly the things that we expect to have changed actually did change confirming That you know, this is not all for knots. Um, we have a registered service worker. It responds when we're offline And you know that all is great also I try to just Tempting favorite crumb in area. I'm just going to do the offline over here I'm just I can do a navigation So worked. Okay, if you trust that that actually simulates things being offline So, okay, um, definitely making progress in the right direction All right, and finally let's address the missing application metadata So these are the options that allow you to control how your web app behaves When is added to a mobile home screen primarily that's Mainly what they're used for and we'll add the metadata in both the web app manifest format and whenever Possible whenever it makes sense you use equivalent meta tags with the goal of supporting a wide range of different browsers Um, don't just set this metadata indiscriminately though Really, you know give some thought about Each of the tags and just copy things that you saw an example Um, you know, some of them have really important meanings like, um, you know, whether you're going to end up behaving like a standalone Application that hides the browsers you are all bar. Maybe that's not appropriate for your particular case. That's fine You know as a developer you get to make that decision and you could do Um, what you think is best for your users that should be the ultimate goal All right, so let's take a look at what's different We have our wonderful icon that's been added in we have our manifest Um, I am specifically on the icon. This is a little interesting. I'm actually using this utm source equals home screen Parameters part of my start URL. So if you had google analytics running For your web application, you could actually keep track of where it's been launched from Um sw pre-cache actually Knows about these parameters and will not Cause you to have to cache like a version that has slash and the version that has slash utm source He was home screen. It'll take care of that for you, which is nice And you know in our case we're using display equals standalone And here we have some Related metadata, um, we're setting theme color setting apple touch icon and we're setting this apple mobile web app capable pound sign equals yes tag And again, not everybody needs to use this exact setting All right, so let's take a look after making those changes And see what effect they add We're going to run through the build process one last time And um, you know what i'm actually going to do First is fire up Um ios safari running in like the device emulator And i want to test what that experience is like Because you know we've added some metadata that's relevant to mobile safari Let's see if it's actually doing what we want I think i have it running over here You have local host 8080 We have our basic web app cool All right, let's see what happens when you try to add it to your home screen Add a home screen All right, i mean it picked up our icon Um, you know in this particular case, we're adding to home screen from the main page So it's going to use the main page as the url Paul came in earlier talked about some interesting ways of Kind of handling the case where a user might add to home screen while you're on one of the sub pages and redirecting to make sure that it actually always takes them back to the initial page When they do launch that shortcut, but for our particular case Pretty straightforward And click on add We go over here Scroll over, you know, we have our Web app saved over there Okay, that's what we want Let's take a look At again started fresh Incognito And let's take a look um This time at that if you do application panel This all looks good. We have our metadata. We can see that's porous We can see like the actual theme color live. So everything seems pretty good Let's see if we have made lighthouse happier with us Go through the poor generation process again And I think we were at something like 60 out of 100 last time something along those lines Cool, we're up to 94. So yeah, we went from 59 Out of 100 and we had a bunch of nos over here And we have some yeses now. So that's great So You know, I think that this process Is definitely useful as Matt mentioned previously as part of like continuous integration In addition to that process and you know making sure that you didn't accidentally Have some regression that's causing like a really big drop in your lighthouse score You know, that's super important just as one additional check But okay, so we're getting to the end of this talk, but as developers our journey really is never over You know new features like constructable response streams that jake was talking about earlier for instance as a rolled out more widely present additional opportunities for enhancement And you know, I hope you'll be inspired to follow my lead though and use lighthouse to guide you towards the ultimate destination And that's a progressive web app that delights your users. You need to focus on your users All right, here's a few links. I know I'm a little short on time Definitely check those out. I'm going to just highlight in particular the progressive web app codelabs You could do them in person here for folks who are watching this via video. You could go to that URL Definitely walk you through a lot of the stuff that we talked about in this session in a hands-on way All right, so thanks everybody. Please grab me afterwards ping me on twitter if you want to chat more about the progressive web app journey And next up we have tall who's going to talk about building for billions Got some slides swapping there Hi everyone, my name is tall openheimer I'm a product manager on the chrome team and i'm here to talk to you about how you can use all the technologies That we've learned about today to make sure that your experiences can work for billions of users So when we're talking about billions of users, that's a pretty big number And that means that we really need to think about how can we reach all of our possible users And one of the really critical things here Is to figure out who your users are and to actually understand how they'll be accessing your experience and what this means Now for a lot of us we spend a lot of time thinking about what product problem we're trying to solve And who we sort of have this mental image in our head of who our user might be And for many of us this can look a lot like us based on just what you're used to and the experiences that you've had And this can lead to a perception of the world that looks something like this And now we are in amsterdam So a few of us might be thinking a little bit outside of the united states and you can throw sort of european there as well But this isn't the whole world by any means and it's definitely not your user base when you're thinking about all of the internet users So today there are roughly 3.3 billion users Using the internet around the world And if we actually drill down and look at where these users are This is a map of internet users um today by country And you'll see that while there are some users in the united states and some in europe We see much more pronounced number of users in a lot of these other areas So while the us has about 286 million internet users India has 462 million internet users and china actually has almost as much as the two of these combined With around 721 million internet users But what's really striking here is not just where the internet users are today But looking at where the growth is coming from So if you look at a snapshot over the last year You'll see that in the last year a lot of internet users came online in One very specific country and this is this is india So we saw over the last year that 108 million users came online in india alone And for india, this was actually a growth of 30 percent year over year compared to the number of users that they had before And this growth was 10 times more than the growth we saw in china in terms of absolute users And over 100 times more the growth we saw in any other country over the last year And just to put this in context This growth in india in a single year Was equal to one third of the united states entire population And that's just in one year And what's more is actually if we look at who's not yet online And where we sort of predict that the growth will be coming from We see the shift away from the united states and europe to other countries So in india you still have 864 million users not yet online the current user base There's still 65 of india's entire population Not online or over 20 times the number that's not yet online in the united states or similar areas And so this sort of question can come up How do we reach these users if we need to be sure that we're building for all of them and thinking about all of them And as i mentioned before what's really critical here is to understand your users and understand who they are So i know we've been sitting for a little while, but just with a quick show of hands How many of you remember the first time that you access the internet? Okay, looks like like most of us do now keep your hands up if that was on a mobile device Okay, we've got no hands up at this point So most of us probably access the internet for the first time on a desktop machine or maybe a laptop But when i was in india last year we spent a whole lot of time talking to internet users who Or maybe knew her to the internet or had been using it for a fair amount of time And i was sitting down with a woman who was sort of in her mid 40s We were sitting in her living room and i asked her the same question If she remembered when she accessed the internet for the first time and what device she used to access it And her answer was yes, she did remember the first time she used the internet It had been earlier that year She borrowed her husband's cell phone and accessed the internet for the very first time A few months later she got her own cell phone and was now able to regularly access the internet And so what this means is that how people are coming to your experience and interacting with it is just fundamentally different We've heard the mantra mobile first probably a number of times and for us this often means Thinking about design mobile first thinking about how our experience would work on a mobile phone But for a lot of these users how they're actually accessing with the internet isn't necessarily mobile first It's actually mobile only They haven't had an experience on the desktop or a laptop computer And they may not be using one regularly and they may not even in the coming years be using one regularly So in terms of how they'll be interacting with your experience It is only going to be on that mobile phone And so this means that you really need to think about what your experience can be like For users who may not have had experience interacting with your product on other platforms and making sure that you're still designing for that in mind But beyond just the sort of using mobile first this means that it's also really important for us to think about what the device that users are using are like So taking a look at one device. This is a device that some of us might have in our pocket This is the nexus 6p and it was released in 2015. So last year It's a it's a pretty big device 5.7 inches measured diagonally It has three gigabytes of ram and then depending on how much you want to buy and how much you feel you need It can have either 32 to 128 gigabytes of storage Now in comparison when we were in india We went to a number of stores and actually asked the shopkeepers. What device do you sell? What device do people ask for what would you recommend for me? And this is just an example of one device. This is a samsung j1 And this device was also released in 2015 It's 4.3 inches measured diagonally. So a bit smaller It has 512 megabytes of ram And four gigabytes of storage So these are two devices that were released in the same year but have very different specs We see one sixth of the ram and even in the best case scenario one eighth of the storage capacity And this means that the user is going to be accessing your experience on their mobile phone under a very different context Than the phone you might have in your pocket and the phone that you might be testing on and seeing what your experience looks like And now the difference in context goes beyond just the physical form factor of the device that they're using Because they're relying on cell phones This also means that cellular connection is their primary way of accessing the internet fairly often Now many of us are probably used to accessing wi-fi. We've connected to wi-fi here Probably sometimes complaining about its speed This isn't necessarily the case for the users and it's because you're relying on something That's in your pocket as you move and shift scenarios So does your connection to the internet and you need to keep this in mind when you're building experiences But this phenomenon is happening all over the world. We also see that in the united states 20% of us households rely only on cellular data When they're making connections to the internet and what's really interesting is that this number is actually doubled since 2013 So we're seeing this increasing So the reliance on cellular networks as your primary way of interacting with the internet is increasing across the globe And this has some consequences when you're thinking about the conditions that someone is trying to access your experience under Now we've heard a lot about sort of slower connections and the impact this can have But we see that globally about 60 of mobile connections are 2g And this is just actual 2g connections It's not necessarily talking about 2g like speeds which can actually be even larger And when we start thinking about the areas where people are coming online for the first time We see this more pronounced at about two-thirds of the connections But what's more is that while we're seeing this decreasing we're not seeing this decreasing at a very fast rate We the predictions if you sort of estimate it out is that by 2020 One fifth of the connections globally will still be 2g and again, this is still excluding those 2g like speeds So the problem of connection speed is going to persist for the foreseeable future And we've seen some stats about this before and it's sort of widely accepted that a delay in your experience has a very large impact on how users Experience your site and we've seen that a study found that in a one single second delay In your page load time can lead to 11% fewer page views or a 16% decrease in customer satisfaction if we're talking more qualitatively And so that 2g connection that might have very slow round trip times If that impacts what your experience is like for the user is likely to have a very negative impact on how happy they are with what you've built But beyond just the connection quality that is introduced by users relying very often on cellular connections Cost also starts to play more of a role here So looking at india again and doing an estimate of sort of minimum wage minimum wage in india is a little bit complex as it depends on your job role etc And looking at how expensive a data plan is With some simplifications, we see here that on average you would require 17 hours of minimum wage work in india To purchase a 500 megabyte data plan And we're all we've been thinking about the mobile web. So just to put this in context looking at sort of the average size of a web page today If a user in india receiving minimum wage were to spend that entire paycheck On just data just to access the mobile web One hour of minimum wage work would load about 15 web pages And just take a moment to think about how many web pages you visited today or even visited During the last talk or during this talk and think about how many hours you would have had to spend to be able to afford that And what this really means is that the cost of data Requires a trade-off if they use one thing it means that it's they're not using something else And they're constantly making these trade-offs to make sure that the data that they have is using the best way possible And this results in the frequency of their connectivity Really varying when data costs are so high You need to make a choice if you're going to use one thing or the other And sometimes you just want to turn it off all together One user that we spoke to actually said that on an average day They turn airplane mode on and off 12 to 15 times because when you're not using your phone And you put it to the side if data is expensive you want to make sure it's not getting used unless you find value out of it And this means that if you're trying to get a user to interact with your experience You really need to make it worth it for them because they need to be willing to pay that amount to just access that experience And so this might be a little bit daunting, right? These are a lot of different constraints and conditions under which people are accessing the internet that you may not be familiar with firsthand And so you may be posed with the question great People are using mobile only devices connections can be intermittent They can be slow and when they do exist. They're really expensive. So so what can I sort of do? And what does this mean for how I develop? So some of the the methods that we think about might be a little bit hard under some of these conditions Installs become really challenging because what you need to do here is convince a user to pay The time and data costs to install your experience Before they've even tried it out and this can be really hard when the costs are so high and the networks are slow Because it can take sometimes hours to download a single app And what's more if the device has limited storage capacity your apk size starts to be really really important You need to start to make sure that it's small so that a user doesn't have to delete photos or videos Or other apps on their phone to make space for your experience And what's more is even beyond this first step You're probably working to improve your experience Which probably means you want your user to update their app And this is again once again challenging because they need to take that extra step on that slow connection or expensive connection But you're all here. You probably all know that there's an app that solves a whole lot of this The mobile web as we know solves a lot of these things just inherently and how users interact with it Right with the with the mobile web as soon as they navigate to your experience. They see your experience They don't have to take an extra step before they try it out. They got there. They see it. They can try it out This also means that storage constraints for that initial interaction are non-existent just by virtue of finding it They can see it and start using it And it's always up to date So as you continue to make improvements on your product your users get them right out of the gate And they don't have to go take an extra step just to see the latest and greatest that you've built But as you know, we've been Uh talking a lot about the reach that this introduces And what we've seen these are some stats that we talked about last year Is that removing these barriers has a real impact on the reach that your experience can have We see that on average users navigate past 25 apps per month And this is compared to over 100 websites that a user will navigate past on chrome on android in a single month And this not only is a breadth of experiences that users pass by but has a real impact on the number of users that a single experience has So looking at the top 1000 mobile apps and the top 1000 web websites We see that on average user there is 2.5 times as many users on the mobile web As there is on these top 1000 mobile apps And what we're seeing is that mobile web is also growing at two times the rate of native apps in terms of numbers of users In these same buckets of top 1000 So really what this means is that the web inherently provides you a whole lot of reach and we've been talking a lot about today Is how you can use progressive web apps to not only leverage the reach that the web inherently has But to build experiences that really work well for you and for your users so that they highlight and have all the Capabilities that you need to build the best possible experience and for your users to get the best possible experience So i'm not going to focus on this too much because you've heard a lot of this today But progressive web apps overall not only offer a very smooth experience, but they also offer a lot of Options for how to support some of these other situations that you really need to think about when you're building for billions of users So how can you leverage progressive web apps to actually reach and build Great experiences for users around the world So the first is cost we talked about how cost can be very limiting for users to even try out your experience for the first time So i'll talk about how you can leverage progressive web apps to really remove that barrier And second is connectivity when you do interact with these sort of flaky connections How can you address that to make sure your experience is still as fast as possible? So you're not incurring that one second delay that has a huge impact on users experience And finally, how can you make sure that you're making the experience as simple as possible? And just removing as many extra steps that your users may or may not need to actually take so that things continue to be fast and efficient So to jump into the first one cost Now on chrome we've been working on addressing this issue across the board So we do have a chrome data saver This is a proxy for htp content that a user can turn on And with functionally no fidelity change users can see up to 60 data savings But we've taken this a step further because we know that cost can be very constraining for some of our users And we've actually decided that on slow connections for htp content We will automatically replace most images on the pages with placeholders We maintain things like navigation icons, etc So users can continue to load the page But at this point the user is in control of where their data goes So they can choose to load all the images on the page They can long press on a single image to load it if they need it But we're not using their data without their knowledge and without them needing it And we've seen that we were able to increase data savings to over 70 percent in some of these situations But we also know that this doesn't necessarily work for for all experiences And so there's also a number of client hints that you as a developer can use to make sure that you're optimizing the experience For the users Based on the device that they do have so with dpr width and viewport width You can make sure that you're only sending the image size that you need To the users and so that they're not incurring data costs for something they may not be using or may not actually need What's more is we've also launched a save data header And in chrome this maps directly to whether the user has that data saver had Feature turned on or not which means that you as a developer know which users are the most data sensitive And can adapt your experience accordingly and can do so in the way that works best for your product So maybe that means only loading, you know one key image that's critical for it and making the other one sort of on Demand for the user or not auto playing video or whatever it might be That makes sure that you aren't removing constraints for the users who need it most While still making sure that your experience works for them But we also know that this can be challenging and there's a lot of optimizations to go on So we also have the page speed module Which is a server side component that you can actually drop into your web server That will do a lot of these optimizations for you And if you drop this in this can do the optimizations on both http and https content With functionally no fidelity change So it's similar to that data saver feature that we have on chrome overall But you can do it on all types of content And what we've also done is we've actually gone a step further so that for the users who have data saver on We do a few extra optimizations to make sure that we're really doing as much as possible to help those users who are Feeling sort of most constrained or who have expressed interest in us saving them even more data So just to give an example of this This is an example of a store mark storefront that we built On the left you'll see a screenshot of the store with with no page speed And on on the right you'll see it with page speed Now these look really familiar and very similar if anyone can point out any differences Let me know afterwards, but they look functionally identical But there are actually differences when you dig into this So If you look at the one on the left here, uh, this is 350 kilobyte paid So it's relatively lightweight compared to the sort of the average website across the board But simulating a 2g connection this page can take over a minute to load And as we know waiting is bad. It causes a bad user experience It causes your metrics to hurt and you really want to reduce that as much as possible Now by just having the optimized for bandwidth in page speed module What we see is that we are able to actually shrink this to 165 kilobytes or about 50 fewer bytes But for users who have data saver on we and we go even further We're actually able to shrink this to 120 kilobytes And what's more is on the same simulated 2g connection We actually dropped the load time to under 30 seconds And this is functionally with no fidelity change to the user The user is seeing the same thing But you are saving them data and saving them time just by dropping this one line of code in And what we're seeing is this is just one example But we've seen that on average even for users who do not have data saver on We see about 37 data saving with no fidelity change at all But beyond just removing uh cost and decreasing cost that comes with data usage on mobile In connectivity is really important and you need to make sure that things load as quickly as possible So just to give a sense of how these things can vary based on connection types So round trip time or the time between making a request and actually getting a response varies pretty drastically between all these connection types At one extreme you often see sort of 50 milliseconds Round trip times on wi-fi. I know conferences can be different But at the other extreme you have sort of 50 times slower on an average 2g network with 2,500 milliseconds round trip times And so this can be a little bit daunting. What can you actually do about this? So the first thing you can do is downlink max actually offers you a way to know which connection type in the first place Your user is actually on when they're accessing your experience and you can subscribe to updates So if a user switches connection types you as a developer know and can make sure that you're giving them the best possible Experience and not incurring any of those delays that might otherwise happen But what can you actually do about it when you do know? Okay, my user is now on a 2g connection So we've heard a lot about service worker today Right, we know it's a client side proxy and written in javascript and you can use it to support offline and all these things But you can also use it to make sure that your experience is as past as possible So jake this morning talked about wi-fi or the experience where your phone thinks it's connected But you as a user are not actually getting anything and this can be incredibly frustrating This isn't only those sort of really flaky intermittent connections But this can also be the case when you're on a really really slow connection and the round trip times are just so large And so what you can do here is with service worker You can actually implement request timeouts to address these flaky connections So that if a user is on that really slow connection They're still getting something very very quickly and you're they're not waiting for it to load But we do know that sometimes there's no connection Right, we've seen this offline dino a lot today when we've been talking about service worker And we're really we're really trying to make sure that you all have all the tools You need to kill the offline dino and make sure that when a user goes to your experience They're never going to see this offline dinosaur But there's been a lot of interesting ways that we've seen people who have been leveraging progressive web apps address the offline situation in a way that addresses the flows that are most critical to them So just as one example, uh, this is conga conga is one of the top e-commerce sites in africa And they will actually be talking a lot more detail about what their progressive web app tomorrow And what they've done is they've built a Checkout flow that can work completely offline So for users online and add some things to their cart And then loses connectivity or goes offline or turns on airplane mode for whatever reason it might be They've actually adjusted their flow so that instead of having an online checkout flow It has sort of a call to order flow so that the user can still complete the transaction or the flow That's most critical for their product in a way that works regardless of their connectivity type So they've really taken their time to think through what is the critical use case for our users And how can we actually let them complete that use case even if they have no connection? And what's more is they've actually found that for that critical flow This has shown a lot of improvement So compared to their previous mobile website This used 84 percent less data And so addressing a lot of these speed connection issues also has a benefit of addressing some of those cost issues that we talked about earlier What's even more is that compared to their native app this new flow Actually used 82 percent less data So this has been a drastic improvement not only to their previous mobile website But also to their native app experience and again, they'll be talking a lot more about their overall Work tomorrow morning. So feel free to come to that But beyond just trying to address connectivity and cost Removing complexity is always a good thing making things easier is always just going to be better for your users And when we're talking about users that are sort of coming online for the first time Every step you're asking your user to take is time and money because on those 2g connections Every page load is just going to be sometimes minutes of waiting So if you're giving them a page load you need to make sure that that page load provides value And if it doesn't get rid of that step and there's a few ways that we can make that happen So we've talked a lot about add to home screen and how you can use this as an easy way for users to get back to your experience This can also be used as an easy way to cut out steps for your user So that users who are more engaged and have expressed interest in your site can with one tap get right into your site They don't have to take extra navigations wait those 5 10 minutes spend that data on those page loads Just to get to your experience. They can tap on it straight from their home screen But beyond that with the notifications you can also make sure to deep link them to specifically the part of your experience at the most critical times So that they're not taking extra steps even within your product experience to get them to the part that might be most relevant to them So this means that regardless of what their connection is or their their cost is you've just removed steps And they don't have to wait that extra time unless it provides value to them But one of the things we talked about is that can be really hard to try this out and make sure you understand What it's like and so there are a few tools you can use to actually test this experience directly and make sure you're testing it With a global perspective and under all of these different situations that maybe aren't what you have in your pocket or what you use on a daily basis So we do have a mini mobile device lab and it's up on github And so this will let you simulate a bunch of different devices So you don't have to go out and buy you know a million and a half devices We can make sure you're simulating your experience on all these different devices to see what users who Use devices that are very different for yours are actually experiencing But what's more is you can actually use dev tools to understand the cost of your experience So just to walk you through one thing here So we've talked a lot about dev tools, but I want to call your attention to the network piece specifically And so you'll see a button at the bottom here That actually lets you know what the what the payload of of your load was and so right now at the start It's sort of pretty light 785 if we look a little bit more into this we noticed a lot of things came from cash So probably why it was pretty light But you can actually just go ahead and hit hit refresh here And now you'll see that sort of on a fresh load. This was actually quite quite a bit heavier And so it was over 200 kilobytes And so this is just one example But you can use this as you're navigating through your experience to get a sense of like, okay How many how many megabytes is a user using if they're actually actively using my experience? But going beyond this you can also use this to understand the time and how much time users are spending on Just waiting for your page to load So you'll see the time down here right next to the the megabytes But what's more is you'll also notice that up here you can throttle it and change the The simulated network speed so that you're not relying just on your wi-fi to see what how the page load actually happens So if you'll see that if we change this to 2g This actually starts going from 600 milliseconds that we saw before To roughly 11 seconds for for just this page to load And what you can do is you and as you adapt your experience as you use service worker And now these other technologies that we've talked about you can see how this changes and make sure that you're really Optimizing for experiences and that you're building an experience that you would be happy to use If you are actually facing sort of some of these other conditions that you might not have firsthand experience with So the main idea here is that by keeping sort of three principles in mind You can make sure that the experience you're building not only leverages the reach of the web But also takes advantage of progressive web app technologies to build the best possible experience for your users across the board And we have a lot of different technologies and details about how you can apply these Not only for progressive web apps, but specifically to address the needs of billions of users online So feel free to go there for more details But the big takeaway here is that just by keeping in mind the fact that not all users who are using your experience Look like you and are accessing the experience under similar constraints You can do a whole lot to make your experience much more accessible And as a result have a much larger reach and have the potential to reach billions of users And so with all of this you can really build an experience that is built to work well for everyone And with that i'm going to hand it over to chris wilson to wrap it up for the day. Thank you very much Good evening Skip the slides ahead here Okay, so good evening. I'm chris wilson. I'm a developer advocate on the web platform at google And I have worked on the web platform for a super long time I actually just had my 23rd anniversary of working on the web platform Um, and I have to say this is one of the most exciting times In that history because progressive web apps are an amazing breakthrough in user experience Like this lets you build stuff that really just works for users And this is the first time I can actually say that and not kind of grimace a little bit inside when I say that So I hope that we filled your heads with a ton of really interesting stuff today I hope that um You know, we've given you a lot of grounding of what you can build and how you can go about getting started I hope we've impressed you with the opportunities both in market opportunities And as tal just talked about in addressing emerging markets, which I think is a really great opportunity for the web as well So in this talk I want to discuss a few areas that are still kind of under construction This isn't stuff you necessarily want to be putting into production today A couple things in here are but but most of it is sort of To spark what what's going to come next in the future So this is kind of the next next level of user experience And if you saw my google io talk Pretty recently what's next for the web you might think this is just a replay of that and it totally is not This is not a whirlwind deluge eye chart of new features I actually just want to focus on three important challenges That are relative to progressive web apps. Um first and foremost knowing who the user is a k authentication and sign on And enabling the user to pay for things on the web which would be kind of nice And finally connecting with hardware Which is kind of near and dear to my heart personally, but i'm going to talk through some developments in each one of these And starting with knowing who the user is uh sign in in particular Now let's take a look at an average sign-in screen Today like this is what users land on most of the time And they often have a lot of problems with this. I know I do because every time I go back to a service Um, I can't remember. Did I sign up with this with my google plus account? Did I use facebook? Which email address do I use did I use because I have multiple email addresses? um, all I want to do is get to the application And of course my favorite button on this entire Page is forgot password. Is there anybody here who's never used a forgot password button? Oh, you're my hero right there, okay Or you're lying which is actually Not calling you a liar, but anyhow on top of that Mobile devices which of course a lot of browsing has been moving to mobile It's really really hard to type particularly things that are not you know words in your preferred language Um, and especially when you're using different characters like you do in a password I know for example, I have optimized at least one of my passwords To have characters that are more easily accessible on a mobile device screen So I don't use till this in my passwords anymore because it's two extra taps away on an android on-screen keyboard And i'm sure you can understand this leads to a problem I'm sure some of you know what this is already so just call it out. What do you think this number is? Most commonly used password. That's right. This was the most popular password in 2015 It edged out the previously most common password password And of course, you know, this isn't even getting into how many of us share passwords across different services I mean, I mean how many of you share passwords across services because I would never do that The point though is the complexity of remembering passwords Leads users to use weak passwords or to share them and that of course is a significant security risk So chrome and pretty much every browser out there try to encourage stronger passwords by using a bunch of characteristics to automatically detect when you've signed in successfully And prompting the user to save it And then auto filling it when the user returns to the site You don't need to remember to you don't need to type anything hopefully this will just work and Chrome actually also has and several other browsers have features that will synchronize that across different devices as long as you're signed into chrome And in chrome for android this also applies to android native apps. So android native apps get the same password data But even just chrome's password manager alone assists eight billion sign-ins a month Like eight billion times during a single month is how many times that saves somebody from typing in a username and password Now to a large extent this should just work like you shouldn't have to do anything I should have stopped talking about this like three minutes ago But since this is auto detection, this is guessing It's best to give password managers hints so that they can guarantee that their password forms are being treated properly The best thing is of course that these hints actually work across all modern browsers This isn't chrome guidance that i'm giving you this just kind of works So despite this talk being mostly about what's next go do this right now Since password managers are heuristic based sometimes extracting that semantic information is difficult Just give us a hint like here. We can't really tell what the What the username is is a display name phone email So you can solve this simply by putting in autocomplete attributes username and password And if you're marking up passwords use current password Because when you have account creation or changing password forms You can use new password for where the new password is going and this has two effects I'm only mentioning this because there's one really interesting one The first boring one is simply this prevents password managers from plugging a password you already used into a new password field But when you mark up your forms with new password The browser can also tell that you're trying to generate a new password and you can do it for them Like we can we can go ahead and just auto generate a password for you So instead of a password like this You will get this Well, not exactly this. I mean don't write this down or anything Something like this like we've been experimenting with auto generating passwords in chrome for a while It's actually in chrome canary dev and beta channels Hope to deploy it to stable soon But if you properly mark up your fields with new password That'll it will make this possible. We'll be able to do this and other browsers will too But setting inside that stuff What's really next generation for sign-in is using something called the credential management api Now we've just shipped this in chrome It's still kind of early days certainly not implemented across all browsers yet But the credential management api gets you away from using form fields with wacky autocomplete Properties attached to it and lets you integrate more deeply into the sign-in process of the browser So you can also by the way Use this to sign into federated services, which is kind of hard to do in a form so AliExpress, which I think we talked about earlier is actually a really great example of a user flow because it's a shopping app It's really important for users to be signed in right away To ensure that if they have items in their cart, they're still there If they have preferences or stuff that they've been looking at or wish lists. It's already there But at the same time you really don't want to force the user to log in as the first step Like you don't want to take that active step of saying Okay, give me your username and password before I show you anything Because if they're a new user, of course, they may just want to browse or I may just be searching for something new I don't want another step in my way so With aliexpress when a user launches from the home screen It loads up this app shell and during the startup the app Asks the browser for the user's credentials if it can get them Without bothering the user And then they can sign the user in you can see this at the bottom here And they don't need to ask the user at this case in this case Now they do this In the credential manager api and the code for this flow is really pretty straightforward There's just a navigator dot credentials object and you have a get method You can ask it you pass it in some options. You say this is a password based credential And most importantly here, I want this to be unmediated I don't want to prompt the user from this call So this code is actually safe to put on every page in your app to try to trigger Sign in because it won't ever interrupt the user's flow. It won't ever pop up a dialogue It will just fail if it can't do it automatically Now auto sign in is kind of new for the web We're starting out pretty conservative So the browser will only hand over these credentials if the user is turned on automatic sign in And if this user only has one credential for the site if they have multiple credentials We don't want to pick for them. We want to make sure that they they get to choose And of course this would be an interesting security place So we need to make sure it's kept secure so credential manager api is restricted to secure contacts like many new features And passwords are never actually directly exposed Like when you do get what you get back as an object that has the password Which you can then hand a fetch to post to a same site endpoint And it has to be a same site endpoint. You can't be pushing this off to other other sites, of course So once you get these credentials when you actually want to sign in You call fetch and pass it in a post Now when automatic sign in isn't possible credential manager api can still offer a one tap login It can still say I want to sign in and then trigger a chooser dialogue So the user can enter new credentials or they can pick between multiple credentials that they have So chrome will present an account chooser like this one. This one only has one available But if you need to do this you use almost exactly the code that you saw a minute ago The only difference is there's no unmediated in this So you can use this flow when the user clearly has an intent to sign in Like if they click the login button then obviously you can run this So this is all great. You actually do need to forcibly store credentials And this is where our heuristics often fail But the credential manager api actually lets developers have the ability to choose When the save your password prompt is triggered so chrome isn't going to miss out on when the right time to to trigger this is So if the user has just entered their credentials into a form you just create a new password credential and tell it to store That constructor will deal with parsing your form pulling all the fields out that kind of stuff And you can use this as I mentioned before for doing federated login google plus facebook any other Federated login you just have to create that credential using whatever Whatever the that particular federated credential wants to use as an id and A end of provider so an identifier and then the browser kind of just deals with the rest of the process for you And finally of course We can forcibly sign you out. We can say hey, don't ever automatically sign me back in always prompt the next time that That the that you call the credential manager api to do an automatic sign in So a number of companies are already using credential manager api or Started working on it in some cases deploying this in bits of pieces in bits and pieces You can play around with these today in chrome Because we shipped this in chrome 51. So it's actually turned on already But now I want to move on and talk about paying for things Now obviously we've been able to pay for things on the web for quite a while And it's no surprise that given the rise of mobile computing A majority of commercial traffic is coming from mobile devices like this one What is surprising though is that 66 percent of purchases are actually happening from the web on mobile devices. So By and large users are using the web to purchase things more than they're using native apps to purchase things So I guess the web isn't dead after all but Unfortunately, there's a lot lower conversion rate too and conversion rate is a weird concept So I want to make sure that I sort of capture this 66 percent fewer conversions Equates to if on average You make three euros per visitor to your site Now on a mobile device you're going to make one euro per visitor on your site on average Like this is pretty bad, right? This means mobile users are not paying you as much or they're not spending as much on your site Now if you if you wonder why I think the answer is actually pretty simple Because checking out particularly on a mobile device Is still a pretty messy problem I'm pretty messy project So check out forms have improved since the beginning web commerce of course, but fundamentally It's still kind of the same thing. I still have to manually input my credit card info My billing address my shipping address. This has gotten so bad for me personally by the way I get really really excited When I go to a form and they have put the zip code first and they automatically fill out my city and state for me Like I'm so excited that they do this when if you back up for a second I shouldn't have to enter any of that like it should just know What that information is And of course this is worse on mobile devices too because you know if you thought typing your email address was bad Try typing a 16 digit credit card Especially when they forget to label the field properly and it gives you the qwerty keyboard Yeah, it's a mess So just like with sign-in our first step to solving this problem is autofill Now autofill works on existing forms. You don't have to modify your site. Although it does actually do the same kind of Same kind of autocomplete types But stores the user's address and credit card info. You can manually save this in settings yourself. You can let it auto detect it Chrome will synchronize it just like with with user sign-ins But so autofill is great. I mean it does actually improve the problem It it raises our conversion rates about 25 percent on an existing site with no changes But although autofill gets rid of the manual nature of data entry It does make it simpler for the user But it's fundamentally the same kind of existing checkout flow. You're you're still Handing the user the same form It's just they have a stamp for parts of it and they just have to make sure they end up in the right places So the web checkout process really needs to be kind of reinvented overall now Like I said before the current checkout process is really pretty form heavy For users though the ideal experience would really be the server just works it out with the browser Like the browser is your user agent Like that's why we call it a user agent. It works on your behalf So sites should be able to focus on creating an amazing and engaging shopping experience and not so much on That last set of pages that you have to navigate through that has a long checkout form So this is where web payments comes in With the payment request api so payment request is a simple javascript api It allows the browser to handle that heavy lifting of payment collection And give the user a one tap checkout But still make sure that the site is going to get the right set of information Not the wrong set of information and the user has explicitly said yes, I want to pay them this much money So this is an openly developed standard api No matter what browser platform or payment method you choose everyone should be able to pay for Pay without a checkout form In the end we're still working on this but obviously we'll come back to that This is under development in the w3c web payments working group That group's goal is to create a universal So cross browser standard for any website to accept any form of payment So this isn't a chrome only api. We want this to be supported across all browsers In fact, I really want to give a shout out to microsoft Because they've done a ton of work in the web payments group as well Some love all right and And uh Although we're targeting mobile first with chromes implementation because that's where it's most impactful Payment request is explicitly designed to not be tied to a given platform The goal really here is to create an open ecosystem where any website can Accept any form of payment with minimal code changes and without any proprietary one-off payment apis So with autofill we can eliminate that manual and tedious bit Our implementation actually uses the same data from autofill to so you won't have to enter your credit card details one more time If you've already done this And since the browser is taking care of this the steps of collecting the right set of information We go from having multiple taps multiple forms to just one. You just have to approve it So the flow here is really the site initiates a payment request The website passes to the browser what it needs for that. So it says how much is being are you charging What set of items do you need? Then the browser determines the intersection of what types of payments they They uh The site supports and what payments the user actually has what payment payment methods And then presents a selection ui to the user to choose which kind of payment app This can be anything from a simple credit card to an installed payment app like android pay And then the browser gets a response back on this and returns it to the merchant and the merchant the website the merchant's website Now has everything they need to process the payment. So credit card info or the right set of tokens So looking at this in code. I know this ends up being kind of small because it has a lot of of information on it, but the real this is by the way based on The first published working draft this may change. So like if you go back at this slide in a year It's probably not going to be totally right on but we'll see When you create a payment request, which is the first line of this All that you do is the first parameter is an array of what supported payment methods the merchant supports So here they'll take visa mastercard amex discover But that's all not any other credit cards or other payment apps or anything like that Now the default here Is that is this right it is using credit cards to pay for things because that's kind of still where we go But they also pass in the line items the set of things you're paying for whether they want shipping options So the website can actually support those shipping options and negotiate them later and then update the total price Now I did talk about payment applications Um, I wanted to describe this a little bit in a little bit more detail So google launched android pay late last year not late last year early last year And we've seen phenomenal growth in people using it to pay for things on android devices and and with merchants physical merchants But what makes this even better than using your credit card Using your credit card directly. I should say is that it uses a tokenized version of your card when it passes it to the merchant So they can't reuse your card information And of course it uses device authentication to protect your transaction. It knows it's using your phone It's not just a number a credit card number So Let's take a look at android pay All that you really do is you have the same payment request creation, but you give it a different supported type a different supported payment method And here of course android pay has some app specific parameters. So it tells you What gateway it's going to use what key it wants you to use what version of the api And of course that would be different for different types different payment apps So you can get started with this today. It actually is supported But it's in dev and beta builds of chrome for android. It's behind a flag until we launch late this year Um, and then we plan to add more platforms including desktop