Cache de page complète PrestaShop, Redis et cache CDN

Ce que nous ferions

Nous mesurerions le parcours réel des requêtes avant de choisir un autre cache. Conservez un cache opérationnel s'il préserve l'exactitude et réduit la charge mesurée. Utilisez le cache de page complète pour les visites publiques répétées éligibles et corrigez en parallèle les traitements coûteux non mis en cache, notamment le panier et la commande. Redis est une piste lorsqu'un adaptateur implémenté peut réutiliser les données responsables du délai.

Le choix dépend de vos versions actuelles de PrestaShop et PHP, de vos modules, intégrations, thème, données de catalogue, groupes de clients, marchés et trafic. Tenez compte de la capacité de votre équipe à surveiller, purger et rétablir chaque service ajouté. Un import de stock ERP, des prix selon le pays ou un en-tête personnalisé peuvent modifier la politique sûre, même lorsque deux boutiques utilisent le même module de cache.

Effectuez le changement sur une copie privée de préproduction avec des données représentatives et les mêmes modules, intégrations et thème pertinents. Isolez son espace de noms de cache et son stockage de sessions de la production, et empêchez les commandes de test, e-mails et exports d'atteindre les systèmes réels. Modifiez une couche à la fois, répétez la navigation, les mises à jour et la reprise après panne, puis planifiez la mise en production en gardant la configuration précédente disponible et en désignant une personne pour vérifier les commandes et la fraîcheur des données.

Si vous souhaitez faire évaluer le goulot d'étranglement avant de choisir un cache, le PrestaShop Speed & Core Web Vitals Audit fournit un plan de corrections mesuré et hiérarchisé ; l'implémentation fait l'objet d'un périmètre distinct.

Quelle approche correspond à vos observations ?

Identifier la couche de cache à modifier

Un cache n'est utile que si l'application y lit des données. Installer Redis ne déplace pas automatiquement tous les caches PrestaShop en mémoire.

Smarty réutilise normalement les templates compilés. Il ne compile pas chaque template à chaque requête. PrestaShop initialise Smarty avec le cache de sortie global désactivé et gère le cache de manière sélective. Utilisez les paramètres pris en charge dans le back-office plutôt que de modifier sans discernement le cache de sortie global.

Les formulaires Performances de PrestaShop 1.7.8 et 9 proposent les backends Memcache, Memcached, APC/APCu et XCache, selon les extensions installées. Ils ne proposent ni Redis ni un backend sur système de fichiers dans ce sélecteur. L'ancien CacheFs est une implémentation distincte. Redis nécessite un adaptateur ou un module qui implémente la couche que vous souhaitez utiliser.

Cache::store() utilise un tableau local à la requête, tandis que Configuration possède des caches statiques. Les résultats de base de données éligibles peuvent utiliser le backend Cache persistant. Changer ce backend ne redirige pas toutes les recherches de catégories, de hooks, de configuration ou de templates.

Choisir une politique sûre de cache de page complète

Le cache de page complète stocke une réponse rendue éligible pour les visiteurs suivants. Si la réponse demandée est absente du cache, le rendu normal a toujours lieu. Un cache de page PHP peut réduire les traitements ultérieurs du contrôleur et des templates tout en conservant le coût de l'initialisation. Une réponse servie depuis le cache d'un proxy ou d'un CDN peut éviter entièrement le serveur d'origine.

Commencez par les pages publiques anonymes. Contournez le cache pour le panier, la commande, l'authentification, les pages du compte, les routes du back-office, les points d'accès privés des modules, les webservices, les rappels et les requêtes qui modifient l'état. Tenez aussi compte d'AJAX, des paramètres de requête, des liens d'aperçu, des cookies de session et des réponses qui définissent des cookies.

Une clé de cache doit distinguer chaque contexte qui modifie la réponse publique. Selon votre boutique, cela peut inclure le nom d'hôte, la boutique, la langue, la devise, le pays, le contexte fiscal, le rendu selon l'appareil et les paramètres de requête pris en charge. Les prix par groupe de clients et les promotions personnalisées demandent une attention particulière.

Ne servez pas le contenu privé d'un client à un autre. Si un contexte ne peut pas être représenté de façon sûre dans une clé, contournez le cache. Évitez de supprimer les cookies uniquement pour forcer une réponse depuis le cache. Testez à la fois la recherche dans le cache et la décision d'y stocker une réponse nouvellement rendue.

