De 71 à 85 sur mobile : optimiser une boutique WooCommerce sans la reconstruire

Un 71 qui ne voulait pas bouger

La boutique en ligne d’AMI Informatique, un revendeur high-tech de Dakar, était sur le point d’ouvrir. Quatre-vingt-six produits, un carrousel sur l’accueil, un guide d’achat, un comparateur, un bouton WhatsApp, des avis clients, des filtres par attributs. Le tout sur Elementor Pro, WooCommerce et une vingtaine d’extensions. Sur ordinateur, PageSpeed Insights donnait 97. Sur mobile, 71, et c’est sur mobile que les clients achètent.

Dans le rapport détaillé, deux chiffres m’ont sauté aux yeux. Le LCP, c’est-à-dire le temps que met le plus gros élément visible de la page à s’afficher, était de 5,3 secondes. Le CLS, qui mesure à quel point la page « saute » pendant le chargement, était de 0,14.

La cause était structurelle. Pour afficher la page d’accueil, le téléphone devait télécharger 43 feuilles de style, soit 824 Ko, plus 328 Ko de styles glissés directement dans la page et 1,9 Mo de scripts. La plupart ne servaient à rien sur cette page. Les filtres de la boutique ou la galerie des avis clients n’ont aucune raison d’être chargés sur l’accueil. Ils l’étaient quand même, parce qu’une extension charge ses fichiers partout par défaut.

Ce que j’ai refusé de faire

Reconstruire le site en blocs natifs aurait donné le meilleur résultat. Mais ce n’était pas le moment. Le client attendait, et une refonte complète se justifie rarement pour quelques points de score. J’ai aussi écarté l’idée d’installer une nouvelle extension d’optimisation « tout-en-un ». Le site en comptait déjà assez, et chaque extension de plus est une source de conflits.

Tout ce qui suit tient dans quelques réglages ajoutés avec l’extension Code Snippets, qui permet de glisser des instructions dans WordPress sans toucher au thème, et dans les options d’Autoptimize, déjà installé.

Première piste : ne charger que ce qui sert

Le levier le plus efficace a été le plus simple. Sur l’accueil et les pages éditoriales, j’ai empêché les extensions réservées à la boutique de charger leurs fichiers. WordPress sait faire cela nativement, à condition de lui dire quoi retirer et sur quelles pages. Chaque fichier est désigné par le nom que lui donne son extension, et n’est conservé que sur la boutique, le panier, la commande et l’espace client.

Sur l’accueil, cela a retiré les filtres YITH, les nuanciers de variations, les avis clients, la galerie PhotoSwipe et le composant SelectWoo. On est passé de 31 à 25 feuilles de style et de 45 à 30 scripts. Puis j’ai rechargé la page en visiteur, et un gabarit de galerie, imprimé en bas de page par l’extension d’avis, s’affichait en clair. Il avait toujours été là, caché par le style que je venais de retirer. Deux lignes de style ont réglé le problème, mais il faut regarder la page entière, pas seulement le score.

Le rapport disait que le coupable était le bandeau de cookies

Je pensais que l’élément LCP était l’image du carrousel. Le rapport Lighthouse disait autre chose : le texte du bandeau de cookies. Ce bandeau est ajouté par un script après le chargement de la page, et son paragraphe de sept lignes constituait le plus grand bloc visible sur un écran de téléphone. Google mesurait donc le moment où ce bandeau apparaissait, plus de deux secondes après le reste.

J’ai réécrit le message du bandeau. Deux lignes au lieu de sept, sans rien retirer aux choix proposés. Le titre de la bannière est redevenu l’élément LCP, et le score est passé de 78 à 80 sans qu’une seule ressource ait été touchée. Le score global ne dit jamais quel élément le pénalise ; il faut aller le chercher dans le détail.

Le carrousel chargeait 1,5 Mo d’images que personne ne voyait

Le carrousel d’accueil affiche cinq diapositives, mais une seule est visible à l’ouverture. Les images des quatre autres, 1,5 Mo de PNG en tout, se chargeaient immédiatement et faisaient concurrence à l’image principale. Aucune d’elles n’avait de dimensions renseignées. Le navigateur ne pouvait donc pas réserver la place avant l’arrivée des fichiers, et la page sautait à chaque image reçue. D’où le CLS de 0,14.

D’abord, j’ai fait en sorte que chaque diapositive reprenne les dimensions enregistrées dans la médiathèque de WordPress. À partir de là, WordPress ajoute lui-même le chargement différé aux images qui ne sont pas visibles au départ, et le navigateur réserve l’espace. Ensuite, j’ai demandé au navigateur de charger en priorité l’image principale et les deux polices utilisées en haut de page. Le CLS est descendu à 0,05, et le premier affichage de contenu est passé de 2,3 à 1,5 seconde.

Le réglage qui a d’abord fait baisser le score

Il restait les scripts qui bloquent l’affichage. Autoptimize différait déjà tout sauf jQuery, exclu par défaut parce que beaucoup de petits scripts en dépendent. Comme il différait aussi ces petits scripts en gardant leur ordre, je pouvais différer jQuery lui-même. Je l’ai fait avec un réglage ajouté dans Code Snippets. La page s’est cassée, mais seulement pour moi. La barre d’administration de WordPress, que seul un utilisateur connecté voit, a besoin de jQuery tout de suite. J’ai limité le réglage aux visiteurs non connectés. Tester uniquement connecté, ou uniquement déconnecté, fait rater la moitié des problèmes.

Restait le regroupement des feuilles de style. Dans Autoptimize, une case fusionne tous les fichiers de style en un seul, ce qui réduit les allers-retours avec le serveur. Lors d’un premier essai, cette case avait fait baisser le score. Le fichier unique pesait plus de 800 Ko et bloquait tout. Une fois les extensions inutiles retirées de la page, j’ai recoché la même case. Le fichier ne pesait plus que 54 Ko compressé, et les 25 requêtes sont devenues deux. L’ordre des opérations compte : regrouper des fichiers inutiles ne fait que déplacer le problème.

Ce que ça a donné, et comment je l’ai vérifié

Le score mobile est passé de 71 à 85, et le score ordinateur de 97 à 99. Le LCP est descendu de 5,3 à 3,8 secondes en conditions simulées, avec 1,3 seconde observée en conditions réelles. Le CLS est passé de 0,14 à 0,05, le premier affichage de 2,3 à 1,5 seconde. Sur l’accueil, les 43 feuilles de style sont devenues 2, et les 45 scripts, 30.

Après chaque étape, j’ai refait le parcours complet en visiteur, la console du navigateur ouverte. Accueil, carrousel, compteurs, menu, recherche, boutique avec ses filtres, fiche produit, ajout au panier, panier, page de commande. Si le score monte pendant que l’ajout au panier cesse de fonctionner, on a juste fermé la boutique plus vite.

Pourquoi je m’arrête à 85 pour l’instant

Sur un site Elementor et WooCommerce, le poids vient rarement d’une seule ressource, plutôt de l’accumulation d’extensions qui chargent leurs fichiers partout. Ne charger que ce qui sert reste le levier le plus rentable, et il ne coûte aucune extension de plus.

Pour dépasser 90 sur mobile, il resterait à intégrer le style critique directement dans la page, une étape plus délicate visuellement, que je préfère garder pour l’après-lancement. Sur mon propre site, construit en blocs natifs, la question ne se pose pas de la même façon. C’est ce que je raconte dans Elementor ou éditeur de blocs : comment choisir.