Comment on a divisé par 3 le TTFB d'une boutique PrestaShop 8

Boutique PrestaShop 8.1, 50k SKU, ~12k visiteurs/jour. Le marchand nous appelle parce que le TTFB est 1100 ms sur la home et 1400 ms sur les fiches produit. Le SEO chute, les conversions aussi. Voici comment on a réglé ça en 4 jours, et ce que ça nous a appris.

Le diagnostic : d'où vient le temps perdu ?

Premier réflexe : un profilage Xdebug + Webgrind sur une page produit froide. La répartition du temps :

• 620 ms en requêtes SQL (oui, sept cents millisecondes)
• 180 ms en chargement Smarty + compilation tpl
• 140 ms en hooks de modules
• 110 ms en initialisation core (autoload, Doctrine, services)

Le coupable principal était évident. Mais creusons.

SQL : pas le problème qu'on croyait

620 ms de SQL, on imagine de la requête lourde mal indexée. La réalité : 187 requêtes dont 140 en moins de 2 ms. Le problème n'était pas la lenteur unitaire mais le volume — chaque hook de module ajoutait 3-5 requêtes pour vérifier ses paramètres.

Première action : activer Redis pour les sessions PHP et pour le cache PrestaShop. La config dans app/config/parameters.php :

'cache_dir' => '_PS_ROOT_DIR_/var/cache/',
'cache_system' => 'CacheRedis',
'redis_servers' => [
    ['ip' => '/var/run/redis/redis.sock', 'port' => '0', 'auth' => '']
]

Gain immédiat : -220 ms. Les requêtes répétitives de configuration (200+ SELECT FROM ps_configuration) tombent à 0 après le premier hit.

OPcache : le réglage qui change tout

OPcache était activé mais avec opcache.memory_consumption=128M. Sur une boutique avec 30+ modules et un thème custom, on avait 6 % de cache miss en permanence. Passage à 512M et opcache.max_accelerated_files=20000 : cache miss à 0,1 %.

Plus important : on est passé en opcache.validate_timestamps=0 + un script de reload PHP-FPM lors des déploiements. Gain : -90 ms sur le cold start (PHP n'a plus à statter chaque fichier).

LSCache : la couche que tout le monde oublie

L'hébergeur tournait sous OpenLiteSpeed mais le module ps_lscache n'était pas installé. C'est pourtant gratuit et terriblement efficace pour PrestaShop. Installation, configuration des règles d'invalidation (purge sur actionProductUpdate, actionCartSave, etc.) :

• Pages catégorie : cache 24h, purge sur changement produit
• Pages produit : cache 6h, purge ciblée
• CMS : cache 7 jours
• Cart / checkout : pas de cache (vary par session)

Pour un visiteur sur une page cachée, le TTFB tombe à 30-50 ms (LiteSpeed sert directement le HTML statique sans toucher PHP). Pour un visiteur logué ou avec panier, on retombe sur le PHP normal mais déjà optimisé.

MariaDB : le tuning qu'il faut faire

Le serveur tournait en config par défaut Ubuntu. innodb_buffer_pool_size=128M sur une DB de 4 Go, ça ne pouvait pas le faire. Ajustements :

innodb_buffer_pool_size = 6G
innodb_io_capacity = 1000
innodb_flush_log_at_trx_commit = 2
innodb_log_file_size = 512M
query_cache_type = 0  # déprécié en MariaDB 10.6
table_open_cache = 4000

Gain : -80 ms sur le SQL résiduel après Redis.

Le résultat final

Après 4 jours de boulot :

• TTFB home : 1100 ms → 340 ms (-69 %)
• TTFB produit : 1400 ms → 380 ms (-73 %)
• TTFB catégorie cachée LSCache : 45 ms
• LCP : 2.8s → 1.3s (sur Pagespeed Insights mobile)
• Score Lighthouse Performance : 62 → 91

Le SEO a remonté en 6 semaines. Les conversions ont gagné +12 % sur le mois suivant. Coût total de l'intervention : ~5 jours-homme.

Les erreurs à ne pas reproduire

Avant nous, le marchand avait essayé deux "optimisations" qui avaient empiré la situation :

1. Activation du cache Smarty force sans purge correcte → fiches produit qui affichaient des stocks périmés
2. Cloudflare en mode "rocket loader" → cassait l'ajout au panier sur Safari iOS

Optimiser une boutique PrestaShop, c'est pas activer 5 toggles dans un panneau. C'est mesurer, ajuster, re-mesurer.

Si votre TTFB dépasse 600 ms, on peut faire un audit gratuit en 1h. Voir notre offre d'infogérance.