safari remove service worker

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

How to disable a persistent "Service Worker"

Just a little FYI. I tried everything to stop a troublesome "Service Worker" from loading, a Javascript that stores cached versions of websites. Finally I got it to stop loading by deleting everything in folder:

The previous Safari had a “Disable Service Workers” in the Develop>Experimental menu, but in version 13 it looks like they removed that option. With a broken Service Worker, you can never reload a website with new content.

Posted on Aug 4, 2020 5:19 PM

Similar questions

• How to turn off the auto-appearing services menu after highlighted text in BigSur Hi, Does anyone know a way to turn off the services menu that auto-appears after you highlight text in BigSur (see image). I have one machine running BigSur where this menu never appears, and one where it always appears. The problem is that anytime you accidentally click it in a web browser, it forces the page to reload, and you lose any unsaved data. It's infuriating. I can't find any information anywhere about how to disable it. Thanks! 205 4
• Safari hangs consistently Ever since installing Monterey, Safari hangs consistently for me. I suspected it was Private Relay, but I have completely disabled it. I have also disabled the "Hide IP from Trackers" in preferences and I'm not running any extensions. It happens multiple times per day which makes Safari completely unreliable. Sometimes it hangs when using the address bar to search while other times it just hangs when going to a website I often use (Amazon, Yahoo, Google, etc.). The only solution is to Quit Safari and relaunch. It's almost like something in Safari gets clogged because using another browser always works. It has nothing to do with the network because Firefox and Chrome always work perfectly. I've waited for a fix through multiple MacOS updates but the bug is still there. I just upgraded to Monterey 12.3 today and Safari is still hanging. This is very annoying. 2458 9
• Cannot clear website data in Safari When I try to clear website data for a specific site, Safari goes into a loop and never load whatever website data there is. See screenshot. I can clear all data but that's inconvenient. Used to be able to clear data for only a specific site. Anyone have any hints on how to solve this? 424 3

Loading page content

Page content loaded

There are no replies.

Removing service workers from Mac Safari

11 March 2019

Somehow I had a stale Service Worker that was causing errors and a blank screen on my site in Safari. Here's how to clear them out.

After I had merged the PR I had created for getting this site up and running on my production domain, I tested it in Safari om my Mac and got a blank screen. Safari Dev Tools were showing weird 404's that seemed to be occurring as a result of a Service Worker.

I don't actually use Service Workers on this site; but I had played around with older versions of Gatsby, as well as Hugo and Jekyll a while back, and maybe I had inadvertantly registered a Service Worker that is now very stale.

In Chrome Dev Tools you can easily find all Service Workers and disable them, but while on Safari on the Mac you can see the Service Workers in the Develop menu and drop into Dev Tools for that Service Worker, you cannot actually unregister them.

You'll need to drop into the Dev Tools Console and run this snippet while you are on the site you want to unregister the Service Workers from:

The console will say Promise {status: "pending"} = $1 , but it should work pretty much straight away.

You should now see that you have no Service Workers for the site anymore.

What is a Service Worker? Transform Your Web Site to an Instant Loading Powerhouse!

Last Updated - Sat Jan 09 2021

Trying to figure out what a service worker is? You're not alone!

A Service Worker is a script that executes in the background, in a separate thread from the browser UI. Service worker cache makes it possible for a web site to function offline. They are the technical powerhouse that levels up a website to a progressive web app . They enable deep platform integration, like rich caching, push notifications and background sync.

Service workers are designed to be an extensible platform, additional features are currently being planned.

They can't access the DOM, but can intercept all network request. This allows developers the opportunity to control how requests are handled, providing a rich way to make websites work offline.

Service workers are have been called a game changer for the web. I don't think that is a simple exaggeration, because they enable many much needed capabilities and make the core architecture I used for years native.

Service Workers sound amazing!

This is the key technology or modern web API behind Progressive Web Applications. Without a service worker a website is just a website, add a service worker and you now have an application.

There are some key features about service workers you need to understand:

• A Service Worker is a JavaScript File
• They execute on a separate thread from the UI
• They cannot access the DOM directly
• There is a life cycle or series of events a service worker flows through to become active, explained later
• They are only live while being used, so no battery strain
• They are isolated to the origin or domain they are registered with
• Service Workers require HTTPS
• Can send messages to and from the UI
• Do not require an open web page to function
• Are supported by all major browsers, including iOS Safari
• Are similar to Web Workers, but better in many ways

How Do Service Workers Work?

Service worker extensibility, service worker life cycle, how long to service workers last, how do i check if a service worker is registered, how do i unregister a service worker, service worker caching, how do i update my service worker cache, what browsers support service workers, what is the difference between a service worker and a web worker, what a service worker can't do.

A Service worker sits between the browser and the network, acting like a proxy server, handling a collection of non-UI centric tasks. They are event driven and live outside the browser process, enabling them to work without an active browser session. The service worker is a script that executes in a thread, separate from the UI. This enables the service worker to perform non-UI tasks, making a web site perform better.

Service workers terminate when not in use and restored when required, this keeps them from straining the CPU and draining batteries. They act as a programmable network proxy, or intermediary between the browser and the network, empowering developers to design how network requests are handled.

The first power a service worker brings to a web site is the ability to enable offline capabilities with granular control. This is done with a rich caching API and intercepting all network requests before they leave.

Caching not only enables offline experiences, websites can load instantly when retrieved from cache. Service worker caching makes the network a progressive enhancement, or not required to make the site usable.

An underestimated service worker feature is its extensibility Service workers are designed to be the backbone that supports additional functionality. The first two features shipping in browsers are native push notifications and background sync. More new APIs are currently being debated and should start appearing in browsers in the near future.

Service workers live in their own thread and do not have access to the DOM. They also have their own global scope, referred to using the 'self' object.

The also require a site is served using HTTPS. This requirement is due to the powerful features service workers offer. HTTPS prevents many common attacks. Today all sites should be served using HTTPS as the barriers to implement have been lifted and the minimal amount of security they offer.

They are also asynchronous. This means all APIs support promises. This also means certain APIs and functions are not accessible in service workers. The most notable is localStorage. Instead, data should be stored using IndexedDB.

Before diving into these great service worker features developers need to understand the life cycle.

