O "sem medo" da regra 1 depende do deploy. Se o servidor ignora a query, app.... · IIolaser

O "sem medo" da regra 1 depende do deploy. Se o servidor ignora a query, app.js?v=2 é o app.js que estiver no disco na hora. Com FTP ou rsync, se o HTML chega antes do JS novo, o JS velho responde 200 na URL nova e, com cache first, fica lá até o próximo deploy. O mínimo é subir os assets antes do HTML. Hash no nome (app.3f2a1c.js) resolve melhor: a URL nova dá 404 até o arquivo chegar, e com if (res.ok) antes do cache.put nada errado entra.

A regra 4 também pega as páginas da regra 2. No cache versionado, cada deploy apaga todas; em cache separado, o HTML guardado aponta pra um ?v= já apagado e abre quebrado offline. No install dá pra baixar de novo as páginas já guardadas.

O Workbox eu usaria quando o ?v= global pesar: mudou uma linha, baixa tudo. O precache dele compara revisão por arquivo e só baixa o que mudou.

Os dois pontos procedem, obrigado pela leitura cuidadosa.

Regra 1: aqui o deploy FTP e o servidor ignora a query, ento o cenrio que voc descreveu podia acontecer. E no service worker pior: o install faz addAll das URLs com o ?v= novo, e se o JS velho ainda estiver no disco ele entra no cache com a URL nova. Mudei o script de deploy para subir nesta ordem: assets, depois o HTML, e o sw.js por ltimo. Hash no nome seria mais robusto, como voc disse (o 404 protege sozinho), mas pede reescrever as referncias no build. Por enquanto a ordem cobre o caso comum.

Regra 4: verdade. As pginas que a regra 2 guarda moram no mesmo cache versionado, ento cada deploy apaga todas e offline sobra s a pgina principal. No abre quebrado, mas perde as outras. Ler as URLs de navegao do cache antigo no install e baixar de novo uma boa sada; vou testar.

E o ponto do Workbox responde a minha pergunta: comparar reviso por arquivo justamente o que falta quando um ?v= global obriga a baixar tudo por causa de uma linha.