Les fragments dynamiques, l'hydratation AJAX, les inclusions côté périphérie et le contournement pour les requêtes personnalisées sont des architectures différentes. L'hydratation et le scintillement ne sont pas des propriétés inévitables du cache de page complète. Si votre implémentation remplace des fragments d'en-tête ou de panier après le chargement, réservez leur espace et testez les appareils lents. Un compteur de panier affichant zéro ne prouve pas, à lui seul, que le panier côté serveur est vide.

Performance Revolution exécute son cache de page d'origine dans PHP après l'initialisation, et sa politique d'éligibilité vérifie les contextes du client, du panier et d'autres éléments de la requête. Sa page d'aide couvre les processus pris en charge de cache de page, CSS critique, préchauffage et CDN.

L'invalidation fait partie de la conception

• Purgez ou mettez à jour les entrées concernées après les modifications de produits, catégories, stock, prix, promotions, traductions et configuration.
• Tenez compte de l'activation et de l'expiration planifiées des règles de prix.
• Exigez que les imports et intégrations déclenchent l'invalidation appropriée. Les écritures directes en base peuvent contourner les hooks de l'application.
• Utilisez le TTL comme limite de fraîcheur, pas comme preuve que les modifications deviennent visibles immédiatement.
• Préchauffez uniquement les pages publiques éligibles et évitez de surcharger le serveur d'origine avec des requêtes simultanées sans réponse en cache.

Testez une modification de prix et de stock via chaque voie de mise à jour que vous utilisez. Une purge manuelle peut résoudre un incident, mais des données périmées récurrentes nécessitent une correction de l'invalidation.

Exemple pratique : prix publics et import de stock ERP

Votre boutique vend aux particuliers de plusieurs pays et propose des prix distincts aux professionnels connectés. Préchauffez une page produit et une page catégorie publiques dans chaque contexte tarifaire pris en charge, puis connectez-vous comme client professionnel. Vérifiez le prix affiché, l'affichage des taxes et le total du panier par rapport à une référence non mise en cache ; la visite professionnelle doit suivre la politique de contournement convenue.

En préproduction, préchauffez les variantes publiques des pages produit et des listes et confirmez les accès servis depuis chaque couche de cache HTML activée. Modifiez uniquement le prix dans le back-office, puis comparez chaque variante à une référence non mise en cache avant toute purge manuelle. Préchauffez à nouveau, confirmez les accès en cache, puis modifiez uniquement le stock par l'import ERP réel et répétez les vérifications, y compris les messages de disponibilité et les copies en périphérie. Testez chaque voie de mise à jour séparément : si l'une laisse des données périmées, contournez le cache de page concerné jusqu'à ce que cette voie l'invalide de façon fiable.

Connecter Redis à une intégration opérationnelle

Redis est un service clé-valeur en mémoire, exécuté sur votre serveur ou fourni par votre hébergeur. Il peut stocker des valeurs de cache, des entrées de cache de page ou des sessions PHP lorsqu'une intégration correspondante l'utilise. Identifiez d'abord l'adaptateur, les versions de PrestaShop/PHP prises en charge, le format des clés, la politique de TTL, l'invalidation et le comportement en cas de panne.

1. Confirmez que votre hébergeur fournit un service Redis accessible. Un service géré par l'hébergeur ne nécessite pas que vous disposiez d'un accès SSH.
2. Vérifiez le client PHP requis dans l'environnement PHP web, pas uniquement dans PHP CLI. PHP-FPM et CLI peuvent charger des configurations différentes.
3. Configurez l'hôte, le port, l'authentification, TLS si nécessaire, la base de données et l'espace de noms dans l'intégration choisie. Dans les conteneurs, utilisez la bonne adresse du service ; localhost désigne le conteneur actuel.
4. Attribuez un espace de noms explicite à chaque installation et à chaque périmètre de boutique ou groupe requis. Un préfixe partagé par défaut comme ps_ n'isole pas les boutiques.
5. Visitez des pages représentatives et vérifiez les clés propres à l'adaptateur, les TTL et les lectures/écritures.
6. Testez l'invalidation, la perte de connexion et la reprise sur un site de préproduction.