A service worker must be registered by a website. Because some browsers still don't support service workers you should perform a feature check before registering a service worker. This is done by checking for the presence of 'serviceWorker' in navigator.

To register the service worker call navigator.serviceWorker.register. Pass the path to the service worker. The register function returns a promise.

If successful the promise returns a reference to the service worker registration object. From there you can perform specific UI tasks as needed.

Standard Service Worker Events

• push (not supported by Safari)
• sync (not supported by most browsers yet)

When a service worker is registered the "install" event. In this event the most common task to perform is called pre-caching.

Pre-caching is where a pre-defined list of assets files needed to form a page or site, and add them to cache before they are requested. This takes advantage of the service worker cache to persist these responses.

The install event is only triggered once in a service worker's life time. The event will not trigger again until the service worker is updated.

The next event that fires as part of the registration life cycle is 'activate'. When a service worker is installed it does not immediately become active. The natural sequence is for a new service worker to wait until all service worker 'clients' are closed.

The reason service workers are designed not to immediately take over is to keep them from breaking the user experience.

The skipWaiting function forces a waiting service worker to become active. This should only be employed when you are certain the new service worker will not break any existing clients.

Once the service worker becomes active the 'activate' event fires.

This event is commonly used to perform any clean up or migration tasks. For example, removing legacy caches that might conflict with the new service worker caches.

There is no hard rule as to how long a browser keeps a service worker running. Internally the browser's engine will use a set of heuristics to determine when to terminate the service worker process.

In general if a web page is dormant the process will spin down after a minute or two, maybe as soon as 30 seconds.

The reality is the exact time will depend on hardware, usage patterns, etc. 

The good news is it takes a handful of milliseconds to turn a service worker on. It is so fast you wont really notice any latency. You also do not need to program anything special to deal with a scenario without the service worker, you site will just work. The magic of progressive enhancement.

There are multiple ways to check if a service worker is registered. The easiest is to call the serviceworkers.getRegistrations method.

This is code you can add to your pages script to log registration for technical support or developer debugging.

The 'getRegistrations' method returns an array of all service workers registered under the current scope or website.

If you are just logging the registration to the console you would be better off viewing the Dev Tools 'Application' tab. It has a sub-panel that displays a visual of the origin's registered service worker. You can also trigger background sync events and test push notifications.

You can also delete the service worker, force an update and other general management that helps with development.

The real value getRegistrations offers is for some sort of back-door support feature. We all know what it is like trying to help someone remotely and you cannot access the DevTools to really troubleshoot the problem. Sometimes you will want some sort of visual support page or modal to provide information about the application state.

The average consumer will not know how to access the DevTools console panel. Instead you can create a user interface within the application to echo the service worker registration object properties.

Hopefully you will not encounter a scenario where your service worker code has create a user experience bug. In case you do there are few things you can do to remove or unregister a service worker .

Most scenarios where you need to remove a service worker will be when you are developing the application. In this case you can use the DevTools to remove or delete the service worker. 

If you need to remove or delete a deployed service worker it gets a little more tricky. There are programmatic ways to get you out of the jam.

Read more about removal techniques.

The service worker specification includes native caching capabilities. This replaces the traditional appCache that has caused many management issues since it was created. Service worker caching is much more manageable.

The cache API provides a persistence layer that stores network responses which can be queried by the matching request.

The key to using service worker caching is the service worker 'fetch' event. This event triggers for each network request allowing you to intercept the request and check if the response has been cached before it goes to the network.

By accessing assets in local cache you can forgo expensive network requests. This means the site can work when there is no network, offline, or poor network connectivity, low bars or false cellular connectivity (known as LiFi).

In the example above the code checks is a response has been previously cached. If so, the cached response is returned. If not the request is passed along to the network.

When the request returns the response is cached and returned to the UI.

If the network fails the logic falls back to an offline response.

There are a lot of moving parts being used in the example code. I will provide more details in a follow up articles.

A common misconception is once you cache a network request it is stored for eternity. This is not the case. You have complete control over when and how cache is invalidated and updated.

This is a very complex and involved topic. I think I can personally detail about 3 dozen caching strategies, all involve a way to manage cache invalidation or updating the cache.

I think the key to invalidation is determining either a time to invalidate (time to live) value, a manifest or a background update process. In the later you can make a HEAD request to see if an update has been made on the server by comparing the last-updated header value against the time the response was cached.

There is no single answer for every application. You will need to plan your strategy and be prepared to adjust as you see how your application is used.

All modern browsers support service workers , at least caching. Chrome, FireFox and Edge support native push notifications and Chrome and Edge have background sync support.

This means the core PWA features are available in all devices and browsers. Push and background sync are enhancements.

We have built several Progressive Web Apps that required sophisticated offline caching strategies to allow applications work offline, even on iOS. These applications require all requests, even POST, PUT and DELETE actions to be cached in a queue. We made these application sync even on iOS when connections were known to be available.

Service workers and web workers are similar tools. Both execute processes in a separate thread from the user interface. The real difference lies in the actual usage context.

Neither have access to the DOM or window object. They are better for middle tier or long, process intensive tasks.

Web workers only run when a web page is open and a task is triggered from a script in the page.

A service worker can also execute when a page is open, but may also be triggered by a platform event like a push notification. A web page does not have to be open for a service worker to execute.

Service workers also act as a proxy between the network and the user interface. If a page is being used (the most common scenario) all HTTPS network requests pass through the service worker as you learned in the caching section.

Communication between the UI and both workers is done using the postMessage method and the message event. If you have done any multi-threaded programming this model is very familiar.

Service Workers Can’t Access the Window Object

The window object executes in the UI thread, separate from the service worker thread. This means a service worker can’t directly manipulate DOM elements. The service worker and the window can communicate via the postMessage method. This allows messages to be passed back and forth. You will need to have logic on each side to process the the messages and trigger different workflows.

Service Workers Require HTTPS

Because Service Workers have so much power they are only enabled if the page is served using HTTPS. This ensures a level of security to allow the service worker to do the things it is designed to do.

Over HTTP the service worker would be susceptible to man in the middle attacks. Developers can work on localhost, which keeps us from installing a local TLS certificate.

In other words the answer to does a service worker work on HTTP is no. The site will still render, but the service worker does not register and is not executed.

Are Only Asynchronous

