 Hello, good morning. My name is Rowan Mierwich. I am a developer advocate for Chrome. That means nothing to anyone that I ever tell that title to. So suffice to say, I will explain it over the course of this presentation for you. I would like to get to know all of you better, so please feel free to follow me on Twitter. You can ask me questions there. I have conversations. I also have a Google Plus account. Can I use something? There's normally one of you. OK, OK, I'll move on from there. Today I want to talk about creating a capable web for everyone. And to answer that, I just want to explain why am I here. Now, when I wrote this slide, I realized that this might be a slightly philosophical question for 9.30 in the morning after one cup of coffee. And I'm trying to distill it down to something a bit more practical. Why is Google here? Why am I here representing Google to Drupal? And that's because we believe that a safer, faster, richer web is going to be better for everyone. And when I say everyone in this context, I mean this. I mean it's going to be better for users. I have an amazing slide that I wanted to put in here, but I've used it too many times. Have you ever had that experience on a website where it's loading and you're about to click on the thing that you want to interact with? And suddenly an ad jumps in right in front of it and you tap on the ad instead. So that's bad for users. There's a perception that the mobile web is something that is a less quality experience than using native apps. It's bad for businesses because if you can't present a good experience on the web, you're not going to be able to do good business on the web. Bad for developers because, frankly, who needs to deal with 50 different browsers or with their own different quirks? Who needs to deal with JavaScript frameworks that release a new version every six weeks and completely change the API underneath you, meaning you need to learn everything all over again? And it's bad for platforms as well, because rather than being able to build a stable base, you end up having to build in all of these different compatibility layers. You end up with years of legacy work that you need to try and maintain. And finally, it's bad for browsers as well, because we are also doing that thing where you know everybody always says, it's kind of like, hey, look at the first web page from CERN, right? You can still access that today and it still works. Do you know how many web APIs are still sat there inside of Chrome that we load up every single time just in case someone goes back to one of these ancient web pages? Okay, the problem is though, it's very easy for me to say that, but building for the web is too hot. And this hurts all of us, okay? So it goes back to this again. And it's the same argument because I skipped a header slide and started telling you about this, rather than all the good points of the web. But that's fine because I have too many slides for an hour, so we're gonna speed up through this. Now effectively, the reason it's too hard is because of this. Easy and achievable does not imply that it is also good and safe. Now, I will highlight that I looked up those things. I'll give you that, because I wanted you to think that I'm clever and know this. Okay, so to give you a little bit of history, this is how I first started developing web pages. When we got an internet connection into the house, this was what I had available. To me, I had a notepad, and it was a Netscape navigator at the time, and of course, what I discovered was animated chess as well. So I wanted to build my first web app because I discovered that the internet connection also came with some shared hosting and some shared web space. So I went in, I did my little about me page and decided I was gonna add a guest book. So this is my first web app. I have a general rule that when I go along with the language, I make sure that the only code I show is code that does not belong to the language. So don't worry, you're not gonna see any PHP code in this presentation. I'm gonna start with Perl. Well, no, not yet. Sorry, I was full of the surprise. Okay, if you have a problem with Perl, look away on the next slide, okay? So this is what I wanted to do. I wanted to create my guest book so you can see there's a form there and you're going to come along and you're going to read my page and then you're going to leave your name and location and a little comment about how you found it and trying to prompt me to join your web brain. Okay, so what happens when I actually press submit on this? Well, this is the kind of Perl code that I was writing that I found in a tutorial. Now what it does is I set up the product, my guest book there. I'm requiring indeed the CGL library so far. Now we also, there can be a little library there that would take the post data and pass out the variables that you can use. So it's kind of like accessing the post to the global array, engaging it. So what I'm doing is I'm getting my comments out there. I'm going to openly get a swap file, okay? And I'm going to append the contents of what someone referred to before. And then I'm going to close that part and we'll review that subject practice. I know it's early, but can anyone spot any problems with this code? No? Okay. Sanitization? Yes, that's possibly a good one. Is this game to do what I want it to do? Is this game to write to my guest book? Yeah? Okay. No, no, Perl, the best one's here? I'm shocked, right? Actually, what I've written here is it is a guest book, but it is also an open write access method to my entire file system. You can put whatever you want in that post data and then I'm going to open up a file on my actual drive. So first of all, it means that the web server has write access to that directory. That's a terrible idea. Second of all, I'm just opening one of the files that I'm trying to serve and spitting out exactly what people put in there. This is a terrible, terrible implementation, but it got me started and it got me results. I really enjoyed it and somehow I've ended up here today. So luckily, if you did this kind of thing now, who knows what your page would be filled with within about five minutes, but these were more innocent times when you could get away with these kind of mistakes. Now, where does Drupal come in to all of this? I think the days of the whole actually having to, you know, FTP your stuff up to your shared web hosting, those days are past. Getting into web development now is a lot easier and in fact, getting into creating content on the web does not mean that you need to be a web developer either. Anyone is able to come ahead and do this. And so I was actually, before I came to Google, I was doing PHP consultancy, I was doing some symphony work and I actually met Drees at an event and it was around about the time that he wrote this article, the assembled web, which I think is actually about 2013 or so. But I really like the way that he was talking about the users of Drupal here, where he was saying, we're not talking about web developers, we're talking about people who assemble pieces of content, people who come to Drupal and they don't necessarily know how to write for the web, they don't necessarily know PHP or HTML, but what they do know is how to go into the Drupal interface and start selecting modules, selecting components, building workflows that solve the problem that they have and allow them to create content on the web. And so that's why I want to talk to you as well, because you are all here responsible for shaping that ecosystem. And it's not just Drupal on its own. The work that you do inside of Drupal has an effect back on the underlying PHP language. The work that you do here also affects the wider CMS community. So the thing is that Drupal does, WordPress will be looking at that, Juno will be looking at that. These other CMSs are all looking at what is going on inside our wider community and how do we build that together. And of course, not that long ago, you now have Symphony underneath inside of Drupal, so again, you're sort of part of that community. And on top of that, we've got jQuery on the front end, so that's yet another huge ecosystem that you are now partaking in and you have the opportunity to drive the direction of it. And also what I wanted to say is one of the issues that I sometimes have inside of Google is that I am surrounded by a huge number of incredibly smart people, often people who wrote a particular standard on something when you want to ask them a question about it. And I was at a conference that I won't name, but it was a sort of very fancy, high-performing front-end framework. And I had gone out for lunch and I had been deliberately not wearing one of my Google t-shirts, I was trying not to get asked a million questions. I had gone down to the end of the garden to quietly eat a sandwich. And a couple other developers came down as well, so we were all just stood around this little table eating. And we had just had a talk on a sort of brand new technology and what should be happening inside of it. And they were talking about this, they were sort of saying, it's kind of like, I love seeing all of this stuff, it's amazing, it's really performing, it's really elegant, it's really clean. But when I actually have a job to do, I still just turn back to jQuery because I can just plug those things together and it works. So this is always the attitude that I want you to be going forward out into the ecosystem with. Developing for the web should not be hard. It should be possible to just create the best experience by default. So that's what I want you to really focus on. Whenever you're building an extension, whenever you're building a site, I want you to be thinking, am I keeping it simple? Not just for you to develop, are you keeping it simple for your content creators to maintain? Are you keeping it simple for your users to understand and navigate through and interact with? And importantly, is there a safe experience? With that said, I want to dig a bit into the state of the web then and what that means. And I'm going to start with HDPR. Has anyone visited or seen this already? Yeah, I see some nodding. These are also the points where if you are... I like to try and gauge the interest in my talks as I'm going, so if you're bored, please feel free to start looking things up on your phone or falling asleep, and I will pick up the pace and try and make things more interesting. If I'm going too fast, look at me in a confused way and I'll try and slow down and make things a bit more obvious. HDPRchive is an open data source that gives you information about the top 10 million origins on the web, I think, at the moment, and it provides a number of reports inside of there, so you can go and you can just explore the various reports around things like loading speed on the web, performance on the web, use of images, use of JavaScript, and what we added into this relatively recently is what we've been calling lenses, and we've added those lenses on... well, on Drupal, WordPress, and Magento. So you can look at all of the reports and then you can also go in and you can filter it directly to Drupal, so you can do a comparison between the state of Drupal, the state of the general web. I really like to think that this is a very good tool for competitive analysis as well if you want to know what your competitors are doing, whether you're performing better than the general ecosystem, this is a very good way to try and gauge yourself in there. And while that is about 10 million overall sites, I think you're looking at about 95,000 Drupal sites inside of there, so that's the size of the sample that you're looking at for these sets. Okay, a brief diversion then before we get into the next section. When I submitted my talk, I wrote in the prerequisites what I thought was like messages directly to the organizers, and it is. But what I also discovered, I loaded this up in the Incolonial window, is like this is completely public, so luckily I didn't write anything insulting or offensive in there, but I just wanted to highlight that this is the prerequisite I'm asking of you, okay. I just need you to be mostly here. Yes, and conscious, okay. Now, that may sound like a low bar, but I am going to put that to the test now. Okay, so, what was the name of that game show with Bruce Forsythe, where he did the cards... Play your cards right? Okay, play your cards right. I never watched it, but what I gleaned from that is that there's an element of shouting higher or lower, okay. So what I'm going to do is, I will show you a number for the web, and then I want you to shout higher or lower about Drupal, and when I'm satisfied enough time is passed, I'll show you what the Drupal number is. Okay, so to get us started then, the first one is percentage of... Percentage of HTTPS requests. So who would like to just shout out a random stab on the web? What percentage of sites do you think are HTTPS? Forty. Forty? Do you mean only HTTPS or both HTTPS and HTTPS? I mean, a percentage that will respond to HTTPS requests. Five, sixty-three. Yeah, so we're at sixty here. Higher, lower, lower, lower. Thirty, thirty-five before. Okay, well let me... It's actually, it's actually pretty good. Seventy-five percentage of the web. Respond to HTTPS requests. Okay, okay, now the heart of it. This is also where I'm trying to gauge what your sort of internal perception of Drupal as a platform is as well, how you feel about performance and so on. So, Drupal sites on HTTPS. Higher or lower? Higher. Lower. Higher. Higher. Higher. Okay, okay, I mean it's England so I'm hearing a lot of mixed voices down here. I assume I have a strong mandate to continue. Yeah, it's actually... So this is percentage of pages with a known JavaScript vulnerability condom. Where do we think the web is on there? Thirty-five. Thirty-five. Higher, lower? Higher. Higher. Higher. Okay, fifty? Fifty. Higher. I have a high... Yeah, a hundred. Seventy-seven point five percent. There's no vulnerabilities on the pages. Drupal. Lower. Fifty-three percent, so... So I'm feeling... I'm worried I maybe made you a bit overconfident. So, if any of you need to get your laptops out right now and run them out, I'm not going to be offended. Your head's going to be offended. Okay. This is measured in seconds. So, how long does it take to get some content onto the screen in front of the user? And I believe this is assuming on like a standard 3G connection here. So, who wants to, like, value in seconds for a first component or for a page for the web? Three, eight, five, two, four, one point eight. Oh, okay. You're going to get a city. Okay, the web is 5.8 seconds. Drupal. This is the home page. So these tests are all run against the origin of the site. So, is anyone saying lower? Okay, I... Is this measured across all Drupal? This is all of these origins that were detected as Drupal. So, any judge. So, actually, I mean, you're right, but not that bad actually, right? So, Drupal's not causing like a big performance hit to your first component or page compared to the rest of the web. Okay, this is where we get a bit more esoteric and I'm kind of testing your knowledge of modern metrics as well. Time to interactive. Who knows what that means? A couple of you, it's good. Don't worry, because by not putting your hands up, you've validated the next few slides. Okay, time to interact. Someone give me a number? Pretty good. Drupal? Actually pretty good. Okay, we all like shouting out numbers and we all like metrics as well because we're developers and we have this sort of belief that if you put a number up there, that actually means something. Let me explain what these numbers mean and why we talk about them. Okay, this is your average page load. So, you've probably all sort of seen this kind of layout or shown it to clients. I'm trying to load up the Google site here, search for Sundar and you can see like the content popping in and so on. Now, if you load up DevTools on your browser and look at the performance timeline, you'll see this kind of layout which is showing you like the work that is happening on the main thread. The bit that I wanted to focus on there is those big blocks of yellow. That's where the CPU on the device is occupied and processing the JavaScript. Okay, and when we talk about these two metrics, first contentful paint, that's basically how long does it take for us to see something on the screen. We try and say first contentful paint here, and then simply first paint, sometimes like first meaningful paint because the idea of this metric is not how long does it take you to put a block of solid color on the screen, but how long does it take you to show the user something meaningful about the page. Now, the other metric, time to interactive, this comes down to the, have you ever been loading a page and you've been trying to scroll through it, but as you start scrolling through it, it just kind of stutters and janks. That's because of that block of yellow there. While the CPU is still busy because JavaScript is inherently single-threaded, it means that if you're busy passing the loading JavaScript, the browser can't actually do anything else to maintain a good framework. So this is where we start looking at how many JavaScript libraries are you loading up front, how much work are you doing, how many interactive things are you booting up on the page, and how long it takes for the user to actually be able to interact with your page. How am I doing for this time? Cool. Okay. Now, those are good metrics, but we wanted to try and create something a little better. So one thing that we started proposing now is what we call the input delay. And this, again, tries to get closer to actions that the user is performing on your site. First input delay is can tap an element on the screen how long does it take for the web page to be able to start reacting to that. So this comes into the combination of time to interact with, because obviously if I tap on a button while you are busy loading all of your libraries, nothing is going to happen until that loading is finished. However, this is a little harder to measure in a sort of abstract state because it actually requires people pressing the screen. Right? So that's why we try and make this differentiation. Over here, we've got lab metrics, and by lab metrics, I mean things I can measure in isolation. Okay? So that's why things like time to interact with or the seed index that we present, because these are purely mechanical numbers we can get from just running the application. Then on the other side, we've got field metrics. Field metrics meaning things you need to collect from actual users using actual browsers. And that's why we start looking at things like field input. Now, you probably don't have a huge number of ways of getting access to this kind of information. Either you need to add the instrumentation to your own page, which can be tricky, and could also be an overhead on your page as well, that you don't necessarily want to add. So that's why I would like to introduce you to the Chrome user experience. Who's already seen this? Amazing. It's actually quite heartening when I'm kind of like, yes, I am telling you something new. You're not just nodding to a newsmeet. Okay. The Chrome user experience report is tied into the HTTP archive. What we have done here is we've taken all of the aggregated metrics that we have from Chrome users across all of our devices and presented them back as an open data set that you can dig into. You can access this through BigQuery, you can access this through Data Studio, and it is broken down by country-specific regions. You can access things like what was the connection speed that the users were on. I think there are things in there around like device power, screen size, all of these kind of bits and pieces. You can create your own custom dashboards inside of this as well. So inside of here, I've just built out a spread of the first contentful paint over the course of months. And I can track this across well, by whatever things I want to do, I could do this as a first contentful paint on 3G devices in France. So you can start segmenting this any way you want. And we started off with 10,000 origins. We're actually up to 4 million origins at the moment. So again, your personal site may not be in this data set, but if you're trying to understand the state of browsing in a particular target market or for a particular competitor, then this is a great way of diving into those figures to see who your users are and what kind of experiences they're getting when they're on your site. Okay, the next thing then is how do you actually measure this when you're doing development? Who already uses Lighthouse? Ah, good, right. So Lighthouse is built into Chrome developer tools. If you open up the developer tools and you go across to the audit panel there, you can run audits against your site that will test for a number of best practices. And a little bonus that I wanted to point out to you here, you see how the light from the Lighthouse is overlapping use there, right? There's a little message to use Lighthouse. That is what we in the advertising biz call a subliminal message. We need to cut that out of the video, that's secret. So this is what I would like if you'd be looking at on a regular basis looking at the best practices and the audits when you are creating the individual pages on your own machine. And to give you an example, it looks like if you run Lighthouse against a given site, you'll get this report back that will give you these top level scores. If you're trying this in the canary version of Chrome, we've actually moved away from doing the score for progressive web apps to giving you a badge that indicates the amount of functionality that you've implemented there. And I know what you're thinking. You're thinking, well, you're thinking when is it going to be finished so I can get another major role. You're also thinking, well, I'm so glad that you gave me another set of performance numbers when I just managed to get people to stop obsessing over page speed insights and now you're telling me there's another way to measure speed on the web. You're happy about that, right? More metrics is better, right? Especially if those speed numbers don't necessarily always tell the same story. Okay. What I can say though is page speed insights is now powered by Lighthouse as well. So the messages that you're getting from page speed insights will match up with the messages that you're seeing in Lighthouse. And you could also dig into the Lighthouse report data from page speed insights as well. And on top of that, there's a page speed insights API so you can now also get those page speed insights back just by doing a simple call against the JSON endpoint and that in turn will include the Lighthouse API results too. So if you want to set up performance monitoring against production sites, then this is an ideal way to do it to just track the performance over time. So to give you a quick review of that, over here on the benchmarking side, you've got page speed insights. That's the site that's already out in the wild. The stuff that you're working on that isn't publicly accessible, is on your own machine. You want the Lighthouse extension or the functionality inside the DevTools. If you're adding it into your continuous integration environment or into your build checks, there's a Lighthouse CLI component that you can get off of MPM that will allow you to hook that into that process. And finally, the page speed API for doing your production monitoring and making sure that that performance is retained over time. Okay. So to take it back to keeping it simple and keeping it safe, we are now armed with all of the metrics we will ever need to monitor our sites and determine whether we have achieved these performance goals, whether we've achieved these technical goals. Why am I telling you this? Well, because like I said, you are the stewards of the ecosystem here. Okay. You are the ones who are out there building this stuff. Not only that, it's Saturday morning and you're here. I'm here talking to you. You're here listening to me when actually I could be in bed eating Netflix, eating a fried egg sandwich. But I'm not because I want to do this and I want to talk to all of you and I assume you are here because you care. You care about improving your own career. You care about improving your sites. And hopefully what I really want you to take away from this is that you are also responsible for improving the web as a whole. It's not just Drupal on its own. You're part of a huge ecosystem here. So maybe nothing I told you matters. Maybe apps and sites are dead. If I've just done that, I should do the other thing that you should never do in a tech talk, which is a car analogy. So before I get back to whatever was on that previous slide, this is a 1984 trying to proclaim CD. This is actually the first car I learned to drive in. By learn to drive, I mean my friend lived on a farm. We were kind of the barn. We ragged it around the field into a ditch and had to get its dad to pull it out with a land rover. But what I'm trying to get to on this is there we go. Hands up. I don't shout this out. Hands up. Who knows what this is? Okay. I'm not going to say anything about the age of the crowd. Okay. So this is beautiful for a number of reasons. This is called a choke. And this icon is like a master class in semiotics, which is the study of iconography and what icons mean. Now in an older car like this, the choke, you had to pull the choke out before you could start the car. Or not before you could start the car, but if you wanted the car to start pulling the choke out was generally a good idea. And what would happen here is the reason the icon looks like this is because when you pull this out, you're actually adjusting the valve inside of the engine. That changes the fuel-air ratio. Because basically, I almost forget which way around it is, you want more fuel in the engine to start it because the engine is cold. Once the engine gets hot, you put the choke back in, you can change the fuel-air ratio Now, this is not how cars work today. Cars work today by as long as, well, if you have a modern car, as long as your fob is in the car, you press the button and you go. And what's my point here? Why am I showing you this? Well, this is because if you wanted to use a car, like just, I want to say 20 years ago, but this is not 20 years ago, this is longer than that. If you have a car in the past, then we require this much higher level of education. Like, you had to start learning about how the engine worked when all you want to do is go from point A to point B. So that's really what I'm trying to say. Not that apps and sites are dead, but apps and sites are implementation details. We've lost so much training onto our users. Right? They understand that, like, oh, if I want an app, I have to go to the app store, I have to go to the play store. I have to make sure that, actually, I've done my homework and the thing that says Amazon really is Amazon, or if it's telling me that I can get all of these videos for free, maybe there's some kind of catch behind it and I shouldn't give them my credit card details. We've tried to train people on the web, right? Not to just click through every single one of these things. Maybe that person has emailed you to access your webcam, wasn't actually able to access your webcam, you don't need to send them any bitcoin. So, not all of these things where we've created this amazing platform, but we've put such a cognitive load onto our users to force them to understand the difference between an app and a site. And I don't think that's necessary. And I think we're moving towards a model where it is no longer I need to install an app or I need to go and find the right site. It's just like I just want some pizza, right? Give me a connection to the restaurant that will get my pizza for me. I need to get from A to B. So bring me some mode of transport that will get me from A to B. So with that, I want to give you a little teaser about progressive web apps. And if this section gets you interested, then Elliot has a talk later today and I'll go into the formal detail on how you can achieve this. But this is the keynote, so I'm just going to do all the glossy bits and skim over the detail and make you think it's really easy. Okay. Who's heard the term progressive web app before? Good, good, cool. Starting to purpleate through the industry. The progressive web app hit the term that allows you to raise your expectations and by that, I mean you as a user. And by expectations, I mean that you should no longer be worried that the web is like a second class experience when it comes to apps. And secondly, it's a term that allows us to quantifiably define that good modern web experience. And by us here, I mean developers, people who create like people who maintain this. And primarily I say this as well because I don't want you to leave thinking the PWA is simply this decade's Web 2.0 where we add some rounded corners, some Ajax and charge 10 times more for it but no one really knows exactly what it is. A PWA has a concrete measurable definition. It's an umbrella term for a collection of technologies but it is hopefully not a meaningless buzzword. And I'm not just saying that because my job depends on it. Now to give you an idea of what I mean by a progressive web app. This is, again, if you want another opportunity to get your phone out, this is your chance to play along at home. If you go to mobile.twitter.com or I think you've been just Twitter.com now as they're continuing to transition their experience over, you'll see something like this. And down the bottom, if you're using Chrome, you may get this at the home screen prompt. In other browsers like Firefox and Samsung they do things like they add the home icon actually in the only bar at the top so different browsers treat this in different ways. And if I tap on that add to home screen option I'm going to get a little pop-up here and I run that and we're going to get a notification saying that it's going to add a community and I can open it up. I've got a Twitter icon on my home screen I can load it I get a nice little flash scene starts loading up tweets then I'm back on and I can move out to the app switcher and now as far as I'm concerned this is the same as an app if I open up the info page about it I'll see all the same things that I expect to see from an application it behaves in the same way an application does it sits inside of my task switcher it's got its own icon I can receive notifications if I load this up when I'm offline then I won't get the Chrome dinosaur anymore which I know is a little bit sad I will get a meaningful error message from Twitter they'll show me the Twitter interface and let me know that I'm not connected to the internet and that I can get my tweets when I'm back on bonus offer here if you want to ask me questions later trusted web activities is a good starting point because if you're saying to yourself Rowan this is all well and good but how do I get my progressive web app into the play store it's your opportunity to talk about that however what I told you there was a laundry list of features offline notifications at home screen this isn't focusing on the user and what I mean by that is last progressive web apps is a big good banner for a bunch of fancy technology it's not focusing on value that you're bringing to people by enabling this so I really want you to be thinking about functionality over the feature set and to give you a little indication what you might go about adding this into your own businesses or your own sites I also don't want you to think that progressive web apps is sort of this brand new shiny thing that requires a complete rebuild of everything that you've written this collection of technologies is something that you can adopt incrementally so I want to show you the method that I'm kind of pushing for this which is you can create these discrete and non-invasive use cases by discrete I mean very clearly defined boundaries you're creating something bite size that you're going to implement and by non-invasive I mean you're looking for opportunities where it doesn't sort of spread out tendrils into other parts of your application you can view this as a very stand-alone very isolated measurable experiment CDM to value okay so to give you an idea then I'll show you this this is an enterprise architecture diagram you can tell who is at the cloud and this represents the architecture between your user their browser through the internet to your site so this is them browsing on your site they're happy because they're giving what they want to but then they use their connection they can't load the site anymore they're unhappy things aren't working that is where service worker comes in so service worker is what I like to think of as the kind of beating heart of your application on your device to put it technically a service worker is a piece of javascript that the browser will install into the browser for you that can run even while your site is not loaded this means it can act like a proxy server between the browser and the internet to start doing these things like caching content for the user transforming responses loading error pages if the user doesn't actually have a connection to the internet and just trying to put this into a real example for you, you can do this on top of that if you go along I was at another event over in Dublin and realised that because I travel a lot I travel a lot and I'm still not very organised so I still end up in hotel hotels at the last minute so I was trying to do this from the Dublin runway which does not have very good internet connection so if you look at Dublin you get a list of hotels there but now what will happen is if you go offline the trago site will save you but they detect that you lost your connection so they grey out your form because you can no longer interact with that you can't do any new searches but they've cached the results there and importantly if you refresh that page you get this you get a message now when I first saw this and I was talking to the team I was kind of like this is what happens when you give developers Friday afternoon hacks they come up with this kind of nonsense and so what this is and I encourage you don't do this in other people's talks you can do this now because this is fun if you go to trago and you put airplane mode on this is actually a little tilt maze so you can tilt your phone around and you can navigate the thought through the maze there to try and solve the maze but that's not the important bit what's important here is that you're disconnected but you're still on the screen that says trago so as they understand what's happened you're currently offline and you've got a little countdown there so they're going to try and reconnect you in 11 seconds and this was that instead of people losing their connection and dropping out of the funnel they were able to continue so if, I always like to include this in the keynotes when you need to go back to business people and tell them why you want to do this thing or why it was important here is a big number that you can put in front of them to show them what you're actually doing here so 67% of the users who were interrupted by that came back and continued browsing on the site whereas before this would have been a major drop off point from the funnel you've now plucked that lead and people are continuing through the process to eventually, hopefully, booking a hotel so that they don't have to sleep on the street or just stay in a bar of an ass okay final two minutes then and I want to whip you some stuff that I think is exciting and I kind of want you, now that you feel empowered to create these amazing sites to quantify them to build them with business cases these are the kind of desserts or sweets at the end to keep you interested for the future WebAssembly WebAssembly is the way of actually creating native code so here's an example you can go to this you can actually even go to this on your phone depending on how powerful your phone is but you can also try this on your laptop so if you go here you will be confronted with a black screen initially because something is happening in the background and it's this and then it's this so so this is actually this is a tiny emu running in a browser because by using WebAssembly it has been compiled for the web this is not like a java app this is javascript running an actual emulator now, the power that you have previously I could not do something like this unless I had access to msd so maybe you're thinking to yourself wait a minute, that's not super important but what you can start doing from there is a number of languages like from C or from Rust the nscript in the project takes C and compiles it to WASM that you can run natively in your browser so one of my colleagues, Soma as an article here where he started exploring and actually Rasmus was talking a bit about this yesterday of the foreign function interfaces coming into PHP allowing you to run C code inside of PHP this is the same thing but in javascript planned there would be useful for your particular application that you want to run in the browser you can do this at native speed and the way this works so I said I wasn't going to show you any PHP so I'm going to show you some C code instead because we all like that so what we're doing here is we're actually just using the WebP library so WebP is a new image format but it's not supported in every single browser and encoding is not supported in every single browser and it's certainly not supported in the same way in every single browser but if you use the C library you will get consistent encoding every single time so what Soma was able to do here is he basically just wrapped the calls that he needs and the way he explains this is he found this in the manual he wasn't entirely sure which directories he needed from the library the entire library and the compiler was pretty good at optimizing what was needed at the other end so this will build out the library that you need and then from inside of your code you can just call those C libraries inside of JavaScript and you can get those as well as that so I don't know too much of this detail but there's my lovely colleague Soma and Paul and what is actually happening here is this image is being encoded by a web assembly module and then spit out into an image tag on the page okay this is the bonus round and then I am done so don't worry so what I wanted to say is whilst actually the M's code can look a little intimidating compiling C code for the web I have not actually done this because it scares me but there are other aspects where you're not just here improving the web ecosystem you can help change the direction of it and talk briefly about the batching API as you've probably seen when you get a notification inside the web app you might get a little blue badge on here that indicates something has happened I needed a test for this so I treated tests we don't interact 35 seconds later James replied to it so having developer friends you can always rely on someone being that person but it did get me what I needed which is an example there but now all I get is that little blue dot that's just an OS level thing indicating there's been a notification for this package but the value API says what if I could set edges for that so if I have a number of unread messages I can actually put that into the message account for a web app in the same way that I can for a native app and not just that any UTFA string in there so if it's a time for checking on my file then I could put a little label in there if my friend posted a picture of a cat to Instagram then I could get a little cat badge from there informing me that's important content I need to go and look at and the reason for bringing this up is because this is a very simple API if you go along to that GitHub repo you can see the set and you can see a question I asked in there why I was looking to confirm a bit of how this would work if you had multiple apps under the same domain and Miguel who's super nice told me that this was already answered in the readme so we've left that up there as an indication that you can happily go and ask stupid questions about these specs no one's going to be angry at you they're going to explain it to you so if you want to get involved in shaping the direction of the web platform then this is an ideal way to do it and with that I'm around for the entire rest of the day I'd love to keep the conversation going you can find me on Twitter we've got these two sites which are kind of documentation sites web.dev is where you can do like house results on your site and we will give you guidance to fix it and also you can find the rest of my team behind the Chromium Dev tag on Twitter if you have questions that I cannot answer so with that thank you very much thank you very much we've got two questions so these are questions not points trusted web activities so trusted web activities is actually a way of although now I'm going to have to come up with another question for people to come approach me afterwards if you want to talk on to one but trusted web activities is a way of basically providing some simple scaffolding that you can put around your site to create an actual APK and then upload that to the Play Store so if you want your Progressive Web App to appear in the Play Store then this is the wrapper that will allow you to do that and access that additional channel for acquiring users this is very easy and it is actually ready to be around it and will it be easy to balance using or release or use a progressive web app so the things I would say there Progressive Web App is an umbrella for a collection of these technologies so at the moment a service worker for example only became supported in Safari about a year a year and a half ago but under that banner there are always draft proposals that the API I showed you at the end that is only at the draft spec stage that's not implemented anywhere yet what I was trying to look up was a good place of kind of keeping up to date with like what are the latest web standards coming in but what I would always suggest is can I use is a good resource for this you can put in whatever API you're interested in and it will show you the browser support across the ecosystem and the market share of each of those browsers the downside of doing a lot of this is that service worker is incredibly powerful so I would always recommend starting with small simple use cases to begin with because it's quite easy to shoot yourself in the foot and do something like accidentally cache your entire site on the browser on the client and then realize that none of your users are actually hitting any of the new content that you just published so whilst it allows a whole new range of functionality that also opens up a whole new range of best practices and bugs for you to discover at the same time thank you