Quand une boutique met six secondes à s'afficher, le premier réflexe est presque toujours le même : changer d'hébergeur. C'est aussi rarement la bonne réponse. Sur la majorité des boutiques que nous reprenons, le serveur n'est pas en cause — il exécute simplement beaucoup trop de travail à chaque page.
Voici les six causes que nous rencontrons le plus souvent, dans l'ordre où elles méritent d'être vérifiées.
1. Les modules, premier suspect
Une boutique de quelques années accumule facilement quarante à soixante modules. Chacun s'accroche à des points d'exécution de PrestaShop, et beaucoup s'exécutent sur toutes les pages, y compris celles où ils ne servent à rien : un module d'avis clients qui interroge sa base sur la page panier, un module de fidélité actif sur les pages de contenu.
Le pire cas que nous ayons vu : trois modules concurrents installés pour le même besoin, tous actifs, aucun désinstallé. Dans le back-office, onglet Performances, activez le profilage sur une page produit et regardez le temps consommé par chacun. La lecture est souvent brutale.
2. Les images non préparées
Une fiche produit qui charge une photo de 3 Mo redimensionnée en CSS coûte cher, surtout en 4G. Trois vérifications :
- Les déclinaisons d'images sont-elles bien régénérées ? Une déclinaison manquante fait servir l'original.
- Le format WebP est-il utilisé ? Il divise le poids par deux à qualité équivalente.
- Les images sous la ligne de flottaison sont-elles en chargement différé ?
3. Le cache désactivé « le temps de faire un test »
Puis jamais réactivé. C'est étonnamment fréquent. Vérifiez dans Paramètres avancés que le cache Smarty est en mode « Ne pas recompiler », que le cache du système de fichiers est actif, et que la combinaison des fichiers CSS et JavaScript est en place.
4. Les requêtes de base non indexées
Une boutique de 200 produits pardonne tout. À 15 000 références et 80 000 commandes, la moindre requête sans index se paie comptant. Activez le journal des requêtes lentes de MySQL pendant quelques heures d'activité normale, puis regardez ce qui remonte.
Les coupables habituels sont les recherches sur les attributs personnalisés et les filtres de navigation à facettes sur de gros catalogues.
5. Un thème qui charge tout, partout
Beaucoup de thèmes du marché chargent l'intégralité de leurs feuilles de style et de leurs scripts sur chaque page, y compris les bibliothèques de carrousel dont seule la page d'accueil se sert. C'est du poids inutile sur 95 % du parcours.
6. L'hébergement, en dernier
Il compte, évidemment. Un mutualisé saturé ou une version de PHP dépassée pénalisent. Mais mettez d'abord les cinq points précédents au propre : une boutique correctement optimisée tourne très bien sur un hébergement modeste, alors qu'une boutique alourdie restera lente sur une machine puissante.
Mesurer avant de corriger
Le piège est d'optimiser au jugé. Prenez une mesure de référence avant toute intervention, sur les pages qui comptent vraiment : accueil, catégorie, fiche produit, panier.
| Indicateur | Ce qu'il mesure | Cible |
|---|---|---|
| LCP | Affichage du plus grand élément visible | moins de 2,5 s |
| INP | Réactivité aux interactions | moins de 200 ms |
| CLS | Stabilité visuelle pendant le chargement | moins de 0,1 |
| TTFB | Temps de réponse du serveur | moins de 600 ms |
Ces indicateurs sont ceux que Google utilise pour classer les pages. Un TTFB élevé pointe vers le serveur ou la base ; un LCP élevé avec un TTFB correct pointe vers les images ou le thème. La mesure vous dit où chercher.
Par où commencer
Si vous ne devez faire qu'une chose cette semaine : ouvrez la liste de vos modules et désinstallez — pas seulement désactivez — ceux dont vous ne savez plus à quoi ils servent. C'est l'intervention au meilleur rapport effort/résultat, et elle réduit aussi votre surface d'attaque.