On a sorti les DevTools sur une boutique PrestaShop 1.6 qui venait de perdre 30 % de son trafic organique en deux mois. Le propriétaire avait tout essayé : compression Gzip, cache navigateur, un CDN gratuit. Rien n’y faisait. Le LCP restait collé à 9,8 secondes en desktop sur la fiche produit. Et le coupable était juste là, dans l’onglet Network, à la quinzième ligne : un fichier theme.css de 820 Ko qui appelait des styles de 15 modules désinstallés.
L’enquête qu’on a menée ce jour-là illustre un problème que je vois traîner sur des dizaines de petites boutiques encore en 1.6 : ce n’est pas PrestaShop qui est lent, c’est le thème gratuit qu’on a gardé pendant six ans sans jamais le nettoyer.
Un LCP de 9,8 secondes ne ment pas, mais il ne dit pas tout seul ce qui coince
On te dira que le LCP d’une page e-commerce, c’est l’image du produit ou le bloc prix. C’est vrai, mais pour que cet élément s’affiche, le navigateur doit d’abord parser le CSS qui définit sa mise en page. Sur le site audité, le theme.css importait la totalité des règles de style de l’ancien système de couleurs du thème, des sliders aujourd’hui disparus, et d’une police d’icônes chargée en bloc via @font-face en data URI. Résultat : 4,2 Mo de CSS à parser avant que la première image produit ne puisse apparaître.
Le piège, c’est que Lighthouse ne te le crie pas en rouge. Il te dit « Reduce unused CSS » avec un petit drapeau orange. 4,2 Mo, ce n’est pas une suggestion, c’est une hémorragie. Et ce volume de CSS inutilisé, je l’ai vu naître d’une seule décision : le thème gratuit a été construit pour afficher toutes les configurations possibles en une seule feuille, sans post-processeur, sans purge, sans logique conditionnelle.
Ouvre ton onglet Network, coche « Disable cache », et cherche les fichiers qui portent le nom d’un module disparu
Le diagnostic concret prend moins de quinze minutes. Lance la fiche produit, vérifie qu’aucun cache n’est actif, trie par type stylesheet. Tu verras des noms comme blocklayered.css, homeslider.css, sendtoafriend.css… Dans notre audit, ces fichiers étaient encore appelés alors que le module n’existait plus depuis une migration PHP de 2019. Le thème les déclarait en dur dans son head.tpl, sans aucune condition {if isset}.
La conséquence ne se voit pas que dans la cascade CSS. Chaque requête réseau supplémentaire, même mise en cache, coûte un slot de priorité de chargement sur les navigateurs modernes. Ici, on avait 67 requêtes JS et CSS bloquantes, dont 14 pour des polices et des icônes qui étaient ensuite redéclarées trois lignes plus bas par un autre plugin jQuery. À ce stade, ton LCP n’est plus une question de temps de réponse serveur : c’est une question de saturation du thread principal.
La bonne nouvelle, c’est qu’on peut régler une partie du problème sans toucher au code du thème. Un simple remplacement des appels statiques par une logique de chargement conditionnel dans le template a déjà fait tomber le LCP à 3,1 secondes sur la même boutique. Le reste du chemin demande de s’attaquer aux dépendances JavaScript, mais ça, c’est la deuxième couche qu’on a documentée dans notre guide sur l’optimisation core web vitals.
Pourquoi les outils de test classiques passent à côté du vrai problème
Quand on teste ce type de page sur PageSpeed Insights, on voit un score performance de 22, des avertissements sur le temps de blocage, et un INP délirant. Mais en se contentant de suivre les recommandations générées automatiquement, le propriétaire de la boutique avait d’abord activé un lazy-loading agressif, réduit la taille des images, et repoussé le JS non critique. Bilan : LCP toujours à 8,4 secondes. Parce que le problème n’était pas le poids des images, c’était le temps de parsing CSS.
Les systèmes de classement de Google mesurent le LCP en conditions réelles via le CrUX. Si le premier contenu visible est un titre de produit stylisé qui attend que 800 Ko de CSS soient interprétés, tu perds des secondes entières que ni la compression ni le lazy-loading ne rattrapent. C’est une erreur que je retrouve souvent chez les devs qui traitent le Core Web Vitals uniquement par le prisme des images et du JavaScript. Le CSS legacy tue le LCP avant même que l’image n’entre dans le viewport.
Le piège insidieux du « all in one CSS »
La plupart des thèmes gratuits distribués entre 2014 et 2018 pour PrestaShop 1.6 utilisaient une feuille de style unique dans laquelle on empilait toutes les déclarations de tous les modules optionnels. L’argument marketeux : « moins de requêtes HTTP ». La réalité physique : 820 Ko de CSS, 12 000 lignes, dont 9 000 ne s’appliquent jamais parce que le module « Bloc Newsletter » en position rightColumn n’existe plus, ou que la boutique n’a jamais activé la wishlist.
Je le répète à chaque audit : un kilo-octet de CSS inutilisé n’est pas un kilo-octet inoffensif. Il est parsé, il rentre dans le CSSOM, il retarde le premier rendu. Quand tu multiplies ça par cinq modules absents, tu obtiens un temps de blocage qui explique pourquoi la page reste blanche plus d’une seconde et demie alors que le serveur a répondu en 180 ms.
💡 Conseil : Plutôt que de recompresser tes assets à l’aveugle, lance l’outil Coverage de Chrome DevTools sur la fiche produit. Le rapport visuel entre le CSS chargé et le CSS utilisé te donne en une seconde la preuve du gâchis, et tu peux l’exporter pour le montrer en réunion sans avoir besoin d’un audit payant.
Ce que ce vieux thème m’a appris pour mes projets modernes
C’est facile de se moquer d’une boutique PrestaShop 1.6 qui traîne un thème gratuit de 2016. Mais le même mécanisme existe aujourd’hui dans les thèmes WordPress achetés sur ThemeForest, ou dans les starters Next.js que des agences génèrent avec des dépendances CSS à tout va. Le jour où un dev enlève le composant « testimonial » du code mais oublie de nettoyer le chunk CSS correspondant, tu te retrouves avec le même problème structurel, juste en plus moderne.
J’ai gardé ce cas sous le coude pour mes formations parce qu’il oblige à penser la performance non pas comme un chemin balisé, mais comme une chasse aux héritages non réclamés. La méthode est la même : tu ouvres la page que Google indexe le plus, tu traces le temps de parsing du CSS, tu repères ce qui ne sert à rien, et tu coupes. Si tu fais ça sur un thème gratuit 1.6, tu deviens capable de le faire sur un bundle Vite de 2026.
Le vrai coût d’un thème gratuit, ce n’est pas zéro euro
Les marchands qui installent ces thèmes ne voient que la gratuité immédiate. Mais quand on sort la calculette, le temps passé à débuguer un LCP pathologique, la perte de chiffre d’affaires pendant six mois de crawl dégradé, et le coût de l’audit qui finit par arriver quand même, on est très loin du zéro euro. Sans compter que le manque de mises à jour structurelles du thème expose la boutique à des incompatibilités PHP qui peuvent casser l’indexation du jour au lendemain.
Je ne dis pas qu’il faut toujours payer 200 € un thème Premium. Je dis qu’un thème gratuit PrestaShop 1.6 doit être audité exactement comme on audite une migration vers un framework moderne. Si tu ne le fais pas, tu acceptes implicitement que ton LCP se dégrade mois après mois à mesure que les navigateurs durcissent leurs politiques de chargement.
Cette approche vaut d’ailleurs pour les décisions plus récentes : quand on compare des IDE pour scripter le nettoyage de code legacy, la différence entre un outil classique et un environnement agentic se mesure vite en heures gagnées à refactorer les inclusions CSS. On en a parlé dans l’article claude code vs cursor ide, parce que le choix de l’outil change concrètement le temps de résolution quand on doit retirer 12 000 lignes de code mort sans casser l’affichage du panier.
Ce type de refactoring oblige aussi à comprendre comment l’information transite dans la page. Dans un thème moderne, on pourrait isoler les états du module newsletter avec un store dédié, mais l’article sur le state management react zustand montre bien qu’une gestion minimaliste de l’état évite de traîner des dépendances CSS supplémentaire pour des composants déjà inactifs. Rien n’est gratuit, y compris la simplicité.
Questions fréquentes
Est-ce que PrestaShop 8 règle automatiquement ces problèmes de thème ?
Non. PrestaShop 8 impose des standards plus récents et abandonne certains modules obsolètes, mais un thème mal construit, gratuit ou payant, charge toujours ce que le créateur a choisi d’inclure. La logique de purge CSS n’est pas native dans le CMS. Vous devez auditer chaque thème individuellement.
Un thème gratuit PrestaShop 1.6 peut-il quand même passer les Core Web Vitals sans retouche ?
Seulement si la boutique est squelettique, avec un catalogue minuscule et aucun module additionnel jamais installé. Dès que vous avez activé et désactivé ne serait-ce que trois modules, le volume de CSS inutilisé explose et le LCP dépasse systématiquement les 4 secondes en mobile réel, quoi que raconte le score synthétique.
Pourquoi la Search Console ne m’alerte-t-elle pas sur ce problème ?
La Search Console signale un groupe d’URL lentes via le rapport Core Web Vitals, mais elle ne descend pas à la granularité du fichier CSS précis. Elle vous dit que la page est lente, pas pourquoi. C’est à vous de faire le lien entre une alerte « LCP insuffisant » et l’onglet Coverage des DevTools.