Service workers are asynchronous, which means they use and rely on Promises and APIs that use Promises. This means synchronous APIs like XHR and localStorage are not available to a service worker. Never fear, you can use the Fetch API (which replaced XHR) and IndexedDB. Most APIs that do not directly interact with the window object are accessible in a service worker.

We use cookies to give you the best experience possible. By continuing, we'll assume you're cool with our cookie policy.

Install Love2Dev for quick, easy access from your homescreen or start menu.

DEV Community

Posted on Jan 25, 2018

Safari now supports Service Workers: What this means (to me at least)

Apple's latest release notes indicate their support for Service Workers .

Highlights of Safari 11.1 Service Workers. Implement background scripts for offline web applications and faster web pages. Payment Request. Provide a consistent user payment experience in Safari using a standards-based API. Security Improvements. Improved protection against memory corruption and code execution attacks. Web Inspector Updates. New designs for the Network Tab and the Styles sidebar in the Elements Tab.

The Service Worker API that acts as a network proxy for the browser that gives web developers more control over requests. This means better experiences in bad network conditions and developers get access to certain app architecture concepts which can improve user experience in all conditions.

Safari's support will put a huge dent in the Can I Use numbers for the better. What this means for me and my team is that we can start confidently leaning in to Service Workers with more of our time and effort. We still have to build applications that progressively enhance from browsers which do not support them, but that extra layer of complication can now be justified. For some teams, they could have reached that justification earlier, but in my mind Service Workers had to be considered more experimental before this major browser got onboard.

App Shell Architecture

One application design enabled by Service Workers is called App Shell Architecture , where the layout and re-used assets of a web page are cached for re-use and the network requests center more around the data being passed over in order to render content of the page as a secondary request. Similar page-construction choices are already somewhat popular in web dev land but they are not necessarily a great choice without this caching layer in my opinion. If you cannot cache the shell, I really wouldn't advise making so many calls home just to render the first content. You want less latency, not more.

We do not make use of this architexture right now, and that's why this Safari update is important. I think it just puts us over the hump where we can put these ideas front of mind. It gives us enough browser support to build paths where the page layout can be stored on the user's machine—desktop or mobile.

We are certainly web-first shop and there is no native dev.to option yet , and I would not want to put the cart before the horse, but this might give us an excuse to stay fully web even on mobile for a while. But I don't want to commit too far in that direction. The development benefits of only having a single application are great if the user experience helped by powerful browser APIs.

Our application already makes use of networking logic at the edge via our CDN Fastly and leaning in to Service Workers gives us one more edge layer. A request that has never been handled by Service Workers is still likely to be handled at an edge node.

If you live in New Zealand we don't expect you to come all the way to Utah for your content. Service Workers mean that much of the HTML (and other assets, of course) can stay with you on your browser so your next visit is much faster to show you some layout and sends fewer bytes over the wire. We still want to provide the same crisp load without service workers, but we have the tools to cater a really good overall web experience for consistent users.

Thanks Apple

This move might ease some heartburn over Safari . I'm glad we have dipped our toes in Service Workers so we are not just catching up now, but I am also glad we did not try jumping in head first a year ago only to maintain a more complicated cross-browser compatibility for only 2/3rds support.

Happy coding ❤️

Top comments (8)

Templates let you quickly answer FAQs or store snippets for re-use.

• Location Newcastle Upon Tyne
• Work Founder at Saint
• Joined Sep 27, 2017

App shell architecture whilst discussed at length by Google in the past really couldn't take off like it should have whilst Apple lagged behind as you say. Hopefully we see more applications following this architecture, it makes complete sense.

• Joined Aug 2, 2017

I currently am reading this from the dev.to PWA. Are you able to share some insights and/or numbers about the PWA usage?

• Email [email protected]
• Location NY
• Education Mount Allison University
• Pronouns He/him
• Work Co-founder at Forem
• Joined Dec 27, 2015

We haven't gotten around to tracking our PWA traffic with much granularity but about 25% of our traffic is Android and we have about 2,000 PWA installs.

The PWA thing is great in the long run if it works out, but in the short term we've been strategically more focused on the technology than the technicalities of PWA install action, which is a bit out of our control.

Awesome to hear that you are using the PWA though!

• Joined Jun 25, 2018

Can you provide some quick insight as to why App Shell Architecture, ( First time I heard about this ) and Services worker provides "mean that much of the HTML (and other assets, of course) can stay with you on your browser so your next visit is much faster to show you some layout and sends fewer bytes over the wire. "

How is that different from good old Browser Caching?

Service workers can act as a pretty smart programmed reverse proxy. A subset of what you can do with this is caching, but you have a lot more explicit control over this functionality. This post has a lot of great responses to help.

• Location Bangalore
• Work iOS Developer
• Joined Nov 20, 2018

It is important to note that the service worker is not available when the page is loaded inside a WKWebview within a non-browser iOS app. Above restriction can be relaxed if you can add the urls in the plots before building but that is too restrictive.

• Email [email protected]
• Location Nomad
• Joined Mar 22, 2017

I like how safari is coming in line, even though it's late. PWAs on iOS would be a huge win for the PWA paradigm.

• Location Dhaka, Bangladesh
• Work Full-Stack Software Engineer
• Joined Dec 13, 2018

I'm using macOS Catalina version10.15.4. I'm not able to visit dev.to from my safari browser. But still, I can able to do that from Chrome. @ben Do you have any idea about this issue?

Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink .

Hide child comments as well

For further actions, you may consider blocking this person and/or reporting abuse

How To Get The Hash of A File In Node.js

saransh kataria - Apr 26

The ABCs of the Critical Path Method

Chad Riebe - Apr 12

Upgrading Your Angular Application to it's latest

Nikhil Sai - Apr 12

New to JS what should be my next goal after JS?

SpiderMonkey17 - Apr 25

We're a place where coders share, stay up-to-date and grow their careers.

• Español – América Latina
• Português – Brasil
• Tiếng Việt

Service workers

Users expect apps to start on slow or flaky network connections, or even when offline. They expect the content they've most recently interacted with, such as media tracks or tickets and itineraries, to be available and usable. When a request isn't possible, they expect the app to tell them instead of silently failing or crashing. And users wish to do it all quickly. As we can see in this study Milliseconds make millions , even a 0.1 second improvement in load times can improve conversion by up to 10%. In summary: users expect PWAs to be reliable and that's why we have service workers.

