I have a question: does it make sense to use service workers in static websites? By static sites I mean things like landing pages for products. I know that it does if your target audience is in a place where MB are expensive. Or if there is information on the site that will be accessed regularly. But I'm not looking for situations where it does make sense, I'm asking if, as a rule, we should always put service workers on websites unless these very specific situations.
It doesn't sound like your web site fits the bill for using service workers. Barring a genuine need for push notifications, you should probably focus on the well-trodden methods of static web site optimisation and performance. The huge effort to build a client-side proxy for caching resources (and maintaining it as the site is updated) is hardly worth the very little gain.
The standard techniques like minifying and consolidating resources, reducing the number of unncessary scripts on the page, async scripts, resource sizes, performance validation on mobile, etc are going to deliver much better usability. They aren't interesting or cool, but will give a lot more value to your users and customer.
Jason Knight
The less code you use, the less there is to break
If it is a relatively static page -- like a squeeze page for a product -- and a "service worker" provides any benefits it is likely that your HTML, CSS, and/or JavaScript are bloated broken garbage and you aren't leveraging conventional caching properly for the page. There's zero reason for them to have push notifications or any sort of realtime updates, and that just leaves caching to avoid database access which is more a myth than fact on advantages if you just have the damned sql cache settings configured right.
It's another of those dimestore hoodoo tricks that people wouldn't need if they weren't relying on idiotic frameworks and a incomplete knowledge of HTML, where the end result is throwing 60 to 200k of markup at delivering 6-8k of plaintext and less than a half dozen media elements (images, movies, etc)... in other words 12-16k of markup's JOB!
Even more so if you use modern practices like those the CSP (content security policy) forces us into where <style>, style="", and <script>var yourScripting="here";</script>, onevent="", and href="javascript:" doesn't even EXIST, meaning there is no reason to even be wasting bandwidth on that halfwitted nonsense that has ZERO damned business in your HTML in the first place.
The less markup you have to output, generally the less need for that type of hoodoo-voodoo trickery since a new page-load is no longer the end of the world!
Though if you have a situation where you need to push, that's how you do it. MOST of the time though pull is entirely adequate particularly on a normal website. More so if you're working accessibility minded where you HAVE to plan for "what does the site do without client side scripting?"
Since if it doesn't work scripting off, it's a WCAG violation, and therefore in violation of both US ADA and UK EQA laws.