Exemples de diagnostic local, en supposant que Redis est délibérément accessible sur le même hôte au port 6379 :

redis-cli -h 127.0.0.1 -p 6379 PING
redis-cli -h 127.0.0.1 -p 6379 INFO stats
redis-cli -h 127.0.0.1 -p 6379 INFO memory
redis-cli -h 127.0.0.1 -p 6379 -n 0 DBSIZE

Respectez les exigences d'authentification et de transport de votre service. PONG confirme l'accessibilité, pas l'utilisation de Redis par PrestaShop. Un nombre de clés non nul peut appartenir à une autre application. Examinez l'espace de noms et l'activité de l'intégration choisie. Les succès et échecs de cache à l'échelle de l'instance ne permettent pas d'identifier le bénéfice pour une boutique donnée.

Utilisez SCAN avec un préfixe connu pour une inspection contrôlée. MONITOR peut exposer les données des commandes et ajouter une surcharge ; réservez son utilisation brève à un diagnostic dans un environnement contrôlé.

Redis Cache Manager & Monitor fournit des tests de connexion administratifs, une surveillance et une gestion des espaces de noms et des clés ; sa page d'aide couvre les processus du module.

Les adaptateurs de cache applicatif, la configuration des sessions PHP et le cache de page complète restent des travaux d'intégration distincts. Un réglage enregistré ou une connexion réussie au tableau de bord ne prouve pas que le cache applicatif a changé. Si l'espace de noms attendu reste vide, vérifiez la base sélectionnée, le préfixe et l'éligibilité des pages avant de modifier la capacité. Vérifiez les erreurs de connexion de l'environnement web et la configuration de l'adaptateur ; installer une extension PHP seule n'ajoute pas Redis au sélecteur natif.

Memcached est une autre solution de cache en mémoire, avec des fonctionnalités différentes. Redis comme Memcached peuvent avoir des gestionnaires de sessions PHP configurés séparément. Choisissez selon les adaptateurs pris en charge, les besoins opérationnels et les mesures, sans supposer que l'un est toujours plus rapide.

Distinguer sessions, éviction et durabilité

Les paniers PrestaShop sont des enregistrements en base de données. L'identité du client repose aussi sur des cookies PrestaShop et des enregistrements en base. Les sessions PHP/Symfony constituent une autre couche. Déplacer les sessions PHP vers Redis ne déplace pas les lignes de panier et ne garantit pas la continuité de la connexion des clients.

Si vous changez le gestionnaire de sessions PHP, suivez les instructions de configuration de phpredis pour votre version installée et appliquez-les au bon pool PHP-FPM. Vérifiez où le framework de votre application prévoit la configuration des sessions.

Définissez les TTL de session, le verrouillage, l'authentification, la capacité, la persistance et le comportement en cas de panne. Les sessions stockées dans Redis peuvent toujours nécessiter un verrouillage pour éviter que des requêtes concurrentes écrasent leur état. Testez des requêtes parallèles provenant de la même session et de sessions différentes.

Des numéros de base Redis distincts peuvent aider à distinguer les clés, mais partagent la mémoire de l'instance, la politique d'éviction et l'exposition aux pannes. Un vidage du cache peut affecter les sessions si son périmètre est incorrect. Préférez un service de sessions provisionné séparément lorsque les sessions nécessitent une politique différente de durabilité et d'éviction.

Les politiques d'éviction Redis s'appliquent à l'instance. volatile-lru évince les clés dotées d'un TTL, qui peuvent inclure les sessions. Cette politique ne les protège pas. Choisissez délibérément l'éviction du cache et surveillez les échecs d'écriture si vous utilisez une politique sans éviction.

Pour les sessions, choisissez explicitement la persistance RDB/AOF, la réplication et les objectifs de reprise. La persistance réduit certains scénarios de perte, mais ne garantit ni absence totale de perte ni connexions ininterrompues.

Sur une boutique avec répartition de charge, vérifiez que chaque nœud web utilise le backend partagé prévu et un espace de noms compatible. Répétez un parcours passant entre les nœuds. Le stockage partagé des sessions PHP ne peut pas, à lui seul, corriger des incohérences de configuration applicative, de portée des cookies ou de secrets, et il ne remplace pas la base contenant les paniers.

