Bonjour,
Quand on a beaucoup... on en veut encore plus. En transférant mes sites de 1&1 à o2Switch j'ai déjà énormément gagné en rapidité d'affichage (bon tous ceux qui ont entendu parler d'o2Switch le savent déjà)
Ils proposent l'outil XtremCache - Varnish
https://faq.o2switch.fr/hebergement-.../cache-varnish
J'ai donc voulu essayé... j'ai résolu certains problèmes à l'aide de leur FAQ
Par contre, lors des vérifications avec leur outil j'ai : "La page testée n'a pas été servi depuis le cache."
J'ai contacté o2Switch qui m'a répondu dans la journée, mais il y a des points que je ne comprends pas, en particulier :
...
Comment analyser les headers ?
Que doit-on modifier au niveau de Joomla (.htaccess certainement) pour que cela fonctionne. ?
Si on trouve la solution, le sujet pourra peut être servir à d'autres.
Merci d'avance pour votre participation.
Ci-dessous ma question à o2switch et leur réponse.
Question posée à o2Switch
Une question technique sur l'utilisation de XtremCache - Cache Varnish pour des site Joomla.
Votre FAQ est très bien faite (bravo) et a permis de résoudre facilement les SSL non détectés et redirection HTTPS dans .htaccess
* J’ai activé tous les sites Joomla avec XtremCache
* Tous donnent le même résultat avec « Verifier » - La page testée n'a pas été servi depuis le cache.
Essais effectués avec cache dans Joomla activé (conservateur) et cache dans Joomla désactivé.
Essais sur un site de test avec un affichage sans contenu en dehors de la page Gantry, donc pas grand-chose d’activé sur cette page
Ma question est donc : Il y a-t-il un truc simple à côté duquel je suis passé ? ou C’est trop compliqué pour moi et je dois laisser tomber ?
Les sites concernés
INFORMATIONS (idem pour tous les sites)
Information sur le cache (exemple avec un site de test : mantois.fr avec un affichage sans contenu en dehors de la page Gantry, donc pas grand-chose d’activé sur cette page)
_____
Nom de domaine mantois.fr (+ version www)
SSL Oui
Adresse IP d'origine 109.234.164.22
Type de personnalisation Cache (actif)
Clé de purge du cache xxxxxxxxxxxxxxxxxxxxxxxx
Template de cache utilisé joomla
Configuration personnalisée (cookie) Cookie #0 : 16648584e9963175213206a6fdaee0ab
Date de création 08/10/2018 à 14:31:39
___
VERIFIER
La page testée n'a pas été servi depuis le cache.
La page testée définie des cookies, voici la liste (nom/valeur):
16648584e9963175213206a6fdaee0ab : 03c5d0edb4f81625c85789a74a6b8b43
Voici la liste des headers renvoyés par le serveur :
Server : o2switch PowerBoost
Date : Tue, 09 Oct 2018 11:55:22 GMT
Content-Type : text/html; charset=utf-8
Connection : close
Expires : Wed, 17 Aug 2005 00:00:00 GMT
Cache-Control : no-store, no-cache, must-revalidate, post-check=0, pre-check=0, max-age=0, no-cache
Pragma : no-cache
X-Mod-Pagespeed : 1.11.33.4-0
Vary : Accept-Encoding
Age : 0
X-Cache : MISS
Accept-Ranges : bytes
Réponse o2Switch
Nous avons prévu de documenter plus en détails comment fonctionne le cache et surtout comprendre les cas ou la page est dans le cache ou non.
Cela implique de bien comprendre le fonctionnement des requêtes HTTP et des headers notamment.
De notre côté, le cache respecte les headers que renvoi le site internet.
Certains de ces headers servent à définir la politique de cache à appliquer sur une ressource. Ces headers là sont lu par le navigateur web, par exemple, pour éviter de demander le re-téléchargement d'une ressource (comme une image).
C'est également respecté par notre serveur de cache, par défaut, nous ne "forçons" pas de cache, nous "écoutons" ce que le site renvoi en se basant sur les headers.
Le header le plus important est celui qui se nomme "cache-control" qui permet de définir si une ressource peut être mise en cache ou non et pour combien de temps.
Souvent, lorsque des pages ne sont pas servi depuis le cache, ce sont des pages qui contiennent un header "cache-control: max-age=0" dans la réponse.
Il y a également d'autres cas ou cela n'est pas en cache, par exemple, lorsqu'il y a des cookies (qui fonctionne aussi avec des header, set-cookie).
Lorsqu'il y a un cookie, cela signifie que le contenu de la page est personnalisé pour l'utilisateur, par exemple, pour le choix de la langue.
Si on conserve une page, avec un cookie dans le cache, le serveur risque de répondre avec une mauvaise version de la page : exemple la page en anglais alors que le visiteur souhaite celle en Français.
Pour résumer de manière simple, des cookies = pas de cache.
C'est à cela que sert l'outil d'exclusion de cookie dans l'outil. Certains cookies peuvent être ignorer car le modifie pas le contenu de la page ou sont créé par la page à mauvais escient (donc plutôt que de refaire le site, on peut l'ignorer au niveau du cache pour quand même mettre en cache la page).
Donc lorsqu'une page n'est pas servi depuis le cache, il faut vérifier :
1. S'il y a des cookies, cela se soit dans les headers. S'ils sont ignorables car ne modifient pas le contenu de la page, ils peuvent être ajoutés dans l'outil de cache pour être ignorés.
2. Les headers de contrôle de cache : cache-control principalement (https://developer.mozilla.org/fr/doc.../Cache-Control), mais aussi expire (qui est déprécié au profit de cache-control) 3. Si c'est de l'ajax ou une requête POST, c'est ignoré également (car la réponse dépend du visiteur donc non cachable)
En résumé, il faut bien analyser les headers car c'est ce qui est utilisé par le cache pour savoir ce qui doit être dans le cache ou non.
Quand on a beaucoup... on en veut encore plus. En transférant mes sites de 1&1 à o2Switch j'ai déjà énormément gagné en rapidité d'affichage (bon tous ceux qui ont entendu parler d'o2Switch le savent déjà)
Ils proposent l'outil XtremCache - Varnish
https://faq.o2switch.fr/hebergement-.../cache-varnish
J'ai donc voulu essayé... j'ai résolu certains problèmes à l'aide de leur FAQ
Par contre, lors des vérifications avec leur outil j'ai : "La page testée n'a pas été servi depuis le cache."
J'ai contacté o2Switch qui m'a répondu dans la journée, mais il y a des points que je ne comprends pas, en particulier :
Le header le plus important est celui qui se nomme "cache-control" qui permet de définir si une ressource peut être mise en cache ou non et pour combien de temps.
Souvent, lorsque des pages ne sont pas servi depuis le cache, ce sont des pages qui contiennent un header "cache-control: max-age=0" dans la réponse.
Souvent, lorsque des pages ne sont pas servi depuis le cache, ce sont des pages qui contiennent un header "cache-control: max-age=0" dans la réponse.
En résumé, il faut bien analyser les headers car c'est ce qui est utilisé par le cache pour savoir ce qui doit être dans le cache ou non.
Que doit-on modifier au niveau de Joomla (.htaccess certainement) pour que cela fonctionne. ?
- XtremCache o2switch sait normalement s'adapter à Joomla
- Les dernières versions de Joomla, sont d'après ce que j'ai compris, sont adaptées à Varnish
Si on trouve la solution, le sujet pourra peut être servir à d'autres.
Merci d'avance pour votre participation.
Ci-dessous ma question à o2switch et leur réponse.
Question posée à o2Switch
Une question technique sur l'utilisation de XtremCache - Cache Varnish pour des site Joomla.
Votre FAQ est très bien faite (bravo) et a permis de résoudre facilement les SSL non détectés et redirection HTTPS dans .htaccess
* J’ai activé tous les sites Joomla avec XtremCache
* Tous donnent le même résultat avec « Verifier » - La page testée n'a pas été servi depuis le cache.
Essais effectués avec cache dans Joomla activé (conservateur) et cache dans Joomla désactivé.
Essais sur un site de test avec un affichage sans contenu en dehors de la page Gantry, donc pas grand-chose d’activé sur cette page
Ma question est donc : Il y a-t-il un truc simple à côté duquel je suis passé ? ou C’est trop compliqué pour moi et je dois laisser tomber ?
Les sites concernés
INFORMATIONS (idem pour tous les sites)
Information sur le cache (exemple avec un site de test : mantois.fr avec un affichage sans contenu en dehors de la page Gantry, donc pas grand-chose d’activé sur cette page)
_____
Nom de domaine mantois.fr (+ version www)
SSL Oui
Adresse IP d'origine 109.234.164.22
Type de personnalisation Cache (actif)
Clé de purge du cache xxxxxxxxxxxxxxxxxxxxxxxx
Template de cache utilisé joomla
Configuration personnalisée (cookie) Cookie #0 : 16648584e9963175213206a6fdaee0ab
Date de création 08/10/2018 à 14:31:39
___
VERIFIER
La page testée n'a pas été servi depuis le cache.
La page testée définie des cookies, voici la liste (nom/valeur):
16648584e9963175213206a6fdaee0ab : 03c5d0edb4f81625c85789a74a6b8b43
Voici la liste des headers renvoyés par le serveur :
Server : o2switch PowerBoost
Date : Tue, 09 Oct 2018 11:55:22 GMT
Content-Type : text/html; charset=utf-8
Connection : close
Expires : Wed, 17 Aug 2005 00:00:00 GMT
Cache-Control : no-store, no-cache, must-revalidate, post-check=0, pre-check=0, max-age=0, no-cache
Pragma : no-cache
X-Mod-Pagespeed : 1.11.33.4-0
Vary : Accept-Encoding
Age : 0
X-Cache : MISS
Accept-Ranges : bytes
Réponse o2Switch
Nous avons prévu de documenter plus en détails comment fonctionne le cache et surtout comprendre les cas ou la page est dans le cache ou non.
Cela implique de bien comprendre le fonctionnement des requêtes HTTP et des headers notamment.
De notre côté, le cache respecte les headers que renvoi le site internet.
Certains de ces headers servent à définir la politique de cache à appliquer sur une ressource. Ces headers là sont lu par le navigateur web, par exemple, pour éviter de demander le re-téléchargement d'une ressource (comme une image).
C'est également respecté par notre serveur de cache, par défaut, nous ne "forçons" pas de cache, nous "écoutons" ce que le site renvoi en se basant sur les headers.
Le header le plus important est celui qui se nomme "cache-control" qui permet de définir si une ressource peut être mise en cache ou non et pour combien de temps.
Souvent, lorsque des pages ne sont pas servi depuis le cache, ce sont des pages qui contiennent un header "cache-control: max-age=0" dans la réponse.
Il y a également d'autres cas ou cela n'est pas en cache, par exemple, lorsqu'il y a des cookies (qui fonctionne aussi avec des header, set-cookie).
Lorsqu'il y a un cookie, cela signifie que le contenu de la page est personnalisé pour l'utilisateur, par exemple, pour le choix de la langue.
Si on conserve une page, avec un cookie dans le cache, le serveur risque de répondre avec une mauvaise version de la page : exemple la page en anglais alors que le visiteur souhaite celle en Français.
Pour résumer de manière simple, des cookies = pas de cache.
C'est à cela que sert l'outil d'exclusion de cookie dans l'outil. Certains cookies peuvent être ignorer car le modifie pas le contenu de la page ou sont créé par la page à mauvais escient (donc plutôt que de refaire le site, on peut l'ignorer au niveau du cache pour quand même mettre en cache la page).
Donc lorsqu'une page n'est pas servi depuis le cache, il faut vérifier :
1. S'il y a des cookies, cela se soit dans les headers. S'ils sont ignorables car ne modifient pas le contenu de la page, ils peuvent être ajoutés dans l'outil de cache pour être ignorés.
2. Les headers de contrôle de cache : cache-control principalement (https://developer.mozilla.org/fr/doc.../Cache-Control), mais aussi expire (qui est déprécié au profit de cache-control) 3. Si c'est de l'ajax ou une requête POST, c'est ignoré également (car la réponse dépend du visiteur donc non cachable)
En résumé, il faut bien analyser les headers car c'est ce qui est utilisé par le cache pour savoir ce qui doit être dans le cache ou non.
Commentaire