Credit : Logo officiel
PrestaShop : optimiser les performances et le SEO
PrestaShop : optimiser les performances et le SEO
La boutique d'un client, environ 8000 references, tournait sur un VPS IONOS Performance avec PrestaShop 8.1 et PHP 8.2. Temps de chargement mesure : 4,8 secondes sur la home, 6,2 secondes sur une fiche produit. Score Lighthouse : 38/100. Bounce rate sur mobile : 71%. Taux de conversion : 0,8%. Bref, un cas typique.
Apres deux jours d'optimisation methodique (cache Smarty, CCC, Redis, CDN Cloudflare, nettoyage base, balisage Schema), on est arrive a 1,6 secondes sur la home, score Lighthouse 92/100, bounce rate a 47%, et le taux de conversion est passe a 1,9%. Multiplie par le panier moyen, ca a represente plusieurs milliers d'euros de chiffre additionnel par mois. Performance et SEO sont les deux faces d'une meme medaille : Google indexe ce qui est rapide, et les utilisateurs achetent ce qui ne rame pas.
Voici la methodologie complete que j'applique sur toutes les boutiques PrestaShop que je reprends.
Mesurer avant d'optimiser
Optimiser sans mesurer, c'est tirer dans le brouillard. Avant toute modification :
curl -o /dev/null -s -w "DNS: %{time_namelookup}s | TCP: %{time_connect}s | TTFB: %{time_starttransfer}s | Total: %{time_total}s\n" https://monsite.fr/
Outils que j'utilise systematiquement :
- PageSpeed Insights (Google) : metriques Core Web Vitals (LCP, FID, CLS) en conditions reelles.
- GTmetrix : waterfall detaille pour identifier les ressources lentes.
- WebPageTest : multi-localisations, multi-navigateurs.
- Lighthouse CLI :
npx lighthouse https://monsite.fr --output=html --output-path=./report.html. - Chrome DevTools > Performance : profile cote rendu pour identifier le JS coupable.
Et pour la base de donnees :
SELECT table_name AS 'Table',
ROUND((data_length + index_length) / 1024 / 1024, 2) AS 'Size (MB)'
FROM information_schema.tables
WHERE table_schema = 'prestashop'
ORDER BY (data_length + index_length) DESC LIMIT 20;
Note tes valeurs avant, et compare apres chaque etape. Sinon impossible de savoir ce qui marche.
Le cache Smarty et le mode production
Smarty est le moteur de templates de PrestaShop. Sans cache il recompile les templates a chaque requete, ce qui charge inutilement le CPU.
Dans Parametres avances > Performances :
- Mode debug : Non
- Cache de template : Oui
- Type de cache : Compilation au premier appel
- Effacer le cache : Jamais (en production)
- Optimiser Smarty : Oui
Ou directement en SQL :
UPDATE ps_configuration SET value = '0' WHERE name = '_PS_DEBUG_PROFILING_';
UPDATE ps_configuration SET value = '0' WHERE name = '_PS_MODE_DEV_';
UPDATE ps_configuration SET value = '1' WHERE name = 'PS_SMARTY_CACHE';
UPDATE ps_configuration SET value = '1' WHERE name = 'PS_SMARTY_CACHING_TYPE';
UPDATE ps_configuration SET value = '0' WHERE name = 'PS_SMARTY_CLEAR_CACHE';
UPDATE ps_configuration SET value = '1' WHERE name = 'PS_SMARTY_LOCAL';
Verifie aussi que defines.inc.php n'a pas _PS_MODE_DEV_ a true. Plus d'une fois j'ai trouve un site lent juste a cause d'un mode debug oublie en production.
Activer le cache OPcache PHP
Dans /etc/php/8.3/fpm/conf.d/10-opcache.ini :
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0
opcache.revalidate_freq=0
opcache.fast_shutdown=1
opcache.interned_strings_buffer=16
opcache.save_comments=1
validate_timestamps=0 desactive la verification des fichiers a chaque requete : a activer uniquement en prod, et a remettre a 1 quand tu deploies. Sinon les nouvelles versions ne sont pas prises en compte.
systemctl restart php8.3-fpm
CCC : Combiner, Compresser, Cacher
PrestaShop peut fusionner les CSS/JS, les minifier, et compresser le HTML :
Parametres avances > Performances > CCC :
- Minification HTML : Oui
- Minification CSS : Oui
- Minification JavaScript : Oui
- Optimisation Apache : Oui (meme sous Nginx, ca active des entetes utiles)
- Differer le chargement de JavaScript : Oui
Resultat typique : 35 fichiers CSS et 28 JS deviennent 2-3 fichiers consolides. Beaucoup moins de requetes HTTP.
Attention : certains modules (chatbot, tracking, payment) injectent du JS inline ou depuis leur CDN, donc tout n'est pas concentre. Profile dans DevTools pour reperer ce qui passe a cote.
Compression et cache HTTP cote Nginx
Dans le vhost :
server {
gzip on;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript image/svg+xml;
location ~* \.(jpg|jpeg|png|gif|ico|webp|avif|svg|woff|woff2|ttf|eot)$ {
expires 1y;
add_header Cache-Control "public, immutable";
access_log off;
}
location ~* \.(css|js)$ {
expires 30d;
add_header Cache-Control "public";
}
}
Brotli, encore mieux que gzip, necessite nginx-module-brotli (compile a part) mais le gain de 15 a 25% sur le poids transfere vaut le coup pour les gros catalogues.
Cache objet Redis
PrestaShop 8.x supporte Redis nativement comme backend de cache. C'est probablement le gain le plus important a faire sur une boutique a fort trafic.
apt install redis-server php8.3-redis -y
systemctl enable --now redis-server
Dans Parametres avances > Performances > Cache :
- Activer le cache : Oui
- Systeme de cache : Redis
- Serveurs :
127.0.0.1:6379
Verification :
redis-cli -n 1 keys "*PS*" | head
redis-cli info stats | grep -E 'keyspace_hits|keyspace_misses'
Ratio hits/misses superieur a 90% = ca cache bien. En dessous, soit ta config est mauvaise, soit tu purges trop souvent.
Mettre en place un CDN
Un CDN distribue les ressources statiques sur des serveurs proches geographiquement des visiteurs. Pour les boutiques avec une clientele internationale, le gain LCP est significatif.
La solution la plus simple : Cloudflare en free tier devant ton domaine.
Dans PrestaShop, Parametres avances > Performances > Serveurs de media :
Serveur media 1 : cdn1.monsite.fr
Serveur media 2 : cdn2.monsite.fr
Serveur media 3 : cdn3.monsite.fr
PrestaShop repartit les ressources sur ces sous-domaines, ce qui augmente le parallelisme des requetes (limitation par hote des navigateurs). Avec HTTP/2 cet effet est moins crucial qu'avant mais reste utile pour le caching CDN.
Optimisation des images
Les images representent souvent 60 a 80% du poids d'une page boutique. Trois leviers :
WebP/AVIF a la generation
A partir de PrestaShop 8.1, les formats next-gen sont supportes nativement. Active-les dans Conception > Images. Un script de regeneration peut prendre 2 a 3h pour 8000 produits, mais ca vaut le coup.
Compression cote serveur
apt install jpegoptim optipng -y
find /var/www/prestashop/img/p -type f -name '*.jpg' -exec jpegoptim --max=85 --strip-all {} \;
find /var/www/prestashop/img/p -type f -name '*.png' -exec optipng -o2 {} \;
A lancer une fois apres import massif, puis par cron mensuel. Gain typique : 20 a 30% sur le poids des JPEG.
Lazy loading natif
PrestaShop 8.x utilise loading="lazy" automatiquement sur les images en dehors du viewport. Si ce n'est pas le cas dans ton theme custom, ajoute-le dans les overrides Smarty :
<img src="{$image.large.url}" alt="{$image.legend|escape:'html'}" loading="lazy" width="{$image.large.width}" height="{$image.large.height}">
Nettoyer la base de donnees
Apres quelques annees d'exploitation, une base PrestaShop accumule paniers abandonnes, sessions, logs de connexion, statistiques de recherche... J'ai vu des bases passer de 2 Go a 400 Mo apres nettoyage, avec un gain immediat sur les requetes lourdes.
Fais un backup d'abord, vraiment :
mysqldump -u root -p prestashop > /backup/prestashop_avant_clean_$(date +%F).sql
Puis :
DELETE FROM ps_cart
WHERE date_add < DATE_SUB(NOW(), INTERVAL 30 DAY)
AND id_cart NOT IN (SELECT id_cart FROM ps_orders);
DELETE FROM ps_connections WHERE date_add < DATE_SUB(NOW(), INTERVAL 60 DAY);
DELETE FROM ps_connections_page WHERE id_connections NOT IN (SELECT id_connections FROM ps_connections);
DELETE FROM ps_connections_source WHERE id_connections NOT IN (SELECT id_connections FROM ps_connections);
DELETE FROM ps_guest WHERE id_guest NOT IN (SELECT id_guest FROM ps_connections) AND id_guest NOT IN (SELECT id_guest FROM ps_customer);
TRUNCATE TABLE ps_statssearch;
TRUNCATE TABLE ps_pagenotfound;
DELETE FROM ps_log WHERE date_add < DATE_SUB(NOW(), INTERVAL 90 DAY);
Puis optimisation des tables :
mysqlcheck -u root -p --optimize prestashop
Le sitemap XML et le SEO technique
Installe le module officiel Google Sitemap, configure-le pour inclure :
- Pages produits avec leurs declinaisons SEO.
- Categories.
- Pages CMS.
- Marques et fournisseurs.
Exclus :
- Pages de filtres a facettes (URLs duplicates).
- Pagination au-dela de la page 1.
- Pages de comparaison.
Cron de regeneration :
crontab -e
0 3 * * * curl -s "https://monsite.fr/modules/gsitemap/gsitemap-cron.php?token=VOTRE_TOKEN" > /dev/null 2>&1
Dans robots.txt :
User-agent: *
Disallow: /admin-*/
Disallow: /*?
Disallow: /*&
Disallow: /search
Disallow: /order
Disallow: /addresses
Sitemap: https://monsite.fr/1_index_sitemap.xml
Et soumets le sitemap a la Google Search Console et a Bing Webmaster Tools. Surveille la couverture chaque semaine.
Les Rich Snippets et donnees structurees
Les balises Schema.org affichent prix, note, disponibilite directement dans les resultats Google. Le CTR augmente de 15 a 30% en moyenne avec des rich snippets bien implementes.
PrestaShop 8.x integre le balisage de base. Verifie le rendu sur une fiche produit :
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Chaussure de running modele X",
"image": "https://monsite.fr/img/p/1/2/3/123-large_default.jpg",
"description": "Chaussure de running legere ideale pour la route",
"sku": "REF-123",
"brand": {"@type": "Brand", "name": "NomMarque"},
"offers": {
"@type": "Offer",
"url": "https://monsite.fr/chaussures/123-modele-x.html",
"priceCurrency": "EUR",
"price": "89.99",
"priceValidUntil": "2026-12-31",
"availability": "https://schema.org/InStock",
"itemCondition": "https://schema.org/NewCondition"
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.5",
"reviewCount": "42"
}
}
Valide avec le Test des resultats enrichis de Google. Tout warning doit etre corrige (sku manquant, brand absent, prix mal formate).
Erreurs courantes et leur fix
- Page admin ultra lente apres optimisation : OPcache
validate_timestamps=0empeche la prise en compte des changements. Repasse a 1 ou faissystemctl reload php8.3-fpmapres deploiement. - Module qui injecte du CSS inline malgre le CCC : la minification PrestaShop ne touche pas aux scripts/styles inline. Soit tu modifies l'override du module, soit tu remplaces le module.
- Redis ne cache rien : le module n'est pas charge cote PHP. Verifie avec
php -m | grep redis. Si absent,apt install php8.3-redis && systemctl restart php8.3-fpm. - Sitemap genere mais 404 sur le frontend : permissions du dossier
/var/www/prestashop/insuffisantes pour www-data.chown www-data:www-data /var/www/prestashop -R. - Rich snippets refuses par Google : champs obligatoires manquants (sku, image, price, priceCurrency). Le test Google donne le detail.
- CCC casse l'affichage : un module charge un fichier JS qui depend d'un autre charge plus tard. Desactive le CCC, identifie le coupable, corrige l'ordre des dependances dans le
composer.jsondu module. - Cloudflare cache aussi les pages dynamiques : configure une Page Rule qui exclut
/*?et/admin-*/du cache.
Pour aller plus loin
L'optimisation PrestaShop touche a plein de domaines. Pour completer :
- Installer PrestaShop sur un VPS IONOS
- Deboguer PrestaShop en mode developpeur
- Mettre en place un CDN gratuit avec Cloudflare
- Configurer Redis comme cache WordPress
- Configurer la compression Gzip et PHP
Conclusion : la performance est le meilleur SEO
Google l'a martele : Core Web Vitals = critere de classement. Une boutique rapide est mieux indexee, mieux convertie, mieux retenue. Et la bonne nouvelle, c'est que toutes les optimisations decrites ici sont gratuites ou quasi-gratuites : tu paies en temps de configuration, pas en infra. Sur la boutique du client en intro, le ROI de deux jours de travail s'est mesure en milliers d'euros mensuels. Les chiffres parlent d'eux-memes.
MAJ 2026 : PrestaShop 8.2 a nettement ameliore le CCC natif, notamment la gestion des dependances JS et la compression Brotli. Si tu es encore en 8.0, planifie la mise a jour, le gain sur les Core Web Vitals est immediat sans aucune autre intervention.