 Good morning. I hope that all of you can understand me today. And maybe I'll get some help with translation from my friends over at the side. So my name's Owen Campbell Moore. And I'm here to talk about web push notifications. And I'm a product manager on the Chrome team. And I have a clicker. OK, so the outline for today. First, we're going to be talking about what are web push notifications and why are they important. And then we'll go on to talk a bit about how do they work and how can you implement them on your site. And then we're going to wrap up with a sneak peek into the future of these features and some of the new things that we have coming down the pipeline. But before we start with what these are, I think it's important to take a step back and ask ourselves, what's the context in which these features exist? So this is something that we've been talking about a lot today. The idea of the reach that the web has. And this is something we've really come to realize in the last year. Here you can see in numbers the average monthly unique users for the top 1,000 apps versus the top 1,000 mobile websites. And you can clearly see that the top mobile websites have, on average, 2.5 times the number of monthly unique users that the top native apps do. But the struggle is, how do we take these monthly unique users that we have on the web and convert them into weekly active users or even daily active users? And this is especially difficult in contrast to native apps, which really take advantage of the capabilities of these mobile devices like push notifications. So this is the question that we ask ourselves. How can we take this amazing reach that the web has and combine it with the engagement capabilities of these mobile devices like push notifications? Is this even possible? And so I'm going to try and answer that with a demo, which I know is everyone's favorite way of answering a question. And the thing to note about this demo is that this was recorded earlier this week running in Chrome Stable on my phone on a local host server. And nothing that you see here is pre-release or experimental. This is all in production and working today. You could go off and build this weekend and ship it to your users on Monday. So let's imagine, OK, in that case, I'm going to just describe for you what you would have seen. Demo gods, man. Let's give a round of applause for the demo gods, please. OK, so what I was about to show you is an experience that I pulled together where I was going to go online and look for some concert tickets in San Francisco. And I was going to see that a band I really like was listed on the site, but they hadn't yet announced when their concert was going to be. But the site had this new amazing feature using web push notifications, where I could opt in to receive a notification when the concert dates are announced, allowing me to buy a ticket to go and see that concert. So I would have clicked through to accept the permission to receive notifications from this site. And then you can imagine that I close off the site, Chrome is not running, and weeks or months later, I'm kind of stood in a coffee shop. I pull out my phone, and I see a notification. It's from that ticketing website, and it tells me that the tickets are now available on sale for that band that I love. And now I'd be able to buy those tickets and get the best tickets before anyone else, and I get to show that off to my friends. So that's really cool. So I think this is really the key here. It's that web push, we believe, allows you to take the reach that you're able to get on the web, like we saw with all of those monthly actives, and combine it with the engagement features of your mobile devices, like push notifications. And I think this is really amazing, because when you think about some of the most prominent experiences on mobile today, many of them are social and messaging, and experiences where you really need this kind of low latency notification as an enabler. And so that's been restricted just to native apps in the past, but now we can build those kind of social and messaging experiences on the web, amongst many other experiences like the ticketing demo. And so to talk a little more about the potential of these features and why we all really need to pay attention to them, I'd like to have you all join me in welcoming Nate Schloss from Facebook to the stage. Cool. Hi, my name's Nate Schloss, and I'm a software engineer at Facebook. And I worked on Facebook's web push implementation, and I also work on Facebook's use of new JavaScript technologies and new things that are available in the browser. So as a mobile first company, the mobile web is a key part of our overall strategy. Like you heard earlier today, mobile first does not mean native only. You can't have a complete mobile strategy without investing in both the mobile web and both native. And many people might think, all right, great. You're investing in the mobile web, but maybe that's taken away from a lot of the growth in native, or maybe you're investing a lot in native, and that's going to hurt the mobile web. But that's not what we see. The mobile web is growing, and it's growing at a similar rate to what we see on native. When we see native grow a lot, we also see mobile web grow at the same time. And when we see a lot of people really engage with the mobile web, that helps native just as much. This is especially true in emerging markets. In places like India, where the barriers to download an app are very high, and it's hard for people to go through all the steps, the mobile web is even more important. And it's often people's primary interface for interacting with Facebook. And similarly with the web overall, the desktop web is an area of continued strategic importance to Facebook. Many people still use the desktop web as their primary way to interact with Facebook. And it's an area where we need to continue to make a great experience, and overall just support and develop really well. And there are a lot of features on native that we haven't been able to bring to the web. The web is great for many things, but up until recently, it's been at a huge disadvantage to native, especially when it comes to re-engagement. One thing we've known that is very impactful on native for a long time is push notifications. It's great for people. They can see when they're missing out on information, click on it, and get exactly to where they want to go. So we've really wanted to bring push notifications to the web for a long time. And we implemented a proprietary push notification integration with both UC and Opera Mini. And it's been great. We saw a lot of the same wins for users and Facebook that we saw in our native apps. We know that push is great, and we know that people want it, and they want it on the interface that they use the most. So just because somebody uses the mobile website the most doesn't mean they should miss out on all the great options that they get from push. So when we heard that Firefox and Chrome and others in the web standards community were working on a standardized way to do web push notifications, we were really, really excited to do implementation using that as well. And we shipped a really great implementation on mobile, and we're going to ship our desktop implementation really soon as well. And as we saw on other interfaces, when we ship web push notifications, we see really, really great growth engagements. It's great for users because they get the notifications on the interface that they're using. And it's really great for Facebook because people come back to the site more and are able to engage. And this is a chart that shows the increase in monthly active users as a result of doing web push notifications on desktop. And as with any really great growth chart, it just goes up and to the right. So there's just a lot of advantages from being able to do web push. And we're not the only company that's been able to see such really great growth wins from web push. To talk a little bit more about that, Owen's going to come back up. Thanks, Nate. So we're going to try the demo once more. I think the northern monkeys have gone and tried some technical jiggery. And we hope. OK, yeah, OK. So now let's imagine that I've gone on this concert website. I'm looking to buy some tickets to go and see a great band. I noticed methodical tactic. They're one of my favorite bands. But I don't see any upcoming concert announced. But I do see a new option saying that I can get notified about future concerts by them in San Francisco. So I'm going to go ahead and notify me. And this shows the local host or the website it would be in production wants to send me notifications. That's great. So now I can leave that site. And I can even kill Chrome entirely and forget that I was ever there. Now, in a couple months time, I can be in my coffee shop. I notice my pocket vibrate. And there I have a notification appearing. And with one tap, I'm back in. And I'm able to buy the tickets for the concert. Now, back to where we were. So it's great to see these kind of results from Facebook taking advantage of features like this. But it's not just Facebook. Here's a stat from Beyond the Rec, which is an online shopping company. They released a web push on their site. And they saw a 50% increase in repeat visitors within three months. So this just goes to show how impactful this can be. So this is all pretty awesome, right? But how does any of it work? So in that demo, you notice that Chrome wasn't running, the site wasn't open. And yet somehow, it was able to run some JavaScript, download some resources, and show a notification. Like, how is any of that even possible, given what we have today? And the answer? Magic. Okay, so maybe it's not magic. But I think the theme of this summit is that whenever you see something and you think, how could this possibly work? Like, I just don't understand. The answer is almost always service worker. So it turns out that service worker is this amazingly powerful new primitive. But when we normally think about service worker, we think of something like this. It's a kind of small JavaScript file that we can keep on the user's device. And then when a network request is made to our origin, an event is fired into it that we can grab and we can generate our own response and send it back down to the page. Like, how does that help with push notifications? The answer is that we can actually flip this diagram around. And if we flip this diagram around, we can imagine a flow in which our web server sends a request to a push service. In Chrome's case, this is Google Cloud Messaging, which keeps a persistent connection open with the device. Now, with that persistent connection, it can say, hey, device, go and wake up this service worker. So Chrome starts running. It starts the JavaScript context and it fires a push event into it. And so in this way, the service worker is this amazing primitive that's giving us this ability to do event handling in the background on the user's device, but in a very controlled way. So the event fires. It's able to show the notification and then we can kill it again immediately. So these things don't stick around. They don't take up your battery. But they really provide a new, a bunch of possibilities for us as browser vendors and for developers to see what we can do with them. So it'll be really exciting over the next year to see all of the cool new APIs and functionality we can enable websites to have using this new primitive of service workers. Okay, so we've talked a lot on a high level, but this is a developer conference, right? So let's see some code. So here we're gonna talk through subscribing for push notifications. So this is on the site. When I tap that notify button, the first thing that I need to do is have the site set up with the push service, registering the service worker so it knows how to wake it up later. So I start by assuming that the service worker is already installed on the device. I'm able to call navigator, service worker ready, which returns a promise, which will resolve when it has the registration of the service worker ready to use. And then with that registration, I can call pushmanager.subscribe. And what this is doing in Chrome's case is sending a message to Google Cloud Messaging, saying, hey, I'm a service worker, this is my identifier, and you should know how to wake me up later. And you can see here that we're passing in user visible only true. Now what does that mean? Essentially the way that the push system is designed today, you could send a push message to the device, have this push event firing your service worker, and you could run something in the background. You could start mining bitcoins. You can do whatever you want and just not tell the user that something's going on. And obviously that would be bad for our users, and we don't want that to happen. So what you're saying here, by specifying user visible only true, is that you're committed that when a push event is fired on your service worker, you're going to make a change that the user can see. So they know that your site ran in the background. You're gonna show a notification. So in this case, it makes sure that sites are only running when users know that they're running and that you're using push to deliver notifications, not just to send an hourly push to take up cycles on that computer. So once this resolves, we're gonna get back a subscription. So this comes back from GCM and is essentially an identifier for the service worker. And then this is a function that you'll write yourself that just sends that subscription up to your backend. And then later you'll be able to use this to send a request to GCM in order to send a push down to the device. Okay, so that's subscribing to receive push notifications. Now let's talk through how we actually receive the push event and show the notification. So this is the diagram I showed you earlier about how the web server sends the request to the push server, which wakes up the service worker. Now it turns out this is only mostly true. And the detail here is that when the service worker event is fired, it actually doesn't have any context. It's not given any payload or any data from the push message. So this means that the service worker wakes up without context and doesn't know what it's supposed to be displaying. So the first thing that you need to do is send a fetch request or a network request back to your server in order to say, hey, I'm awake, what notifications am I supposed to be showing to this user? So let's take a look at the code for how this works. So here we're in the service worker code and this is our event handler for our push message. So when the push event fires, the first thing we do is we get this event. And so this line is kind of magic. So event.wait until basically says, hey, I'm running in the background in my service worker. You need to keep me alive. You need to wait until this promise resolves. When this promise resolves, I'm done. You can go ahead and kill me. This is how we get the performance benefits and how we make sure that it doesn't keep running in the background on the user's device. So the developer calls event.wait until. It then makes a fetch request to its server to work out what notifications it's supposed to be showing. It parses that into a JavaScript object. And then using that result from the server, it's able to use the show notification API and pass in the information provided by the server. And that is what actually shows the notification on the device. So it's been really awesome over the last few months to see a bunch of developers adopting this new capability and exploring different UX that they can build with it. And I think it's interesting to share some of those lessons that we've all learned together about how to build a good experience with push notifications. Now, some of these lessons came over from native and some of they're entirely original to the web. So here's the one that I think is the most important thing. Make sure that you're sending notifications that users care about. Now, as this is a new kind of communication channel with users, I think the first thing that a lot of us think is great, I'm going to vibrate that pocket whenever anything happens and take all my email and send it to them as push notifications. Now, I think it's important first to ask yourself is what I want to send them, both urgent and important? Because if it's not urgent, you probably don't want to be taking them out of their context, vibrating their pocket and disturbing them. And if it's not important, but it is urgent, then it's also not something that you probably want to disturb them for, unless you think that it's very likely that they're going to be interested in it. So take, for example, that there's a live stream starting. This is urgent. It's starting right now, right? But do they have any interest in this live stream? Is it a topic that they care about? If yes, and you think that there's a high probability that they're going to go and click and watch that live stream, then it's probably a good notification. If you're not sure or they might not be interested, sure it's urgent, but it's actually not important to the user. And the best examples of push notifications are those that are both urgent and important, like an incoming chat message from a friend, or your vehicle has arrived outside the building and you need to go and get in it. So those are the kind of experiences we really want to be building. And another thing to remember about this is that Chrome makes it really easy for users to disable notifications from sites that they find are using it spammily. So if you start sending notifications too aggressively, users are going to disable it, and then you'll never be able to send them more notifications and take advantage of this new stream. So use it carefully. The next thing is not requesting permission on page load. So the story here is we first shipped this capability back in May. And in about June, I was landing on a blog, and I saw a permission request pop up, and it said, hey, this site wants to send you notifications. And at first I was like, oh, this is so awesome. A feature that I built is real, and people are using it. How cool. And then the next week, the same thing happened. I landed on site, and this permission popped up. And I went, hm, I actually don't even know what they want to send me notifications about. And I don't even really know what the site is yet. I haven't had a chance to take a look around. So I think the key here is not to forget the lessons that we've learned about general UX. Make sure that users understand what you're asking and why. In this case, I think Twitter have done a really good job of this, where if you go in the direct messages panel on desktop, you see a new section that says, would you like to receive notifications for new messages? And in the ticketing example earlier, there was a box that said, do you want to get notified when these tickets go on sale? And then when the user clicks enable notifications or notify me, there's a lot of context, and they understand why they're being asked to give permission. So it's really important to make sure that we remember those lessons when building permissioning flows, because a permissioning flow is a first class flow within our site. Just because the UI is being shown by the browser doesn't mean that we can forget the UX that leads through that process. The next thing is making permissions controllable. So this is, again, back to the fact that we've made it easy for users to disable notifications from sites they don't want. But you don't want them to do that. You want them to first go into the settings on the site and try and control what they do and don't want. So here, Facebook have done a great job of letting you go in and say, I want notifications for when I'm tagged in a photo, but not when someone comments on one of my photos. And this is a great example of control that you should be giving your users. So this is a really meaty topic now, de-duplicating with native. So you can see an example here of notifications. Imagine I installed the TicketNow app and I'd been on the TicketNow website and accepted this permission request. Well, now we're in this difficult world where I might get notified twice, once from the app and once from the website. And this is a problem that we're trying to solve and there's no ideal solution today. And we're looking for kind of suggestions and ways that the browser can help you do this and new tricks that we as developers can use to do this. But the best advice that we have today to deal with this is two things. Firstly, you can use a kind of heuristic that says, if the user's logged in on two different platforms, don't send notifications to both of those platforms if the device looks really similar. If it has the exact same screen resolution, it's probably the same mobile phone and you don't want to send it to both. So be careful about that. And the second thing that you can do is when the user taps turn on notifications in your site, you can actually fire an intent into the native app on the device. And so if the app is installed, it'll open up the native app. And you can in there say, hey, notifications are turned on. You can control them in this way within the native app. And if the app isn't installed, you can specify the URL that the user should go to to complete this opt-in process. So again, this is an open area that we're working on and we're looking for feedback and new ideas as we go. But these are some of the best practices we would suggest at the moment. Okay, next is refocusing existing windows. So when you get a notification on mobile from a native app and you tap on it, it takes you to the app and the app takes you to the exact page that you're looking for. This is great. Now on the web, if you do this naively, you'll just end up creating new tabs and new tabs. And then in the tab switcher, you'll see pages and pages from the same site, especially if you're doing a low latency use case like messaging. So the key here is to refocus the existing page that's already looking at this site. So if you already have a window open on the device, which is on this site, you should navigate that to the new page and focus it. So let's look through exactly how you do that. First, in the service worker, you can use the clients.matchall API to get a list of all of the active windows that your service worker controls on the device. And then if there is at least one of these clients, you're gonna go ahead and send a post message to it saying, hey, navigate to this new URL and then you have to receive that post message on the other side and actually do the navigation and then focus that client. And if it turns out that you didn't have any windows open, you can just go ahead and open a new window. The next thing is to make sure that you're summarizing your notifications. No one wants to open their notification panel on Android and see that one app has sent them 15 different notifications all for different chat messages within the same thread. So you should always think when you're showing a notification, you should use the API to find out what notifications are already showing, work out how to group them and summarize them the best and then replace the one that you have currently showing with the summarized notification that groups up all of the interaction that's happened since. And the last tip I wanna share is a throwback to Jeff's talk, which was earlier today and you can find online on YouTube about loading instantly. So when the notification is there, you've got to run in the service worker in the background, right? That doesn't mean you can just download the notification contents and show it. You can also download all the resources to show that page, which means when the user taps on it, if you've built your app shell correctly, the page can load instantly and the content in the page can load instantly. And you get this amazing experience and it works even if they're offline. So if they get a notification saying they have a message and then they go into a tunnel, they can still tap on that notification and get to that message immediately, which is an amazing experience. Okay, so we've talked about what these web push notifications are and why they're important. We've talked about how to do them and how to build a good experience with them. So finally, I want to talk about what's next, what's coming down the pipeline. The first thing I'm really excited about are custom actions. So here you can see this notification includes my custom button. So you could set this to say whatever you like and you can do what you like when the user taps on it, open a new page or just send a network request, change the contents of the notification. So you can imagine being able to build entire experiences that work within notifications. So imagine that you've gone on an auction website and you've set a bid on a product and then you get a notification saying, hey, you've been outbid, but there's a button on it that says, increase my bid to X dollars. This means that user can just tap that. They don't even need to go back to the site. You can say, great done, they can swipe it away and you've built this entire flow all within the notifications. I think this is really powerful and something that we're all gonna get to play around with. This is available in Chrome Dev today so you can start playing around with it. And the next thing that I'm really excited about is payload. So earlier you'll remember that I said that when the push message is received in the service worker, you have to make a network request back to the server to find out what happened. So this is changing with payload support and what this basically means is that your site is going to be able to include some data, basically serialized JSON with the push that it sends to the push service and then that'll be sent down and included when the event is fired on the device. So you'll know immediately what you're supposed to do and you don't need to make the request back to the server like you did before. Okay, so to wrap up, since May of this year, Chrome for both Android and all of the desktop platforms has supported the new web standard designed together by Mozilla and Google and others in the web standards community that enable web push notifications based on service workers. Web push is really fundamental to this idea of progressive web apps and service workers are providing this new fundamental capability on the web like we've never seen before. And web push is making real business impact to companies like Facebook and Beyond the Rack today and we can't wait to see what you build with it next. Thank you.