Optimiser CSS, JS et polices dans PrestaShop sans casser la boutique

Ouvrez une fiche produit d'une boutique PrestaShop qui compte quarante modules et comptez les fichiers CSS et JS qu'elle charge. On dépasse facilement les cinquante. Parmi eux, le CSS du formulaire de contact, le JS du module d'avis qui n'apparaît que sur une autre page et une police en six graisses dont le thème n'en utilise que deux.

Aucun de ces fichiers ne casse quoi que ce soit à lui seul. Ensemble, ils obligent le navigateur à télécharger, analyser et exécuter bien plus que nécessaire avant d'afficher la page. Cela pèse sur le LCP et l'INP, les métriques des Core Web Vitals les plus difficiles à tenir pour les boutiques.

D'où viennent tous ces fichiers

Dans PrestaShop, chaque module enregistre ses ressources dans le hook du front-office. La plupart le font sur toutes les pages, par commodité : le développeur ne sait pas où vous placerez son bloc, alors il le charge partout. Ajoutez-y le thème, son thème parent s'il s'agit d'un thème enfant, les bibliothèques que chacun apporte et les scripts tiers (analyse, chat, pixels, avis externes).

C'est pourquoi optimiser ne se résume pas à « compresser ». Il existe quatre leviers différents, et mieux vaut ne pas les mélanger.

1. Combiner et minifier

PrestaShop propose de série, dans Paramètres avancés > Performances, le cache intelligent pour les CSS et le JavaScript : il regroupe les fichiers en un seul ou en quelques-uns et les minifie. C'est la première chose à activer, et cela fonctionne presque toujours.

• Avantage : moins de requêtes et moins d'octets.
• Limite : tout continue d'être chargé sur toutes les pages, simplement regroupé. Si 40 % du CSS ne sert pas sur la fiche produit, il ne sert toujours pas, désormais dans un fichier plus gros.
• Risque : un JS mal écrit qui dépendait de l'ordre de chargement ou d'une variable globale peut échouer une fois combiné. On le remarque parce qu'un bouton ne répond plus ; l'erreur apparaît dans la console du navigateur.

Après l'avoir activé, videz le cache et testez le parcours complet : liste, fiche produit, panier, tunnel de commande et paiement.

2. Retirer ce qui ne sert pas sur chaque page

C'est ce qui se remarque le plus et ce qui se fait le moins. Si le CSS du module de formulaires ne sert que sur la page de contact, il n'y a aucune raison de le charger sur la fiche produit. Pour décider, il vous faut un inventaire : quelle ressource charge chaque type de page, combien elle pèse et de quel module elle provient.

Avec cet inventaire sous les yeux, les règles sont simples : « ce CSS, hors de la fiche produit », « ce JS, uniquement dans le tunnel de commande ». Le risque est de retirer quelque chose qui servait bel et bien à un endroit que vous n'aviez pas regardé. C'est pourquoi chaque règle est testée sur les pages concernées avant d'être conservée.

3. Defer, async et différer jusqu'à l'interaction

Un script classique dans le <head> interrompt l'analyse de la page jusqu'à ce qu'il soit téléchargé et exécuté. Il existe trois façons de l'éviter :

Différer jusqu'à l'interaction est très efficace avec les scripts tiers, qui sont souvent les plus lourds. Mais cela comporte deux pièges :

• Analyse et consentement. Si vous différez la balise d'analyse, les visites qui rebondissent sans rien toucher ne sont pas mesurées. Cela peut être acceptable ou non, selon vos besoins. Et le script de consentement n'est jamais différé : il doit passer avant tout le reste.
• Dépendances. Si un script différé définit quelque chose qu'un autre utilise au chargement, le second échoue. Les scripts différés doivent s'exécuter dans l'ordre du document et avec un délai maximal, pour ne pas attendre indéfiniment.

4. Les Google Fonts depuis votre serveur

De nombreux thèmes chargent les polices depuis les serveurs de Google. Cela a deux coûts :

• Performances : des connexions vers un autre domaine, et souvent plus de graisses et d'alphabets que ceux que vous utilisez.
• Protection des données : le navigateur du visiteur envoie son adresse IP à Google en demandant la police, avant d'avoir accepté quoi que ce soit. Un tribunal allemand a déjà condamné un site pour cela, et c'est une réclamation fréquente.

La solution consiste à télécharger les fichiers woff2 et à les servir depuis votre domaine, en ne gardant que les graisses et sous-ensembles utilisés (pour l'espagnol, généralement latin et latin-ext). En outre :

• Préchargez uniquement la police du texte qui s'affiche en premier, pas toutes.
• Utilisez font-display: swap pour que le texte s'affiche avec la police système en attendant la vôtre.
• Vérifiez qu'il ne reste aucune référence à Google dans le thème parent, dans les modules ni dans le CSS qu'ils génèrent.

Comment mesurer sans vous tromper

1. Mesurez d'abord. PageSpeed Insights fournit des données de terrain (utilisateurs réels, si votre boutique a assez de trafic) et de laboratoire.
2. Changez une seule chose à la fois.
3. Comparez la même page avec et sans le changement, sur mobile.
4. Parcourez le tunnel de commande et passez une commande de test.
5. Regardez la console du navigateur : une nouvelle erreur est une fonctionnalité cassée que vous n'avez pas encore trouvée.

La version compte

Les boutiques sous PrestaShop 1.6 ou les premières 1.7 traînent des thèmes avec un jQuery ancien et des bibliothèques impossibles à différer sans casser quelque chose. Avec PrestaShop 8 et 9, un PHP récent et des thèmes comme Hummingbird, le point de départ est plus propre et chaque optimisation rapporte davantage. Si votre boutique a beaucoup de retard, la mise à jour fait partie de l'optimisation, ce n'est pas une étape à part.

Comment le résoudre dans PrestaShop

RKR OptiMatters dresse l'inventaire des CSS et JS chargés par chaque type de page, avec leur poids et leur module d'origine, et vous permet de créer des règles pour les retirer, appliquer defer ou async, les différer jusqu'à la première interaction, les charger après la page ou forcer leur chargement, limitées par page, contrôleur, catégorie, appareil ou URL. Il télécharge les Google Fonts utilisées par votre boutique et les sert depuis votre serveur, avec uniquement les graisses et sous-ensembles nécessaires, et propose un mode test pour comparer n'importe quelle page avec et sans l'optimiseur. Côté serveur, All In One Cache ajoute un cache de page complète, un cache des requêtes dans Redis (PrestaShop 8 ou supérieur) et la gestion d'OPcache, avec une minification optionnelle du HTML et du CSS et JS en ligne.