Workbox: Flexible PWA Libraries (Chrome Dev Summit 2017)

Key Takeaways

[Music] 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 work box which is a set of tools that could help anyone who's building a progressive web app but before we delve into work box 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 apps 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 a 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 in 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 handles requests is called its strategy and here's an example of an extremely basic strategy like before our web app requests me HTML but now we've got a service worker in the middle and it intercepts a request this network only strategy all the service worker does is just pass on that request to network the network response goes back through the service worker and onto our web app okay and what is the service worker that implements a network only strategy look like well it looks like this it's you know event based JavaScript code and here what we're doing is just responding to our web apps fetch events by just refactoring that same request against the network and passing a response along through but you know 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 cash storage API so now we can implement a more useful strategy in this case we're going to talk about still while we validate now this works by first returning a cached 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 that specific URL and if there is you know greater we can return it to the web app immediately but a service worker doesn't stop there independent of the cache look up it also makes a network request the response is stored in the cache replacing the previous potentially stale contacts and if there wasn't a match the cache was in a match in the cache when we originally checked it then we could 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 serviceworker that implements still while revalidate 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 the width at power comes complexity and that's where work box comes in work box 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 serviceworker with work box you get to trade complexity for flexibility so here's an example let's go back to that previous slide with the code for sale while revalidate strategy work box offers the same behavior in a single line of code so that's a pretty clear example of work box handling complexity for you but I also mentioned flexibility and that's where work box really shines so all it takes is a few additional lines of configuration to customize the way your serviceworker behaves here we've got that same scale while revalidate strategy but we till work box that cache responses should expire after 60 minutes and this can be useful when you're ok was slightly still 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 same for me implement cache expiration but you'd end up turning your dozens of lines of code into hundreds of lines and requiring everyone to reimplementation ality 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 that's why should you care about adding in a service worker to a web app to begin with caching is cool and all but what 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 and 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 could be reliably fast all the time but he can't just throw together any old serviceworker 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 work boxes two comes in work box allows you to build on a solid foundation which you can 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 work box also gives you control over how you build your serviceworker 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 work box strategies to an existing serviceworker but if you prefer work box to handle more for you we have tools that will generate it and configure your entire service worker from scratch and using work box 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 deployed web apps using work box first up is Pinterest which we Patti just talked about a bit and it'll probably company that many of you 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 a serviceworker caching is key to that goal Pinterest turned to work box to power their serviceworker and let's take a closer look at some of the features that they're using so first Pinterest is using work box for pre caching pre-caching assures 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 free caching work box automatically takes care of 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 work box generates a manifest of versioned URLs this list is stored as part of the service workers code when a given version in the service workers first installed work box uses this list of revision 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 work box'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 the 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 work box handles the 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 work box uses this information to keep track of when it needs to update the pre cache URLs and you won't get stuck serving the same cache HTML indefinitely Pinterest is also using work box to handle navigation requests so these are the initial requests that your browser makes for the web apps 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 she would always have that as a bottleneck but service workers change that model we can now serve cached HTML immediately by passing a network for navigations entirely using a cache first strategy net for navigations is crucial for speed and reliability and work box really makes it easy to do so let's take a closer look at that here's a high-level view of how work box handles navigation requests so let's say there is a logged in user that returns to Pinterest and the service work is already installed the visitor navigates to a specific URL and the service worker can tell that it's a navigation request it gets that information as part of the fetch event that it's handling our service worker it 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 alike 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 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 work box code that corresponds with that behavior that we just saw using work box means focusing on flexible configuration not on copying countless lines a boilerplate code all you do is tell work box which HTML document should be used for most navigations ideally there should be a URL that was previously pre cached and is always gonna 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 a serviceworker and when they started using work box they weren't starting from scratch has that he mentioned they had an existing service worker in place and they had some established build processes already around it but work box 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 consider that a great opportunity to look into making it a PWA at the same time so their goal 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 work box could help because they're starting without any existing serviceworker their use case is a little bit different than Pinterest they're fine with letting work box generate their entire service worker for them each time they rebuild their site work box has a few ways of integrating with it build processes and it's flexible enough to work with most set ups in Wired case they were already using NPM scripts so using work box'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 works box is flexible enough to sit slide in right at the end of their build chain they just added in a new NPM script that calls the work box CLI and there are new service workers behavior is entirely determined by this configuration file that they pass in to the CLI let's take a closer look at that file you know 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 wired one and take advantage of that for their PWA as well sending up pre-caching is as simple as configuring these two options that you see here in their a configuration file they point workbox to the root directory that contains all of their builds assets and they provide patterns that are used to match a subset of the files in that directory that they want precache so they've decided the precache all of their HTML javascript SVG images and their CSS when they run the work box CLI each time they rebuild their site that configuration leads to a section of their serviceworker that looks something like this contains that manifest 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 and that's not the only type of image that's displayed and wires web app each article page has at least one image associated with it and those images tend to be larger I 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 why are you thinking approach to my colleague Evo 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 are all happen to be smaller SVG's are pre cached and always available but their article images you use a runtime fashion strategy along with cache expiration works boxes flexibility makes this easy to setup 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 our article images at runtime and define an expiration policy after they run their build process work box 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 our Dwyers goals for their PWA was reengage in 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 serviceworker 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 cash directly without having to go through the serviceworker to get that information cache storage API returns a list of cache URLs and then wive's using that list to populate its offline view here so why are pw a journey isn't over yet their team is hard at work on many areas with their web app but they're happy to open up a pre-release version of the PWA to the public today and so 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 the many partners that have deployed a Service Worker using the current version of work box what does the future hold for work box as a project for looking forward here's a quick look back at some history so work box is a direct descendants of two widely used projects sw-precache and sw-toolbox we took the core features from both and join them together in a consistent interface we've been busy work box 100 was released back in May at Google i/o and the toooo release came out in August since then our main focus has been on the work box the REO 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 three oh 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 in two three oh hi in the list of priorities for work box Rio is a revamped web pack plugin while we've shipped a web pack plug-in since our launch we've heard your feedback that required a lot of extra configuration and it didn't support common web pack development server environments we've listened and for the common pre-caching use case the new web pack plug-in should be zero configuration so this becomes this of course you saw 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 cue up and retry requests that require a network connection when you're offline and new and version of 3.0 is support for binary request spot use which is perfect for retrying uploads of videos images or other rich media another focus for 300 was reducing the amount of JavaScript that the work box runtime adds to your serviceworker instead of shipping one large bundle and encouraging everybody to use that 3 Oh introduces a lightweight dynamic module loader you can continue writing code against the work box SW interface like before but under the hood only actual dependency is 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 serviceworker we're really happy with the results so our goal is to take the runtime 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 300 is our official CDN which is hosted on Google Cloud Storage by default our build tools will import the work box 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 I just mentioned if you use the work box s with W library hosted on the student 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 300 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 work box codebase and a special shout out that person 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 and we really appreciate his help and speaking of open source we'd 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 work box special thanks goes out to all those projects maintained errs so while free o is still on the horizon everyone could go out and start building with the current release of work box 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 work box can help we've got documentation along with new getting started guides and migration code lab on developers.google.com at the URL you see on the screen and feel free to reach out if you would like to chat more about work box I love hearing about how people are using it thanks everybody for taking the time to learn about work box today and thanks for all the partners and members of the community who continue to show your support it's very much [Music]