Hello service workers

When an app requests a resource covered by the service worker's scope, including when a user is offline, the service worker intercepts the request, acting as a network proxy. It can then decide if it should serve the resource from the cache via the Cache Storage API, from the network as normally would happen without a service worker, or create it from a local algorithm. This lets you provide a similar experience to that provided by a platform app. It can even work entirely off line.

Registering a service worker

Before a service worker takes control of your page, it must be registered for your PWA. That means the first time a user comes to your PWA, network requests will go directly to your server because the service worker is not yet in control of your pages.

After checking if the browser supports the Service Worker API, your PWA can register a service worker. When loaded, the service worker sets up shop between your PWA and the network, intercepting requests and serving the corresponding responses.

Verify if a service worker is registered

To verify if a service worker is registered, use developer tools in your favorite browser.

In Firefox and Chromium-based browsers (Microsoft Edge, Google Chrome, or Samsung Internet):

• Open developer tools, then click the Application tab.
• In the left pane, select Service Workers .
• Check that the service worker's script URL appears with the status "Activated". (You'll learn what this status means in the lifecycle section in this chapter). On Firefox the status can be "Running" or "Stopped".
• Click the Develop menu then the Service Workers submenu.
• Check that an entry with the current origin appears in the submenu. It opens an inspector over the service worker's context.

The folder your service worker sits in determines its scope. A service worker that lives at example.com/my-pwa/sw.js can control any navigation at the my-pwa path or below, such as example.com/my-pwa/demos/ . Service workers can only control items (pages, workers, collectively "clients") in their scope. Scope applies to browser tabs and PWA windows.

Only one service worker per scope is allowed. When active and running, only one instance is typically available no matter how many clients are in memory (such as PWA windows or browser tabs).

Safari has more complex scope management, known as partitions, affecting how scopes work if you have cross-domain iframes. To read more about WebKit's implementation, read their blog post .

Service workers have a lifecycle that dictates how they are installed, this is separate from your PWA installation. The service worker lifecycle starts with registering the service worker. The browser then attempts to download and parse the service worker file. If parsing succeeds, its install event is fired. The install event only fires once.

Service worker installation happens silently, without requiring user permission, even if the user doesn't install the PWA. The Service Worker API is even available on platforms that do not support PWA installation, such as Safari and Firefox on desktop devices.

After the installation, the service worker is not yet in control of its clients, including your PWA. It needs to be activated first. When the service worker is ready to control its clients, the activate event will fire. This doesn't mean, though, that the page that registered the service worker will be managed. By default, the service worker will not take control until the next time you navigate to that page, either due to reloading the page or re-opening the PWA.

You can listen for events in the service worker's global scope using the self object.

serviceworker.js

Updating a service worker

Service workers get updated when the browser detects that the service worker currently controlling the client and the new (from your server) version of the same file are byte-different.

After a successful installation, the new service worker will wait to activate until the existing (old) service worker no longer controls any clients. This state is called "waiting", and it's how the browser ensures that only one version of your service worker is running at a time. Refreshing a page or reopening the PWA won't make the new service worker take control. The user needs to close or navigate away from all tabs and windows using the current service worker and then navigate back. Only then will the new service worker take control. Visit this service worker lifecycle article for more information.

Service worker lifespan

Once installed and registered, a service worker can manage all network requests within its scope. It runs on its own thread, with activation and termination controlled by the browser. This lets it work even before or after your PWA is open. While service workers run on their own thread, there is no guarantee that in-memory state will persist between runs of a service worker, so make sure anything you want to reuse on each run is available either in IndexedDB or some other persistent storage.

If not already running, a service worker will start whenever a network request in its scope is asked for, or when a triggering event, like periodic background sync or a push message, is received.

Service workers don't live indefinitely. While exact timings differ between browsers, service workers will be terminated if they've been idle for a few seconds, or if they've been busy for too long. If a service worker has been terminated and an event occurs that would start it up, it will restart.

Capabilities

With a registered and active service worker, you have a thread with a completely different execution lifecycle than the main one on your PWA. However, by default, the service worker file itself has no behavior. It won't cache or serve any resources, as this has to be done by your code. You'll find out how in the following chapters.

Service worker's capabilities are not just for proxy or serving HTTP requests; other features are available on top of it for other purposes, such as background code execution, web push notifications, and process payments. We'll discuss these additions in the capabilities chapter .

• Service Worker API (MDN)
• Service Worker mindset
• WebKit Workers at your service
• ES Modules in Service Workers
• Service worker lifecycle

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License , and code samples are licensed under the Apache 2.0 License . For details, see the Google Developers Site Policies . Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2021-12-03 UTC.

• Skip to main content
• Select language
• Skip to search
• Using Service Workers

Why is my service worker failing to register?

Custom responses to requests, deleting old caches.

This is an experimental technology Because this technology's specification has not stabilized, check the compatibility table for usage in various browsers. Also note that the syntax and behavior of an experimental technology is subject to change in future versions of browsers as the specification changes.

This article provides information on getting started with service workers, including basic architecture, registering a service worker, the install and activation process for a new service worker, updating your service worker, cache control and custom responses, all in the context of a simple app with offline functionality. 

The premise of service workers

One overriding problem that web users have suffered with for years is loss of connectivity. The best web app in the world will provide a terrible user experience if you can’t download it. There have been various attempts to create technologies to solve this problem, as our Offline page shows, and some of the issues have been solved. But the overriding problem is that there still isn’t a good overall control mechanism for asset caching and custom network requests. The previous attempt — AppCache — seemed to be a good idea because it allowed you to specify assets to cache really easily. However, it made many assumptions about what you were trying to do and then broke horribly when your app didn’t follow those assumptions exactly. Read Jake Archibald's Application Cache is a Douchebag for more details.

Note : As of Firefox 44, when AppCache is used to provide offline support for a page a warning message is now displayed in the console advising developers to use Service workers instead ( bug 1204581 .)

Service workers should finally fix these issues. Service worker syntax is more complex than that of AppCache, but the trade off is that you can use JavaScript to control your AppCache-implied behaviours with a fine degree of granularity, allowing you to handle this problem and many more. Using a Service worker you can easily set an app up to use cached assets first, thus providing a default experience even when offline, before then getting more data from the network (commonly known as Offline First ). This is already available with native apps, which is one of the main reasons native apps are often chosen over web apps.

