Categories
Online Marketing

Service Workers – The State of the Web

My guest is jeff posnick, he’s on Google’s developer relations team and today we’re talking about service workers and how they’re elevating the capabilities of progressive web apps. Let’S get started all right, so Jeff, thanks for being here in the context of web technologies. What does it mean for a worker and what does it actually do so? The whole idea of a worker has been around for a while.

Traditionally there were web workers and it’s basically serves as almost like a background thread for the web, so a worker can execute JavaScript code, that’s kind of independent from the context of your actual web page and it’s a great way to kind of offload processing or I Do tasks that might take a certain amount of time without slowing down the main thread for your web page and yeah, that that’s kind of should been the traditional model for workers on the web.

So now what does it mean for a Service Worker? What does that? Actually do the service workers builds kind of on that concept and adds some superpowers really things that you were not able to do before so a service worker is similar to worker and that it’s, you know, running independent from your actual web page and it doesn’t have Access to things like the Dom you know or the global scope of your web page, but unlike workers, it could respond to specific events and some of those events relate to network traffic.

So one of the really cool things and most common use cases for a Service Worker is to respond to outgoing Network requests that your webpage might be making, and you can kind of sit in between your webpage and the network and almost serve as a proxy that You control and you could write code to take advantage of things like the cache, storage, API and say hey. You know, I know how to respond to this particular request without having to go to the network.

I could just use this cache response and thereby saving you know the uncertainty and unreliability that comes with coming against the network. It also enables capabilities like push notifications, etc. Yeah so there’s a whole bunch of kind of event based listeners that you can set up in the Service Worker, including responding to portion of vacations. That may come from a notification server and you know fetching requests and people other kind of interesting things are kinda slated for the future as well.

So what’s the status of its implementation and support? Yes, the service workers are well supported right now in modern browsers. So pretty much anything Chrome or chromium based, Firefox, Safari and edge at the moment, it’s great. They all have at least a basic level of support for service workers and some of the enabling technologies, like the cache storage API, so they’re they’re ready to use right now.

So web sites may experience Network reliability issues at any. Given time, would you recommend service workers for every website? Should they all be using one? Well, I mean it’s tempting to just throw a service worker up and see what happens. I would suggest to take a little bit more of a considerate approach before adding a Service Worker to your web app. Ideally, a service worker will kind of play the same role that your web server would play and maybe share the same logic for doing routing and templating that your web server would normally respond with.

And if you have a setup where, like your web server, for instance from a lot of single page apps, the web servers just can respond with some static HTML that could be used satisfy any sort of request. That’S pretty easy to map into a Service Worker behavior. We call that the app shell model or a service work role say: hey. You know, you’re navigating to XYZ URL. I could just respond with this HTML and it’ll always work.

So that’s a really good model for using a serviceworker. If you have a single page app we’re also seeing some success with partners or using models where their servers implemented in JavaScript, they have some routing logic and they have some templating logic. That’S on JavaScript, and that translates over really well to the serviceworker as well, where the serviceworker you just basically fill the role that the server would normally play.

I would say if you have a scenario where your back-end web server is doing a whole bunch of complex templating and remote API calls and language that is not JavaScript. It really might be hard to get your serviceworker to behave exactly the same way. So in those scenarios I mean you can add a serviceworker and we have some kind of provisions in place to not pay the price of having that serviceworker, intercepting all requests and then not doing anything and just going on against the network.

There are waves of saying, hey, you know we have a serviceworker, but we’re not going to be able to respond with HTML for navigation requests. In those scenarios it is still possible use the serviceworker for things like ok, show, custom offline page when you detect that a user’s network connection is down or implement a kind of interesting caching strategy, like still while revalidate for certain types of resources.

So it is still possible to add a serviceworker in those cases, but you won’t necessarily get the same performance and reliability benefits that you get when your serviceworker really respond to all navigations with HTML by essentially having a network proxy juggling requests and responses. Is there a latency cost of having a serviceworker yeah, so I mean you’re you’re running JavaScript code, that’s sitting in between your web app and then a work and that’s not for me.

Some of it depends upon whether the serviceworker is already running. One of the kind of neat features about a serviceworker is that just it’s particularly to preserve battery on mobile devices? It’S killed pretty aggressively. It doesn’t just keep running forever in the background. So sometimes you do have to startup the serviceworker again and there is a cost involved in that startup. There’S a really good talk from the chrome dev summit that just happened a couple of months ago that kind of goes into some metrics and real-world performance.

Timings of you know exactly how long it takes to startup a serviceworker, seeing tens to hundreds of milliseconds depending upon the actual device and things like the storage beautiful device. So you are going to be paying that cost. Potentially, when you’re using a serviceworker – and you know again – that’s really why it’s important to make sure that you have a strategy in place for responding to requests, hopefully by avoiding that work and just going against storage API.

Ideally, and if you’re doing that, then you should see the service worker give you an that positive in terms of performance, you know paying tens, maybe even hundreds of milliseconds is nothing compared to the multiple seconds. Simply didn’t see that you might expect from making a network request each time you navigate to a new URL right. What’S the saying the fastest request is the one that you never need to make indeed yeah.

