Join egghead, unlock knowledge.

Want more egghead?

This lesson is for members. Join us? Get access to all 3,000+ tutorials + a community with expert developers around the world.

Unlock This Lesson
Become a member
to unlock all features

Level Up!

Access all courses & lessons on egghead today and lock-in your price for life.


    View the Service Worker and the Cache, and Debug a PWA with Chrome’s Dev Tools

    Chris AchardChris Achard
    chrome-devtoolsChrome DevTools

    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.



    Become a Member to view code

    You must be a Member to view code

    Access all courses and lessons, track your progress, gain confidence and expertise.

    Become a Member
    and unlock code for this lesson




    Instructor: 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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.