Dimensionnez Redis à partir du nombre de clés, de la taille des données, des variantes, des TTL et des pics d'utilisation mesurés. Surveillez used_memory, used_memory_peak, maxmemory, evicted_keys, les écritures rejetées et les connexions. L'éviction peut être normale dans un cache jetable de taille limitée ; interprétez-la avec la latence et les profils d'accès au cache. Il n'existe ni formule mémoire fondée sur la taille du catalogue ni objectif universel de 90 % de succès du cache.

Calculez le taux de succès du cache sur une période en divisant l'augmentation de keyspace_hits par la somme des augmentations de keyspace_hits et keyspace_misses, en excluant les périodes avec remise à zéro des compteurs ou sans recherches. Ces compteurs couvrent toute l'instance Redis, pas seulement la boutique. Un faible taux de réutilisation peut refléter de nombreuses variantes de pays/devise ou des URL rarement revisitées. Mettez-le en relation avec les expirations, imports, purges et la pression mémoire avant d'augmenter maxmemory. Suivez connected_clients par rapport au trafic et aux erreurs de connexion ; sa croissance seule ne prouve pas une fuite.

Configurer Cloudflare ou Varnish autour de l'application

Le comportement de cache par défaut de Cloudflare vise principalement les ressources statiques éligibles ; le cache HTML nécessite une configuration délibérée. Commencez par la diffusion statique et confirmez que les requêtes dynamiques restent privées. Utilisez Full (Strict) TLS avec un certificat d'origine valide et un nom d'hôte correspondant. Le mode Flexible utilise HTTP vers le serveur d'origine et peut entrer en conflit avec les redirections HTTPS.

• Excluez du cache HTML partagé le panier, la commande, le compte, l'administration, l'API, AJAX et les rappels de paiement.
• Respectez les directives private/no-store et le comportement de Set-Cookie. Testez les règles réellement appliquées en périphérie, pas seulement les en-têtes d'origine.
• Laissez les enregistrements DNS liés aux e-mails sans proxy lorsque le service de messagerie l'exige.
• Ne restaurez les adresses réelles des visiteurs qu'à partir de proxies Cloudflare de confiance. Ne faites pas confiance à un en-tête de transfert arbitraire fourni par le client.
• Testez les règles WAF et antibots avec les rappels de paiement, la validation des commandes et les intégrations.
• Désactivez Rocket Loader ou excluez-en explicitement les scripts de commande s'il modifie l'ordre d'exécution requis ; testez le parcours complet.

Une intégration HTML CDN contrôlée peut ne marquer pour le cache que les réponses anonymes GET/HEAD éligibles et envoyer des en-têtes de contournement pour les autres contextes. Configurez les mécanismes de purge pris en charge et vérifiez les capacités actuelles de votre compte. Les en-têtes seuls ne prouvent pas que la périphérie a mis en cache ou contourné une réponse.

Varnish est un proxy inverse HTTP. Lorsqu'une réponse est en cache, il peut répondre avant l'exécution de PHP. Il nécessite des règles pour les méthodes, cookies, clés de cache, réponses privées, invalidations et comportements en cas de panne. De nombreux déploiements terminent TLS dans un composant distinct. Les fragments dynamiques sont un travail d'implémentation facultatif.

Ajoutez un proxy inverse lorsque le trafic anonyme mesuré ou la saturation des workers PHP justifie son exploitation. Il ne peut pas supprimer les traitements de commande non mis en cache. Prévoyez une capacité d'origine suffisante pour les requêtes sans réponse en cache, les purges et les pannes, et protégez les points d'accès d'invalidation.

Vider et diagnostiquer le bon cache

Commencez par Paramètres avancés > Performances > Vider le cache. Consignez le symptôme étudié. Actualiser le navigateur ne vide ni les caches d'origine, ni OPcache, ni les caches en périphérie.

1. Utilisez la préproduction si possible. Modifiez ou contournez une couche à la fois.
2. Videz les caches pris en charge par l'application et vérifiez la page directement à l'origine par votre voie de diagnostic autorisée.
3. Invalidez tout espace de noms distinct de module ou de Redis concerné.
4. Réinitialisez l'OPcache web uniquement si le déploiement l'exige. Un opcache_reset() en CLI ne réinitialise normalement pas le pool PHP-FPM web.
5. Purgez les entrées du proxy ou du CDN concernées une fois l'origine correcte.
6. Revérifiez une nouvelle requête anonyme et une requête personnalisée, puis rétablissez les paramètres souhaités.

