 So the time has finally come. We are bringing our blog to the offline world. We are going to write a service worker for our WordPress blog. It's going to get a little bit weird at times because WordPress doesn't yet have out-of-the-box support for service worker, so we will have to do some shoehorning ourselves. But in terms of caching strategy, I took a fairly simplistic approach because I'm just using stale while revalidate for everything. If you remember a couple of episodes ago, we made sure that our caching headers are really, really solid and that means that our revalidate step is going to be really cheap. So if you want to catch up on that, I also did a micro-tip on stale while revalidate a while ago, which I'm going to link to in the description. In the context of a blog, though, content is usually fairly static and doesn't change a lot, so I thought it's a good trade-off to push more towards being onscreen fast rather than waiting for a fresh response from a potentially very slow network. So to see how that works, let's look into some code. Service worker is part of my theme. On install, it just downloads and caches everything that I need to get onscreen very quickly. It won't re-download all these assets because most of them are already in the cache from just loading the initial index HTML, but since there is no service worker yet, it will have to revalidate those with the server. So that means that the install step of our service worker is going to be very cheap, but not very fast. But that's okay because the user is busy reading our blog posts and interacting with the page. So this will all happen in the background and the service worker will boot up and at some point just take over when it's ready to do so. The fetch handler in my service worker looks a bit messy, but essentially it just uses stale while revalidate. There is a couple of if statements at the top because I wanted to implement a lot of exceptions on this. So for example, we don't want to cache WordPress's admin panel. We don't want to cache some sort of WordPress plugin or some assets from different domains. And that's basically just what these if statements do. The actual response is built on the fly. We are already caching the header and the footer independently. So that means that if the user navigates to a new blog post, it really only needs to download the content without header and footer because we already have those. And then we stitch those things together and send them off to the browser. That also means that even if the user is on a very slow network, they will almost instantly see the header on screen giving them the feeling of a progressively loading page while the actual content rolls in over a much slower network. So you might not believe it, but that's all we need to do to make our blog work offline. This is all the service worker does seriously. But also last episode, I promised you a second use case for our message bus involving service worker. So let's look into that. So I augmented my message bus to not only live within one tab, but to actually span across all open tabs and the service worker. And that means that if the service worker dispatches a message onto the message bus that it will get distributed to all open tabs at the same time. And that actually turned out to be really, really useful. So here you can see my implementation of stale wire validate. If there's something in the cache, I'm gonna use the cache response straight away. And if there's not, I'm gonna wait for the network to give me a new response. But even if there is something in the cache, I'm gonna send something out to the network to check with the server if there is a newer version of this resource by comparing e-tags. If the e-tag has changed, I update my cache, but I also send a message to all open tabs using my message bus. Now every open tab can check independently if that new resource is relevant to them or not. And if so, they will show a banner where the user can click to reload. I found this to be a great compromise between being on screen as fast as possible and informing the user that what they have been served actually turned out to be stale data. And with this, we actually conclude the commit lock series for my WordPress project. I hope you enjoyed it. I hope you learned something. If you wanna take a look at some details of the code, the entire project is on GitHub and I will link to it in the description of this video. If you have any questions, feel free to put them in the comments below or over on Twitter. If you find it interesting, you should consider subscribing so you know when the next Supercharged is coming out and with this, thank you for watching.