Setting up to play with service workers

Many service workers features are now enabled by default in newer versions of supporting browsers. If however you find that demo code is not working in your installed versions, you might need to enable a pref:

• Firefox Nightly : Go to  about:config  and set  dom.serviceWorkers.enabled  to true; restart browser.
• Chrome Canary : Go to  chrome://flags  and turn on  experimental-web-platform-features ; restart browser (note that some features are now enabled by default in Chrome.)
• Opera : Go to  opera://flags  and enable  Support for ServiceWorker ; restart browser.

You’ll also need to serve your code via HTTPS — Service workers are restricted to running across HTTPS for security reasons. GitHub is therefore a good place to host experiments, as it supports HTTPS. In order to facilitate local development,  localhost  is considered a secure origin by browsers as well.

Basic architecture

With service workers, the following steps are generally observed for basic set up:

• The service worker URL is fetched and registered via serviceWorkerContainer.register() .
• If successful, the service worker is executed in a ServiceWorkerGlobalScope ; this is basically a special kind of worker context, running off the main script execution thread, with no DOM access.
• The service worker is now ready to process events.
• Installation of the worker is attempted when service worker-controlled pages are accessed subsequently. An Install event is always the first one sent to a service worker (this can be used to start the process of populating an IndexedDB, and caching site assets). This is really the same kind of procedure as installing a native or Firefox OS app — making everything available for use offline.
• When the oninstall handler completes, the service worker is considered installed.
• Next is activation. When the service worker is installed, it then receives an activate event. The primary use of onactivate is for cleanup of resources used in previous versions of a Service worker script.
• The Service worker will now control pages, but only those opened after the register() is successful. i.e. a document starts life with or without a Service worker and maintains that for its lifetime. So documents will have to be reloaded to actually be controlled.

The below graphic shows a summary of the available service worker events:

Promises are a great mechanism for running async operations, with success dependant on one another. This is central to the way service workers work. Promises can do a great many things, but for now, all you need to know is that if something returns a promise, you can attach .then() to the end and include callbacks inside it for success, failure, etc., or you can insert .catch() on the end if you want to include a failure callback.

Let’s compare a traditional synchronous callback structure to its asynchronous promise equivalent.

In the first example, we have to wait for myFunction() to run and return value before any more of the code can execute. In the second example, myFunction() returns a promise for value , then the rest of the code can carry on running. When the promise resolves, the code inside then will be run, asynchronously. Now for a real example — what if we wanted to load images dynamically, but we wanted to make sure the images were loaded before we tried to display them? This is a standard thing to want to do, but it can be a bit of a pain. We can use .onload to only display the image after it’s loaded, but what about events that start happening before we start listening to them? We could try to work around this using .complete , but it’s still not foolproof, and what about multiple images? And, ummm, it’s still synchronous, so blocks the main thread. Instead, we could build our own promise to handle this kind of case. (See our Promises test example for the source code, or look at it running live .)

We return a new promise using the Promise() constructor, which takes as an argument a callback function with resolve and reject parameters. Somewhere in the function, we need to define what happens for the promise to resolve successfully or be rejected — in this case return a 200 OK status or not — and then call resolve on success, or reject on failure. The rest of the contents of this function is fairly standard XHR stuff, so we won’t worry about that for now.

When we come to call the imgLoad() function, we call it with the url to the image we want to load, as we might expect, but the rest of the code is a little different:

On to the end of the function call, we chain the promise then() method, which contains two functions — the first one is executed when the promise successfully resolves, and the second is called when the promise is rejected. In the resolved case, we display the image inside myImage and append it to the body (it’s argument is the request.response contained inside the promise’s resolve method); in the rejected case we return an error to the console.

This all happens asynchronously.

Note : You can also chain promise calls together, for example: myPromise().then(success, failure).then(success).catch(failure);

Note : You can find a lot more out about promises by reading Jake Archibald’s excellent JavaScript Promises: there and back again .

Service workers demo

To demonstrate just the very basics of registering and installing a service worker, we have created a simple demo called sw-test , which is a simple Star wars Lego image gallery. It uses a promise-powered function to read image data from a JSON object and load the images using Ajax, before displaying the images in a line down the page. We’ve kept things static and simple for now. It also registers, installs, and activates a service worker, and when more of the spec is supported by browsers it will cache all the files required so it will work offline!

• In the original, we only passed in a URL to an image we wanted to load. In this version, we pass in a JSON fragment containing all the data for a single image (see what they look like in image-list.js ). This is because all the data for each promise resolve has to be passed in with the promise, as it is asynchronous. If you just passed in the url, and then tried to access the other items in the JSON separately when the for() loop is being iterated through later on, it wouldn’t work, as the promise wouldn’t resolve at the same time as the iterations are being done (that is a synchronous process.)
• We actually resolve the promise with an array, as we want to make the loaded image blob available to the resolving function later on in the code, but also the image name, credits and alt text (see app.js lines 31-34 ). Promises will only resolve with a single argument, so if you want to resolve with multiple values, you need to use an array/object.
• To access the resolved promise values, we then access this function as you’d then expect (see app.js lines 60-64 ). This may seem a bit odd at first, but this is the way promises work.

Enter service workers

Now let’s get on to service workers!

Registering your worker

The first block of code in our app’s JavaScript file — app.js — is as follows. This is our entry point into using service workers.