var/cache/prod et var/cache/dev restent actifs pour les caches du framework et de Smarty après l'installation d'un adaptateur Redis distinct. Les anciennes arborescences 1.6 utilisent cache/smarty ; l'ancien CacheFs utilise cache/cachefs. Confirmez votre version exacte et la racine avant tout nettoyage du système de fichiers.

Privilégiez l'opération de vidage du cache prise en charge. Si la reprise nécessite un nettoyage manuel, isolez le site, préservez la structure des répertoires et les contrôles d'accès, exécutez l'opération en tant qu'utilisateur de l'application et vérifiez les propriétaires ainsi que la reconstruction du cache. N'appliquez pas de suppression récursive sans périmètre défini depuis un répertoire de travail incertain.

Utilisez une invalidation d'espace de noms adaptée à l'intégration. FLUSHDB supprime toutes les clés de la base sélectionnée ; FLUSHALL supprime toutes les bases de l'instance. Aucune de ces commandes ne remplace de façon sûre une purge limitée à une boutique sur une infrastructure partagée.

Si le cache renvoie des prix, des informations personnelles ou un état de commande incorrects, contournez la couche concernée jusqu'à correction et vérification. Les paramètres de cache en production doivent dépendre de l'exactitude et de la charge mesurée, plutôt que d'une règle inconditionnelle consistant à laisser tous les caches activés.

Mesurer les performances et corriger les traitements non mis en cache

Enregistrez les réponses à froid et à chaud pour les mêmes URL, données, langue, devise, appareil et état de connexion. Incluez la concurrence des requêtes, la charge d'origine et l'état du cache. Comparez la navigation ordinaire aux requêtes de panier et de commande. Mesurez plusieurs essais plutôt qu'une seule requête.

Le TTFB mesure le délai avant le début de la réponse. Il aide au diagnostic du chargement, mais n'est pas un Core Web Vital. Les Core Web Vitals sont LCP, INP et CLS. Présentez LCP et INP comme des durées, CLS comme une valeur sans unité et le score de performances Lighthouse séparément. De meilleurs scores ne garantissent pas un meilleur classement.

Utilisez le profileur historique PrestaShop pour les requêtes ordinaires de la boutique relevant du système historique, sur une préproduction protégée. Utilisez le profilage Symfony pour les requêtes traitées via Symfony. L'APM en production, les journaux de requêtes lentes et les métriques du serveur web peuvent aider sans exposer de page de débogage.

• Profilez les hooks coûteux, les requêtes répétées et les appels externes en direct. Ne mettez en cache que les données dont vous pouvez définir la fraîcheur et le périmètre.
• Corrigez les index manquants et les requêtes coûteuses. Appliquez une politique de conservation avant de nettoyer les journaux, les enregistrements d'e-mails ou les données de connexion.
• Utilisez les paramètres de compilation Smarty pris en charge et videz les templates compilés après le déploiement lorsque c'est nécessaire.
• Activez et dimensionnez OPcache pour l'environnement web. JIT est distinct et nécessite un benchmark de l'application. Si la validation des horodatages est désactivée, réinitialisez OPcache de façon fiable pendant le déploiement.
• Choisissez PHP selon la matrice de compatibilité de la version exacte. PrestaShop 1.7.8 ne prend pas officiellement en charge PHP 8.
• Ajustez MySQL selon votre charge de travail et votre budget mémoire total. MySQL 8.0.30+ utilise innodb_redo_log_capacity ; MariaDB et les anciennes versions de MySQL diffèrent.
• Testez l'optimisation CSS/JavaScript, le CSS critique, les images adaptatives et les scripts tiers. Réservez les dimensions des images et l'espace des interfaces dynamiques pour limiter les décalages de mise en page.

Si l'activation d'un cache laisse la même requête lente, profilez aussi son fonctionnement : construction des clés, sérialisation, verrous et calcul répété d'empreintes des ressources peuvent ajouter du travail au traitement de la requête. Comparez ce coût au travail économisé, y compris en l'absence de réponse en cache.

Un cache peut réduire les traitements répétés tout en laissant des requêtes lentes lorsqu'il n'a pas de réponse. Conservez-le lorsqu'il améliore les performances mesurées de façon sûre ; ne le retirez ou remplacez qu'après avoir testé la charge et l'expérience client qui en résultent.

