O que um service worker permite fazer, e com o que você teria cuidado antes de adicionar um?

Um service worker é um proxy entre a página e a rede, então ele pode servir respostas em cache, funcionar offline, fazer precache de uma casca e tratar background sync ou push. O cuidado é com o ciclo de vida: ele só controla páginas depois da ativação, um worker antigo continua servindo assets antigos até ser substituído, e uma regra de cache ruim pode prender usuários num build quebrado. Sempre versione seus caches e entregue um caminho de atualização claro.

Ele fica entre a página e a rede como um worker separado, então consegue interceptar fetches e decidir se responde de um cache. Isso me dá suporte offline, uma casca instantânea em visitas repetidas, background sync para ações enfileiradas e notificações push. O que eu vigio é o ciclo de vida, porque é de onde vêm os incidentes. Um worker novo instala e então espera até toda aba controlada sumir para ativar, então usuários podem ficar em código antigo muito mais tempo do que você espera. E se eu colocar o HTML em cache com uma regra cache first e depois entregar um worker quebrado, eu efetivamente inutilizei os usuários que voltam, já que eles nunca buscam a correção. Então versiono os nomes de cache e apago os antigos no activate, mantenho o HTML como network first e cache first só para assets com hash, e sempre mantenho um caminho de emergência que desregistra e limpa os caches. Se o requisito é só velocidade em visitas repetidas e não uso offline genuíno, prefiro tirar isso de cabeçalhos de cache e uma CDN e pular essa classe inteira de problema.