• The outer block performs a feature detection test to make sure service workers are supported before trying to register one.
• Next, we use the ServiceWorkerContainer.register() function to register the service worker for this site, which is just a JavaScript file residing inside our app (note this is the file's URL relative to the origin, not the JS file that references it.)
• The scope parameter is optional, and can be used to specify the subset of your content that you want the service worker to control. In this case, we have specified ' /sw-test/' , which means all content under the app's origin. If you leave it out, it will default to this value anyway, but we specified it here for illustration purposes.
• The .then() promise function is used to chain a success case onto our promise structure.  When the promise resolves successfully, the code inside it executes.
• Finally, we chain a .catch() function onto the end that will run if the promise is rejected.

This registers a service worker, which runs in a worker context, and therefore has no DOM access. You then run code in the service worker outside of your normal pages to control their loading. A single service worker can control many pages. Each time a page within your scope is loaded, the service worker is installed against that page and operates on it. Bear in mind therefore that you need to be careful with global variables in the service worker script: each page doesn’t get its own unique worker.

Note : Your service worker functions like a proxy server, allowing you to modify requests and responses, replace them with items from its own cache, and more.

Note : One great thing about service workers is that if you use feature detection like we’ve shown above, browsers that don’t support service workers can just use your app online in the normal expected fashion. Furthermore, if you use AppCache and SW on a page, browsers that don’t support SW but do support AppCache will use that, and browsers that support both will ignore the AppCache and let SW take over.

This could be for the following reasons:

• You are not running your application through HTTPS.
• The path to your service worker file is not written correctly — it needs to be written relative to the origin, not your app’s root directory. In our example, the worker is at https://mdn.github.io/sw-test/sw.js , and the app’s root is https://mdn.github.io/sw-test/ . But the path needs to be written as /sw-test/sw.js , not /sw.js .
• The service worker being pointed to is on a different origin to that of your app. This is also not allowed.

• The service worker will only catch requests from clients under the service worker's scope.
• The max scope for a service worker is the location of the worker.
• If your server worker is active on a client being served with the Service-Worker-Allowed header, you can specify a list of max scopes for that worker.
• In Firefox, Service Worker APIs are hidden and cannot be used when the user is in private browsing mode .

Install and activate: populating your cache

After your service worker is registered, the browser will attempt to install then activate the service worker for your page/site. The install event is fired when an install is successfully completed. The install event is generally used to populate your browser’s offline caching capabilities with the assets you need to run your app offline. To do this, we use Service Worker’s brand new storage API — cache — a global on the service worker that allows us to store assets delivered by responses, and keyed by their requests. This API works in a similar way to the browser’s standard cache, but it is specific to your domain. It persists until you tell it not to — again, you have full control.

Note : The Cache API is not supported in every browser. (See the Browser support section for more information.) If you want to use this now, you could consider using a polyfill like the one available in Google's Topeka demo , or perhaps store your assets in IndexedDB .

Let’s start this section by looking at a code sample — this is the first block you’ll find in our service worker :

• Here we add an install event listener to the service worker (hence this ), and then chain a ExtendableEvent.waitUntil() method onto the event — this ensures that the service worker will not install until the code inside waitUntil() has successfully occurred.
• Inside waitUntil() we use the caches.open() method to create a new cache called v1 , which will be version 1 of our site resources cache. This returns a promise for a created cache; once resolved, we then call a function that calls addAll() on the created cache, which for its parameter takes an array of origin-relative URLs to all the resources you want to cache.
• If the promise is rejected, the install fails, and the worker won’t do anything. This is ok, as you can fix your code and then try again the next time registration occurs.
• After a successful installation, the service worker activates. This doesn’t have much of a distinct use the first time your service worker is installed/activated, but it means more when the service worker is updated (see the Updating your service worker section later on.)

Note : localStorage works in a similar way to service worker cache, but it is synchronous, so not allowed in service workers.

Note : IndexedDB can be used inside a service worker for data storage if you require it.

Now you’ve got your site assets cached, you need to tell service workers to do something with the cached content. This is easily done with the fetch event.

A fetch event fires every time any resource controlled by a service worker is fetched, which includes the documents inside the specified scope, and any resources referenced in those documents (for example if index.html makes a cross origin request to embed an image, that still goes through its service worker.)

You can attach a fetch event listener to the service worker, then call the respondWith() method on the event to hijack our HTTP responses and update them with your own magic.

We could start by simply responding with the resource whose url matches that of the network request, in each case:

caches.match(event.request) allows us to match each resource requested from the network with the equivalent resource available in the cache, if there is a matching one available. The matching is done via url and vary headers, just like with normal HTTP requests.

Let’s look at a few other options we have when defining our magic (see our Fetch API documentation for more information about Request and Response objects.)

The Response() constructor allows you to create a custom response. In this case, we are just returning a simple text string:

This more complex Response below shows that you can optionally pass a set of headers in with your response, emulating standard HTTP response headers. Here we are just telling the browser what the content type of our synthetic response is:

If a match wasn’t found in the cache, you could tell the browser to simply fetch the default network request for that resource, to get the new resource from the network if it is available:

If a match wasn’t found in the cache, and the network isn’t available, you could just match the request with some kind of default fallback page as a response using match() , like this:

You can retrieve a lot of information about each request by calling parameters of the Request object returned by the FetchEvent :

Recovering failed requests

So caches.match(event.request) is great when there is a match in the service worker cache, but what about cases when there isn’t a match? If we didn’t provide any kind of failure handling, our promise would resolve with undefined and we wouldn't get anything returned.

Fortunately service workers’ promise-based structure makes it trivial to provide further options towards success. We could do this:

If the resources isn't in the cache, it is requested from the network.

If we were being really clever, we would not only request the resource from the network; we would also save it into the cache so that later requests for that resource could be retrieved offline too! This would mean that if extra images were added to the Star Wars gallery, our app could automatically grab them and cache them. The following would do the trick:

Here we return the default network request with return fetch(event.request) , which returns a promise. When this promise is resolved, we respond by running a function that grabs our cache using caches.open('v1') ; this also returns a promise. When that promise resolves, cache.put() is used to add the resource to the cache. The resource is grabbed from event.request , and the response is then cloned with response.clone() and added to the cache. The clone is put in the cache, and the original response is returned to the browser to be given to the page that called it.

Cloning the response is necessary because request and response streams can only be read once.  In order to return the response to the browser and put it in the cache we have to clone it. So the original gets returned to the browser and the clone gets sent to the cache.  They are each read once.

The only trouble we have now is that if the request doesn’t match anything in the cache, and the network is not available, our request will still fail. Let’s provide a default fallback so that whatever happens, the user will at least get something:

We have opted for this fallback image because the only updates that are likely to fail are new images, as everything else is depended on for installation in the install event listener we saw earlier.

Updating your service worker

If your service worker has previously been installed, but then a new version of the worker is available on refresh or page load, the new version is installed in the background, but not yet activated. It is only activated when there are no longer any pages loaded that are still using the old service worker. As soon as there are no more such pages still loaded, the new service worker activates.

You’ll want to update your install event listener in the new service worker to something like this (notice the new version number):

While this happens, the previous version is still responsible for fetches. The new version is installing in the background. We are calling the new cache v2 , so the previous v1 cache isn't disturbed.

When no pages are using the current version, the new worker activates and becomes responsible for fetches.

You also get an activate event. This is a generally used to do stuff that would have broken the previous version while it was still running, for example getting rid of old caches. This is also useful for removing data that is no longer needed to avoid filling up too much disk space — each browser has a hard limit on the amount of cache storage that a given service worker can use. The browser does its best to manage disk space, but it may delete the Cache storage for an origin.  The browser will generally delete all of the data for an origin or none of the data for an origin.

Promises passed into waitUntil() will block other events until completion, so you can rest assured that your clean-up operation will have completed by the time you get your first fetch event on the new cache.

Developer tools

Chrome has chrome://inspect/#service-workers , which shows current service worker activity and storage on a device, and chrome://serviceworker-internals , which shows more detail and allows you to start/stop/debug the worker process. In the future they will have throttling/offline modes to simulate bad or non-existent connections, which will be a really good thing.

Firefox has also started to implement some useful tools related to service workers:

• You can navigate to about:debugging to see what SWs are registered and update/remove them.
• When testing you can get around the HTTPS restriction by checking the "Enable Service Workers over HTTP (when toolbox is open)" option in the Firefox Developer Tools settings .

Note : You may serve your app from http://localhost (e.g. using me@localhost:/my/app$ python -m SimpleHTTPServer ) for local development. See Security considerations

Specifications

Browser compatibility.

[1] Service workers (and Push ) have been disabled in the Firefox 45 Extended Support Release (ESR.)

• The Service Worker Cookbook
• Is ServiceWorker ready?
• Download the Service Workers 101 cheatsheet .
• Using web workers

Document Tags and Contributors

• ServiceWorker
• Service Worker API
• CacheStorage
• ExtendableEvent
• InstallEvent
• Navigator.serviceWorker
• NotificationEvent
• PeriodicSyncEvent
• PeriodicSyncManager
• PeriodicSyncRegistration
• ServiceWorkerContainer
• ServiceWorkerGlobalScope
• ServiceWorkerRegistration
• SyncManager
• SyncRegistration
• WindowClient
• Channel Messaging API
• Notifications API
• Web Workers API
• Documentation:
• Pages tagged "ServiceWorker"
• Service Worker doc status
• The MDN project

Service Workers Tutorial

New Course Coming Soon:

Get Really Good at Git

Service Workers are a key technology powering Progressive Web Applications on the mobile web. They allow caching of resources and push notifications, two of the main distinguishing features that up to now set native apps apart

Introduction to Service Workers

Background processing, precache assets during installation, caching network requests, installation, updating a service worker, fetch events, background sync, push events, a note about console logs.

Service Workers are at the core of Progressive Web Apps , because they allow caching of resources and push notifications, two of the main distinguishing features that up to now set native apps apart.

A Service Worker is programmable proxy between your web page and the network, providing the ability to intercept and cache network requests, effectively giving you the ability to create an offline-first experience for your app .

It’s a special kind of web worker , a JavaScript file associated with a web page which runs on a worker context, separate from the main thread, giving the benefit of being non-blocking - so computations can be done without sacrificing the UI responsiveness.

Being on a separate thread it has no DOM access, and no access to the Local Storage APIs and the XHR API as well, and it can only communicate back to the main thread using the Channel Messaging API .

Service Workers cooperate with other recent Web APIs:

And they are only available on HTTPS protocol pages, except for local requests, which do not need a secure connection for an easier testing.

Service Workers run independent of the application they are associated to, and they can receive messages when they are not active.

For example they can work:

• when your mobile application is in the background , not active
• when your mobile application is closed , so even not running in the background
• when the browser is closed , if the app is running in the browser

The main scenarios where Service Workers are very useful are:

• they can be used as a caching layer to handle network requests, and cache content to be used when offline
• to allow push notifications

A Service Worker only runs when needed, and it’s stopped when not used.

Offline Support

Traditionally the offline experience for web apps has been very poor. Without a network, often web mobile apps won’t work, while native mobile apps have the ability to offer either a working version, or some kind of nice message.

This is not a nice message, but this is what web pages look like in Chrome without a network connection:

Possibly the only nice thing about this is that you get to play a free game by clicking the dinosaur, but it gets boring pretty quickly.

In the recent past the HTML5 AppCache already promised to allow web apps to cache resources and work offline, but its lack of flexibility and confusing behavior made it clear that it wasn’t good enough for the job, failing its promises (and it’s been discontinued ).

Service Workers are the new standard for offline caching.

Which kind of caching is possible?

Assets that are reused throughout the application, like images, CSS, JavaScript files, can be installed the first time the app is opened.

This gives the base of what is called the App Shell architecture .

Using the Fetch API we can edit the response coming from the server, determining if the server is not reachable and providing a response from the cache instead.

A Service Worker Lifecycle

A Service Worker goes through 3 steps to be fully working:

Registration

Registration tells the browser where the server worker is, and it starts the installation in the background.

Example code to register a Service Worker placed in worker.js :

Even if this code is called multiple times, the browser will only perform the registration if the service worker is new, not registered previously, or if it has been updated.

The register() call also accepts a scope parameter, which is a path that determines which part of your application can be controlled by the service worker.

It defaults to all files and subfolders contained in the folder that contains the service worker file, so if you put it in the root folder, it will have control over the entire app. In a subfolder, it will only control pages accessible under that route.

The example below registers the worker, by specifying the /notifications/ folder scope.

The / is important: in this case, the page /notifications won’t trigger the Service Worker, while if the scope was

it would have worked.

NOTE: The service worker cannot “up” itself from a folder: if its file is put under /notifications , it cannot control the / path or any other path that is not under /notifications .

If the browser determines that a service worker is outdated or has never been registered before, it will proceed to install it.

This is a good event to prepare the Service Worker to be used, by initializing a cache , and cache the App Shell and static assets using the Cache API .

The activation stage is the third step, once the service worker has been successfully registered and installed.

At this point, the service worker will be able to work with new page loads.

It cannot interact with pages already loaded, which means the service worker is only useful on the second time the user interacts with the app, or reloads one of the pages already open.

A good use case for this event is to cleanup old caches and things associated with the old version but unused in the new version of the service worker.

To update a Service Worker you just need to change one byte into it, and when the register code is run, it will be updated.

Once a Service Worker is updated, it won’t become available until all pages that were loaded with the old service worker attached are closed.

This ensures that nothing will break on the apps / pages already working.

Refreshing the page is not enough, as the old worker is still running and it’s not been removed.

A fetch event is fired when a resource is requested on the network.

This offers us the ability to look in the cache before making network requests.

For example the snippet below uses the Cache API to check if the request URL was already stored in the cached responses, and return the cached response if this is the case. Otherwise, it executes the fetch request and returns it.

Background sync allows outgoing connections to be deferred until the user has a working network connection.

This is key to ensure a user can use the app offline, and take actions on it, and queue server-side updates for when there is a connection open, instead of showing an endless spinning wheel trying to get a signal.

This code listens for the event in the Service Worker:

doSomething() returns a promise. If it fails, another sync event will be scheduled to retry automatically, until it succeeds.

This also allows an app to update data from the server as soon as there is a working connection available.

Service Workers enable web apps to provide native Push Notifications to users, through the use of:

• Notifications API

Push and Notifications are actually two different concepts and technologies, but combined to provide what we know as Push Notifications . Push provides the mechanism that allows a server to send information to a service worker, and Notifications are the way service workers can show information to the user.

Since Service Workers run even when the app is not running, they can listen for push events coming, and either provide user notifications, or update the state of the app.

Push events are initiated by a backend, through a browser push service, like the one provided by Firebase .

Here is an example of how the service worker can listen for incoming push events:

If you have any console log statement ( console.log and friends) in the Service Worker, make sure you turn on the Preserve log feature provided by the Chrome DevTools , or equivalent.

Otherwise, since the service worker acts before the page is loaded, and the console is cleared before loading the page, you won’t see any log in the console.

Here is how can I help you:

• COURSES where I teach everything I know
• THE VALLEY OF CODE your web development manual
• BOOTCAMP 2024 cohort in progress, next edition in 2025
• BOOKS 16 coding ebooks you can download for free on JS Python C PHP and lots more
• SOLO LAB everything I know about running a lifestyle business as a solopreneur
• Interesting links collection
• Follow me on X

Safari Extension: The service_worker script failed to load due to an error.

I have updated my web extension to use Manifest v3. While trying to test, I get the error:

_The service_worker script failed to load due to an error. _

I do not see details on the error, or a place where to find details. Any suggestions?

• Safari Extensions

Accepted Reply

I had a problem in my manifest.json, while porting I changed my manifest permission from contextMenus to context, this should be menus.

Still having other issues causing a crash. Any clues on how to troubleshoot?

I know it's four months late but I ran into the same issue, I was able to debug mine properly by putting the extension inside of chrome and debugging there. It's stupid but seems like the only way.

Same Problem here 😖 Is there a solution for this in the meantime?

Same problem for me but only when i run it on iOS, works fine on MacOS.

Same here. Converted from chrome to safari with xcrun ../dist -> works on iOS, crashes on macos with a grey background and no errors except when i toggle the extension, I'm getting: The service_worker script failed to load due to an error. Just print a error message, is that so complicated?

Loading into Chrome can be helpful, but I am at the point where Chrome accepts the whole extension just fine and Safari just won't load it for some reason it will not tell me . I am not even transitioning an existing extension I am start from scratch and having this issue.

Please if anyone has a way to make Xcode/Safari give a more helpful error, please post. I'll keep trying on my end, but this... is a weirdly frustrating blocker because it is probably something quite simple... but it won't tell me.

Yeah I have the same issue, a chrome extension and a safari extension but the error message in safari it totally unhelpful. How can we as developers identify the issue?

Same issue here.

I believe this is a bug in Safari. Safari MV3 supports the background.page key (so-called 'Event Pages') which you might be able to use as a workaround. Try something like

• In manifest: background: {page: background.html}
• In background.html: <script src="my_service_worker.js"></script>

Since incorporating my "service worker" like this I have stopped seeing the error (touch wood).

Watch CBS News

Secret Service agent assigned to Kamala Harris hospitalized after exhibiting "distressing behavior," officials say

By Nicole Sganga

April 24, 2024 / 7:57 PM EDT / CBS News

Washington — A U.S. Secret Service agent assigned to Vice President Kamala Harris exhibited "distressing behavior" Monday morning at Joint Base Andrews and was hospitalized, authorities said. Harris was not present at the airbase at the time.

In a statement provided to CBS News, the U.S. Secret Service said that at about 9 a.m. local time Monday, the agent "began displaying behavior their colleagues found distressing. The agent was removed from their assignment while medical personnel were summoned."

Two sources briefed on the situation told CBS News the agent spouted gibberish, was speaking incoherently and provoked another officer physically.

According to sources, the agent in question pushed the special agent in charge while they were near the lounge of Joint Base Andrews.

Harris was at the Naval Observatory at the time, USSS said, and the incident had "no impact on her departure from Joint Base Andrews." Sources said it occurred about one hour before Harris arrived at the airbase for a flight to Wisconsin.

The agent was immediately handcuffed and detained by other Secret Service agents who intervened, sources said, and ambulances were called to the scene.

After an initial medical evaluation, the agent was admitted to a hospital, sources said. There was no indication of substance use at this time, they added.

The USSS remains in a temporary holding pattern until further information becomes available, the sources said. After the agent receives additional medical attention and further evaluation, it will be determined if they can return to work. An internal review will be conducted and the USSS will assess if the agent's top secret security clearance will be removed for medical or disciplinary reasons, sources explained.

The sources also disclosed that, at this time, this is being treated as a medical incident and not a disciplinary matter, given the nature of the clear mental health challenges exhibited by the agent. 

• United States Secret Service
• Kamala Harris
• Mental Health

CBS News reporter covering homeland security and justice.

More from CBS News

Congressional Black Caucus chairman on Biden's efforts to appeal to Black voters

Trump and DeSantis meet in South Florida to talk about 2024 election

U.S. pilot accounted for 57 years after vanishing during Vietnam War

2021 Red Hill jet fuel contamination came after decades of issues

This website requires JavaScript.