Répéter la transition et transmettre la procédure de reprise

1. Consignez les réglages actuels, temps de réponse et états du cache pour des pages d'accueil, catégories et produits représentatives, ainsi qu'un panier et un parcours de commande. Conservez les contextes de test précis pour pouvoir répéter la comparaison.
2. En préproduction, préchauffez les variantes publiques prévues. Utilisez des profils de navigateur distincts pour les visiteurs anonymes et les clients de groupes ou devises différents. Vérifiez le panier, la connexion et l'en-tête personnalisé ainsi que le corps de la page.
3. Effectuez des mises à jour via le back-office, les promotions planifiées et chaque import ou intégration utilisé. Vérifiez le cache applicatif et toute copie de proxy/CDN par rapport aux données actuelles attendues.
4. Répétez une purge et une navigation à froid avec une concurrence représentative. Rendez ensuite Redis ou le service de cache de page indisponible dans l'environnement contrôlé et vérifiez les erreurs, la charge de repli et la reprise séparément pour chaque couche activée.
5. Convenez de la fenêtre de mise en production, du critère de retour en arrière et du responsable. Appliquez la configuration testée, invalidez ou préchauffez uniquement le périmètre prévu et vérifiez la navigation réelle, les achats et l'import suivant après la transition.

Un retour en arrière pour du HTML en cache jetable peut consister à contourner cette couche et purger ses copies. Le retour en arrière d'un gestionnaire de sessions nécessite sa propre procédure : le stockage précédent peut ne pas contenir les sessions créées après la transition. Convenez des attentes de continuité avant de changer de gestionnaire et répétez les deux sens. Ne remplacez pas la base de production par celle de préproduction pour mettre en service une configuration de cache.

Questions à poser à votre développeur ou agence

• Quelle couche change, où un accès servi depuis le cache arrête-t-il le traitement et qu'est-ce qui continue à s'exécuter ?
• Quels contextes de requête sont représentés dans les clés ou contournés, et où est la preuve que du contenu privé ne peut pas entrer dans le stockage partagé ?
• Quelles mises à jour invalident quelles copies, et qui est responsable de l'invalidation pour les imports ERP et promotions planifiées ?
• Que se passe-t-il lors d'une purge, d'une panne de cache ou d'un retour à l'ancien gestionnaire de sessions, et l'origine peut-elle absorber la charge résultante ?
• Où sont consignés pour le personnel les réglages testés, le plan des espaces de noms, la surveillance, les instructions de purge ciblée et la procédure de reprise ?

Questions des responsables de boutique

Quel cache acheter en premier ?

Choisissez selon la requête lente et le travail qu'elle répète. Demandez une mesure de référence et un essai réversible avant d'acheter de l'infrastructure ou un autre module. Si le diagnostic reste incertain, utilisez le guide des performances pour organiser les mesures.

Redis remplace-t-il OPcache ou la base de données ?

Non. OPcache réutilise le code PHP compilé ; une intégration Redis réutilise certaines valeurs ou stocke des sessions. La base conserve les enregistrements de votre boutique, et les requêtes non mises en cache nécessitent toujours une capacité suffisante.

Pourquoi une visite répétée est-elle rapide alors qu'un nouveau visiteur attend ?

La visite répétée peut trouver une réponse dans le cache du navigateur, de page ou de données qui manque à la nouvelle requête. Vérifiez l'état réel du cache et le contexte du visiteur, puis comparez les résultats à froid et à chaud. Votre navigateur déjà préchauffé ne prouve pas la qualité de l'expérience d'une première visite.

Faut-il laisser tous les caches activés lors d'un incident ?

Contournez la couche servant du contenu incorrect ou privé, puis examinez-la à l'aide d'une référence non mise en cache. Surveillez la charge de l'origine lorsqu'elle prend en charge davantage de requêtes et rétablissez la politique testée après correction.

Puis-je retirer le cache de page complète après optimisation de la boutique ?

Testez d'abord son contournement en préproduction sous une charge représentative. Conservez-le ou retirez-le selon l'exactitude, la capacité en pointe et l'expérience client ; une page non mise en cache plus rapide ne suffit pas à démontrer que les pics de trafic sont couverts.