Configuration recommandée de JCH Optimize Page Cache

-- HikaShop version -- : 6.5.2
-- Joomla version -- : 5.4.9
-- PHP version -- : 8.4.24
-- Browser(s) name and version -- : Firefox 156.0

Bonjour,

Je n’avais encore jamais utilisé le Page Cache de JCH Optimize, mais depuis son activation, j’ai constaté une nette amélioration des performances et un affichage vraiment beaucoup plus rapide.

Je cherche donc à configurer au mieux JCH Optimize avec HikaShop afin de conserver ce gain de performance tout en évitant tout problème lié au panier, aux sessions utilisateur ou aux pages de commande.

L’option Use HTTP Requests est activée. J’ai également activé le plugin User – JCH Optimize User State, avec l’option Exclude form users activée.

J’ai effectué un test avec deux sessions navigateur totalement distinctes : après l’ajout d’un produit, le premier visiteur conserve correctement le contenu de son mini-panier après avoir rechargé la page d’accueil, tandis qu’un second visiteur voit bien un panier vide.

Je souhaite conserver la Page Cache JCH non seulement pour la page d’accueil, mais également pour les pages publiques de catégories et les fiches produit HikaShop. Pour le moment, j’ai exclu globalement le composant com_hikashop de la Page Cache JCH. Toutefois, cela empêche également la mise en cache des catégories et fiches produit, qui sont très importantes pour les performances et le référencement.

Mon objectif serait donc de ne pas exclure l’ensemble du composant com_hikashop, afin de pouvoir mettre en cache les pages publiques de catégories et les fiches produit.

Je vais donc exclure de manière ciblée les URL dynamiques liées à la connexion, à l’inscription, à la déconnexion, au panier, au checkout, au paiement et à ses pages de retour, au compte client, aux commandes, aux adresses, ainsi qu’à la réinitialisation de mot de passe et à la confirmation de commande.

Existe-t-il, dans HikaShop, d’autres pages, vues, URL ou endpoints dynamiques que je devrais également exclure de la Page Cache JCH, même s’ils ne font pas partie de ces pages visibles dans la navigation du site ?

Je réalise tous ces essais d’abord sur un environnement de développement, avant toute mise en production.

Merci!

Meilleurs voeux pour votre nouveau site, très reussi, bravo!

Lorenzo

Bonjour,

Votre liste couvre déjà l'essentiel. À ajouter, même si ce ne sont pas des pages que l'on visite en navigant normalement :

Le changement de devise (ctrl=currency&task=update) stocke la devise choisie en session, et son code ne vide que le cache natif de Joomla, jamais un cache tiers comme celui de JCH Optimize : si vous proposez plusieurs devises, une page restera affichée dans l'ancienne devise jusqu'à l'expiration du cache après un changement.

Le suivi des liens d'affiliation (ctrl=affiliate&task=apply), si vous utilisez ce module, enregistre le parrainage en session dès le premier clic sur le lien.

Les notifications de paiement et leurs retours (task=notify, task=threedsecure, task=after_end) sont des appels faits par la banque ou le prestataire de paiement lui-même, pas par le navigateur du client : une réponse mise en cache sur ces URL casserait silencieusement la mise à jour du statut des commandes. Vous les excluez sans doute déjà si tout ctrl=checkout est exclu, mais ce sont des URL qu'on n'atteint jamais en cliquant, donc faciles à oublier dans une liste construite à partir de la navigation visible.

Sur le contrôleur product lui-même, donc ce que vous voulez justement garder en cache, les tâches cartinfo (retourne en JSON le contenu du panier de la session en cours), updatecart et cleancart (recalcul du panier depuis la fiche produit) doivent rester exclues même si task=show, la fiche produit normale, reste cachée. Pareil pour task=compare si vous utilisez le comparateur de produits.

Un point plus structurel à vérifier : le mini-panier affiché sur toutes les pages, y compris l'accueil, les catégories et les fiches produit, est aujourd'hui généré côté serveur et intégré directement dans le HTML de la page, sans rafraîchissement en Ajax après le chargement. Une page de catégorie ou de fiche produit servie depuis le cache JCH contient donc le panier tel qu'il était au moment précis où cette page a été mise en cache, pas forcément celui du visiteur qui la reçoit ensuite.

Le fait que votre test à deux sessions se soit bien comporté suggère que le plugin User State de JCH repasse en rendu dynamique dès qu'une session ou un panier existe, plutôt que de servir une page strictement statique à tout le monde. Avant la mise en production, je vous recommande un test plus poussé avec une seule session : ajoutez un produit au panier, puis rechargez plusieurs fois une même page de catégorie déjà en cache sur toute la durée de vie du cache configurée dans JCH, pas seulement juste après l'ajout, pour vérifier que le mini-panier ne reste pas bloqué sur une ancienne valeur. Refaites le test en retirant un produit du panier.

Si vous voulez garder les catégories et fiches produit en cache tout en gardant un mini-panier toujours exact, HikaShop expose un point d'entrée prévu pour cela :

Cette URL affiche uniquement le contenu du module panier et est marquée dans son code comme à ne jamais mettre en cache. En l'appelant en Ajax depuis votre thème après le chargement de la page, à la place du bloc panier déjà présent dans le HTML, puis en excluant cette URL précise du cache JCH, le panier resterait exact même sur une page servie depuis le cache. C'est une adaptation à faire dans le thème, pas une fonctionnalité prête à l'emploi.

Enfin, si certains de vos produits ont des prix différents selon le groupe de client, ou une TVA calculée depuis le pays du client, gardez à l'esprit que ces valeurs sont elles aussi générées côté serveur dans le HTML de la fiche produit ou de la catégorie : une page mise en cache pour un visiteur peut en afficher une version incorrecte à un autre jusqu'à l'expiration du cache. Si vous n'utilisez pas ces fonctionnalités, ce point ne vous concerne pas.

Bonjour,

Je vais effectuer des tests sur mon environnement de développement en excluant les URL que vous m’avez indiquées, ainsi que celles liées au compte utilisateur Joomla/HikaShop. Je retirerai ensuite l’exclusion globale de com_hikashop afin de vérifier si les catégories et fiches produit peuvent être mises en cache de manière fiable et stable.

Je testerai également le mini-panier avec plusieurs sessions navigateur et après l’expiration du cache.

Merci encore pour votre aide.