Un service worker se place entre votre application et le réseau, et répond quand le réseau ne le peut pas. Tout dépend des réponses qu’il a le droit de garder.
Les trois stratégies
- Le cache d’abord. Servir depuis le cache, aller au réseau seulement en cas d’absence. Pour les polices, les icônes et les ressources compilées, qui ne changent qu’au déploiement.
- Le réseau d’abord. Essayer le réseau, se rabattre sur le cache. Pour les pages de contenu, où une page un peu périmée vaut mieux qu’une page d’erreur.
- Le réseau seulement. Ne jamais mettre en cache. Pour tout ce qui suit.
Ce qui relève du « jamais »
- Tout ce qui porte un prix, un niveau de stock ou une disponibilité.
- Tout ce qui reflète une permission. Une page mise en cache pendant qu’un administrateur était connecté, servie ensuite à quelqu’un d’autre, est une fuite de données sans aucun attaquant.
- Tout ce qui contient le nom d’une personne. Même raison.
- Toute requête non idempotente. POST, PUT, DELETE. En rejouer une n’est pas de la mise en cache, c’est agir deux fois.
- Les réponses d’authentification. Une page de connexion en cache avec un jeton périmé est un ticket qui met trois jours à se reproduire.
Versionnez votre cache, et faites le ménage
Mettez une version dans le nom du cache et supprimez les anciens à l’activate. Sans cela, chaque déploiement laisse une copie entière derrière lui, et un utilisateur qui passe une fois par mois transporte un an de ressources mortes.
Testez la panne que vous aurez vraiment
Basculer le navigateur en mode hors ligne est le cas facile : les requêtes échouent aussitôt et vos replis se déclenchent. Le cas intéressant est la connexion lente et capricieuse où les requêtes restent suspendues au lieu d’échouer, et où une stratégie de cache d’abord sert tranquillement des données vieilles d’un mois pendant que la roue tourne.
Bridez plutôt que de déconnecter. C’est là que sont les bogues.