Préparer la suppression du cache d'appli

Chrome 85 supprime la compatibilité avec AppCache par défaut. La plupart des développeurs doivent migrer d'AppCache dès maintenant, et ne pas attendre plus longtemps.

Suite à nos annonces précédentes, la prise en charge d'AppCache sera supprimée de Chrome et des autres navigateurs basés sur Chromium. Nous encourageons les développeurs à abandonner AppCache dès maintenant, plutôt que d'attendre plus longtemps.

Les service workers, qui sont largement compatibles avec les navigateurs actuels, offrent une alternative à l'expérience hors connexion offerte par AppCache. Consultez la section Stratégies de migration.

Chronologie

En raison de modifications récentes apportées au calendrier de publication de Chrome, le calendrier de certaines de ces étapes peut varier. Nous nous efforcerons de tenir ce calendrier à jour, mais à ce stade, veuillez supprimer AppCache dès que possible, au lieu d'attendre des étapes spécifiques.

Une fonctionnalité "obsolète" existe toujours, mais enregistre des messages d'avertissement déconseillant son utilisation. Une fonctionnalité "supprimée" n'existe plus dans le navigateur.

Abandon dans les contextes non sécurisés Chrome 50 (avril 2016)
Suppression des contextes non sécurisés Chrome 70 (octobre 2018)
Abandon dans les contextes sécurisés Chrome 79 (décembre 2019)
Restriction de la portée d'AppCache Chrome 80 (février 2020)
Début de l'essai "Inverser" de l'origine Chrome 84 (juillet 2020)
Suppression des contextes sécurisés, sauf pour ceux qui ont activé la phase d'évaluation de l'origine Chrome 85 (août 2020)
Suppression complète des contextes sécurisés pour tous les utilisateurs, une fois la phase d'évaluation de l'origine terminée 5 octobre 2021 (environ Chrome 95)

Essai Origin

Le calendrier indique deux jalons à venir pour la suppression. À partir de Chrome 85, le cache des applications ne sera plus disponible par défaut dans Chrome. Les développeurs qui ont besoin de plus de temps pour migrer d'AppCache peuvent s'inscrire à un essai d'origine "inverse" pour prolonger la disponibilité d'AppCache pour leurs applications Web. La phase d'évaluation de l'origine commencera dans Chrome 84 (avant la suppression par défaut dans Chrome 85) et sera active jusqu'au 5 octobre 2021 (environ Chrome 95). À ce stade, AppCache sera complètement supprimé pour tous les utilisateurs, même ceux qui s'étaient inscrits au test de la version d'origine.

Pour participer au test de l'origine "inverse" :

  1. Demandez un jeton pour votre origine.
  2. Ajoutez le jeton à vos pages HTML. Pour ce faire, vous avez deux options :
    • Ajoutez une balise <meta> origin-trial dans l'en-tête de chaque page. Par exemple : <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">.
    • Vous pouvez également configurer votre serveur pour qu'il renvoie des réponses contenant l'en-tête HTTP Origin-Trial. L'en-tête de réponse obtenu doit se présenter comme suit : Origin-Trial: TOKEN_GOES_HERE
  3. Ajoutez le même jeton à vos fichiers manifestes AppCache. Pour ce faire, accédez à un nouveau champ dans votre fichier manifeste, au format suivant:
ORIGIN-TRIAL:
TOKEN_GOES_HERE

(Une nouvelle ligne doit être ajoutée entre ORIGIN-TRIAL et votre jeton.)

Vous pouvez voir un exemple de projet intégré ci-dessous qui montre comment ajouter les jetons d'essai d'origine appropriés dans les fichiers index.html et manifest.appcache.

Pourquoi les jetons sont-ils nécessaires à plusieurs endroits ?

Le jeton d'essai de même origine doit être associé à :

  • Toutes vos pages HTML qui utilisent AppCache.
  • Tous vos fichiers manifestes AppCache via le champ de fichier manifeste ORIGIN-TRIAL.

Si vous avez déjà participé à des tests d'origine, il est possible que vous n'ayez ajouté le jeton qu'à vos pages HTML. Le test d'origine "inverse" de l'AppCache est spécial en ce sens que vous devez également associer un jeton à chacun de vos fichiers manifestes AppCache.

Ajouter le jeton de test d'origine à vos pages HTML active l'interface window.applicationCache dans vos applications Web. Les pages qui ne sont pas associées à un jeton ne pourront pas utiliser les méthodes et événements window.applicationCache. Les pages sans jeton ne pourront pas non plus charger de ressources à partir du cache d'application. À partir de Chrome 85, ils se comporteront comme si le cache des applications n'existait pas.

Ajouter le jeton de test d'origine à vos fichiers manifestes AppCache indique que chaque fichier manifeste est toujours valide. À partir de Chrome 85, les fichiers manifestes qui ne comportent pas de champ ORIGIN-TRIAL seront considérés comme incorrects, et les règles du fichier manifeste seront ignorées.

