 My name is Sam Birch. I'm a product manager working on Chrome for Android. I've also got Alex today. I got a text from Alex. He said, the web is still too slow. Just let me do a couple more traces. He's very serious about web performance. So I guess he'll join later on. If you didn't catch Rahul's talk in the last sessions, you might want to look it up on YouTube later. I thought it was a really crisp overview of why we are so excited about the web. It's the biggest platform in the world, bigger than any other OS or any other form factor. And there hasn't been another platform like it in the history of computing. So what we're going to focus on in this session specifically is the web's role as a platform for apps, for deeply engaging experiences, and specifically progressive web apps. But let me start at the beginning. Why build apps on the web? If you have a significant mobile web presence today, it's likely that it already has a lot of visitors, and you're not alone. Here's a recent breakdown comparing monthly unique visitors to the top 1,000 apps and sites. And what you see is that the web reaches three times as many people. And you might have heard in the developer keynote earlier today that that reach is growing faster, too. Historically, though, most users have visited the web in passing, particularly on mobile, where it's a lot harder to type a URL than it is to tap on a home screen icon. You might watch a video clip or read an article, but you're not that likely to come back later. Because native apps have had access to features like push notifications and icons on the home screen, users who engage deeply with services on their phone have tended to do so through apps. So looking at the amount of time users spend in those same apps and sites, the average for apps is much higher than it is for the web. So I think the opportunity here is pretty clear. What if you could give users a deeply engaging experience as soon as they landed on your website? Instead of asking them to take the high friction step of installing a native app, what if they could get a native-like experience from the web? And the good news is, the past few years have seen a dramatic increase in the quality and the capabilities of web apps. The web platform has third-to-broadly support features like push notifications, placement on the home screen, and technologies like ServiceWorker that make your site more reliable. So if you're not familiar with the term, web apps taking advantage of some of these technologies are called progressive web apps. They're reliable, they're fast, and they're more engaging. As a result of this change, folks who are investing in the mobile web are seeing great results. A lot of decisions have been made in the past, assuming that it's too hard to get users to come back to your website. And now that that's changing the way that we should invest should change, too. Let me dive into a few more examples here. Way back in 2011, the Financial Times abandoned their native apps. They built a web app using the best technology available at the time, and app.ft.com has been going strong ever since. Recently, that experience has gotten even better as browsers caught up to support developers building deeply engaging experiences on the web. And now their site is a fully fledged progressive web app. That means I can save it to my home screen and even read an article while I'm offline. The Financial Times will sync an offline section of the paper so that I can read it even while I'm on the train. And this uses the service worker. And they've even got an offline-enabled podcasting app, which is available at listen.ft.com. So you can build these pretty sophisticated experiences on the web today. And it's fascinating to see how prescient the Financial Times was back in 2011. Fellow publishing giant Forbes just took a similar step launching their progressive web app for mobile. And they've even made a slick video to match their new experience. With the instant access of the web, there's no place I can't reach. The impact of the web on the newsroom was monumental. It's now more of a reader telling the newsroom, this is important. You really have to start to build from scratch what is a story on the phone. With a progressive web app, there's a link, tap it, and install it with no friction. The PWA is on their phone. And once that is installed, we are able to alert you to, hey, we've got some information for you. If you're interested in whatever areas that you are, you can install that subject or topic. And we're going to serve you the content that you want. And that's going to change our business in a big way. The technology has enabled us to make our new PWA faster than your current mobile site. We're now able to deliver visuals faster. And if you can start to deliver visuals faster, then you can start to change the formats you do. People are willing to stay longer. If they stay longer, they see more advertising. The PWA is going to result in a more personalization. Personalization will heal more engagement. The web has made me realize there's an audience out there. There's an audience that's knowledgeable. And there's parties that needs to be understood. That's pretty compelling stuff. And I want to underline a couple of statistics that they called out in that video. After rolling out the Progressive Web App, Forbes saw a 43% increase in the number of sessions per user. And those sessions were double the length on average. So it turns out that a better experience for Forbes's users was also a great business move. Sorry for the delay. This isn't just about publishing. Lyft has also launched their new mobile website as a Progressive Web App with the needs of users and of emerging markets in mind. And you can try it yourself at ride.lyft.com. In emerging markets where you can't take bandwidth or even connectivity for granted, it's harder for your audience to get into an app. And so instead of making a site which is a landing page asking users to take this high friction step to install, Lyft's PWA is a feature-complete version of Lyft just without the install step. After all, the goal isn't to get users to install an app. It's to get them using your service. So to recap, users are already visiting mobile websites. Making the experience of your mobile website radically better by building a PWA helps you engage and retain users who are formerly just passing by. The pivotal moment for any app is when it earns a place on the user's home screen, with Progressive Web Apps that happens when users choose to add a site to their home screen. Improvements to this key step have been a focus for us lately, and they're rolling out now. And there's actually a flag you can enable here if you want to test it with your own site. There are two key changes here for engagement. First, something we've heard consistently from developers and users is that it's confusing that Progressive Web Apps were on the home screen but not in other parts of the Android system UI, like the app drawer. As part of the improved app to home screen experience, users can find them now, find them there now. They'll also show up in system settings, allowing users to manage Progressive Web Apps more like other apps. But I want to emphasize that this is actually pretty general. For example, they'll show up as suggestions and open from the Google Search widget. This deeper integration for Progressive Web Apps means users will be able to find them in a lot of places that were formerly reserved just for apps. Second, something else we've heard is that it's confusing that sometimes Progressive Web Apps would load in a tab in Chrome and other times as a full-screen activity after the user had added it to their home screen. So I'm happy to say now that we'll be able to handle intent from links opened in other apps or in Chrome. That means that users who have added your PWA to their home screen will get the immersive version of your site whenever they navigate to it. OK, now let's take a closer look at the manifest, which provides the metadata to enable Progressive Web Apps to be added in the first place. This is the same manifest that you would use today to allow users to add shortcuts. So if you support that today and you have a Progressive Web App, all of this happens and you'll switch over without requiring any extra work. So it starts with a name and a short name. If you've seen a talk about Progressive Web Apps or App Manifest before, this will look pretty familiar. The short name is actually what shows up on the user's home screen and in system settings. And the full name will appear basically where there's space for it, so in the Chrome prompt and in the splash screen, which shows before your site loads. Then you've got an icon. You can specify multiple sizes here, but we recommend at least one icon, which is a ping with at least 144 pixels to the side. 192 will scale up even better. And that icon gets used in a few different places. So in the app drawer, as I just showed you, in the rest of the system UI on Android, inside of Chrome when users are prompted to add your site to the home screen, and they're used to generate that splash screen. The start URL is, so to speak, the main screen of your app. It's what users will get when they tap on the icon on your home screen. And if it's open in the background already, they'll just pop back to whatever page they had left. The display mode controls how your app shows up on screen. Usually, you want stand alone, which is sort of like full screen. You won't see a browser toolbar or other browser UI, but you will still see the Android status bar and the Android navigation bar. So this is, by default, sort of what native apps look like. But there are also a couple of other modes coming to Chrome. So first, full screen, which, in contrast to stand alone, does cover up the status bar and the navigation bar. That's what you see here with paperplanes.world. And minimal UI, which is a new mode, which has a simplified toolbar with your URL and allows users to see it and copy it more easily. Then there's scope. Even if you have an app manifest today, you probably don't use this scope, because today it actually hasn't done anything to affect the behavior of your app. However, with support for links coming into Chrome, this field does now have some meaning. So a core part of the user experience of Progressive Web Apps is that they open reliably, and users never see a network error from the browser. In Chrome, that's the dinosaur page. And that's ensured by having a service worker, which handles a set of URLs inside your Progressive Web App. But if you do provide a scope explicitly in the manifest, it'll restrict the set of URLs that should open in your Progressive Web App in its immersive form. The scope of your Progressive Web App will also define the boundary of your app. So right now, navigations to other sites from your Progressive Web App, that is navigations outside of the scope, will open with this little URL bar on the top that you can see here. That little bar isn't all that useful. We've heard from you all that it's lacking, especially compared to what you can do opening content from native apps. So to close this gap, we're planning to move this to a more featureful and familiar UI. It'll allow you to copy the URL, to open it in Chrome, or jump back to the Progressive Web App that opened that content with the X. And we're looking forward to getting your feedback on this as it rolls out later this year. OK, so you have a Progressive Web App with a manifest. Now you want to make sure your T's are crossed and your eyes are dotted so that users will be able to add it. How do you figure out what precisely qualifies as a Progressive Web App? The best way to check the requirements is to use Lighthouse, where you can see there's a section called User Can Add Site to Home Screen. It's pretty self-explanatory. If those are green, your site should be addable on any Android device. As we announced today, Lighthouse will soon be integrated into Chrome's developer tools, making this even easier to get at. And we also know that being able to add your site predictably is important. So we make changes to these criteria carefully, and with advanced notice on the Chromium Developer Blog. So with all those requirements in place, users can be prompted to add your site after the browser fires the on-before-install-prompt event. Today, that prompts looks like this. In Chrome, it's fired when we determine your site is an eligible Progressive Web App, and that the user has been sufficiently engaged with your site. The intent of that engagement check is to avoid spamming users with requests that they aren't likely to accept. And we said at Chrome Developer Summit last fall that we were experimenting with a threshold for user engagement. At the very beginning, this was a few minutes and a couple visits to your site. And we heard from a lot of developers that this wasn't very predictable. And so in the most successful variant of that experiment, we saw banner triggering increase by half. And remarkably, the user acceptance rate didn't change much, even though we were triggering earlier. So we saw a 48% increase in the number of installs as well. And what that suggests to us is that we were being too conservative before. And so I'm pleased to say that we've decreased the engagement threshold in Chrome Stable. Targeting your prompts is even better than leaving it to Chrome. So you can hold on to the on-before-install-prompt event and show the prompts later at a time that makes the most sense to your app. Flipkart, for example, in this screenshot, delayed prompting users until after they completed a purchase, a moment when users are engaged and getting a lot of value from their service. And this led to three times more users accepting the prompt than that had before. Pretty soon, we're going to be taking this even further. By firing on-before-install-prompt for sites, as soon as Chrome understands the site is a progressive web app. If you add a listener for this event early on in your page, Chrome will suppress the default prompt and leave triggering the install flow up to you, which gives you a lot more control. When the prompt is triggered from a user action, the display will change from the toast at the bottom to this style of modal prompts in the GIF here. This better aligns with the way that users and sites are using Add to Home screen today. In fact, we see that most additions come from Chrome's overflow menu, which sites often actually point to from their own UI. And so by giving developers more control and the ability to reprompt when the user taps something, it'll be easier to show more timely and relevant prompts. So to summarize again, you can make your mobile web experience radically better by building a PWA. And that can help you engage and retain users who are already coming to you. We've been working in particular to make it easier than ever for users to add their site, add your site to their home screen, to improve the experience and users' engagement once it's there. And with that, I'll hand it over to Alex to talk about some of the other platforms building for PWAs and some of the new capabilities. Thanks, Sam. Can't wait to see all that stuff rolled out later this year. Hi, everybody. I'm Alex Russell. I'm a software engineer on the Chrome team, like Sam mentioned. And I wanted to spend the next 15 minutes or so making you as sad about web performance as I am. No? I'm kidding. Of course, kind of, maybe. I did promise, Sam, that I wouldn't use my last minute slide editing power to make this secretly a performance talk. It is actually taking quite a lot of self-restraint for me to not go into why it takes 40 seconds for this site to load. But I'll do it. So where were we? Was it progressive web apps again? OK. Right. So app.ft.com is awesome. But you might not know that progressive web apps are also on Chrome OS. So if I go to app.ft.com in a tab on Chrome OS and I spend a little bit of time on it, I'll eventually get an add to shelf banner very much the same way that I would on Chrome for Android with that add to home screen prompt at the bottom. If I click add, I'll get a new item in my shelf at the bottom. And if I launch it, it shows up as a full screen window, a standalone thing. It even shows up as a differentiated item in the task switcher. It's a real boy. It's a full first class application. This is pretty great. So Chrome has been taking some steps to make progressive web apps work on the desktop. But it turns out we're not alone. For the past few years, we've been extraordinarily lucky to work with our friends at the Samsung internet browser team to develop the standards behind progressive web apps. Since version four that they released last year, Samsung internet has had great support for progressive web apps. You can even try it on Google Experience devices today out of the Play Store. So in addition to the usual add to home screen banner that you'll get with a user engagement threshold, Samsung internet has been forging ahead with new ideas about how to communicate to users that they're visiting something that isn't just a regular website. So here's TwitterLite again. If I land on TwitterLite, I see the usual star button at the upper left when I first land there. If you've used Samsung internet, you'll know that this is a little button that lets you bookmark any page. It's a quick action for that. But once Samsung internet detects that the site is a progressive web app, that star changes to a plus. That's a visual cue to you that this isn't just your regular website. There's more to do here. Tapping on the plus brings you up to this menu, which lets you both bookmark and add it to the home screen. So it's a persistent cue that lets you understand that this thing is a PWA. So here's how the experience feels in context. This is the site that I am particularly partial to, and not just because it loads fast. As you can see, Samsung internet's progressive web app integration feels fast and fluid. Just like Chrome, Samsung internet progressive web apps get their own top level activities in the task switcher when launched from the home screen. And they launch display standalone too. So if you follow Android hardware, you might have heard of the new DEX. DEX is an add-on for the recently launched flagship S8 phone, which was released last month. DEX is a bit like a dock for your phone. It gives you a desktop mode, letting you connect an external mouse, keyboard, and monitor, all driven from the phone that you put inside the dock. As you saw on Chrome OS, there's kind of no reason to believe that progressive web apps can't excel on the desktop too. So here's the same flow. The Samsung internet team sent us this video showing adding a PWA to the desktop, launching it, and once launched, it again launches in its own top level standalone window. Because making responsive multi-form factor experiences is so easy and fluid on the web, the Polymer Shop demo works great in both form factors. I think this is an outstanding testament to what's possible with the web today. And because web apps are standards-based, advanced features like push notifications can follow you to whichever browser you happen to favor on your Android. But that's not all. Thanks to the open nature of standards, our friends on the Microsoft Edge team have also been working with us on compatibility for features like service workers and web push. But what I'm really excited about is some of the stuff they unveiled at their build conference last week in Seattle. Later this year, Windows 10 will gain some very deep integration with Progressive Web Apps. In a first for Progressive Web Apps, the Windows Store will crawl the web to discover which sites are. Bing users will see them as installable apps in search results, and developers will be able to easily claim store listings. Listings in the Windows Store let users discover Progressive Web Apps wherever they might be looking for them, either in a tab or in the store. So Progressive Web Apps like jig.space will always be available in the browser, of course. But if you're searching for the same experience in the store, they'll be listed there too. Installing these apps is just like downloading any other app from the Windows Store, except they're tiny. But as a developer, all you had to do was build a great Progressive Web App experience. You didn't have to target a brand new runtime. Apps that are downloaded and pinned this way get all the same UI affordances as native apps, including the ability to be configured, installed, and uninstalled naturally, just like you would any other Windows 10 app. Billions of users across desktop and mobile are getting first class support for Progressive Web App experiences this year. I think it's a great time to be a web developer. This is hugely exciting. So PWAs are everywhere. In tabs for sites that you visit, on the home screen, if you want them to be, on your desktop, and soon inside stores. For apps that need what the web already is great at, that opens up huge opportunities. If you saw Rahul's mobile web state of the union, you know how vitally important that is to businesses and how PWAs are positively impacting sites worldwide. But what keeps me up at night, on the engineering side, is the set of things that the web hasn't been great at. A few years ago, people sort of thought it was nuts that we would do push notifications and deep system integration without coming up with a brand new format and a brand new way of packaging and distributing applications. I mean, everybody else was using stores, right? But we've got some great examples now, things like TwitterLite, OlaCabs, Forbes, and Lyft, showing what's possible if we just add a couple of things that are currently missing from the web and how much better that can be. So what is that next set of apps? On the Chrome team, we've been kind of preoccupied with the question, why aren't all of my social and media apps progressive web apps? So back in 2013, we were struggling to answer the question, why don't web apps ever feel great on a phone? The answer was a set of capabilities that reinforced each other. To make reliable apps that loaded quickly every time, we had to solve the offline problem, hence service workers. To participate in a tap and swipe ecosystem on your phone, we had to make it possible for you to access them from the home screen and inside the notification tray. So we worked on add to home screen and notifications and manifests. So, what next? Well, we think it's a similar constellation of new capabilities targeted specifically at social sharing and media. We've been working on a lot of stuff over the past year to expand the power and reach of progressive web apps, but I wanna highlight a few that are close to shipping, namely, web share, improved media selection, image capture and shape detection. This is not by any means the full tour. There will be lots of other talks which will point you at a few of them, but rest assured we're continuing to expand the set of capabilities for the web. So if you've implemented a modern website, you'll no doubt be familiar with the endless opportunities for performance degradation that social media widgets add. As bad as that performance problem is on desktop, it's much, much, much worse on mobile. I promised I wouldn't turn this into a performance talk, so here's the shiny video. This is Twitter Lite using a new experimental API called Web Share. Web Share lets sites trigger a share intent on Android in exactly the same way native apps can. On other OSes, Web Share triggers whatever the built-in sharing system is too. Instead of pulling in half a dozen social network scripts to enable sharing, the browser can now do the heavy lifting for you. That's a huge win for performance and for consistency with EOS. Triggering sharing is pretty simple. You just call the navigator.share method with the data that you want to share, and you'll have to provide either text or a URL in order for it to work out. The API is asynchronous, so it returns a promise which integrates nicely with a new async function syntax coming to JavaScript. As you probably guessed, we're also working on the ability for progressive web apps that have been installed to handle intents too. That's happening via the share target API, and you should look for both of them in a Chrome near you sometime in the next year. Another major issue with sharing from the web today is that when you go to select a photo or a video to attach to a post, you'll often wind up seeing an intent chooser that looks kind of like this. Now, I don't know about you, but the difference between camera and camera wasn't immediately obvious to me. It turns out that the one on the left is for taking a still image, and the one on the right is for video. Who knew? The last one, files, brings you into a system provided file picker like this. This isn't the nicest UI, and while it's functional, it shares a problematic commonality with the first two. Because this is using the Android intent system to launch another application into the foreground, that means that Chrome can go into the background where it might be killed, specifically on a low memory device. So you sit there and you go through and you find the perfect thing to upload. Along with this post, you hit okay and suddenly the page is reloading. Where did it go? This is a pretty bad experience. So to get rid of the confusing dialogues and to deal with the memory pressure issues, we were working hard on a new UI that mirrors what most native apps have taken a shine to for similar reasons. Here it is. This new picker is faster and more intuitive, and I'm happy to say that it won't require any extra work from you to take advantage of it. Like the social apps you're used to, it allows you to select items from context already. There's also work happening to make background uploads of large media files easier, and one-shot background syncs are already shipped last year in Chrome. That means it's now the most reliable way to do an action like posting something to the web. It even retries when it detects that you're back online from a disconnected state. All of these APIs work together to make sharing and media easier. And that's a big improvement for selecting photos that you've already taken. But what about camera-based apps? I always tell the team that the web is for cat gifts, and making cat gifts is too darn hard on the web. What's up with that? Luckily, they agreed, and the Image Capture API is shipping in Chrome 59. This API builds on Chrome's really great get-user media infrastructure to give you access to detailed information from the camera. It also lets you build your own controls to manage important features like zoom level, focus mode, color temperature, red-eye reduction, flash, contrast, saturation, exposure, I could keep going. It's a long list. And we finally are going to get control over those features on the web in the next release of Chrome. There's so many options for Image Capture that I'm not gonna go through code examples for them because it would be basically an exercise in regurgitating WebIDL. And I don't know about you, but reading WebIDL is not my idea of a good time. So luckily, the Polymer team has been paying attention to this problem space too, and they put together some high-quality components that let you easily integrate Image Capture into your app. Check them out at webcomponents.org by searching for the app-media component set. It's pretty great stuff. Something that's increasingly important for AR and media applications is the ability to quickly understand what's in a scene, though. This is helpful both for focusing when you're taking a photo, but also for matching effects to faces and things that you might have in frame. Interestingly, it turns out the face detection shape detection and text recognition are built into nearly all modern OSs, and in the case of things like QR codes, sometimes even into the firmware for the camera itself. That sort of thing is expensive and slow to do in JavaScript and can potentially jank your main thread at a moment when you really want it to be smooth. You're taking a photo after all. You want to put some pictures on screen. Like WebShare, having the platform doing the heavy lifting for you can really transform the quality of the application that you deliver to the end user. So we're bringing shape detection to the web. Using the new image capture constructor, you can easily grab a frame from input that's coming from the camera or any other media stream whose contents you can actually read. From there, the face detector lets you scan captured frames for faces, returning a list of detected faces with x, y, width, and height attached to each of them. You can capture multiple faces in a single frame, and this API takes care of all the fiddly bits for you. Same for the barcode detection. It works exactly the same way. You grab frames from the screen and pass them into image capture, and then you decode them using the new barcode detector object. It does exactly the same thing, except that barcodes not only have x, y, width, and height, but they also have a raw value, giving you the decoded value of the QR code or the barcode that you're currently looking at. And while this may not seem like a big deal to those of us who don't live in countries where QR codes are used every day, in many parts of the world, physical commerce is increasingly mediated by the ability to quickly scan QR codes. This capability unlocks the ability for progressive web apps in the web to compete on equal footing, letting commerce-focused progressive web apps easily integrate a heavily used feature at much lower cost. You no longer have to send your own QR code detection library down the wire. This is great for users. And there's so much more to say about media. In fact, John and Francois are giving a whole talk focusing on playback on Friday at 10.30, which you should absolutely check out. The set of things that you can do today with service workers in the web's built-in media stack blew my socks off when they showed me the demos. I think you'll be similarly impressed. Also, be sure to check out Owen Campbell Moore's talk on building great user experiences tomorrow at 11.30 over on stage two. We've learned some really important lessons and common patterns in working with partners over the past few years, and his talk is gonna be essential if you're just starting on that journey. It'll help you learn a lot from the things that we've learned.