So what are some anti patterns that you’ve seen the way that people have implemented service workers? There’S a lot of power involved in using a Service Worker? It is just JavaScript that you could write that will pretty much do whatever you want, so you can do all sorts of crazy things, some of which are kind of cool as proof of concepts, but not necessarily things you want to deploy to production in terms of The things that we’ve seen kind of as pain, points or things that are pretty easy to, unfortunately get wrong when implementing a Service Worker.

I think one of the things that it’s most common is caching requests and responses, as you go without having any sort of upper limit on the amount of data that you’re storing. So now you can imagine a website that maybe has a bunch of different articles. Each of those articles has images it’s pretty easy to write a serviceworker that just intercepts all those requests and takes the responses, save some in the cache, but those cached responses will never get cleaned up by default.

There’S not really any provision in the cache storage API for saying you know stop when you reach 50 or 100 entries, or something like that, so you could very easily just keep using up space on your users devices and potentially use up space for things that are Never going to be used again, you know if you have an article from a week ago and you’re caching, all the images and that article that’s kind of cool.

I guess if you’re going to be visit article immediately, but if it’s a page that users never going to go to again, then you’re, really just caching things for no reason. I would say that really one of the important things before you implement your serviceworker kind of have a strategy for each type of request and say: here’s my navigation requests that are being made for HTML; here’s how I’m going to respond to them here.

The image requests. I’M making you know, maybe it doesn’t make sense to cash them at all, or maybe certain it only cache certain images and not others. So thinking about that – and that really just means getting really comfortable with the kind of network info panel in the browser’s dev tools and just seeing the full list of requests are being made. You know. Sometimes your web app is making requests.

If you don’t even realize it’s happening and it’s coming from the third-party code and your service worker ends up seeing that too, so you want to make sure that you know what your service work is doing. You know what your web app is doing and just one other. I would know that a lot of times and kind of pain, point and things that could go wrong with me using a service work, but just has to do with controlling updates to resources.

So you know you are stepping in between. You know your web app and a web server you’re responding, potentially the cached resources, if you’re not sure that those cached resources are being updated. Every time you make changes to your actual website and you read – apply to your web server, it’s possible that your users will end up seeing stale content kind of indefinitely, and this is a trade-off like seeing stale content, but avoiding the network gives you performance benefits.

So that’s that’s good for a lot of scenarios, but you do need to have a provision in place for updating and making sure that you know. Maybe the user sees still content then the next time they visit the site. They get fresh content. So you know you could do that right. Unfortunately, you could get that part wrong and the users can end up the frustrating experience. So you maintain a tool called work box j/s.

What is that? What does it do sure so? Work box is open source and a set of libraries for dealing with service workers and kind of all aspects of building service workers. So we have some tools that integrated with build processes, including you know we have web pack plugin. We have a command line tool. We have a node module and that aspect of the tools, basically, is something you can drop in your current build process and kind of get a list of all of the assets that are being produced.

Every time you rebuild your site along with kind of some fingerprinting information like say you know, this is a particular version of your index. Dot HTML work backs will keep track of that for you and then it will efficiently cache all of those files that are being created by your build process for you and that just helps ensure that you don’t run into scenarios like I just described where you’ve rebuilt.

Your site – and you know you never get updates to your previously cached resources and we also have some tools as part of work box, that kind of harm or execute at runtime. That’S part of the serviceworker, so some libraries for doing common things like routing requests. We have there’s just kind of some canonical response strategies for dealing with caching, so things like still while we validate or going cache.

First, we have implementations of those strategies inside of work box, and then we have some kind of like value adds on top of what you get with the basic serviceworker spec in the cache stored specs. So we actually have an implementation of a cache expiration policy that you could apply to the caches that would otherwise just grow indefinitely, but using work box you could say, hey. You know it actually like to stop.

When I reach ten items and purge the least recently used items and just cache when that happens, and a few other kind of ran two modules, we see it as a bit of a kind of grab bag for all the things that somebody might want to do With a serviceworker and we kind of ship them as individual modules, you can choose the ones that you think would be useful for your particular use case. I don’t want to use something, that’s fine, you don’t have to incur the cost of you know downloading it or anything like that.

Do you foresee some of those caching and expiration policies making their way back into the cache storage API yeah. I mean it’s kind of interesting whenever you have something: that’s almost like a polyfill for some behavior on the web. You know whether that ends up being implemented back into the standards, and you know the the actual runtime could just fade away and just use the underlying standards.

And you know I’d like to see that. I think that where cost has been really great for kind of enabling folks to ship service workers in production and seeing the types of things that they actually need, when you’re shipping somebody in production and a lot of times when you could do that and get points. As a vision thing like yeah, you know it is actually important to have run time, cache expiration.