Calendrier et logistique du déploiement de l'essai Origin Trial

Bien que le test d'origine "inverse" commence officiellement avec Chrome 84, vous pouvez vous inscrire au test d'origine dès aujourd'hui et ajouter les jetons à vos fichiers manifestes HTML et AppCache. À mesure que l'audience de votre application Web passera progressivement à Chrome 84, tous les jetons que vous avez déjà ajoutés entreront en vigueur.

Une fois que vous avez ajouté un jeton à votre fichier manifeste AppCache, accédez à about://appcache-internals pour vérifier que votre instance locale de Chrome (version 84 ou ultérieure) a correctement associé le jeton de la phase d'évaluation aux entrées en cache de votre fichier manifeste. Si votre test d'origine est reconnu, un champ avec Token Expires: Tue Apr 06 2021... doit s'afficher sur cette page, associé à votre fichier manifeste :

Interface about://appcache-internals affichant un jeton reconnu.

Tests avant la suppression

Nous vous encourageons vivement à quitter AppCache dès que possible. Si vous souhaitez tester la suppression d'AppCache dans vos applications Web, utilisez l'indicateur about://flags/#app-cache pour simuler sa suppression. Cet indicateur est disponible à partir de Chrome 84.

Stratégies de migration

Les services workers, qui sont largement compatibles avec les navigateurs actuels, constituent une alternative à l'expérience hors connexion fournie par AppCache.

Nous avons fourni un polyfill qui utilise un service worker pour reproduire certaines des fonctionnalités d'AppCache, mais pas l'interface AppCache dans son intégralité. En particulier, elle ne remplace pas l'interface window.applicationCache ni les événements AppCache associés.

Pour les cas plus complexes, des bibliothèques telles que Workbox permettent de créer facilement un service worker moderne pour votre application Web.

Les service workers et AppCache s'excluent mutuellement

Lorsque vous élaborez votre stratégie de migration, n'oubliez pas que Chrome désactive la fonctionnalité AppCache sur toutes les pages chargées sous le contrôle d'un service worker. En d'autres termes, dès que vous déployez un service worker qui contrôle une page donnée, vous ne pouvez plus utiliser AppCache sur cette page.

C'est pourquoi nous vous recommandons de ne pas essayer de migrer vers les service workers par étapes. Il serait une erreur de déployer un service worker qui ne contient qu'une partie de votre logique de mise en cache. Vous ne pouvez pas utiliser AppCache pour "combler les lacunes".

De même, si vous déployez un service worker avant la suppression d'AppCache, puis que vous découvrez que vous devez revenir à votre implémentation AppCache précédente, vous devez vous assurer de désenregistrer ce service worker. Tant qu'un service worker enregistré est présent sur une page donnée, AppCache n'est pas utilisé.

L'histoire multiplate-forme

Nous vous invitons à contacter un fournisseur de navigateur spécifique si vous souhaitez en savoir plus sur ses plans de suppression d'AppCache.

Firefox sur toutes les plates-formes

Firefox a abandonné AppCache dans la version 44 (septembre 2015) et a supprimé sa prise en charge dans ses versions bêta et Nightly à partir de septembre 2019.

Safari sur iOS et macOS

AppCache est obsolète dans Safari depuis début 2018.

Chrome sur iOS

Chrome pour iOS est un cas particulier, car il utilise un moteur de navigateur différent de celui de Chrome sur d'autres plates-formes: WKWebView. Les services workers ne sont actuellement pas compatibles avec les applications iOS qui utilisent WKWebView. L'annonce de suppression du cache des applications dans Chrome ne concerne pas la disponibilité du cache des applications dans Chrome pour iOS. Gardez cela à l'esprit si vous savez que votre application Web est populaire auprès de Chrome pour iOS.

WebViews Android

Certains développeurs d'applications Android utilisent Chrome WebView pour afficher du contenu Web et peuvent également utiliser AppCache. Toutefois, il n'est pas possible d'activer une phase d'évaluation pour une WebView. Par conséquent, Chrome WebView sera compatible avec AppCache sans phase d'évaluation jusqu'à la suppression finale, prévue dans Chrome 90.

En savoir plus

Voici quelques ressources destinées aux développeurs qui migrent d'AppCache vers des service workers.

Articles

Outils

Obtenir de l'aide

Si vous rencontrez un problème avec un outil spécifique, signalez-le dans son dépôt GitHub.

Vous pouvez poser une question générale sur la migration d'AppCache sur Stack Overflow à l'aide de la balise html5-appcache.

Si vous rencontrez un bug lié à la suppression de l'AppCache dans Chrome, veuillez le signaler à l'aide de l'outil de suivi des bugs de Chromium.

Image principale basée sur les archives de la Smithsonian Institution, Acc. 11-007, boîte 020, image MNH-4477.