The Service Worker API for browsers allows web designers to offer visitors something they never had before: access to sites or web applications even when offline, be it for short or long periods of time.
Whether you want to ensure a visitor can still read your site while going through a train tunnel, or you want to create apps that don’t require an internet connection, service workers provide the perfect solution.
As great as service workers are, when you begin coding them for the first time there are a few snags that can slow your progress–unless you’re aware of what those snags are up front. This tutorial will furnish you with five essential tips for service worker development, and we hope they’ll help you avoid these hiccups and save you from the associated troubleshooting headaches.
Before We Start
If you’re new to service workers check out our beginner’s course Simple Service Workers for Offline Websites, and Jeremy Keith’s book Going Offline, both available on Envato Elements.
![]()
Service WorkersSimple Service Workers for Offline Web Pages
1. Put Your Service Worker Script in the Root Directory
The earliest issue that could trip you up when you write your first service
worker, is that you’ll probably do what you always do and put your script
into a sub-directory named js or scripts. However, with service workers, this run-of-the-mill action can be problematic.
The reason is that the scope of your service worker is, by default, defined by its location. What does that mean? It means if you put your script in a /js directory its scope is now limited to that /js directory. As a result it can only handle page requests that come via www.yoursite.com/js/, and will completely ignore other requests, such as those through www.yoursite.com or www.yoursite.com/news/ for example.
This limited scope in turn means you won’t be able to provide offline fallbacks for most of your site. For your service worker to be able to handle any requests that come through any part of your site, its scope needs to be all-encompassing.
Note: you can actually override your service worker’s default scope when registering it, e.g.
navigator.serviceWorker.register('/sw.js', {
scope: '/'
});
With this approach you can still house all your scripts in a sub-directory if doing so is very important for your project.
But generally speaking, the easiest approach is to put your service worker in the root directory, hence automatically setting its scope to cover the entire site.
2. Use the Application Panel in Chrome / Chromium Dev Tools
While service workers are supported in all major browsers, at the moment Chrome or Chromium is arguably the best browser to develop them in. This is due to the very helpful Application panel, found in the Developer Tools. When you’re going through the development process you’re pretty much going to live in this tab:
In this tab there is a dedicated section for service workers where you can verify your script is registered, active and running. You can also use this tab to simulate being offline, temporarily bypass your service workers, and manually unregister previous scripts you no longer need.
3. Don’t Use Hard Reload
As well as not putting scripts in a sub-directory, another development habit you’ll have to break when putting together service workers is using “Hard Reload” or “Empty Cache and Hard Reload”. You’ve probably done this thousands of times when testing sites, using the functionality to purge your cache and ensure you see an accurate reflection of your development changes. But with service workers this won’t get the desired effect.
When
you have a service worker registered and active, any use of “Hard
Reload” will completely bypass it. You might hard reload your site, see
that your code hasn’t executed the way you expect and think you’ve made a mistake, only to realize later the script never ran in the first
place.
So the bad news is “Hard Reload” and “Empty Cache and Hard Reload” are out of bounds during service worker development, leading us to our next question:
How
can you properly refresh your page and test your service worker code
changes if you can’t use “Hard Reload” or “Empty Cache and Hard Reload”?
The answer to this question lies in the following two tips:
4. Check the “Update on Reload” Box
By default, when you refresh a page on which you’re testing a service worker, you won’t actually see the results of any of your code changes. This is because the version of the script you initially registered is the one that stays active in the browser, even after page reloads, unless you take explicit action to update it.
So again here, we have a situation where you might be refreshing your
page and wondering why your code changes aren’t taking effect, unless
you’re aware of the quirks of service workers.
To make sure you’re always loading the latest version of your script, go into the Applications tab and check the Update on Reload box. This ensures that every time you reload the page, (and remember, use only normal reload, not hard reload), the browser will automatically update the service worker for you.
Note: there is the additional option to click on the Update link displayed next to your registered service worker, but using the automated approach on reload is typically easier.
5. Inspect and Manually Delete Cache Objects
The final, very handy, feature of the Applications tab we’re going to touch on is the ability to peek inside objects stored in the cache, and manually delete them as required. Given we don’t want to use Empty Cache and Hard Reload, this functionality will become an essential part of the service worker development process.
In the left column of the Applications tab, you’ll see an area
labeled Cache Storage. If you expand this area, you’ll be able to see
any cache objects held in storage that relate to the current URL.
Click any of these items and you can inspect their
contents, which is very helpful for verifying that resources you want to
serve offline are being properly added to the cache by your service worker.
To get rid of cache objects you no longer need, just right-click on an object and choose Delete.
Between this cache object deletion function, and the Update on Reload checkbox, you’re all set to stick with using the normal page reload while still ensuring you’re properly testing the latest changes to your work.
To Summarize
- Generally speaking, put service worker scripts in your project’s root directory so the entire site is within their scope.
- Use Chrome / Chromium’s Application tab while developing.
- Don’t use Hard Reload or Empty Cache and Hard Reload.
- Check the Update on Reload box in the Application tab to ensure the registered service worker is up to date.
- Manually delete cache objects as necessary via the Cache Storage section of the Application tab, where you can also inspect cache object contents.
For more on service workers check out our new course Simple Service Workers for Offline Websites, and Jeremy Keith’s book Going Offline, now available on Envato Elements.
Powered by WPeMatico
