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.

Bonjour,

Je reviens sur cette discussion avec un cas précis concernant les visiteurs non connectés.

Lorsqu’un visiteur ajoute un produit au panier, JCH crée le cookie jch_optimize_no_cache_user_activity et l’exclut du cache de pages. Cependant, après avoir entièrement vidé son panier, le cookie reste présent et le visiteur reste exclu, même en naviguant sur d’autres pages.

Samuel, le développeur de JCH, m’a confirmé que c’est le fonctionnement prévu: JCH détecte le POST, mais ne peut pas savoir quand le panier HikaShop redevient vide. Le cookie expire selon la durée du cache JCH, soit 7 jours dans ma configuration.

Il suggère un petit plugin qui supprimerait ce cookie lorsqu’un événement HikaShop signale que le panier est vide.

Quel événement HikaShop faudrait-il utiliser pour détecter cela de manière fiable, y compris lors de la suppression des produits en AJAX? Existe-t-il déjà une solution pour ce cas?

Je dois conserver l'option de JCH "Exclude form users" activé et permettre au visiteur de bénéficier à nouveau du cache une fois son panier vidé, sans compromettre le fonctionnement du mini-panier ni la confidentialité.

Merci.

Bonjour,

Il n'existe pas de solution toute prête pour JCH Optimize dans HikaShop, mais deux événements HikaShop couvrent tous les cas où le panier se vide :

- onAfterCartSave, appelé à chaque enregistrement du panier : ajout, retrait d'un produit (y compris la suppression en AJAX depuis le mini-panier, qui passe par la tâche updatecart avec une quantité à 0), changement de quantité sur la page panier ou le checkout ;

- onAfterCartDelete, appelé quand le panier est supprimé : bouton « vider le panier » (tâche cleancart) et suppression du panier après la création de la commande.

Ces deux événements existent dans votre version 6.5.2. Ils sont décrits dans la documentation développeur : www.hikashop.com/support/documentation/6...r-documentation.html

Ni l'un ni l'autre ne reçoit directement l'information « panier vide » : $element dans onAfterCartSave ne contient pas toujours la liste complète des produits selon l'appel. Le plus fiable est donc, dans ces deux événements, de compter en base les produits restant dans les paniers (type cart, hors listes de souhaits) de la session en cours, ou du client HikaShop s'il est identifié, et de supprimer le cookie seulement si ce nombre est à 0.