That could then be used. You know when going to different standards, groups and saying hey, we really do need to extend. You know, what’s supported natively in the platform, to take care of this really common use case. You know what that actually happens or not remains to be seen, but you know I think work box is positioned to help folks with kind of that initial, proving that these things are necessary stage kind of take it from there.

So, in terms of adoption, according to the HTTP archive, less than 1 % of websites tested actually include a serviceworker which is kind of a misleading number. For two reasons. The first is that it’s actually growing at a very fast rate and the websites that do include it are actually pretty popular websites. Can you give us some examples of those yeah? So I think you know the raw number of URLs unique URLs might be on the lower side, but I think in terms of traffic, you know sites as big as Google search have deployed a serviceworker for some types of clients.

You know partners that we’ve talked about using work box, in particular in the past and Gleevec Starbucks has a nice progressive web app, that’s implemented Pinterest as well, and there’s also some sites that you might have heard of like Facebook and Twitter that are using service workers. Not using work box but using them to kind of unlock things like you know, they’re progressive web app experience – or you know in some cases just showing notifications, which is important part of you know being on the web and having parity with native apps.

So you know, I think that the actual number of you know you visits to web pages is probably much higher than the 1 % number would indicate, and you know I mean there are challenges with adding a service worker into especially legacy sites. You know it does. Take that coordination that we talked about before tree, making sure that your service worker actually is behaving in a similar way that your web server would behave and yeah that doesn’t always fit into existing sites.

So a lot of times we’ve seen when working with partners in particular, is like you know: you’re planning a rewrite, re architecture of your site anyway, that’s a great time to add a service worker in and just kind of take care of that story as well. Are there any options for CMS users who may be using things like WordPress or Drupal? So there definitely are, and I think that you know first of all, I’d work for everybody back to another talk from the most recent chrome dev summit.

That really goes into some detail about the WordPress ecosystem in general, so they have a really cool solution, some folks from the dev rel team that Google have been working on it and I think it kind of works around one that that problem. I was saying where the architecture for your kind of back-end web server needs to match up with the serviceworker implementation I kind of just sending a baseline.

So it’s not an attempt to take any arbitrary, WordPress site that might be out there, which might be executing random PHP code depending upon you know what kind of themes and extensions and all the other stuff is going on. You really are not going to be able to successfully translate that into just a general-purpose serviceworker, but the approach that was subscribed and this talk. It seems to be building on top of a kind of a common baseline of using the amp plugin as a starting point.

So any site that has gone through the effort of kind of meeting all the requirements for using the amp plugin. So it means I don’t know the full set, but I think, like not running external scripts, not doing anything too crazy with other plugins. That’S inserting random HTML on the page building. On top of that, you can then have a serviceworker. That’S like okay. I actually do know how to handle this subset of activities that you know WordPress is doing when it’s using the unplug in and it can automatically generate that serviceworker for you.

So again, it’s part of a migration story. I think it’s not going to just drop into any existing legacy WordPress site, but it does give a nice path forward for folks who are planning on rewriting anyway are planning on making some changes anyway, and plugging into the CMS ecosystem is great way to increase adoption By tens of percents on what yeah absolutely so, what kinds of resources would you recommend for someone who’s just getting started with service workers? We have a lot of material available, some of which is more recent than others.

I would say that the things that I worked on most recently are the resiliency section of web dev. So if you were to go there kind of have something I would walk you through the various steps of thinking about adding a service worker to your website or just really thinking about making your website more resilient in general. So it’ll talk about you know identifying your network traffic it’ll talk about using the browser’s HTTP cache effectively, which is kind of your first line of defense, and then it all kind of go into how you could add work box to an existing site and the various Steps involved there, so if you want kind of a guided path, I would say that’s one option we’ll biased.

For that. I would say that if you want to just learn more about service workers in general and material written by my colleague, Jake Archibald, it’s probably the best that for folks who really want to deep dive on things, he was somebody who worked on the actual serviceworker specification And you know he knows more than anybody else about these things, so he was a really great article talking about the serviceworker lifecycle, just all the different events we have fired, and you know how you have to handle those events differently and implications that they have for You know the state of your caches and updates, and things like that so diving into that would be kind of my recommended starting point, and he has another article that talks about kind of a cookbook almost for recipes for caching, so implementations of the stove are valid.

A pattern cache first pattern: if you wanted to implement it yourself, instead of using work box, he kind of walks through the process. There is that the offline cookbook, yes, the offline cookbook, and if you want something, that’s really offline, there’s some actual physical books that that are pretty cool, related to service workers and progressive web apps in general. There’S a new book written by Jason, Grigsby, eight in particular, that I would recommend and just kind of talks a little bit about, I’m necessarily some of the technical aspects of service workers, but more about why you should think about adding a service worker to your site And why you might want to build progressive web app in general and that’s a really cool book, that kind of takes it from a slightly different angle, but gives some good perspective great Jeff.

Thank you again for being here. Absolutely you can find links to everything we talked about in the description below thanks a lot and we’ll see you next time.


Website management packages are important for any business these days. Check out the video from Allshouse Designs to see what can be done for your company and yes, for how much. 

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.