Edit History

@Eolia @doekia merci des infos, si l'implémentation memcache sur Presta est foireuse là c'est dommage, je n'ai pas de visu Presta là dessus mais selon vous il faut le désactiver c'est noté. Une possibilité que le problème vienne de là ?

Déso je sors du sujet mais

8 hours ago, Eolia said:

Quel plaisir à lire quand un pro énonce clairement ce que personne ne comprend  

Un professionnel Prestashop sans aucun doute, moins système (aucune critique, chacun son métier, j'ai juste l'impression que @doekia me prend pour un jambon et j'aime pas trop ça ), un peu de clarification fera du bien.

Pour info c'est en prod et rôdé (bientôt 4 ans). L'optimisation globale et le tuning a pris quelques semaines à l'époque avant d'arriver à un truc au poil. L'infrastructure est up to date, automatisé, fiable, viable, exploitable, maintenable.

@doekia déjà ton workflow et ton analyse de la stack technique est foireuse : NON et NON, ni Cloudflare ni Pagespeed ne sont là pour faire un « snapshot » de la page, le premier optimise les assets, le second distribue de manière géographique, le reste est délivré par le serveur applicatif à travers Nginx. Le tout est délivré à l'end user par Clouflare. Aucun rapport DB/PHP.

9 hours ago, doekia said:

L'erreur a mon avis c'est de faire des benchmark non représentatif quand on parle de l'utilité des caches autre que 1er niveau (smarty). [...] Ton infra passe son temps à faire des caches pour les invalider. Perdre 50ms en page d’accueil pour gagner 50ms partout ailleurs c'est win/win.

Tu n'as pas du tout compris. Prestashop n'est qu'un composant applicatif qui s'inscrit dans un système plus global, Nginx/Pagespeed/Cloudflare ne font pas parti de l'applicatif cœur Prestashop. Je n'ai pas le temps d'expliquer deep dive le fonctionnement Pagespeed/Nginx/Cloudflare, mais tout est indépendant par rapport à Presta, ce ne sont pas des couches qui se superposent et se mélangent (memcache compris, du offload en RAM des query DB/call api/rendering, si c'est bien implémenté ça n'overlap pas avec le cache presta), ce sont des composants qui travaillent ensemble de manière autonome.

Chaque brique a sa propre fonction, c'est géré et tuné proprement en conséquence. Sans cette stack technique bien spécifique les performances sont ce que je considère comme très moyenne. Des tests de performances ça a été fait, correctement et violemment. La différence est juste énorme avec du Presta vanilla, que ce soit en terme de capa ou de temps de réponse.

9 hours ago, doekia said:

Heu, il y a le bouton gomme (effacer le cache) pour régler ce problème et qui normalement n'arrive jamais en réglage (recompiler si besoin)

Je parle d'une modification de template. Faut bien recompiler si un template est modifié ? Si cliquer sur "vider le cache" ça recompile les templates c'est un problème d'UI alors.

9 hours ago, doekia said:

Dernier client que j'ai transféré, de son VPS perf, il avait 1.4s de TTFB, transféré on est passé à 850ms, j'ai éliminé tout ses caches (en plus il avait un module dit "de cache") on est maintenant entre 350 à 480ms sur toutes les pages. Les stats de la search console ne font plus de dents de scie, nous sommes passé de 50 visites simultanées aux heures de pointes à 70.

Concernant le TTFB c'est intéressant que tu en parles vu que ça n'a aucune valeur représentative niveau optimisation (il y a des enjeux de SEO si c'est trop haut).

Le TTFB c'est le premier byte que va recevoir ton client. Mais lui s'en fous du header HTTP, il veut voir sa page. Donc l'important c'est quand démarre le rendering. Cloudflare a sorti un très bon article là dessus : https://blog.cloudflare.com/ttfb-time-to-first-byte-considered-meaningles/

Use case ultra classique TTFB sans/avec gzip :

                          |  TTFB   |  Page loaded
------------------------- | ------- | -------------
No compression (gzip off) | 213us   | 43ms
Compressed (gzip on)      | 1.7ms   | 8ms

Donc oui logique t'enlève du processing ton TTFB drop. Une archi propre, TTFB plus élevé ça explosera quand même les perfs de ton site avec juste le cache smarty à 350ms et la page sera rendue avant, à coup sûr. Pour moi l'optimisation Prestashop native n'est pas assez poussée. Rentre en compte taille totale de la page, temps global de chargement, etc. Pagespeed correctement implémenté aide en partie à palier à ce souci. 

Dernier point :

9 hours ago, doekia said:

Déja php7.2, puis nginx, puis pagespeed, puis cloudflare, ... puis là tu viens de rajouter memcache

Ça sous entend quoi ? Si tu parles de comptabilité 7.2 c'est sensé l'être ? (hors partie memcache). Si c'est niveau web server... apache et ses magnifiques .htaccess process à chaque fois, voir dans chaque sous dossier même si non présent, son modèle pre-fork worker child... je rentrerais pas dans ce débat ^^

Enfin bref, faut faire attention à ce qui est dit hors fonctionnement purement applicatif Prestashop quand le sujet n'est pas maîtrisée des fois ça peut vite être limite voir dangeureux, j'avais vu passer une commande je sais plus où d'un chown récursif de fichiers php avec comme référence un autre dossier... ça fait peur... 
 

Merci à vous les gars  

@Eolia @doekia merci des infos, si l'implémentation memcache sur Presta est foireuse là c'est dommage, je n'ai pas de visu Presta là dessus mais selon vous il faut le désactiver c'est noté.

Déso je sors du sujet mais

8 hours ago, Eolia said:

Quel plaisir à lire quand un pro énonce clairement ce que personne ne comprend  

Un professionnel Prestashop sans aucun doute, moins système (aucune critique, chacun son métier, j'ai juste l'impression que @doekia me prend pour un jambon et j'aime pas trop ça ), un peu de clarification fera du bien.

Pour info c'est en prod et rôdé (bientôt 4 ans). L'optimisation globale et le tuning a pris quelques semaines à l'époque avant d'arriver à un truc au poil. L'infrastructure est up to date, automatisé, fiable, viable, exploitable, maintenable.

@doekia déjà ton workflow et ton analyse de la stack technique est foireuse : NON et NON, ni Cloudflare ni Pagespeed ne sont là pour faire un « snapshot » de la page, le premier optimise les assets, le second distribue de manière géographique, le reste est délivré par le serveur applicatif à travers Nginx. Le tout est délivré à l'end user par Clouflare. Aucun rapport DB/PHP.

8 hours ago, doekia said:

L'erreur a mon avis c'est de faire des benchmark non représentatif quand on parle de l'utilité des caches autre que 1er niveau (smarty). [...] Ton infra passe son temps à faire des caches pour les invalider. Perdre 50ms en page d’accueil pour gagner 50ms partout ailleurs c'est win/win.

Tu n'as pas du tout compris. Prestashop n'est qu'un composant applicatif qui s'inscrit dans un système plus global, Nginx/Pagespeed/Cloudflare ne font pas parti de l'applicatif cœur Prestashop. Je n'ai pas le temps d'expliquer deep dive le fonctionnement Pagespeed/Nginx/Cloudflare, mais tout est indépendant par rapport à Presta, ce ne sont pas des couches qui se superposent et se mélangent (memcache compris, du offload en RAM des query DB/call api/rendering, si c'est bien implémenté ça n'overlap pas avec le cache presta), ce sont des composants qui travaillent ensemble de manière autonome.

Chaque brique a sa propre fonction, c'est géré et tuné proprement en conséquence. Sans cette stack technique bien spécifique les performances sont ce que je considère comme très moyenne. Des tests de performances ça a été fait, correctement et violemment. La différence est juste énorme avec du Presta vanilla, que ce soit en terme de capa ou de temps de réponse.

8 hours ago, doekia said:

Heu, il y a le bouton gomme (effacer le cache) pour régler ce problème et qui normalement n'arrive jamais en réglage (recompiler si besoin)

Je parle d'une modification de template. Faut bien recompiler si un template est modifié ? Si cliquer sur "vider le cache" ça recompile les templates c'est un problème d'UI alors.

8 hours ago, doekia said:

Dernier client que j'ai transféré, de son VPS perf, il avait 1.4s de TTFB, transféré on est passé à 850ms, j'ai éliminé tout ses caches (en plus il avait un module dit "de cache") on est maintenant entre 350 à 480ms sur toutes les pages. Les stats de la search console ne font plus de dents de scie, nous sommes passé de 50 visites simultanées aux heures de pointes à 70.

Concernant le TTFB c'est intéressant que tu en parles vu que ça n'a aucune valeur représentative niveau optimisation (il y a des enjeux de SEO si c'est trop haut).

Le TTFB c'est le premier byte que va recevoir ton client. Mais lui s'en fous du header HTTP, il veut voir sa page. Donc l'important c'est quand démarre le rendering. Cloudflare a sorti un très bon article là dessus : https://blog.cloudflare.com/ttfb-time-to-first-byte-considered-meaningles/

Use case ultra classique TTFB sans/avec gzip :

                          |  TTFB   |  Page loaded
------------------------- | ------- | -------------
No compression (gzip off) | 213us   | 43ms
Compressed (gzip on)      | 1.7ms   | 8ms

Donc oui logique t'enlève du processing ton TTFB drop. Une archi propre, TTFB plus élevé ça explosera quand même les perfs de ton site avec juste le cache smarty à 350ms et la page sera rendue avant, à coup sûr. Pour moi l'optimisation Prestashop native n'est pas assez poussée. Rentre en compte taille totale de la page, temps global de chargement, etc. Pagespeed correctement implémenté aide en partie à palier à ce souci. 

Dernier point :

8 hours ago, doekia said:

Déja php7.2, puis nginx, puis pagespeed, puis cloudflare, ... puis là tu viens de rajouter memcache

Ça sous entend quoi ? Si tu parles de comptabilité 7.2 c'est sensé l'être ? (hors partie memcache). Si c'est niveau web server... apache et ses magnifiques .htaccess process à chaque fois, voir dans chaque sous dossier même si non présent, son modèle pre-fork worker child... je rentrerais pas dans ce débat ^^

Enfin bref, faut faire attention à ce qui est dit hors fonctionnement purement applicatif Prestashop quand le sujet n'est pas maîtrisée des fois ça peut vite être limite voir dangeureux, j'avais vu passer une commande je sais plus où d'un chown récursif de fichiers php avec comme référence un autre dossier... ça fait peur...
 

Bon au final je suis pas plus avancé, mais merci quand même à vous les gars  

@Eolia @doekia merci des infos, si l'implémentation memcache sur Presta est foireuse là c'est dommage, je n'ai pas de visu Presta là dessus mais selon vous il faut le désactiver c'est noté.

Déso je sors du sujet mais

8 hours ago, Eolia said:

Quel plaisir à lire quand un pro énonce clairement ce que personne ne comprend  

Un professionnel Prestashop sans aucun doute, moins système (aucune critique, chacun son métier, j'ai juste l'impression que @doekia me prend pour un jambon et j'aime pas trop ça ), un peu de clarification fera du bien.

Pour info c'est en prod et rôdé (bientôt 4 ans). L'optimisation globale et le tuning a pris quelques semaines à l'époque avant d'arriver à un truc au poil. L'infrastructure est up to date, automatisé, fiable, viable, exploitable, maintenable.

@doekia déjà ton workflow et ton analyse de la stack technique est foireuse : NON et NON, ni Cloudflare ni Pagespeed ne sont là pour faire un « snapshot » de la page, le premier optimise les assets, le second distribue de manière géographique, le reste est délivré par le serveur applicatif à travers Nginx. Le tout est délivré à l'end user par Clouflare.

8 hours ago, doekia said:

L'erreur a mon avis c'est de faire des benchmark non représentatif quand on parle de l'utilité des caches autre que 1er niveau (smarty). [...] Ton infra passe son temps à faire des caches pour les invalider. Perdre 50ms en page d’accueil pour gagner 50ms partout ailleurs c'est win/win.

Tu n'as pas du tout compris. Prestashop n'est qu'un composant applicatif qui s'inscrit dans un système plus global, Nginx/Pagespeed/Cloudflare ne font pas parti de l'applicatif cœur Prestashop. Je n'ai pas le temps d'expliquer deep dive le fonctionnement Pagespeed/Nginx/Cloudflare, mais tout est indépendant par rapport à Presta, ce ne sont pas des couches qui se superposent et se mélangent (memcache compris, du offload en RAM des query DB/call api/rendering, si c'est bien implémenté ça n'overlap pas avec le cache presta), ce sont des composants qui travaillent ensemble de manière autonome.

Chaque brique a sa propre fonction, c'est géré et tuné proprement en conséquence. Sans cette stack technique bien spécifique les performances sont ce que je considère comme très moyenne. Des tests de performances ça a été fait, correctement et violemment. La différence est juste énorme avec du Presta vanilla, que ce soit en terme de capa ou de temps de réponse.

8 hours ago, doekia said:

Heu, il y a le bouton gomme (effacer le cache) pour régler ce problème et qui normalement n'arrive jamais en réglage (recompiler si besoin)

Je parle d'une modification de template. Faut bien recompiler si un template est modifié ? Si cliquer sur "vider le cache" ça recompile les templates c'est un problème d'UI alors.

8 hours ago, doekia said:

Dernier client que j'ai transféré, de son VPS perf, il avait 1.4s de TTFB, transféré on est passé à 850ms, j'ai éliminé tout ses caches (en plus il avait un module dit "de cache") on est maintenant entre 350 à 480ms sur toutes les pages. Les stats de la search console ne font plus de dents de scie, nous sommes passé de 50 visites simultanées aux heures de pointes à 70.

Concernant le TTFB c'est intéressant que tu en parles vu que ça n'a aucune valeur représentative niveau optimisation (il y a des enjeux de SEO si c'est trop haut).

Le TTFB c'est le premier byte que va recevoir ton client. Mais lui s'en fous du header HTTP, il veut voir sa page. Donc l'important c'est quand démarre le rendering. Cloudflare a sorti un très bon article là dessus : https://blog.cloudflare.com/ttfb-time-to-first-byte-considered-meaningles/

Use case ultra classique TTFB sans/avec gzip :

                          |  TTFB   |  Page loaded
------------------------- | ------- | -------------
No compression (gzip off) | 213us   | 43ms
Compressed (gzip on)      | 1.7ms   | 8ms

Donc oui logique t'enlève du processing ton TTFB drop. Une archi propre, TTFB plus élevé ça explosera quand même les perfs de ton site avec juste le cache smarty à 350ms et la page sera rendue avant, à coup sûr. Pour moi l'optimisation Prestashop native n'est pas assez poussée. Rentre en compte taille totale de la page, temps global de chargement, etc. Pagespeed correctement implémenté aide en partie à palier à ce souci. 

Dernier point :

8 hours ago, doekia said:

Déja php7.2, puis nginx, puis pagespeed, puis cloudflare, ... puis là tu viens de rajouter memcache

Ça sous entend quoi ? Si tu parles de comptabilité 7.2 c'est sensé l'être ? (hors partie memcache). Si c'est niveau web server... apache et ses magnifiques .htaccess process à chaque fois, voir dans chaque sous dossier même si non présent, son modèle pre-fork worker child... je rentrerais pas dans ce débat ^^

Enfin bref, faut faire attention à ce qui est dit hors fonctionnement purement applicatif Prestashop quand le sujet n'est pas maîtrisée des fois ça peut vite être limite voir dangeureux, j'avais vu passer une commande je sais plus où d'un chown récursif de fichiers php avec comme référence un autre dossier... ça fait peur...
 

Bon au final je suis pas plus avancé, mais merci quand même à vous les gars  

@Eolia @doekia merci des infos, si l'implémentation memcache sur Presta est foireuse là c'est dommage, je n'ai pas de visu Presta là dessus mais selon vous il faut le désactiver c'est noté.

Déso je sors du sujet mais

8 hours ago, Eolia said:

Quel plaisir à lire quand un pro énonce clairement ce que personne ne comprend  

Un professionnel Prestashop sans aucun doute, pas un professionnel système (aucune critique, chacun son métier, j'ai juste l'impression que @doekia me prend pour un jambon et j'aime pas trop ça ), un peu de clarification fera du bien.

Pour info c'est en prod et rôdé (bientôt 4 ans). L'optimisation globale et le tuning a pris quelques semaines à l'époque avant d'arriver à un truc au poil. L'infrastructure est up to date, automatisé, fiable, viable, exploitable, maintenable.

@doekia déjà ton workflow et ton analyse de la stack technique est foireuse : NON et NON, ni Cloudflare ni Pagespeed ne sont là pour faire un « snapshot » de la page, le premier optimise les assets, le second distribue de manière géographique, le reste est délivré par le serveur applicatif à travers Nginx. Le tout est délivré à l'end user par Clouflare.

8 hours ago, doekia said:

L'erreur a mon avis c'est de faire des benchmark non représentatif quand on parle de l'utilité des caches autre que 1er niveau (smarty). [...] Ton infra passe son temps à faire des caches pour les invalider. Perdre 50ms en page d’accueil pour gagner 50ms partout ailleurs c'est win/win.

Tu n'as pas du tout compris. Prestashop n'est qu'un composant applicatif qui s'inscrit dans un système plus global, Nginx/Pagespeed/Cloudflare ne font pas parti de l'applicatif cœur Prestashop. Je n'ai pas le temps d'expliquer deep dive le fonctionnement Pagespeed/Nginx/Cloudflare, mais tout est indépendant par rapport à Presta, ce ne sont pas des couches qui se superposent et se mélangent (memcache compris, du offload en RAM des query DB/call api/rendering, si c'est bien implémenté ça n'overlap pas avec le cache presta), ce sont des composants qui travaillent ensemble de manière autonome.

Chaque brique a sa propre fonction, c'est géré et tuné proprement en conséquence. Sans cette stack technique bien spécifique les performances sont ce que je considère comme très moyenne. Des tests de performances ça a été fait, correctement et violemment. La différence est juste énorme avec du Presta vanilla, que ce soit en terme de capa ou de temps de réponse.

8 hours ago, doekia said:

Heu, il y a le bouton gomme (effacer le cache) pour régler ce problème et qui normalement n'arrive jamais en réglage (recompiler si besoin)

Je parle d'une modification de template. Faut bien recompiler si un template est modifié ? Si cliquer sur "vider le cache" ça recompile les templates c'est un problème d'UI alors.

8 hours ago, doekia said:

Dernier client que j'ai transféré, de son VPS perf, il avait 1.4s de TTFB, transféré on est passé à 850ms, j'ai éliminé tout ses caches (en plus il avait un module dit "de cache") on est maintenant entre 350 à 480ms sur toutes les pages. Les stats de la search console ne font plus de dents de scie, nous sommes passé de 50 visites simultanées aux heures de pointes à 70.

Concernant le TTFB c'est intéressant que tu en parles vu que ça n'a aucune valeur représentative niveau optimisation (il y a des enjeux de SEO si c'est trop haut).

Le TTFB c'est le premier byte que va recevoir ton client. Mais lui s'en fous du header HTTP, il veut voir sa page. Donc l'important c'est quand démarre le rendering. Cloudflare a sorti un très bon article là dessus : https://blog.cloudflare.com/ttfb-time-to-first-byte-considered-meaningles/

Use case ultra classique TTFB sans/avec gzip :

                          |  TTFB   |  Page loaded
------------------------- | ------- | -------------
No compression (gzip off) | 213us   | 43ms
Compressed (gzip on)      | 1.7ms   | 8ms

Donc oui logique t'enlève du processing ton TTFB drop. Une archi propre, TTFB plus élevé ça explosera quand même les perfs de ton site avec juste le cache smarty à 350ms et la page sera rendue avant, à coup sûr. Pour moi l'optimisation Prestashop native n'est pas assez poussée. Rentre en compte taille totale de la page, temps global de chargement, etc. Pagespeed correctement implémenté aide en partie à palier à ce souci. 

Dernier point :

8 hours ago, doekia said:

Déja php7.2, puis nginx, puis pagespeed, puis cloudflare, ... puis là tu viens de rajouter memcache

Ça sous entend quoi ? Si tu parles de comptabilité 7.2 c'est sensé l'être ? (hors partie memcache). Si c'est niveau web server... apache et ses magnifiques .htaccess process à chaque fois, voir dans chaque sous dossier même si non présent, son modèle pre-fork worker child... je rentrerais pas dans ce débat ^^

Enfin bref, faut faire attention à ce qui est dit hors fonctionnement purement applicatif Prestashop quand le sujet n'est pas maîtrisée des fois ça peut vite être limite voir dangeureux, j'avais vu passer une commande je sais plus où d'un chown récursif de fichiers php avec comme référence un autre dossier... ça fait peur...
 

Bon au final je suis pas plus avancé, mais merci quand même à vous les gars  

@Eolia @doekia merci des infos, si l'implémentation memcache sur Presta est foireuse là c'est dommage, je n'ai pas de visu Presta là dessus mais selon vous il faut le désactiver c'est noté.

Déso je sors du sujet mais

8 hours ago, Eolia said:

Quel plaisir à lire quand un pro énonce clairement ce que personne ne comprend  

Un professionnel Prestashop sans aucun doute. Mais c'est différent d'un professionnel infrastructure (aucune critique, chacun son métier, j'ai juste l'impression que @doekia me prend pour un jambon et j'aime pas trop ça ), un peu de clarification fera du bien.

Pour info c'est en prod et rôdé (bientôt 4 ans). L'optimisation globale et le tuning a pris quelques semaines à l'époque avant d'arriver à un truc au poil. L'infrastructure est up to date, automatisé, fiable, viable, exploitable, maintenable.

@doekia déjà ton workflow et ton analyse de la stack technique est foireuse : NON et NON, ni Cloudflare ni Pagespeed ne sont là pour faire un « snapshot » de la page, le premier optimise les assets, le second distribue de manière géographique, le reste est délivré par le serveur applicatif à travers Nginx. Le tout est délivré à l'end user par Clouflare.

8 hours ago, doekia said:

L'erreur a mon avis c'est de faire des benchmark non représentatif quand on parle de l'utilité des caches autre que 1er niveau (smarty). [...] Ton infra passe son temps à faire des caches pour les invalider. Perdre 50ms en page d’accueil pour gagner 50ms partout ailleurs c'est win/win.

Tu n'as pas du tout compris. Prestashop n'est qu'un composant applicatif qui s'inscrit dans un système plus global, Nginx/Pagespeed/Cloudflare ne font pas parti de l'applicatif cœur Prestashop. Je n'ai pas le temps d'expliquer deep dive le fonctionnement Pagespeed/Nginx/Cloudflare, mais tout est indépendant par rapport à Presta, ce ne sont pas des couches qui se superposent et se mélangent (memcache compris, du offload en RAM des query DB/call api/rendering, si c'est bien implémenté ça n'overlap pas avec le cache presta), ce sont des composants qui travaillent ensemble de manière autonome.

Chaque brique a sa propre fonction, c'est géré et tuné proprement en conséquence. Sans cette stack technique bien spécifique les performances sont ce que je considère comme très moyenne. Des tests de performances ça a été fait, correctement et violemment. La différence est juste énorme avec du Presta vanilla, que ce soit en terme de capa ou de temps de réponse.

8 hours ago, doekia said:

Heu, il y a le bouton gomme (effacer le cache) pour régler ce problème et qui normalement n'arrive jamais en réglage (recompiler si besoin)

Je parle d'une modification de template. Faut bien recompiler si un template est modifié ? Si cliquer sur "vider le cache" ça recompile les templates c'est un problème d'UI alors.

8 hours ago, doekia said:

Dernier client que j'ai transféré, de son VPS perf, il avait 1.4s de TTFB, transféré on est passé à 850ms, j'ai éliminé tout ses caches (en plus il avait un module dit "de cache") on est maintenant entre 350 à 480ms sur toutes les pages. Les stats de la search console ne font plus de dents de scie, nous sommes passé de 50 visites simultanées aux heures de pointes à 70.

Concernant le TTFB c'est intéressant que tu en parles vu que ça n'a aucune valeur représentative niveau optimisation (il y a des enjeux de SEO si c'est trop haut).

Le TTFB c'est le premier byte que va recevoir ton client. Mais lui s'en fous du header HTTP, il veut voir sa page. Donc l'important c'est quand démarre le rendering. Cloudflare a sorti un très bon article là dessus : https://blog.cloudflare.com/ttfb-time-to-first-byte-considered-meaningles/

Use case ultra classique TTFB sans/avec gzip :

                          |  TTFB   |  Page loaded
------------------------- | ------- | -------------
No compression (gzip off) | 213us   | 43ms
Compressed (gzip on)      | 1.7ms   | 8ms

Donc oui logique t'enlève du processing ton TTFB drop. Une archi propre, TTFB plus élevé ça explosera quand même les perfs de ton site avec juste le cache smarty à 350ms et la page sera rendue avant, à coup sûr. Pour moi l'optimisation Prestashop native n'est pas assez poussée. Rentre en compte taille totale de la page, temps global de chargement, etc. Pagespeed correctement implémenté aide en partie à palier à ce souci. 

Dernier point :

8 hours ago, doekia said:

Déja php7.2, puis nginx, puis pagespeed, puis cloudflare, ... puis là tu viens de rajouter memcache

Ça sous entend quoi ? Si tu parles de comptabilité 7.2 c'est sensé l'être ? (hors partie memcache). Si c'est niveau web server... apache et ses magnifiques .htaccess process à chaque fois, voir dans chaque sous dossier même si non présent, son modèle pre-fork worker child... je rentrerais pas dans ce débat ^^

Enfin bref, faut faire attention à ce qui est dit hors fonctionnement purement applicatif Prestashop quand le sujet n'est pas maîtrisée des fois ça peut vite être limite voir dangeureux, j'avais vu passer une commande je sais plus où d'un chown récursif de fichiers php avec comme référence un autre dossier... ça fait peur...
 

Bon au final je suis pas plus avancé, mais merci quand même à vous les gars  

@Eolia @doekia merci des infos, si l'implémentation memcache sur Presta est foireuse là c'est dommage, je n'ai pas de visu Presta là dessus mais selon vous il faut le désactiver c'est noté.

Déso je sors du sujet mais

8 hours ago, Eolia said:

Quel plaisir à lire quand un pro énonce clairement ce que personne ne comprend  

Un professionnel Prestashop sans aucun doute. Mais c'est différent d'un professionnel infrastructure (aucune critique, chacun son métier, j'ai juste l'impression que @doekia me prend pour un jambon et j'aime pas trop ça ), un peu de clarification fera du bien.

Pour info c'est en prod et rôdé (bientôt 4 ans). L'optimisation globale et le tuning a pris quelques semaines à l'époque avant d'arriver à un truc au poil. L'infrastructure est up to date, automatisé, fiable, viable, exploitable, maintenable.

@doekia déjà ton workflow et ton analyse de la stack technique est foireuse : NON et NON, ni Cloudflare ni Pagespeed ne sont là pour faire un « snapshot » de la page, le premier optimise les assets, le second distribue de manière géographique, le reste est délivré par le serveur applicatif à travers Nginx. Le tout est délivré à l'end user par Clouflare.

8 hours ago, doekia said:

L'erreur a mon avis c'est de faire des benchmark non représentatif quand on parle de l'utilité des caches autre que 1er niveau (smarty). [...] Ton infra passe son temps à faire des caches pour les invalider. Perdre 50ms en page d’accueil pour gagner 50ms partout ailleurs c'est win/win.

Tu n'as pas du tout compris. Prestashop n'est qu'un composant applicatif qui s'inscrit dans un système plus global, Nginx/Pagespeed/Cloudflare ne font pas parti de l'applicatif cœur Prestashop. Je n'ai pas le temps d'expliquer deep dive le fonctionnement Pagespeed/Nginx/Cloudflare, mais tout est indépendant par rapport à Presta, ce ne sont pas des couches qui se superposent et se mélangent (memcache compris, du offload en RAM des query DB/call api/rendering, si c'est bien implémenté ça n'overlap pas avec le cache presta), ce sont des composants qui travaillent ensemble de manière autonome.

Chaque brique a sa propre fonction, c'est géré et tuné proprement en conséquence. Sans cette stack technique bien spécifique les performances sont ce que je considère comme très moyenne. Des tests de performances ça a été fait, correctement et violemment. La différence est juste énorme avec du Presta vanilla, que ce soit en terme de capa ou de temps de réponse.

8 hours ago, doekia said:

Heu, il y a le bouton gomme (effacer le cache) pour régler ce problème et qui normalement n'arrive jamais en réglage (recompiler si besoin)

Je parle d'une modification de template. Faut bien recompiler si un template est modifié ? Si cliquer sur "vider le cache" ça recompile les templates c'est un problème d'UI alors.

8 hours ago, doekia said:

Dernier client que j'ai transféré, de son VPS perf, il avait 1.4s de TTFB, transféré on est passé à 850ms, j'ai éliminé tout ses caches (en plus il avait un module dit "de cache") on est maintenant entre 350 à 480ms sur toutes les pages. Les stats de la search console ne font plus de dents de scie, nous sommes passé de 50 visites simultanées aux heures de pointes à 70.

Concernant le TTFB c'est intéressant que tu en parles vu que ça n'a aucune valeur représentative niveau optimisation (il y a des enjeux de SEO si c'est trop haut).

Le TTFB c'est le premier byte que va recevoir ton client. Mais lui s'en fous du header HTTP, il veut voir sa page. Donc l'important c'est quand démarre le rendering. Cloudflare a sorti un très bon article là dessus : https://blog.cloudflare.com/ttfb-time-to-first-byte-considered-meaningles/

Use case ultra classique TTFB sans/avec gzip :

                          |  TTFB   |  Page loaded
------------------------- | ------- | -------------
No compression (gzip off) | 213us   | 43ms
Compressed (gzip on)      | 1.7ms   | 8ms

Donc oui logique t'enlève du processing ton TTFB drop. Une archi propre, TTFB plus élevé ça explosera quand même les perfs de ton site avec juste le cache smarty à 350ms et la page sera rendue avant, à coup sûr. Pour moi l'optimisation Prestashop native n'est pas assez poussée. Rentre en compte taille totale de la page, temps global de chargement, etc. Pagespeed correctement implémenté aide en partie à palier à ce souci. 

Dernier point :

8 hours ago, doekia said:

Déja php7.2, puis nginx, puis pagespeed, puis cloudflare, ... puis là tu viens de rajouter memcache

Ça sous entend quoi ? Si tu parles de comptabilité 7.2 c'est sensé l'être ? (hors partie memcache). Si c'est niveau web server... apache et ses magnifiques .htaccess son modèle pre-fork worker child... je rentrerais pas dans ce débat.

Enfin bref, faut faire attention à ce qui est dit hors fonctionnement purement applicatif Prestashop quand le sujet n'est pas maîtrisée des fois ça peut vite être limite voir dangeureux, j'avais vu passer une commande je sais plus où d'un chown récursif de fichiers php avec comme référence un autre dossier... ça fait peur...
 

Bon au final je suis pas plus avancé, mais merci quand même à vous les gars  

@Eolia @doekia merci des infos, si l'implémentation memcache sur Presta est foireuse là c'est dommage, je n'ai pas de visu Presta là dessus mais selon vous il faut le désactiver c'est noté.

Déso je sors du sujet mais

8 hours ago, Eolia said:

Quel plaisir à lire quand un pro énonce clairement ce que personne ne comprend  

Un professionnel Prestashop sans aucun doute. Mais c'est différent d'un professionnel infrastructure (aucune critique, chacun son métier, j'ai juste l'impression que @doekia me prend pour un jambon et j'aime pas trop ça ), un peu de clarification fera du bien.

Pour info c'est en prod et rôdé (bientôt 4 ans). L'optimisation globale et le tuning a pris quelques semaines à l'époque avant d'arriver à un truc au poil. L'infrastructure est up to date, automatisé, fiable, viable, exploitable, maintenable.

@doekia déjà ton workflow et ton analyse de la stack technique est foireuse : NON et NON, ni Cloudflare ni Pagespeed ne sont là pour faire un « snapshot » de la page, le premier optimise les assets, le second distribue de manière géographique, le reste est délivré par le serveur applicatif à travers Nginx. Le tout est délivré à l'end user par Clouflare.

8 hours ago, doekia said:

L'erreur a mon avis c'est de faire des benchmark non représentatif quand on parle de l'utilité des caches autre que 1er niveau (smarty). [...] Ton infra passe son temps à faire des caches pour les invalider. Perdre 50ms en page d’accueil pour gagner 50ms partout ailleurs c'est win/win.

Tu n'as pas du tout compris. Prestashop n'est qu'un composant applicatif qui s'inscrit dans un système plus global, Nginx/Pagespeed/Cloudflare ne font pas parti de l'applicatif cœur Prestashop. Je n'ai pas le temps d'expliquer deep dive le fonctionnement Pagespeed/Nginx/Cloudflare, mais tout est indépendant par rapport à Presta, ce ne sont pas des couches qui se superposent et se mélangent (memcache compris, du offload en RAM des query DB/call api/rendering, si c'est bien implémenté ça n'overlap pas avec le cache presta), ce sont des composants qui travaillent ensemble de manière autonome.

Chaque brique a sa propre fonction, c'est géré et tuné proprement en conséquence. Sans cette stack technique bien spécifique les performances sont ce que je considère comme très moyenne. Des tests de performances ça a été fait, correctement et violemment. La différence est juste énorme avec du Presta vanilla, que ce soit en terme de capa ou de temps de réponse.

8 hours ago, doekia said:

Heu, il y a le bouton gomme (effacer le cache) pour régler ce problème et qui normalement n'arrive jamais en réglage (recompiler si besoin)

Je parle d'une modification de template. Faut bien recompiler si un template est modifié ? Si cliquer sur "vider le cache" ça recompile les templates c'est un problème d'UI alors.

8 hours ago, doekia said:

Dernier client que j'ai transféré, de son VPS perf, il avait 1.4s de TTFB, transféré on est passé à 850ms, j'ai éliminé tout ses caches (en plus il avait un module dit "de cache") on est maintenant entre 350 à 480ms sur toutes les pages. Les stats de la search console ne font plus de dents de scie, nous sommes passé de 50 visites simultanées aux heures de pointes à 70.

Concernant le TTFB c'est intéressant que tu en parles vu que ça n'a aucune valeur représentative niveau optimisation (il y a des enjeux de SEO si c'est trop haut).

Le TTFB c'est le premier byte que va recevoir ton client. Mais lui s'en fous du header HTTP, il veut voir sa page. Donc l'important c'est quand démarre le rendering. Cloudflare a sorti un très bon article là dessus : https://blog.cloudflare.com/ttfb-time-to-first-byte-considered-meaningles/

Use case ultra classique TTFB sans/avec gzip :

                          |  TTFB   |  Page loaded
------------------------- | ------- | -------------
No compression (gzip off) | 213us   | 43ms
Compressed (gzip on)      | 1.7ms   | 8ms

Donc oui logique t'enlève du processing ton TTFB drop. Une archi propre, TTFB plus élevé ça explosera quand même les perfs de ton site avec juste le cache smarty à 350ms et la page sera rendue avant, à coup sûr. Pour moi l'optimisation Prestashop native n'est pas assez poussée. Rentre en compte taille totale de la page, temps global de chargement, etc. Pagespeed correctement implémenté aide en partie à palier à ce souci. 

Dernier point :

8 hours ago, doekia said:

Déja php7.2, puis nginx, puis pagespeed, puis cloudflare, ... puis là tu viens de rajouter memcache

Ça sous entend quoi ? Si tu parles de comptabilité 7.2 c'est sensé l'être ? (hors partie memcache)

Enfin bref, faut faire attention à ce qui est dit hors fonctionnement purement applicatif Prestashop quand le sujet n'est pas maîtrisée des fois ça peut vite être limite voir dangeureux, j'avais vu passer une commande je sais plus où d'un chown récursif de fichiers php avec comme référence un autre dossier... ça fait peur...
 

Bon au final je suis pas plus avancé, mais merci quand même à vous les gars  

@Eolia @doekia merci des infos, si l'implémentation memcache sur Presta est foireuse là c'est dommage, je n'ai pas de visu Presta là dessus mais selon vous il faut le désactiver c'est noté.

Déso je sors du sujet mais

8 hours ago, Eolia said:

Quel plaisir à lire quand un pro énonce clairement ce que personne ne comprend  

Un professionnel Prestashop sans aucun doute. Mais c'est différent d'un professionnel infrastructure (aucune critique, chacun son métier, j'ai juste l'impression que @doekia me prend pour un jambon et j'aime pas trop ça ), un peu de clarification fera du bien.

Pour info c'est en prod et rôdé (bientôt 4 ans). L'optimisation globale et le tuning a pris quelques semaines à l'époque avant d'arriver à un truc au poil. L'infrastructure est up to date, automatisé, fiable, viable, exploitable, maintenable.

@doekia déjà ton workflow et ton analyse de la stack technique est foireuse : NON et NON, ni Cloudflare ni Pagespeed ne sont là pour faire un « snapshot » de la page, le premier optimise les assets, le second distribue de manière géographique, le reste est délivré par le serveur applicatif à travers Nginx. Le tout est délivré à l'end user par Clouflare.

8 hours ago, doekia said:

L'erreur a mon avis c'est de faire des benchmark non représentatif quand on parle de l'utilité des caches autre que 1er niveau (smarty). [...] Ton infra passe son temps à faire des caches pour les invalider. Perdre 50ms en page d’accueil pour gagner 50ms partout ailleurs c'est win/win.

Tu n'as pas du tout compris. Prestashop n'est qu'un composant applicatif qui s'inscrit dans un système plus global, Nginx/Pagespeed/Cloudflare ne font pas parti de l'applicatif cœur Prestashop. Je n'ai pas le temps d'expliquer deep dive le fonctionnement Pagespeed/Nginx/Cloudflare, mais tout est indépendant par rapport à Presta, ce ne sont pas des couches qui se superposent et se mélangent (memcache compris, du offload en RAM des query DB/call api/rendering), ce sont des composants qui travaillent ensemble de manière autonome.

Chaque brique a sa propre fonction, c'est géré et tuné proprement en conséquence. Sans cette stack technique bien spécifique les performances sont ce que je considère comme très moyenne. Des tests de performances ça a été fait, correctement et violemment. La différence est juste énorme avec du Presta vanilla, que ce soit en terme de capa ou de temps de réponse.

8 hours ago, doekia said:

Heu, il y a le bouton gomme (effacer le cache) pour régler ce problème et qui normalement n'arrive jamais en réglage (recompiler si besoin)

Je parle d'une modification de template. Faut bien recompiler si un template est modifié ? Si cliquer sur "vider le cache" ça recompile les templates c'est un problème d'UI alors.

8 hours ago, doekia said:

Dernier client que j'ai transféré, de son VPS perf, il avait 1.4s de TTFB, transféré on est passé à 850ms, j'ai éliminé tout ses caches (en plus il avait un module dit "de cache") on est maintenant entre 350 à 480ms sur toutes les pages. Les stats de la search console ne font plus de dents de scie, nous sommes passé de 50 visites simultanées aux heures de pointes à 70.

Concernant le TTFB c'est intéressant que tu en parles vu que ça n'a aucune valeur représentative niveau optimisation (il y a des enjeux de SEO si c'est trop haut).

Le TTFB c'est le premier byte que va recevoir ton client. Mais lui s'en fous du header HTTP, il veut voir sa page. Donc l'important c'est quand démarre le rendering. Cloudflare a sorti un très bon article là dessus : https://blog.cloudflare.com/ttfb-time-to-first-byte-considered-meaningles/

Use case ultra classique TTFB sans/avec gzip :

                          |  TTFB   |  Page loaded
------------------------- | ------- | -------------
No compression (gzip off) | 213us   | 43ms
Compressed (gzip on)      | 1.7ms   | 8ms

Donc oui logique t'enlève du processing ton TTFB drop. Une archi propre, TTFB plus élevé ça explosera quand même les perfs de ton site avec juste le cache smarty à 350ms et la page sera rendue avant, à coup sûr. Pour moi l'optimisation Prestashop native n'est pas assez poussée. Rentre en compte taille totale de la page, temps global de chargement, etc. Pagespeed correctement implémenté aide en partie à palier à ce souci. 

Dernier point :

8 hours ago, doekia said:

Déja php7.2, puis nginx, puis pagespeed, puis cloudflare, ... puis là tu viens de rajouter memcache

Ça sous entend quoi ? Si tu parles de comptabilité 7.2 c'est sensé l'être ? (hors partie memcache)

Enfin bref, faut faire attention à ce qui est dit hors fonctionnement purement applicatif Prestashop quand le sujet n'est pas maîtrisée des fois ça peut vite être limite voir dangeureux, j'avais vu passer une commande je sais plus où d'un chown récursif de fichiers php avec comme référence un autre dossier... ça fait peur...
 

Bon au final je suis pas plus avancé, mais merci quand même à vous les gars  

@Eolia @doekia merci des infos, si l'implémentation memcache sur Presta est foireuse là c'est dommage, en tant que tel c'est du offload en RAM des query DB (session php, call API), je n'ai pas de visu Presta mais selon vous il faut le désactiver c'est noté.

Déso je sors du sujet mais

8 hours ago, Eolia said:

Quel plaisir à lire quand un pro énonce clairement ce que personne ne comprend  

Un professionnel Prestashop sans aucun doute. Mais c'est différent d'un professionnel infrastructure (aucune critique, chacun son métier, j'ai juste l'impression que @doekia me prend pour un jambon et j'aime pas trop ça ), un peu de clarification fera du bien.

Pour info c'est en prod et rôdé (bientôt 4 ans). L'optimisation globale et le tuning a pris quelques semaines à l'époque avant d'arriver à un truc au poil. L'infrastructure est up to date, automatisé, fiable, viable, exploitable, maintenable.

@doekia déjà ton workflow et ton analyse de la stack technique est foireuse : NON et NON, ni Cloudflare ni Pagespeed ne sont là pour faire un « snapshot » de la page, le premier optimise les assets, le second distribue de manière géographique, le reste est délivré par le serveur applicatif à travers Nginx. Le tout est délivré à l'end user par Clouflare.

8 hours ago, doekia said:

L'erreur a mon avis c'est de faire des benchmark non représentatif quand on parle de l'utilité des caches autre que 1er niveau (smarty). [...] Ton infra passe son temps à faire des caches pour les invalider. Perdre 50ms en page d’accueil pour gagner 50ms partout ailleurs c'est win/win.

Tu n'as pas du tout compris. Prestashop n'est qu'un composant applicatif qui s'inscrit dans un système plus global, Nginx/Pagespeed/Cloudflare ne font pas parti de l'applicatif cœur Prestashop. Je n'ai pas le temps d'expliquer deep dive le fonctionnement Pagespeed/Nginx/Cloudflare, mais tout est indépendant par rapport à Presta, ce ne sont pas des couches qui se superposent et se mélangent, ce sont des composants qui travaillent ensemble de manière autonome.

Chaque brique a sa propre fonction, c'est géré et tuné proprement en conséquence. Sans cette stack technique bien spécifique les performances sont ce que je considère comme très moyenne. Des tests de performances ça a été fait, correctement et violemment. La différence est juste énorme avec du Presta vanilla, que ce soit en terme de capa ou de temps de réponse.

8 hours ago, doekia said:

Heu, il y a le bouton gomme (effacer le cache) pour régler ce problème et qui normalement n'arrive jamais en réglage (recompiler si besoin)

Je parle d'une modification de template. Faut bien recompiler si un template est modifié ? Si cliquer sur "vider le cache" ça recompile les templates c'est un problème d'UI alors.

8 hours ago, doekia said:

Dernier client que j'ai transféré, de son VPS perf, il avait 1.4s de TTFB, transféré on est passé à 850ms, j'ai éliminé tout ses caches (en plus il avait un module dit "de cache") on est maintenant entre 350 à 480ms sur toutes les pages. Les stats de la search console ne font plus de dents de scie, nous sommes passé de 50 visites simultanées aux heures de pointes à 70.

Concernant le TTFB c'est intéressant que tu en parles vu que ça n'a aucune valeur représentative niveau optimisation (il y a des enjeux de SEO si c'est trop haut).

Le TTFB c'est le premier byte que va recevoir ton client. Mais lui s'en fous du header HTTP, il veut voir sa page. Donc l'important c'est quand démarre le rendering. Cloudflare a sorti un très bon article là dessus : https://blog.cloudflare.com/ttfb-time-to-first-byte-considered-meaningles/

Use case ultra classique TTFB sans/avec gzip :

                          |  TTFB   |  Page loaded
------------------------- | ------- | -------------
No compression (gzip off) | 213us   | 43ms
Compressed (gzip on)      | 1.7ms   | 8ms

Donc oui logique t'enlève du processing ton TTFB drop. Une archi propre, TTFB plus élevé ça explosera quand même les perfs de ton site avec juste le cache smarty à 350ms et la page sera rendue avant, à coup sûr. Pour moi l'optimisation Prestashop native n'est pas assez poussée. Rentre en compte taille totale de la page, temps global de chargement, etc. Pagespeed correctement implémenté aide en partie à palier à ce souci. 

Dernier point :

8 hours ago, doekia said:

Déja php7.2, puis nginx, puis pagespeed, puis cloudflare, ... puis là tu viens de rajouter memcache

Ça sous entend quoi ? Si tu parles de comptabilité 7.2 c'est sensé l'être ? (hors partie memcache)

Enfin bref, faut faire attention à ce qui est dit hors fonctionnement purement applicatif Prestashop quand le sujet n'est pas maîtrisée des fois ça peut vite être limite voir dangeureux, j'avais vu passer une commande je sais plus où d'un chown récursif de fichiers php avec comme référence un autre dossier... ça fait peur...
 

Bon au final je suis pas plus avancé, mais merci quand même à vous les gars  

@Eolia @doekia merci des infos, si l'implémentation memcache sur Presta est foireuse là c'est dommage, en tant que tel c'est du offload en RAM des query DB (session php, call API), je n'ai pas de visu Presta mais selon vous il faut le désactiver c'est noté.

Déso je sors du sujet mais

8 hours ago, Eolia said:

Quel plaisir à lire quand un pro énonce clairement ce que personne ne comprend  

Un professionnel Prestashop sans aucun doute. Mais c'est différent d'un professionnel infrastructure (aucune critique, chacun son métier, j'ai juste l'impression que @doekia me prend pour un jambon et j'aime pas trop ça ), un peu de clarification fera du bien.

Pour info c'est en prod et rôdé (bientôt 4 ans). L'optimisation globale et le tuning a pris quelques semaines à l'époque avant d'arriver à un truc au poil. L'infrastructure est up to date, automatisé, fiable, viable, exploitable, maintenable.

@doekia déjà ton workflow et ton analyse de la stack technique est foireuse : NON et NON, ni Cloudflare ni Pagespeed ne sont là pour faire un « snapshot » de la page, le premier optimise les assets, le second distribue de manière géographique, le reste est délivré par le serveur applicatif (à travers Cloudflare mais par le serveur)...

8 hours ago, doekia said:

L'erreur a mon avis c'est de faire des benchmark non représentatif quand on parle de l'utilité des caches autre que 1er niveau (smarty). [...] Ton infra passe son temps à faire des caches pour les invalider. Perdre 50ms en page d’accueil pour gagner 50ms partout ailleurs c'est win/win.

Tu n'as pas du tout compris. Prestashop n'est qu'un composant applicatif qui s'inscrit dans un système plus global, Nginx/Pagespeed/Cloudflare ne font pas parti de l'applicatif cœur Prestashop. Je n'ai pas le temps d'expliquer deep dive le fonctionnement Pagespeed/Nginx/Cloudflare, mais tout est indépendant par rapport à Presta, ce ne sont pas des couches qui se superposent et se mélangent, ce sont des composants qui travaillent ensemble de manière autonome.

Chaque brique a sa propre fonction, c'est géré et tuné proprement en conséquence. Sans cette stack technique bien spécifique les performances sont ce que je considère comme très moyenne. Des tests de performances ça a été fait, correctement et violemment. La différence est juste énorme avec du Presta vanilla, que ce soit en terme de capa ou de temps de réponse.

8 hours ago, doekia said:

Heu, il y a le bouton gomme (effacer le cache) pour régler ce problème et qui normalement n'arrive jamais en réglage (recompiler si besoin)

Je parle d'une modification de template. Faut bien recompiler si un template est modifié ? Si cliquer sur "vider le cache" ça recompile les templates c'est un problème d'UI alors.

8 hours ago, doekia said:

Dernier client que j'ai transféré, de son VPS perf, il avait 1.4s de TTFB, transféré on est passé à 850ms, j'ai éliminé tout ses caches (en plus il avait un module dit "de cache") on est maintenant entre 350 à 480ms sur toutes les pages. Les stats de la search console ne font plus de dents de scie, nous sommes passé de 50 visites simultanées aux heures de pointes à 70.

Concernant le TTFB c'est intéressant que tu en parles vu que ça n'a aucune valeur représentative niveau optimisation (il y a des enjeux de SEO si c'est trop haut).

Le TTFB c'est le premier byte que va recevoir ton client. Mais lui s'en fous du header HTTP, il veut voir sa page. Donc l'important c'est quand démarre le rendering. Cloudflare a sorti un très bon article là dessus : https://blog.cloudflare.com/ttfb-time-to-first-byte-considered-meaningles/

Use case ultra classique TTFB sans/avec gzip :

                          |  TTFB   |  Page loaded
------------------------- | ------- | -------------
No compression (gzip off) | 213us   | 43ms
Compressed (gzip on)      | 1.7ms   | 8ms

Donc oui logique t'enlève du processing ton TTFB drop. Une archi propre, TTFB plus élevé ça explosera quand même les perfs de ton site avec juste le cache smarty à 350ms et la page sera rendue avant, à coup sûr. Pour moi l'optimisation Prestashop native n'est pas assez poussée. Rentre en compte taille totale de la page, temps global de chargement, etc. Pagespeed correctement implémenté aide en partie à palier à ce souci. 

Dernier point :

8 hours ago, doekia said:

Déja php7.2, puis nginx, puis pagespeed, puis cloudflare, ... puis là tu viens de rajouter memcache

Ça sous entend quoi ? Si tu parles de comptabilité 7.2 c'est sensé l'être ? (hors partie memcache)

Enfin bref, faut faire attention à ce qui est dit hors fonctionnement purement applicatif Prestashop quand le sujet n'est pas maîtrisée des fois ça peut vite être limite voir dangeureux, j'avais vu passer une commande je sais plus où d'un chown récursif de fichiers php avec comme référence un autre dossier... ça fait peur...
 

Bon au final je suis pas plus avancé, mais merci quand même à vous les gars