Cache navigateur : votre page HTML force-t-elle un rechargement à chaque visite ?

Sans en-têtes de cache, le navigateur re-télécharge toute la page à chaque visite. Le test #02 vérifie votre politique de cache en quelques secondes.

Votre visiteur charge une page. Il clique un lien, puis revient. Sans en-têtes de cache, le navigateur retélécharge tout le HTML — même contenu, même poids, même attente. À chaque fois.

Le cache navigateur pour les pages HTML est l'un des réglages de performance les plus négligés. Tout le monde met en cache les images et le CSS, mais le document HTML lui-même ? La plupart des sites WordPress n'ont pas de politique de cache appropriée.

Le test #02 d'Orilyt inspecte les en-têtes de cache de la réponse HTML. Pas les assets, pas les images — le document principal. Il vérifie Cache-Control, Expires, ETags et Last-Modified en un seul passage. Le résultat vous dit si les visiteurs récurrents bénéficient d'une expérience rapide ou d'un téléchargement redondant.

Comment fonctionne le cache navigateur pour le HTML

Quand un serveur envoie une page HTML, il peut inclure des en-têtes qui indiquent au navigateur comment la mettre en cache. Les acteurs clés :

1. Cache-Control: max-age=N — indique au navigateur de garder cette page N secondes sans redemander au serveur. Un max-age de 600 signifie 10 minutes de cache local
2. Cache-Control: s-maxage=N — idem que max-age, mais pour les caches partagés (CDN, proxies). Prend priorité sur max-age quand il est présent
3. Expires — un en-tête plus ancien qui fixe une date/heure absolue d'expiration. Fonctionne comme fallback quand Cache-Control est absent
4. ETag et Last-Modified — des validateurs qui permettent les requêtes conditionnelles. Au lieu de retélécharger, le navigateur demande « cela a-t-il changé depuis X ? » — sinon, le serveur renvoie un 304 Not Modified (aucun corps)

Cache-Control: no-store signifie que le navigateur ne doit jamais mettre en cache. Cache-Control: no-cache signifie qu'il peut le mettre en cache mais doit revalider à chaque fois. Les deux déclenchent une requête serveur à chaque visite.

Pour les pages HTML qui changent rarement (la plupart du contenu WordPress), un max-age de 300 à 3600 secondes combiné avec des ETags est le juste milieu. La page se charge instantanément depuis le cache, et la prochaine revalidation est légère.

Comment Orilyt note votre politique de cache

Le test #02 lit les en-têtes de réponse et évalue la politique de cache :

1. Score 90 — Cacheable avec un TTL supérieur à 300 secondes. Le navigateur peut servir la page depuis son cache local pendant au moins 5 minutes. Meilleur résultat
2. Score 70 — Cacheable mais le TTL est court ou absent. La page a des en-têtes de cache mais la fenêtre de fraîcheur est trop brève pour être utile
3. Score 30 — Non cacheable ou aucun en-tête de cache détecté. Le navigateur télécharge la page complète à chaque visite. C'est le défaut pour la plupart des sites non configurés

Le test détecte également la présence de validateurs (ETag, Last-Modified), si la page est marquée private, et si des en-têtes Set-Cookie interfèrent avec le cache.

Pourquoi le cache HTML est souvent absent

Le cache HTML est moins courant que le cache d'assets à cause d'une tension fondamentale : les pages peuvent changer. Mais il existe des solutions plus intelligentes que pas de cache du tout :

1. WordPress par défaut — WordPress ne définit pas d'en-têtes Cache-Control par défaut. Le serveur (Apache, Nginx) doit être configuré séparément, et la plupart des panels d'hébergement ne le font pas
2. Pages dynamiques avec Set-Cookie — si la réponse inclut un Set-Cookie, de nombreux CDN et proxies sautent le cache. Pages de connexion, paniers WooCommerce et contenu personnalisé déclenchent ce comportement
3. no-store partout — certains plugins de sécurité ou plugins de cache mal configurés définissent no-store sur toutes les pages, y compris le contenu statique qui devrait être mis en cache
4. ETag/Last-Modified manquants — sans validateurs, le navigateur ne peut pas faire de requêtes conditionnelles. Il utilise soit la version en cache aveuglément, soit retélécharge la page entière. La plupart passent à côté

L'insight clé : pour 90 % des pages WordPress (articles, pages de services, landing pages), un max-age modéré (300–600 s) avec revalidation ETag est sûr et efficace. Le navigateur obtient un cache hit rapide, et les modifications se propagent en quelques minutes.

La politique de cache comme argument de vente

Pour les freelances et agences, une politique de cache manquante est un constat d'audit fort. Ça affecte chaque visiteur récurrent — et les visiteurs récurrents sont votre trafic le plus précieux.

Dans le rapport Orilyt, le test #02 génère une recommandation FIA structurée :

1. Fait : « Aucun en-tête Cache-Control ou Expires sur le document HTML. Aucune politique de cache détectée »
2. Impact : « Chaque visite déclenche un téléchargement complet de la page, même pour les visiteurs récurrents. Gaspillage de bande passante et temps de chargement inutile »
3. Action : « Ajouter Cache-Control: public, max-age=600 aux réponses HTML. Ajouter la validation ETag pour une revalidation intelligente »

Un score de 30/100 sur la politique de cache signale un site qui n'a pas été optimisé au-delà des bases. C'est le genre de détail qui distingue un audit professionnel d'un rapport générique « votre site est lent ».

Rendez les visites récurrentes instantanées

Le cache navigateur pour le HTML n'est pas une question de cache agressif ou de risque de contenu périmé. C'est dire au navigateur : « tu peux garder ça quelques minutes, et voici comment vérifier si ça a changé. »

Le test #02 vérifie tout ça en un passage. Pas d'inspection manuelle des en-têtes, pas de commandes terminal — juste un score (90, 70 ou 30) avec une explication claire et une correction actionnable.

Si vous auditez des sites clients, la politique de cache est un de ces constats invisibles à l'œil nu mais mesurables en données. C'est le genre d'amélioration qui fait une vraie différence — et qui ne coûte presque rien à implémenter.