View the Service Worker and the Cache, and Debug a PWA with Chrome’s Dev Tools
Progressive Web Apps can be difficult to debug because of how they are cached by the browser, and also because they aggressively cache static assets from your app. In the Application tab of the Chrome Dev Tools, you can choose to update the service worker on every reload, bypass the service worker entirely, or switch to offline mode - all of which help to debug your PWA.
You can also see what is in the service worker’s cache, and you can use the Network tab to see what is being served by the service worker, and when assets are coming directly from the web server.
Instructor: [00:00] In the Chrome DevTools, click the Application tab. Here, we can see the service worker info. We can see the name of the current service worker and the date and time it was received. If you are running into caching issues, then check here first to make sure that you have the latest service worker running.
[00:20] For development, we could also avoid some caching issues by clicking "Update on reload," which should now update the service worker if we reload, or you can update to a new version by clicking "Update" or even by unregistering the service worker altogether before reloading.
[00:37] In production or when you really run into cache issues, make sure to close any and all tabs that are open to your app and reopen them to refresh the service worker. Without the "Upload on reload" checkbox clicked, it is not enough to just refresh the browser tab to update a service worker in production.
[00:57] We can also click on the service worker name to see the contents of the currently running worker. We can see here that "Create React App" uses Workbox from Google to build its service worker.
[01:10] Back in the Application tab, we can force the browser into offline mode by clicking this Offline checkbox and refreshing the tab. We can see the Network tab with a caution icon showing us that we don't have a network connection, but our app still loads all the static assets.
[01:27] However, the item's HTTP call can't load because dynamic JSON calls aren't cached by default. We can see when it's cached by the service worker by opening the cache storage tree here and can select the Workbox cache and see all of the static assets that are cached by the service worker.
[01:46] We can see the same information if we go to the Network tab. We can see the static assets being served from the service worker, but not the items JSON call.
[01:56] Even if we go back to the Application tab and turn off offline mode and reload, then in the Network tab we can still see the static assets being served from the service worker, which will generally be faster than a full network call, especially on a mobile network.
[02:14] Even if we don't want to enable a full offline mode with our progressive web app, enabling the service worker can still increase the loading performance of your application. To turn off the service worker caching for developing, back in the Application tab you can click "Bypass for network," which will skip the service worker altogether for your assets.
[02:33] If we reload and switch back to the Network tab, we can see all the assets being served directly from the web server now, and not from the service worker. This can help in development, but keep in mind that users will not have these tools available.
[02:47] Let's simulate a real user by disabling the "Update on reload" and "Bypass for network" and then make a simple change to our application by just changing the header from "To-Do List" to "My To-Do List" and then build and serve that new version of the app.
[03:06] Back in the browser, it doesn't matter how many times we reload. We will always see the old version of the app because that's what's being cached by the old service worker.
[03:16] Forced reloading with command-shift-R may work to get the new version of the app, but the only guaranteed way to get the new version of both the service worker and the app is to close all the Application tabs and reopen them.
[03:30] That aggressive caching is one of the biggest potential downsides to using a service worker. You'll have to keep that in mind as you're developing your application.
Yes, there are a few potential downsides.
One is exactly what Kent pointed out - that once a user is running a service worker, to get a new version, they HAVE to close all tabs that were running the old one - there is no way to force a new one to install. (In that way, it's a lot like a native app).
The other downside I would mention is that not every browser supports service workers - or doesn't support all the features. So, you always have to keep in mind that some users won't be able to use the service worker, and you site should always be able to operate without it.
Should I be concerned that my service worker info (in Application tab) displays 'Received 12/31/1969, 7:00:00 PM'?
That's possibly a problem with Chrome? I found the following bug report: https://bugs.chromium.org/p/chromium/issues/detail?id=845629
If you force it to update the cache, does the date/time update? Also, does the service worker work as expected anyway?
Thanks for quick response. I was not too concerned because everything seems to be working fine. I tried a number of things when I noticed the date. My cache is always set to disabled. I stopped/started the service worker, hit the 'Update' link and even opened and closed the tab and no difference in the date displayed. The same date shows up from other domains' service workers (like Code Sandbox). And I have never had any issues with those other domains either. As long as it does not start acting up, I can ignore this for the time being. Otherwise, I have the Firefox Developer Edition I can fall back on, or might download Chromium down the road. As an aside, I am just beginning to look into mobile side of React. After React (PWA) I wanted to explore React Native. Do mobile frameworks also rely on service workers?
Ok yeah, sounds like it's ok then - just a weird display issue or bug.
Nope - React Native doesn't use service workers - it's a different thing all together. React Native takes React code that you write (using special react-native components, not web components), and builds a separate ios and android app. Those apps take those components, and run them as actual native components. That means you're not writing a webpage that's running in a view like some other frameworks - but you're creating apps that use real, native components.
Egghead has some great courses about React Native too!
Thanks. That gives me a good starting point for comparing the two approaches down the road.
There is a header "Clear-Site-Data" that can be sent by the server to the browsers to clear bad service worker implementations or rougue files. The only catch is that the usual suspects in the browser work (IE, Edge, Safari) has not implemented it yet.
Is there any REAL downside to having a Service Worker? I've read Tweets from people(Kent C Dodds) in particular that was having one HECK of a time removing / re-loading of a defunct ServiceWorker. it's incredibly scary to think that if anything was to happen, it could be catastrophic to your users.