Un point important sur l'ordre des opérations : JCH pose son cookie jch_optimize_no_cache_user_activity au tout début de chaque requête POST, or la suppression d'un produit en AJAX est elle-même un POST. Le plugin doit donc envoyer la suppression du cookie après JCH, dans la même réponse, ce qui est le cas en passant par ces événements HikaShop (le dernier en-tête Set-Cookie reçu l'emporte dans le navigateur). Le cookie doit aussi être supprimé avec le même chemin et le même domaine que ceux utilisés par JCH (ceux de la configuration globale de Joomla, sinon la racine du site).

Je vous joins un petit plugin qui fait exactement cela : plg_hikashop_jchcartcookie.zip. Installez-le par Système > Installer > Extensions, puis activez le plugin « HikaShop - JCH Optimize empty cart cookie » dans la liste des plugins. Il ne fait rien tant qu'il reste au moins un produit dans le panier, et ne touche à aucun autre cookie (ni à la session, ni au cookie de JCH pour les utilisateurs connectés).

Je l'ai testé avec un visiteur non connecté ayant le cookie de JCH : après l'ajout de deux produits, le cookie reste ; après le retrait du premier produit en AJAX depuis le mini-panier, il reste ; au retrait du dernier, la réponse AJAX supprime le cookie et le mini-panier s'affiche vide au rechargement. Même résultat avec le bouton de vidage du panier. Je n'ai pas pu le tester avec JCH Optimize Pro lui-même : merci de le vérifier sur votre environnement de développement, en regardant dans les outils de développement de Firefox (onglet Stockage) que le cookie disparaît bien après avoir vidé le panier, puis qu'une page de catégorie est de nouveau servie depuis le cache.

Gardez en tête que l'option Exclude form users de JCH pose ce cookie pour n'importe quel formulaire envoyé (contact, connexion, etc.) : le plugin le retirera aussi lorsqu'un visiteur ayant envoyé un autre formulaire vide son panier. Pour un visiteur non connecté, c'est sans conséquence sur la confidentialité, puisque les pages en cache sont les mêmes pour tous les visiteurs non connectés, à condition de garder exclues du cache les URL dont nous avons parlé précédemment (panier, checkout, compte, etc.).

Bonjour,

Merci pour les explications fournies et le plugin, c'est très gentil de le proposer! 

Par contre, il y a un petit souci: j'ai remarqué qu'au moment d'effacer le dernier article du panier, le cookie disparaît bien, mais il réapparaît tout de suite après.

Bonjour Nicolas, je vous écris en déplacement. Le développeur de JCH m’a répondu sans que je lui ai rien demandé en me disant qu’il avait réalisé une nouvelle version qui allait régler le problème. Je vous envoie sa réponse. Désolé de vous avoir fait travailler pour rien…

“In the next release, the cookie can be removed by triggering a Joomla event when the cart becomes empty. The User State plugin, which comes with JCH Optimize, then removes the cookie, and the visitor is served cached pages again on their next page load:
 
Trigger it during the request that empties the cart, for example from a small system plugin that listens to HikaShop's cart update event and checks that the cart has no products, or if HikaShop wants to implement this in their code.
It does nothing for a visitor who doesn't have the cookie, and cart behaviour isn't affected: a guest with an empty cart sees the same pages as every other guest. The User - JCH Optimize User State plugin must be enabled.
You can find the latest development build with these changes here:
www.jch-optimize.net/component/ars/?view...1590&format=html ”

Bonjour,

Après avoir relu la réponse du développeur de JCH, je dois préciser ma phrase précédente: votre plugin n’a pas été inutile, désolé pour cette formulation.

La nouvelle version de JCH Optimize ne détecte pas elle-même qu’un panier HikaShop devient vide. Lorsqu’un plugin déclenche l’événement Joomla onJchOptimizeUserPostFormDeleteCookie, le plugin User State de JCH supprime le cookie.

Samuel, le développeur de JCH, indique donc qu’il faut déclencher cet événement pendant la requête qui vide le panier, par exemple depuis un plugin qui écoute les événements de mise à jour du panier HikaShop et vérifie qu’il ne reste aucun produit.

J’ai testé votre plugin actuel avec JCH Optimize Pro 9.4.4-dev202610281415-rev0f3ffac4, après la suppression AJAX du dernier produit, le cookie jch_optimize_no_cache_user_activity disparaît, puis réapparaît immédiatement comme écrit auparavant.

Serait-il possible d’adapter votre plugin pour déclencher cet événement au lieu de supprimer directement le cookie?

Encore merci et désolé pour la confusion, je pensais que la nouvelle version de JCH allait résoudre le problème sans votre plugin, mais apparemment ce n’est pas le cas. Merci.

Bonjour,

Rien n'est perdu : l'événement que prépare le développeur de JCH sert à supprimer le cookie, mais il faut toujours quelque chose côté HikaShop pour le déclencher au bon moment, c'est-à-dire pendant la requête qui vide le panier. C'est exactement le rôle du petit plugin que nous vous avons envoyé.

Un point important pour la suite : si le déclenchement se fait seulement sur l'événement de mise à jour du panier, vous retrouverez le problème que vous avez constaté avec la première version. Après le retrait du dernier produit, le module panier se rafraîchit par une seconde requête POST, sur laquelle JCH repose son cookie. Il faut donc aussi déclencher la suppression sur ce rafraîchissement, ce que fait déjà notre plugin.

Vous trouverez ci-joint la version 1.0.2 du plugin : plg_hikashop_jchcartcookie.zip. Installez-la par-dessus la précédente (Système > Installer > Extensions), sans rien désinstaller. Elle utilise le nouvel événement onJchOptimizeUserPostFormDeleteCookie dès que votre version de JCH Optimize le propose : c'est alors le plugin « User - JCH Optimize User State » de JCH qui supprime son propre cookie, avec ses propres réglages. Avec une version de JCH qui ne le propose pas encore, le plugin continue de supprimer le cookie lui-même, comme la version 1.0.1. Vous pouvez donc l'installer dès maintenant et mettre à jour JCH Optimize quand vous le souhaitez, sans rien changer d'autre. Le plugin « User - JCH Optimize User State » doit rester activé.

Nous l'avons testé avec un visiteur non connecté, en simulant JCH (cookie posé à chaque requête POST, et un plugin utilisateur qui répond au nouvel événement) : avec deux produits dans le panier, le retrait du premier laisse le cookie en place ; au retrait du dernier, l'événement est bien déclenché sur la suppression du produit et sur le rafraîchissement du module panier, et le cookie disparaît. Sans plugin répondant à l'événement, le cookie est supprimé comme avant. Nous n'avons pas pu tester avec la version de développement de JCH Optimize elle-même : merci de vérifier, après l'avoir installée, dans l'onglet Stockage des outils de développement de Firefox, que le cookie ne revient plus après avoir vidé le panier.

Bonjour Nicolas,

Merci beaucoup pour cette nouvelle version.

J’ai installé la version 1.0.2 par-dessus la précédente et tout fonctionne maintenant très bien avec la version de développement de JCH Optimize : après la suppression du dernier produit, le cookie ne revient plus et le visiteur retrouve les pages en cache. Encore merci.

Bonjour,

Merci pour votre retour. Le plugin est désormais publié gratuitement sur notre marketplace, en version 1.0.3 : www.hikashop.com/marketplace/integration...-optimize-empty-cart

Elle fonctionne exactement comme la 1.0.2 que vous utilisez, avec en plus les fichiers de langue et le serveur de mise à jour : installez-la par-dessus la vôtre (Système > Installer > Extensions), sans rien désinstaller, et les prochaines versions vous seront proposées par le gestionnaire de mises à jour de Joomla.