WooCommerce
Contexte
Miloon, la boutique en ligne de ZVM SRL, est un site e-commerce spécialisé dans les cosmétiques coréens : soins de la peau, maquillage et soins du corps d’une trentaine de marques, avec un catalogue d’environ 2 400 produits vendus en trois langues (italien, français et anglais). La boutique tourne sur WooCommerce avec un thème commercial à page builder et un méga menu qui organise les produits par besoin de la peau, par ingrédient et par marque.
Comme beaucoup de boutiques qui ont grandi vite, elle avait accumulé des fonctionnalités ajoutées une par une : liste de souhaits, filtres AJAX, programme de fidélité, badges promotionnels, liste d’attente pour les produits épuisés, avis vérifiés, notifications push, bandeau d’information, paiement en plusieurs fois et une dizaine de balises marketing gérées via Google Tag Manager. Aucune n’était superflue pour l’activité ; le problème était la façon dont elles se chargeaient.
Ce que disaient les données
Plus de 80 % du trafic vient de smartphones, souvent issu de campagnes sur les réseaux sociaux, et les données CrUX mobiles décrivaient un site lent exactement là où cela compte : LCP à 4,4 secondes, INP à 410 millisecondes et CLS à 0,22 au 75e percentile. Les fiches produit et les catégories dépassaient les seuils des trois métriques ; la page d’accueil, chargée de sliders promotionnels, était la pire pour le LCP.
Le score de laboratoire variait beaucoup d’un test à l’autre et n’expliquait pas le problème à lui seul. Nous avons donc mis en place, en plus des données CrUX, un monitoring des utilisateurs réels (RUM) avec attribution des métriques, pour savoir quel élément était le LCP, quelle interaction était lente et ce qui se déplaçait.
Le diagnostic
Deux semaines d’analyse ont révélé une cause différente pour chaque métrique, côté serveur comme côté application :
- TTFB élevé et irrégulier : 1,3 seconde au 75e percentile. Le cache de page était contourné par un cookie de session posé pour chaque visiteur, même avec un panier vide ; la base de données chargeait plus de 4 Mo d’options à chaque requête et conservait des centaines de milliers d’actions planifiées déjà terminées.
- LCP retardé : l’image principale était la première diapositive d’un carrousel initialisé en JavaScript, en lazy loading et sans priorité, après 38 feuilles de style et plus de 140 scripts.
- INP dû à des interactions lourdes : l’ouverture du méga menu, l’ajout au panier et les filtres de catégories déclenchaient des tâches longues sur le thread principal, aggravées par des pixels et des widgets tiers qui s’exécutaient tous au chargement.
- CLS dû à des éléments injectés : le bandeau d’information, les badges d’avis, le bandeau de cookies et les badges promotionnels apparaissaient après le premier rendu et repoussaient le contenu vers le bas.
Travail côté serveur
Le premier chantier a été de rendre la réponse du serveur rapide et prévisible, car chaque milliseconde de TTFB s’ajoute au LCP.
- Passage de PHP 7.4 à PHP 8.3, avec un OPcache dimensionné sur le code réel et le JIT désactivé après test.
- Cache de page au niveau du serveur web, avec des règles d’exclusion fondées sur les cookies de panier et de session client, et non sur n’importe quel cookie : les visiteurs anonymes reçoivent toujours la page en cache.
- Cache d’objets persistant avec Redis pour réduire les requêtes répétées sur les produits, les variations et les traductions.
- Nettoyage de la base de données : options chargées à chaque requête ramenées de 4,1 Mo à 0,6 Mo, sessions expirées et actions planifiées terminées supprimées par une routine périodique.
- HTTP/3, compression Brotli et en-têtes de cache corrects pour les images, les polices et les fichiers statiques.
Travail côté application
Sur le front-end, l’objectif était de conserver toutes les fonctionnalités marketing en ne changeant que le moment et la manière de les charger.
- Sur la page d’accueil, le carrousel a été remplacé par une image principale statique, servie en AVIF et en WebP avec
srcset, préchargée et avecfetchpriority="high"; les autres promotions ont été déplacées sous la ligne de flottaison. - Polices hébergées en local, réduites aux graisses réellement utilisées et avec des métriques de repli alignées, pour éviter à la fois le texte invisible et le décalage au moment du remplacement de la police.
- Scripts et styles des plugins chargés uniquement là où ils servent : la liste de souhaits et la liste d’attente sur les fiches produit, les filtres AJAX sur les catégories, le paiement en plusieurs fois dans le panier et le tunnel de commande. Six plugins devenus inutiles ont été supprimés.
- Balises marketing réorganisées dans Google Tag Manager : celles qui ne sont pas nécessaires au premier rendu se déclenchent après le chargement ou à la première interaction, dans le respect du consentement recueilli par le bandeau de cookies.
- Méga menu rendu côté serveur et ouvert en CSS, filtres de catégories avec requêtes groupées et mises à jour du DOM limitées à la seule grille de produits.
- Espace réservé à l’avance pour le bandeau d’information, les badges d’avis et les badges promotionnels, afin qu’aucun élément ne déplace le contenu en apparaissant.
Résultats
Les données CrUX sont une moyenne glissante sur 28 jours. Nous avons donc comparé la fenêtre précédant les travaux à celle close quatre semaines après la dernière mise en production, toujours sur mobile et au 75e percentile.
| Métrique (mobile, p75) | Avant | Après |
|---|---|---|
| TTFB | 1,3 s | 0,4 s |
| LCP | 4,4 s | 2,3 s |
| INP | 410 ms | 180 ms |
| CLS | 0,22 | 0,04 |
Les trois Core Web Vitals sont passés dans la zone « bon » sur mobile, et l’évaluation CrUX de l’origine est passée de « échec » à « réussie ». Sur la même période, le taux de conversion sur smartphone a augmenté, mais la saisonnalité des promotions ne permet pas de l’attribuer au seul travail de performance ; nous ne le présentons donc pas comme un résultat du projet.
Comment nous maintenons le résultat
Un site e-commerce change chaque semaine : nouvelles campagnes, nouveaux plugins, nouvelles balises. Pour éviter toute régression, nous avons laissé actif le monitoring RUM avec des alertes sur les seuils des Core Web Vitals, un contrôle Lighthouse automatisé avant chaque mise en production et une courte liste de règles partagées avec l’équipe marketing sur les images, les bandeaux et les nouveaux scripts. Chaque mois, nous passons ensemble en revue les données et les éventuelles régressions.