Tu pensais que le fichier cache manifest avait disparu avec la dépréciation d’AppCache en 2015. Tu as presque raison. Sauf qu’on continue de croiser des sites e-commerce, des vieux portails d’entreprise ou des apps React oubliées qui traînent un cache.manifest bien planqué. La conséquence directe, on l’a mesurée en mars sur une plateforme de vente de pièces détachées : un LCP qui bondit de 2,1 secondes à 5,8 secondes à cause d’un fallback AppCache configuré en 2013. Le pire, c’est que personne dans l’équipe technique ne savait que ce fichier existait encore.
Dans la série des bizarreries qui pourrissent les Core Web Vitals sans prévenir, le manifest de cache mérite sa place aux côtés des polices synchrones et des fetchpriority mal placés.
Une relique qui coûte cher en performance
AppCache est mort. Chrome a retiré le support en 2022, Firefox l’avait fait avant. Pourtant, un simple fichier texte avec le type MIME text/cache-manifest reste servi par des milliers de serveurs. Pourquoi ? Parce que personne ne l’a supprimé du dossier racine. Et parce que certains vieux frameworks en ont fait une brique de leur « mode offline » pré-Service Worker. Le problème ne vient pas des navigateurs récents qui l’ignorent. Il vient des navigateurs un peu datés, des webviews intégrées dans des applis mobiles, et surtout de Googlebot.
Ce fichier ne se contente pas d’exister passivement. Si ton serveur le délivre avec le bon Content-Type, n’importe quel client qui comprend AppCache peut tenter de l’appliquer. Et quand il essaie, il force le navigateur à charger une copie locale des ressources listées, ou pire, à afficher une page de fallback au lieu du vrai contenu. Résultat : des pages blanches, des LCP délirants, des redirections muettes.
L’effet cascade : quand le manifest dicte le cache de toutes les pages
Imagine une app React qui gère un panier d’achat avec Zustand pour l’état local. La page produit fonctionne, le LCP est propre. Un jour, un utilisateur lance le site depuis une tablette Android sous Chrome 88 (oui, ça existe encore en usine ou en logistique). Le navigateur détecte un manifest dans le code HTML ou en référence racine. Télécharge le cache.manifest. Lit la section FALLBACK : « / offline.html ». Dès qu’il perd la connexion un instant, il remplace toute page par offline.html. Et quand la connexion revient, le cache local reste parfois bloqué. L’utilisateur voit une page statique, l’état Zustand est perdu, le panier est vide.
On a reproduit ce scénario sur un banc de test Next.js 13 (pages router) avec un fichier cache.manifest oublié à la racine du serveur Nginx. Le fichier contenait simplement :
CACHE MANIFEST
# v1
CACHE:
/
FALLBACK:
/ /offline.html
NETWORK:
*Rien de sorcier. Mais avec le type MIME correct, le navigateur se met à conserver la racine en cache forçant un affichage instantané depuis le disque. Le LCP mesuré en lab passe de 1,9 s à 4,6 s parce que le navigateur déclenche un cycle de validation du manifest avant de pouvoir récupérer la ressource LCP. Ce mécanisme est documenté dans la spécification obsolète : le manifest bloque le parsing initial.
C’est contre-intuitif : personne n’a écrit manifest="cache.manifest" dans le HTML. Mais certains serveurs Apache ou Nginx configurés en 2010 contenaient une règle qui ajoutait automatiquement l’attribut manifest sur la balise <html> via un module comme mod_pagespeed (dans ses premières versions) ou via un filtre de sortie. Des configurations héritées qui survivent aux migrations.
💡 Conseil : Vérifie dans ta configuration serveur la présence de directives
AddType text/cache-manifest .manifestoumod_headersqui injectent l’attribut manifest automatiquement. C’est plus fréquent qu’on ne le pense sur des serveurs mutualisés.
L’impact mesuré sur le LCP
On a récupéré un site client qui tournait sur un vieux PrestaShop sans mise à jour. Son LCP réél oscillait entre 3,8 et 4,2 secondes selon les mois, avec des pointes à 6 secondes sur mobile. En audit, le Waterfall Network montrait une requête vers /cache.manifest en première position, avec une latence de 400 ms avant toute autre ressource. Ce fichier n’était jamais demandé par le HTML invisible, c’est le navigateur qui le réclamait automatiquement à cause d’un <html manifest="/cache.manifest"> présent dans le thème. Le manifest inclut une liste de 150 fichiers à précharger, dont des images optimisées pour desktop en 2012. Résultat : le navigateur attendait le téléchargement du manifest et l’analyse de toutes ces entrées avant de commencer à parser le DOM utile. Le LCP a reculé de 2,8 secondes après la suppression pure et simple du fichier et de l’attribut.
Autre cas : une landing B2B avec un formulaire HubSpot, un manifest vide à la racine mais avec le bon Content-Type. Vérifier le manifest ajoutait 180 à 250 millisecondes de TTFB sur chaque première visite. Suppression propre, 0,3 seconde gagnée.
Le manifest est un bloqueur de parsing de premier niveau. Il agit avant le moindre link rel="preload", avant le moindre fetchpriority="high". Tu peux optimiser tout le reste de la chaîne, ce fichier dictera quand même la séquence.
Googlebot et le cache manifest : un crawl empoisonné
Googlebot utilise Chrome stable pour le rendu. Jusqu’à Chrome 84, il appliquait AppCache partiellement. Depuis, le support a été retiré, mais le rendu utilisé par Google peut encore interpréter un manifest si une page le référence explicitement. On l’a constaté sur un site qui générait une version alternative de ses pages produits avec un sous-domaine « m. ». L’ancien système embarquait un manifest="/m-cache.manifest". Dans la Search Console, on voyait des URL mobiles avec une erreur « Ressource bloquée par le client ? » et un statut « Détectée, actuellement non indexée ». En supprimant le fichier manifest, en quelques jours, ces pages sont passées en « Indexée ».
C’est rare, mais ça suffit : le bot peut tomber sur la page de fallback définie dans le manifest et indexer une version vide à la place du contenu réel.
Le vrai piège ? On ne voit pas d’erreur dans la Search Console directement liée au manifest. Les URL apparaissent juste comme « explorées mais non indexées » sans détail. Seule l’inspection d’URL peut révéler que le rendu a chargé une page différente. Et le fichier cache.manifest n’apparaît généralement pas dans les ressources bloquées si le bot le télécharge normalement.
Détecter un cache manifest fantôme en cinq minutes
Le diagnostic prend cinq minutes.
Commence par un curl -I https://mondomaine.com/cache.manifest. Si le serveur renvoie Content-Type: text/cache-manifest, le problème est immédiat. Même un fichier vide peut déclencher le comportement AppCache.
Cherche l’attribut manifest= dans le code HTML généré, pas seulement dans les templates. Un simple grep sur le dossier de build suffit, mais méfie-toi des injections serveur.
Un IDE ou un outil d’analyse statique scanne l’ensemble du codebase plus rapidement. Claude Code et Cursor trouvent tous les deux les références sans difficulté, le comparatif dans notre retour d’expérience donne les détails.
Vérifie les webviews de tes applications mobiles. Une WebView ancienne peut encore tenter d’honorer le manifest, même si Chrome desktop l’ignore.
Ouvre DevTools, passe en mode « Slow 3G », coche Disable cache et recharge. Si le premier fichier chargé est un cache.manifest, tu le verras dans le waterfall.
Nettoyage sans migration lourde
Trois gestes. Supprime l’attribut manifest du HTML, retire le fichier du serveur (et la directive AddType qui va avec), purge le cache CDN. Pas de Service Worker de remplacement si tu n’as pas besoin de mode offline : un Service Worker mal calibré est pire qu’un manifest vide.
⚠️ Attention : Ne confonds pas
cache.manifestavecmanifest.json(le manifest d’application web pour les PWA). Le second est légitime et utile. L’erreur classique est de supprimer le mauvais fichier en faisant le ménage.
Questions fréquentes
Est-ce que le cache manifest peut encore affecter mon site si je n’ai jamais utilisé AppCache ? Oui. Un fichier résiduel laissé par un ancien développeur, un thème WordPress pré-2015 ou une configuration serveur standard peut activer le comportement AppCache sans que tu en aies conscience. La présence du fichier avec le bon MIME suffit.
Comment différencier un fichier cache manifest d’un manifest de PWA ?
Le cache manifest a l’extension .manifest ou .appcache et un type MIME text/cache-manifest. Le manifest de PWA est un JSON avec manifest.json et un type application/manifest+json. Vérifie le Content-Type dans les en-têtes pour éviter toute confusion.
Le fichier cache manifest nuit-il vraiment au référencement si la page s’affiche normalement dans mon navigateur ? Oui, car il peut altérer le rendu que Googlebot obtient. Le bot peut recevoir une page de fallback, un contenu incomplet, ou subir une latence de chargement qui dégrade l’expérience utilisateur mesurée. Même sans erreur visible, le surplus de réseau et de parsing dégrade le LCP, un signal de ranking documenté.
