Adding those headers via a service worker is equivalent from a security perspective, and it will enable equivalent functionality. There are a few things to keep in mind, though:

• A service worker can't control a client page during the first time a user navigates to a site, or following a shift-reload. Setting these headers via the actual web server is the only way to guarantee that they will apply to those scenarios. Generally speaking, you should be careful to degrade gracefully if there are any features in your main web app that depend on the presence of a service worker.

• There's a slight overhead involved with having a service worker controlling a page. If you were responding to requests by going straight to a local cache instead of the network, that would normally outweigh the overhead. Since it does not look like you plan on doing any caching in your service worker, you should feature-detect for navigation preloads and enable it if it's supported. This will mitigate the potential performance impact.

• The headers only need to be set on responses that can create a client, like responses for documents or workers. I'd recommend checking in your service worker whether or not the request's destination is for one of those things before calling event.respondWith(). This will help your fetch handler play nicely with any other fetch handlers that might also be registered and which, e.g. respond to subresource requests using a caching strategy. Something like the following should work:

self.addEventListener("fetch", (event) => {
  if (!["document", "iframe", "worker"].includes(event.request.destination)) {
    return;
  }

  event.respondWith(/* your logic here */);
});