Developing on Chrome: Unlocking Value for Your Users on the Web (Cloud Next '19)

Just another WordPress site

Developing on Chrome: Unlocking Value for Your Users on the Web (Cloud Next '19)

[MUSIC PLAYING] ELIZABETH SWEENY: I’m going to kind of set the stage for us, and I will say, whether our users are enterprise clients or individual consumers, we really want them to have a great experience It’s kind of the core of what we’re searching for And I actually had a really interesting experience this past week that I think kind of sums up why this is an important experience for your users, and I’d like to recount that with you So if I’m moving a little slowly on stage today, it’s because I actually had an emergency abdominal surgery just a few days ago But the great part is I didn’t have to change my slides at all I just have a way better story to go with them, so worth it So exactly a week ago, almost to the hour, I started having abdominal pain, and I was like, huh, OK, I want to look up what’s going on Why does this hurt? And I want to know treatment options So I type into search, “abdominal pain that could kill horses,” and I see a few different site options pop up I click on one of the first ones, and I get this This did not delight me I was very frustrated with this outcome at that point in time And so I pop out of this site, because I’m like, this, I can’t handle right now I return to the search results, and I click another option I get something even worse Is it loading? Is it happening? There’s no feedback, right? And I’m stuck just really wanting to know why I feel like I’m going to explode, and I’m not getting any information So it finally starts to load, thank goodness But the content that is rendered on the page isn’t the content that I want What was happening was something that’s normally further down on the page, the way that the code was being shipped, was being rendered first And so I was actually being shown risk factors for abdominal issues instead of treatment options So I want to know if I need to go to the emergency room to not die, and instead, I’m being told that I’m most likely, given my symptoms, a 60-year-old male who lives in a retirement community Not good But finally, the right content loaded, and it basically told me that, yes, I do need to seek medical care And I go to click on the link It doesn’t respond The site’s not interactive yet The main thread is too busy, and so I’m stuck So this whole experience, just no You never want to give this for your users This is not what they want This is the opposite of what you need them to experience, and users notice it, and they hate it But that’s a problem that’s way too common on the web And there are a lot of things that can torpedo your ability to avoid this, and so that’s what I want to talk to you about today I want to talk about the impetus behind building a really high quality experience and the core principles that define that quality and how you can effectively measure, optimize, and monitor those core principles So we know how frustrating it is to have a bad experience on the web, as my experience just showed But how universal is this reality? Let’s put it in the context of stress response factors So this is actually a consumer study done by Ericsson, and they asked consumers to rank stress factors Waiting in line at a retail store– we know that we hate this, and we want our latte, and we want it now OK, great Even worse– watching a melodramatic TV show And I stole this joke, but it’s too good to pass up– Netflix and not chill Then you can be standing at the edge of a virtual cliff and watching a horror movie– these are all stressful experiences But what’s worse than “Cujo”? Mobile delays on a site Right? It’s the worst Well, no, the only thing that’s worse is solving a math problem We don’t want to make our users do that either, but that I think we all understood intuitively So I’m standing here, because I want to make sure that all stakeholders fundamentally understand the importance of developers spending time on investing in these core principles of quality This is not an exercise of espousing best practices just for the sake of it It is about your bottom line So just to give some more context for that through an example, Pinterest revamped their mobile web experience to focus on performance and saw tremendous results Their mobile website is now their top platform for sign-ups, and similarly, after implementing and enforcing a really aggressive but reasonable performance budget, Tinder was able to see more swipes on the web now than they do on their mobile app So over and over again, we see the same pattern Those who know how to design and implement a really high quality experience on the web see increased satisfaction, more time spent on pages, and ultimately, higher revenue So we see that sweet spot is around two seconds with conversion rates dropping with every millisecond

of slowdown after that So it’s important to have an accurate measurement as well, which we’ll talk about a bit later Performance sites are profitable sites That’s the moral of the story But where do you start? There’s a lot going on You start with a business goal, effectively, because that’s what you’re looking for You don’t want to just have a great FCP for the sake of FCP, as cool as that is You want to make sure that you’re addressing core business goals So what are those core principles that allow you to accomplish that? The example I gave earlier is actually a really complicated one, because my trying to actually engage with web content that wasn’t loading properly caused a slew of user pain points It wasn’t just a single problem It wasn’t just that it wasn’t loading quickly It was that it was loading wrong And like I said, it’s difficult to define quality, so let’s take a stab at it There’s a lot of ways to break it down, but there are a few core principles that are fairly canonical and don’t often shift, so even in the face of strong new fads So I’d like to go over those underlying principles, the first step being performance Speed and the user perception of speed is going to be at the core of our metrics and tooling discussion in a few minutes But it’s one of the most critical points that you’re going to want to focus on But there’s also things like accessibility, and we want your site to be accessible for everybody Why would you want to miss out on potential consumers? This means that the site’s content and functionality can be operated by literally anyone It’s really altogether too easy to assume that people engage with content the same way that we do And while we tend to center the discussion of accessibility on people with physical impairments, often, we can all relate to experiences of using an interface in a way that isn’t particularly helpful and that isn’t accessible for other reasons So for instance, if you are using a desktop site on a mobile phone, I feel like I’m can just stop with the examples there, and everybody can feel the pain, or seeing the message, this content is not available in your area, which in India, could not watch anything, or been unable to find a familiar menu item on a tablet All these things are accessibility issues as well For discoverability, everything else is kind of a moot point if people don’t find you So there are a lot of things that you can do to help in terms of how you actually implement your site, such as giving your site a really strong URL structure I mean the more structure you give, the more indexable you’re going to be Making your site responsive and that it’s easily consumable on all devices, using rel canonical and rel alternative for separate desktop and mobile sites– there are a slew of other tips and tricks to make your site more discoverable But at the end of the day, we want– the web is all about driving people to you That’s one of the things we’re best that, so to leverage it to the full extent of its ability, smart move Security– I mean from authenticating your users, maintaining sessions with them, encrypted communications, security is kind of a universally accepted core quality And it encompasses so many subtopics, but at the end of the day, if you think about it from the perspective of the end user, if they’re not comfortable interfacing with you and giving you any sort of tangible insight into their needs, you’re both going to hurt Smoothness– I really, really like coffee And I love coffee But smoothness on a web page means that things aren’t janky or moving around everywhere just kind of in a weird way It means that animations aren’t stuttering or unnatural, and it also means that everything just feels seamless And we all know what that feels like, and it feels good So fundamentally, this comes down to a few core concepts– choosing the right things to animate and being aware of the performance trade-offs, because sometimes they can be unexpectedly draconian So watching out for that is key Using animations to support interactions and not unnecessarily hindering the page or the user’s interactions– so we all remember Clippy Like, we– yeah Enough said And avoid animating expensive properties Basically, stick to transforms and opacity changes If all else fails, those are your guiding lights So all of these core principles amount to being able to answer this question with a resounding “heck yes,” because you want to let your users, and delighting your users means performant, accessible, secure, discoverable, and smooth sites And it’s interesting to consider the core principles and how they’ve evolved in the context of both native and web applications Many of the web applications that we’ve seen develop over the past few years have been to enable the same richness of experience that people have become traditionally accustomed to in native apps And many of the web technologies that Thomas is going to talk about that we’ve

seen develop over the past few years, like I said, are to do this And the strength of the web has been primarily in reach, but these web technologies have been changing that equation So yeah, I already said this slide I am just like– yeah I’m going to keep going That’s one of the reasons why PWAs came about is to really make that rich experience achievable in a much more simple, straightforward way So progressive web apps allow your web experience to be fast because of caching and prefetching, integrated, because it gives you that prime real estate on the home screen It’s reliable with network fluctuations because of service workers and offline capabilities, and then engagement with push notifications So it feels very intuitive for the user to engage with it as they would in a native application And ultimately, the slew of technologies that underpin PWAs allow for easier achievement of quality, as we’ve talked about So as we saw before, Pinterest updated their web experience and saw tremendous results But this was with a PWA, just to kind of fall back on that context And they ultimately were looking and analyzed usage for unauthenticated mobile web users, and they realized that their old, kind of out-of-date experience only managed to convert 1% of users into sign-ups, logins, or native app installs And the opportunity to improve this conversion was huge So things like boosting engagement with push notifications was a big deal for them And as a result, they see time spent up 40%, and core engagement is up 60% So what’s the takeaway? The core principles foundationally underlie the acquisition, engagement, conversion, and retention of your users That’s why they’re canonical Performance, accessibility, security, discoverability, and smoothness– they all directly impact the business’s ability to execute against its most rudimentary goals So if these principles are so important, then why do we regress or not really ever kind of get started with them? Before we get into some of the more nitty-gritty of how we measure these core principles quantitatively, I wanted to take a look at some of the components that are less technical that cause challenges to actually execute against this high quality experience And one of the challenges is having all the stakeholders onboard You want to have the organization fully bought in to the fact that we have a stake in these core principles and that it has a direct effect on your bottom line If there’s any disjoint in that, it causes problems So let’s take this as an example I know it’s a busy slide, and I apologize But in the red org structure, performance and other core implementations are siloed from marketing and other critical business teams with no visibility, shared accountability It’s kind of difficult But even when it’s shared, stakeholders don’t often know who shares the code So that makes it difficult Things are better in the green org structure, where the core principles of quality are well-defined They’re owned by management, and they’re enforced throughout It needs to be one of the first things that a team considers when they’re designing something new, not something to be tacked on later I think most people in the audience probably understand that pain a little too acutely, because there is nothing more painful than having to layer on security or performance onto a fundamentally insecure non-performant site It is painful But this can be seen in how organizations often approach the designing of their web apps Performance is an afterthought, and a lot of the core principles come to light in the heat of an emergency, like customers are complaining We’re losing money Panic ensues And then you get Band-Aid fixes, and as soon as the fire tamps down, those things go down in the priority And that’s not sustainable But like I said, at the end of the day, these core principles are about solving business problems and understanding that the conversation– we need to increase conversions, and we need to lower our FCP– are the same conversation is something that is so critical to get both business stakeholders and engineering really excited about solving these problems Now it’s time to get to the good stuff So we can’t improve what we can’t measure We need to know what we’re measuring and how to measure it So let’s start with a brief history of things, just to whet the appetite again for why measuring precisely has become so important So welcome to the human attention span Even in 2000– yeah, that was nine years ago, I realized, a few days ago, which is terrifying The average human could have barely waited for the average page in the Netherlands to load- just couldn’t handle it You’d walk away

Even a goldfish would be too impatient to wait for the average EMEA site to load And then in 2013, we got even more impatient, and our attention decreased to lower than that of a goldfish Humanity’s great And now here’s the good and the bad news Online, you really only have three seconds before you lose people And I actually don’t know why that’s good and bad news It’s just kind of news that needs to be accounted for So you have three seconds, but there’s a lot to do in three seconds, and it’s always a balancing act, and you’re going to have to prioritize The impact on user experience is critical So you look at the fact that the speed it takes a load a page is the most important factor for a user, far and above how easy it is to find what they want, more important than the simplicity of using the site, and three times more important than how attractive the site looks So performance is important You’re going to be really bored of hearing me saying that by the end of this But before we learn where to measure, what are we actually measuring? Loading isn’t a single moment in time, and there isn’t one metric that can fully capture it So this gets back to my experience that when a page loads, it begs the question, what is performance? It’s partly the speed of initial load, to be sure, but how do we actually break that down? And focusing on user performance metrics is a great way to get started A user perceives that something is happening Am I receiving content? That’s– is it happening? And that’s first paint and first [INAUDIBLE] pain Is it useful? Is what I’m receiving visible and digestible? That’s first meaningful paint And then is it usable? If I click on it, will it respond? That’s time to interactive Taking one step down, so FCP actually measures the time from navigation to the time when a browser first renders the first bit of content onto the page So it’s an important milestone for the user, because it provides feedback that something’s actually happening and that the page is loading The time to interactive metric measures how long a page takes to actually become interactive, so it means that interactive defined by a page has displayed useful content Event handlers are registered, and the page responds to user interactions within 50 milliseconds So it’s a difficult metric to achieve, and it’s much later in load, but it’s important, because you know that rage clicking? That’s that And this is a great example of a metric that’s great in the lab but doesn’t work as well in the field, because people actually have to– did I swap that? I don’t know if I swapped that So yeah, time interactive, great in the lab, not so great in the field, because in the field, you need actually somebody responding and pushing on the screen to get that input, whereas with TTI, it’s just simulated And we’ll talk about the differences between lab and field in a minute But FID is where we’re talking about– it measures the time from when a user first interacts, clicks, or taps, and when the browser is actually able to respond to that interaction So in general, input delay happens, because the browser’s main thread is too busy, and we’re doing something else, and it can’t yet respond to the user We all know that One common reason that can happen is the browser is busy parsing a lot of JavaScript We know that depending on how you bundle it, it’ll affect this experience for the user And to dive one step deeper than that, on the goldfish slide, you lose people at three seconds, but they notice latency at anything over 100 milliseconds So that’s something to keep in mind We perceive– we perceive that change, and that measurement is incredibly important So quick raise of hands Who prefers A? Who prefers B? Yeah Unfortunately, some sites optimize content visibility at the expense of interactivity So you have A. It’s great It’s loaded But you’re clicking on it It’s not doing anything, whereas with B, you’re not seeing something, but as soon as you see something, you click, and it works Both kind of suck Right? Like, eh, you want some healthy balance To the best of your ability, you’re trying to optimize for both, and that’s hard to do So why do we care about all these metrics? Because all of them represent a different part of the user experience, and as we said, it’s not a single metric It’s really a cohesive experience So you’ll see– I know we have a lot of moving goal posts sometimes with metrics, but we’re constantly trying to find what is actually representative of what the user is experiencing when something loads So there are two sides to the measurement equation, as I kind of alluded to earlier There’s performance in the lab, and there’s

performance in the real world Now you can look at this from the perspective of both metrics, as well as measurement of those metrics So lab measurement, synthetic testing, where you can test code quality The others field where you’re looking at real user interactions and understanding how they are actually experiencing a site Some metrics are available in both Some, one or the other Like I said, nearly everything is available in the lab, but FID is unique, because you need that real user input And TTI and FID are interactivity metrics, so they’re going to be sensitive to the main thread activity It’s good to kind of get a sense of when you’re going to get that rage clicking scenario going on So lab data is fantastic for a lot of reasons It gives a sense of how changes are likely to behave in the real world You can catch problems before making things go live They’re helpful for debugging performance issues, reproducible It’s great But the downsides are that they’re not going to really capture real world bottlenecks, and they can’t correlate against real world KPIs So that’s a downside So that’s where field data comes in, and it complements it beautifully Real world’s messy– permutations of devices, network configurations, cache conditions I mean, it’s impossible to simulate all these things in the lab, and you need those real signals So RUM helps– Real User Measurement actually helps you understand what matters most to real users, their actual behavior, and that might be different than your assumptions Best strategy? Combine the two Having both lab and field metrics is a proxy for what your users are experiencing and how they’re experiencing the core principles of your site So we know we want lab and field data Great Where do we get it? So the primary three metrics that we’ve discussed kind of on an ongoing basis today are available in their respective lab and field environments Because FCP can be measured both in the lab and field with users, it is available across the board in tools like Lighthouse, PageSpeed Insights, Chrome User Experience Report, and actually as a web perf API as well TTI is only available in the lab, so it can be accessed via Lighthouse and PageSpeed Insights, and FID requires the real user input, as we said, so you can go to CrUX for that My tip of the day, just to make your life easier– if you want to get a snapshot of your site’s lab and field performance to benchmark overall quality, go run your page through PageSpeed Insights So you can do this via a web app at the URL shown here or via the V5 API that we launched in November of last year At the top of the PSI report, you’ll see a high level performance score, which is the same that you see if you run Lighthouse, and it’s calculated based on the lab metrics that are measured and weighted Metrics that contribute to this high level score include things like FCP, FMP, Speed Index, and TTI And you’ll clearly see in the field report– in the PSI report, that you’ve run both field and lab, which is really cool to have in one place, and from their respective sources, CrUX and Lighthouse So the two primary field metrics are pulled out for the URL that you run And so for each metric, you see the percentage of page loads that, in the real world, were slow, average, or fast What a tool like Lighthouse offers you is that if you use it via one of the surfaces other than PSI, it gives you a means to measure more of the core principles aside from just performance So you can audit your site for accessibility, best practices, search engine optimization, and which criteria have been filled for PWA Lighthouse also allows you to dive more deeply into opportunities for each category, making improving the quality of your site really actionable and tangible So setting performance budgets are a fantastic way to keep from regressing as well and can be one of the most effective ways to monitor, so we’re talking measuring, optimizing, and monitoring This is where the monitoring comes in Budgets can take on many forms, but setting them and enforcing them, even in the context of the latest and greatest new feature– it’s great to push back on features you don’t want to implement, by the way, pro tip– it’s going to help your pocketbook big time So there are a slew of tools that are at your disposal that can help you gauge the quality of your site, ranging in level of technicality And I encourage you to enjoy playing with them, both in the lab and field Your users and your bottom line will thank you for it And with that, I pass it to my amazing colleague, Thomas THOMAS NATTESTAD: Thank you so much, Elizabeth Yeah, round of applause for Elizabeth [APPLAUSE] She literally dragged herself out of the hospital bed to be here in order to give this talk, and if that’s not caring about metrics, I don’t know what is So for my part of the talk, I want to share about some of the new things that we’re building in Chrome that fundamentally expand the set of experiences that are possible to create on the web

And in order to showcase how impactful some of these improvements and technological changes can be, I want to first take a step way back and understand the web as a platform and as an application platform compared to how Android, iOS, and Windows are also these application platforms And so to really take a step back, I’m going to step way back to the first ever web page published by Tim Berners Lee And as you can see, this web page is really just very slightly formatted text, some of which you could click on to get to other pages of slightly formatted text And that’s all the web was Then a little something called JavaScript came along, which was famously created and written in a 10-day hackathon And this 10-day hackathon brought JavaScript and brought interactivity to the web for the first time ever Suddenly, you could respond to user input, do dynamic logic on your page itself, and even with this very basic set of interactivity functionality, you saw the first wave of web applications In the past, things like Outlook and other native applications had been the only way to do email, and now suddenly, you could just type Gmail.com, and you were in an email client, where you could send and receive and manage all your emails And there were, of course, many other applications that followed along, things like MapQuest or eBay, things that were highly interactive and dynamic now being able to be delivered directly through the browser But why were these applications actually moving to the web? In the native world, you can use any language you want, not just JavaScript You have full access to everything that the computer can do You can do absolutely anything to your heart’s desire, so why were applications actually moving to the web? Well, it turns out that there are three fundamental properties that make the web a really unique platform The first of these, and one that is unsurprising, is linkability, the ability to have a single string that then maps to the web page itself, and have that string be clickable from any other page so that you can find your application really easily, but also shareable so that I can share a simple string that shares not only the application itself, but also a specific document for that application that can now be instantly accessed The second property of the web is its ephemerality And this Is a very fancy word that basically means that the user doesn’t have to worry about installing the application, do they have enough space on their machine, and do they actually trust the application The application or website is delivered through the browser completely sandboxed, and the user never has to worry about clicking a link the same way they should be absolutely terrified about installing an EXE And lastly, the web is the only truly universal platform, meaning that your application is accessible by anyone on any device Today, the web obviously runs on desktop, laptops, and mobile phones, but also on watches, and I’ve seen the web literally running on treadmills and refrigerators And this means that you can use your single code base to power all of your deployments, even to reach your fridge-based users So now, hopefully, that we all have a better shared understanding of what the web is and some of the properties that define it, I want to share about some of the new technologies that we’re building in to Chrome that developers can use to, again, expand the set of things that are actually possible to do on the web And the first of these that I want to talk about is WebAssembly WebAssembly is a new low level binary format, which means that it’s close to the CPU virtual machine code that your computer understands, but with all of the safety and sandboxing that you’ve come to expect from the web WebAssembly, much like Assembly, is compiled from other languages like C++, meaning that you probably shouldn’t be writing WebAssembly by hand, unless that’s your thing And because WebAssembly is a low level binary format, it offers better maximized and reliable performance than JavaScript can So let’s dive in to some of the advantages of WebAssembly in detail As I mentioned, WebAssembly is compiled ahead of time from something like C++, and that means that you can do a lot of optimizations and performance tuning before the code actually hits the browser JavaScript, by contrast, is sent as raw source code to the browser, and then the browser has to optimize it as it’s actually being executed on the page And this can cause some of that choppiness that you sometimes get on web pages Critically, WebAssembly also gives you more access to your CPU We recently launched WebAssembly Threads, and WebAssembly Threads let you use the multiple cores that come on practically every CPU to fully squeeze out every ounce of performance And to showcase some of these performance differences and to actually hear some of these differences, I’m going to jump ahead to the case studies that I’ll get to later, and show off one specific example called Soundation Soundation is a fantastic web application They have a C++ code base, and Soundation is a music editing studio similar to GarageBand that lets you easily mix

and match songs with various effects They have a C++ application that they compiled to WebAssembly, and it works really fantastic But sometimes when you have to render really complex songs in real time, the performance demands on that application can be intense We actually partnered with them to try and render one of their difficult to render songs, and we tried to do this on a single-threaded version of their application And we’re going to get to hear what that sounds like Fair warning– this is not going to be a pleasant experience But if we have audio, which it doesn’t sound like we do– [BROKEN MUSIC PLAYING] Ah, there it is So I’m going to move past that, because clearly, we can all tell that is a terrible experience, not something you want your users listening to But as soon as they turned on WebAssembly Threads, they were able to render that same song– [MUSIC PLAYING] –now sounding much more normal and using far less of the CPU So that was just one performance advantage of WebAssembly, and letting you really maximize everything that you can get out of the CPU Another advantage of WebAssembly is its portability Because you compile WebAssembly from other languages like C++, you can port not only your own applications that you’ve written in C++, but also the wealth of open source C++ libraries and application that exist out there in the world And because C++ specifically is supported across practically every platform, including iOS and Android, you can now use C++ as your common language across all of your different deployments, even if you want that iOS and Android native application Lastly, and potentially most exciting to many of the developers out there in the audience, is the promise of more flexibility when writing for the web In the past, JavaScript was the only option that you had for fully browser-supported language, and now with WebAssembly, you get more choice The set of fully supported languages today are C, C++, and Rust, but there are many other languages, including Kotlin and .NET, which are working on adding experimental support to WebAssembly, and some of these have actually already shipped that experimental support The most exciting thing about WebAssembly, though, is that it is fully launched in all four major browsers, meaning that you can truly use WebAssembly to reach every single one of your web users It’s important to know, though, at this point that WebAssembly is explicitly not a replacement for JavaScript Rather, WebAssembly is meant to augment all of the things that JavaScript isn’t really designed for JavaScript is a dynamic language, useful for scripting If you want to do simple interactivity, JavaScript is and remains the way to do that But if you want to really maximize your performance, really get that reliability, WebAssembly gives you that option If you want to get started with WebAssembly, the first thing to check out is Emscripten Emscripten is a highly advanced tool chain that not only helps you compile your C++ into the WebAssembly format, but it also does a lot of emulation For example, if your application uses open GL rendering calls, Emscripten will automatically transfer those open GL calls into web GL calls so that you can really easily wholesale port your entire application using the Emscripten tool chain OK, so that was WebAssembly, and now I want to switch tracks and talk a little bit about some of the new capabilities that we’re adding to Chrome Again, going back to the world’s first ever web page, we can see that you really couldn’t do anything Outside of the lack of JavaScript, there really wasn’t any additional access or functionality that you could get out of your web page Then the image tag came along, and suddenly, you could show images on your web page And that was a huge deal and a major development It was great But obviously, the story didn’t stop there And today, many of you likely know that you can access location and even get a camera feed You can take your website into full screen mode, all of these different capabilities that you’ve all seen But the picture is actually so much more complex than most people imagine Today, on the web, you can do so much more, things like accessing USB devices, sending push messages, managing your credentials, weaving files, syncing in the background, detecting your device position, vibration All of these different things are accessible through browser standardized APIs But the story is far from complete, and I’m happy to say that in 2019 and 2020, Chrome is planning to dramatically expand the set of capabilities that your browser can access These include things like SMS verification, the ability to see the contacts that are on a device, task scheduling, and even the ability to write back to files that have been shared with your website so that you can create a rich native-like file editor or even an IDE I want to dive into a few of these specific capabilities in more detail The first of these is offline As you all know, the web is great when you have a secure, reliable connection, as most of us do on desktop machines, but not so much on mobile The way that a traditional web server works with a browser is you go, and you fetch your content,

you load it into the browser, and yeah, you’re done But when you have poor connectivity or even no connectivity, that’s a really negative experience, and you end up seeing what’s called– what we like to call the offline-asaurus-rex or Offline Dino And as much fun as this game is– which by the way, hit space, if any of you haven’t before– this isn’t really the content that users are looking for Luckily, though, in the last few years, we’ve been launching something called Service Worker And what Service Worker lets you do is that once you’ve actually fetched your web application, you can intelligently cache it, and then detect that when the user tries to come back to your website, if they’re on poor connectivity or no connectivity, you can serve that same web page directly from the cache And then if the user eventually enters a better connectivity state, you can then fetch the updated content and serve that to your users on return visits Another important capability that we give you access to, if you have a service worker in your application, is the ability to add your website to the home screen And this is what we call PWAs And this is that ability to render a button that says, Install, and when the user clicks it, they’ll say, yes, I want to add this to my home screen And then you actually get a standalone icon on the user’s device And when they click that icon, it opens up into a full screen view with no URL bar at the top whatsoever, and it really feels and looks like a native application Another important capability is the ability to send push messages This is something that iOS and Android has had access to since the beginning, but it’s also now something that you have access to through the browser and have had access to for the last few years It works exactly the same way it does in iOS and Android And once the user grants the permission to be shown push notifications, you can send them directly from your web application So these together kind of form what we call Progressive Web Applications, or PWAs And these are all about delivering that native look and feel of an application using all of the web-based technologies that are also so powerful and in the browser And we’re at a place today, where you can quite literally create a PWA and a native app experience alongside each other, completely undetectable which one is the web experience And you’re welcome to try and guess which of these two is the native and which one is the PWA For those of you who guessed that the one on the left there is the PWA, you were right, but I’m willing to guess that that was mostly based on random luck, because these two experiences really are interchangeable and completely indistinguishable I’m also happy to say that with progressive web applications, we have now completely expanded to desktop It works exactly the same way on desktop You can render an Install button When the user decides to install, you can simply say yes, and then you get, again, that same icon in the shelf, as well as your own standalone window, fully integrated into the operating system, feeling exactly like a native application We also launched recently something called Trusted Web Activities Trusted Web Activities, or TWAs, let you take your PWA and turn it into an Android native APK that you can list directly in the Play Store TWAs, instead of using web views, use something called Chrome Custom Tabs And this means that TWAs share and sync storage with Chrome This means that if a user is locked into your site on Chrome, and they then go and download your TWA from the Android Play Store, they’ll automatically be logged in, and all of the data will be synced, enabling them to switch between your in-browser experience and your app experience completely seamlessly The resulting APK that you get out on the other end for a TWA is also incredibly tiny, smaller than any native application that you could have made And this has been really impactful for a lot of our partners in emerging markets who struggle with storage space on users’ devices All right, so those are some of the highlights of some of the different technologies that we’ve been working on over the last few years and some of the things yet still to come For the last part of my talk, I want to quickly run through a couple of different case studies of partners who have used and adopted some of these new technologies and some of the results that they’ve found The first of these that I want to mention is Twitter Twitter adopted the Add to Home Screen and PWA functionality, and through that, they found that they were able to completely reinvigorate their mobile web experience They see as much as 1 million daily visits of users who access their application through that home screen icon, as well as a 75% increase and a 65%– a 75% increase in tweets and a 65% increase in page views/session duration, which is really powerful for them and helps unlock more value on the mobile web Another interesting application that we partnered with more recently is Spotify Spotify was looking to solve two fundamental challenges First of all, they wanted to lower the friction of accessing their application

It’s a very high ask to ask your users to go and download an entire application just to listen to one song that some friend of yours sent you a link to They also wanted to solve storage space, because it’s hard for users who don’t know about Spotify, the application, to decide it’s worth the amount of storage on their device to actually go and download the native application Spotify’s approach was to start small and use rigorous A/B testing to detect the changes in user behavior resulting from users who were shown the PWA experience as opposed to being redirected to the Play Store They found great results with a 54% increase in day one plays activations, a 14% increase in retention, and as much as a 30% reactivation of users who had churned and previously uninstalled the app Next up is Starbucks Starbucks, similarly, was trying to solve two fundamental challenges First, they really wanted their mobile web experience to have full UX parity with their native application, and similar to Spotify, they wanted a solution for users who didn’t have enough storage on their device for the full native application Their approach was to start with as many of the performance basics that Elizabeth did a fantastic job of laying out in her section of the talk, focusing on less code, intelligent caching, and image optimizations, as well as adopting many of the PWA engaging and delightful patterns to Add to Home Screen and enable better sign-on and authentication Their results surprised even us and themselves They found that they were able to double the amount of the time to interactive for their web page, as well as a 65% increase in Starbucks rewards registrations, which is their most important conversion point The last case study that I want to go over is a really great company that pulls together a lot of these principles, and that’s Figma Figma is a powerful cloud-based screen design platform that makes it really easy for teams to work and collaborate in sync With native design tools, you had to worry about managing the right files and making sure that everybody’s files were up to date, making sure that everyone had the right software installed, and whether or not the operating system that one of your team members was using even supported the application in the first place Now by leveraging the powers of links as the single source of truth, you can easily collaborate, ping somebody a single string that they can then click to instantly open up the application, jump right in, collaboratively edit without having to worry about any of the process of installing the application itself I want to briefly mention the actual setup that Figma has, because it’s quite a well done architecture that they were able to come up with In the surrounding areas of their application, the menus and such, they use a TypeScript and React-based framework, which works really well And then inside of the central editor section of their application, they have a single canvas tag, where they have a custom rendering engine written in WebAssembly through C++ that uses WebGL to rapidly render that file and any changes to that canvas area They also have a custom text editor, where they were able to take the popular open source C++ libraries, FreeType and HarfBuzz, and compile those to WebAssembly, and then just use those directly– again, one of those portability advantages that I was talking about earlier And then lastly, they use web sockets to enable really fast and smooth multiplayer editing of any file in the Figma application Here are some of the links to many of the resources that I talked about I will give everyone in the audience a second to take a picture, or give everyone listening and watching at home a chance to pause the video This is just some of the useful links and resources that you have access to [MUSIC PLAYING]