 Hi, everybody. Thank you for that introduction. I'm Jeff Posnick from Google's web developer relations team. And I'm really excited to talk to you today about Workbox, which is a set of tools that could help anyone who's building a progressive web app. But before we delve into Workbox, let's cover some foundational concepts first. So understanding how and from where your web app loads data is really the key to understanding your web app's performance. In a traditional model, web apps make HTTP requests against a network like this request for some HTML. If all goes well, which isn't always a safe assumption, the network returns a successful response with the data our web app needs. So that's been the model for a while. But you've probably heard that service workers change everything. And they do. Service workers sit in between your web app and the network, and they can intercept your HTTP requests. What they do with those requests is completely up to you. So the way service workers handle the request is called a strategy. And here's an example of an extremely basic strategy. Like before, our web app requests some HTML. But now we've got a service worker in the middle, and it intercepts a request. This network-only strategy, all this service worker does is just pass along that request to the network. The network response goes back through the service worker and on to our web app. OK, and what is a service worker that implements a network-only strategy look like? Well, it looks like this. It's event-based JavaScript code. And here what we're doing is just responding to our web app's fetch events by just refetching that same request against the network and passing the response along through. But a network-only strategy isn't particularly useful if you want to build things. Let's turn to a more complex example. So we really see the true power of a service worker when we add in another piece of the picture, and that's the cache storage API. So now we can implement a more useful strategy. In this case, we're going to talk about stale while we validate. Now this works by first returning a cache copy of a response and then going against the network to refresh the cache in the background. So the service worker can respond immediately with previously cached content. But updated content will always be available the next time the same request is made. So this gets a little bit more involved, and let's walk through the strategy step by step. Our web app again makes a request for an HTML document, and our service worker again intercepts it. But this time, we take advantage of the cache storage API and check to see if there's a match for that specific URL. And if there is, great. We can return it to the web app immediately. But our service worker doesn't stop there. Independent of the cache lookup, it also makes a network request. The response is stored in the cache, replacing the previous potentially stale content. And if there wasn't a match in the cache when we originally checked it, then we can also take that response from the network and pass it along back to our web app, fulfilling that original request. So given everything that was going on in that diagram, it's not surprising that the code for a service worker that implements stale while we validate is significantly more complex. And before you go and take pictures of the slide, I'm going to go and show you something better. So don't worry about that. And that gets to one of the key points that I want to make. Service workers offer great power, but with that power comes complexity. And that's where Workbox comes in. Workbox gives you access to all the power of complex caching strategies via a combination of tools that hook into your build process, as well as libraries that you could use from inside of your service worker. With Workbox, you get to trade complexity for flexibility. So here's an example. Let's go back to that previous slide with the code for stale while we validate strategy. Workbox offers the same behavior in a single line of code. So that's a pretty clear example of Workbox handling complexity for you. But I also mentioned flexibility. And that's where Workbox really shines. So all it takes is a few additional lines of configuration to customize the way your service worker behaves. Here, we've got that same stale while we validate strategy. But we tell Workbox that cache responses should expire after 60 minutes. And this could be useful when you're OK with slightly stale data, but you don't want to reuse anything that's too old. Now it's possible to manually write all the code your service worker needs to implement cache expiration. But you'd end up turning your dozens of lines of code into hundreds of lines. And requiring everyone to reimplement core functionality just from scratch really doesn't make sense. So taking a step back from the code and diagrams for a minute, there's a question that you might be asking yourself. And why should you care about adding in a service worker to your web app to begin with? Caching is cool and all. Is it really worth that extra effort? So here's a key point that I hope everyone takes away from this. A service worker properly configured makes your web app fast and reliable. Let's break that down. First, it's both fast and reliable. And that really should be everybody's goal. Even when you have what you think is a good connection, the network is always a wild card. If you avoid the network, your web apps can start up immediately and not just some of the time. By taking network variability out of the picture, you can be reliably fast all the time. But you can't just throw together any old service worker and expect your web app to suddenly become fast and reliable. Making sure that you deploy a properly configured service worker, one that uses an appropriate combination of caching strategies, is really crucial. And that's where Workbox comes in. Workbox allows you to build on a solid foundation, which you then configure to meet your specific needs. That's a better alternative than using copy and pasted code that you have to cobble together yourself. Workbox also gives you control over how you build your service worker. If you're the type of developer who prefers to take things one step at a time, you could use an incremental approach and manually add in Workbox strategies to an existing service worker. But if you prefer Workbox to handle more for you, we have tools that will generate and configure your entire service worker from scratch. And using Workbox means that you're building on top of extensively tested production-ready code. But you don't have to take my word on that. Let's take a closer look at a couple of companies that have deployed web apps using Workbox. First up is Pinterest, which Addy just talked about a bit. And it's probably a company that many of you are already familiar with. So Pinterest has been gradually adopting PWA functionality. And one of their recent goals was to provide a fast and reliable experience for logged-in users. Not surprisingly, service worker caching is key to that goal. Pinterest turned Workbox to power their service worker. And let's take a closer look at some of the features that they're using. So first, Pinterest is using Workbox for pre-caching. Pre-caching ensures that the assets that are crucial to their loading experience, their core HTML, JavaScript, and CSS are always cached ahead of time and available. With pre-caching, Workbox automatically takes care of cleaning up the old entries and updating new entries each time you rebuild your site. Let's take a closer look at what's going on. So the process starts at build time when Workbox generates a manifest of versioned URLs. This list is stored as part of the service worker's code. When a given version of the service worker is first installed, Workbox uses this list of revision information to figure out which URLs need to be fetched from the network. And those network responses are put into the cache for future use. Then after the service worker is activated, it could start handling requests for pre-cached resources by retrieving them directly from the cache, bypassing the network completely. These cache responses will always be fast, and you never need to worry about reliability. But that's just a diagram, and I'm sure folks would like to see the code that configures Workbox's behavior. So here's a snippet of the actual service worker that Pinterest is using. And I want to highlight a few bits in particular. First, remember when I said that pre-caching works by passing in URLs along with revision information into the service worker? So for some URLs, like the one shown here, that's easy, since they already include a hash as part of their file name. But for other assets, like HTML documents, modifying file names isn't an option. Workbox handles this situation by creating its own hash of those files during its build process and includes that revision information as part of the manifest, as you can see alongside the URL. Workbox uses this information to keep track of when it needs to update the pre-cached URLs, and you won't get stuck serving the same hash HTML indefinitely. Pinterest is also using Workbox to handle navigation requests. So these are the initial requests that your browser makes for the web app's HTML. And traditionally, these requests always had to be served from the network, even if you're following all the other HTTP caching best practices. So you'd always have that as a bottleneck. But service workers change that model. We can now serve cached HTML immediately, bypassing the network for navigations entirely. Using a cache-first strategy for navigations is crucial for speed and reliability. And Workbox really makes it easy to do. So let's take a closer look at that. Here's a high-level view of how Workbox handles navigation requests. So let's say there is a login user that returns to Pinterest, and the service worker is already installed. The visitor navigates to a specific URL, and the service worker can tell that it's a navigation request. He gets that information as part of the fetch event that it's handling. Our service worker knows that the URL could be fulfilled with a generic app shell that's been pre-cached previously. And that is ultimately returned to the web app from the cache, avoiding the network completely. But Pinterest needs a more flexible approach than just serving the same HTML for every single URL. Some navigation requests, like for their About page, can't be satisfied with that same HTML app shell. And the service worker needs to send those requests to the network. For those requests, they do lose the benefits of going cache-first, but it does mean that they have the flexibility of serving HTML that's tailored to some of their custom pages. And here's a Workbox code that corresponds to that behavior that we just saw. Using Workbox means focusing on flexible configuration, not on copy and countless lines of boilerplate code. All you do is tell Workbox which HTML document should be used for most navigations. And ideally, this should be a URL that was previously pre-cached and is always going to be available. And then you get to customize the navigation behavior via white and black lists. Here's where they've opted out of their About page from the default shell HTML. So it has a little bit of routing information involved there, too. So what we've just seen is only a few snippets of Pinterest's service worker. And when they started using Workbox, they weren't starting from scratch. As Addy mentioned, they had an existing service worker in place. And they had some established build processes already around it. But Workbox is flexible. And part of that flexibility means being able to layer in the new caching behavior without having to abandon their existing code base. All right, so that's Pinterest. And next up is another familiar company, Wired. So Wired recently started down the path of rebuilding their web experience as a single-page app. And they considered that a great opportunity to look into making it a PWA at the same time. So their goals for their PWA are first and foremost to boost both initial engagement as well as re-engagement with return visitors. And central to that goal is providing a fast, reliable, and offline-capable experience so Workbox could help. And because they're starting without any existing service worker, their use case is a little bit different than Pinterest. They're fine with letting Workbox generate their entire service worker for them each time they rebuild their site. Workbox has a few ways of integrating with build processes. And it's flexible enough to work with most setups. In Wired's case, they were already using NPM scripts. So using Workbox's command line interface made the most sense for them. Let's take a look at a stripped-down version of their build setup. So you can see their build steps here. They're using Webpack for JavaScript bundling. And they also rely on a custom CSS post-processing step. And even though this is a custom build process, Workbox is flexible enough to slide in right at the end of their build chain. They just added in a new NPM script that calls the Workbox CLI. And their new service worker's behavior is entirely determined by this configuration file that they pass in to the CLI. Let's take a closer look at that file. Hopefully, it's not too complicated, but it is clearer if you break it down into two different sections. We've already talked about the performance benefits of pre-caching and why I'd want to take advantage of that for their PWA as well. Setting up pre-caching is as simple as configuring these two options that you see here in their configuration file. They point Workbox to the root directory that contains all of their built assets. And they provide patterns that are used to match a subset of the files in that directory that they want pre-cached. So they've decided to pre-cache all of their HTML, JavaScript, SVG images, and their CSS. And when they run the Workbox CLI, each time they rebuild their site, that configuration leads to a section of their service worker that looks something like this. It contains that manifest that we talked about before with a list of versioned URLs to pre-cache. And each time they regenerate their site, the list will also be regenerated to reflect the current assets and the current versions of each. So we mentioned that some SVG images are pre-cached by Word, but that's not the only type of image that's displayed in Wired's web app. Each article page has at least one image associated with it. And those images tend to be larger and are really only displayed when you're reading a specific story. It wouldn't make sense to cache all of those article images ahead of time or to keep them stored on users' devices indefinitely. So Wired was taking the approach that my colleague Eva described in her talk earlier today. They divide their images up into different categories and cache each category differently. So the images that are crucial to navigation and site design, which all happen to be smaller SVGs, are pre-cached and always available. But their article images use a runtime caching strategy along with cache expiration. Workbox's flexibility makes this easy to set up. Returning, again, to that configuration file, let's take a look at the second section where the image caching behavior is defined. So these options in the configuration file are all it takes to cache their article images at runtime and define an expiration policy. After they run their build process, Workbox uses those options to generate this code in this new service worker file. Up until now, we've been focused on how network independence makes a web app fast and reliable, and those are very important characteristics. But there's another benefit to caching as well. Wired can now create a rich reading experience when users come to their site while they're offline. When offline, the web app shows a list of previously cached articles, all available to read in full. One of Wired's goals for their PWA was re-engaging with return visitors, and this offline experience helps ensure that readers keep coming back, even when they know that they don't have a network connection. So let's take a quick look at how they're generating that offline article list. A little-known secret of the Cache Storage API is that it's also available outside of the context of the service worker, and I'm always surprised at how many people don't know that. It's very useful. A web page can ask for the contents of any cache directly without having to go through the service worker to get that information. Cache Storage API returns a list of cache URLs and then Wired's using that list to populate its offline view. See here? So Wired's PWA journey isn't over yet. Their team is hard at work in many areas of their web app, but they're happy to open up a pre-release version of their PWA to the public today, and it's available at pwa.wired.com. So give it a try and feel free to share feedback directly with their team as they continue to iterate on the site. All right, so those are just two of the many partners that have deployed a service worker using the current version of Workbox. What does the feature hold for Workbox as a project? If we're looking forward, here's a quick look back at some history. So Workbox is a direct descendants of two widely used projects, SW Precache and SW Toolbox. We took the core features from both and joined them together in a consistent interface. We've been busy. Workbox 1.0 was released back in May at Google I.O. And the 2.0 release came out in August. Since then, our main focus has been on the Workbox 3.0 release. It's not quite ready for developers to use yet, apologies for that, but I wanted to preview a few of the key features that we're planning for 3.0. And we love your feedback and contributions. It really directly affects what we end up building. You can visit that link on the slide for information how you could reach out and participate in the community. So into 3.0. High enlisted priorities for Workbox 3.0 is a revamped webpack plugin. While we've shipped a webpack plugin since our launch, we've heard your feedback that required a lot of extra configuration and it didn't support common webpack development server environments. We've listened and for the common pre-caching use case, the new webpack plugin should be zero configuration. So this becomes this. Of course, you still have the flexibility of adding in configuration if you need additional features like runtime caching. We've also put some work into the existing background sync library. It makes it easy to queue up and retry requests that require a network connection when you're offline. And new inversion of 3.0 is support for binary request bodies, which is perfect for retrying uploads of videos, images, or other rich media. Another focus for 3.0 was reducing the amount of JavaScript that the Workbox runtime adds to your service worker. Instead of shipping one large bundle and encouraging everybody to use that, 3.0 introduces a lightweight dynamic module loader. You can continue writing code against the Workbox SW interface like before. But under the hood, only actual dependencies that your code uses will be downloaded. Now, lazy loading and code splitting is commonplace nowadays in client-side code. But there are some specific hurdles that we had to overcome in order to do it from within a service worker. We're really happy with the results though. Our goal is to take the rundown bundle size down from 47 kilobytes to 15 kilobytes for common use cases, and it looks like we're gonna be able to hit that goal. So another big change in 3.0 is our official CDN, which is hosted on Google Cloud Storage. By default, our build tools will import the Workbox runtime from the Content Delivery Network URL, meaning that there's one fewer thing that you need to worry about deploying. This also ties in nicely with that dynamic runtime loading that I just mentioned. If you use the Workbox SW library hosted on the CDN, it'll automatically know how to pull in all of the additional libraries from the CDN as well. So this is just a small piece of what we've been working on for the 3.0 release. And while I'm the one on stage right now talking about it, I'm by no means the only one writing code and documentation. So I wanted to give a shout out to all the core contributors to Workbox code base and a special shout out to that person in the bottom right, Will Farley. So Will doesn't work for Google, but he's been an active open source contributor of code around the web back plugin for a while now. We really appreciate his help. And speaking of open source, we've benefited from using dozens and dozens of other open source projects while building, testing, and shipping our code. So I don't have time to go through them all, but I did want to highlight a few on the slide that were particularly indispensable when we worked on Workbox. Special thanks goes out to all of those projects' maintainers. So while 3.0 is still on the horizon, everyone can go out and start building with the current release of Workbox today. Whether you're just dipping your toes into the PWA waters or if you've got an existing service worker that you're looking to turbocharge, Workbox can help. We've got documentation, along with new Getting Started guides and a migration code lab on developers.google.com, the URL you see on the screen. And feel free to reach out if you would like to chat more about Workbox. I love hearing about how people are using it. Thanks everybody for taking the time to learn about Workbox today. And thanks for all the partners and members of the community who continue to show your support. Thanks very much. Thank you.