Vitesse sur mobile d'une boutique PrestaShop : quoi mesurer et ce qui améliore vraiment

Vous testez votre boutique depuis l'ordinateur du bureau, avec la fibre, et tout va bien. Votre client l'ouvre depuis un mobile milieu de gamme, avec une couverture irrégulière, dans le bus. Pour lui, la même page met plusieurs secondes à afficher la photo du produit et réagit avec retard quand il appuie sur « Ajouter au panier ». C'est cette seconde expérience qui compte, aussi bien pour vendre que pour Google, qui indexe et évalue les pages d'après leur version mobile.

Laboratoire et terrain : deux mesures différentes

Avant de changer quoi que ce soit, distinguez deux types de données :

• Données de laboratoire : celles que fournit un test simulé comme Lighthouse ou la partie inférieure de PageSpeed Insights. Utiles pour diagnostiquer, car elles mesurent toujours dans les mêmes conditions, mais ce sont des simulations.
• Données de terrain : ce qu'ont vécu de vrais utilisateurs de Chrome ces derniers jours, en agrégé. C'est ce qui apparaît en haut de PageSpeed Insights (s'il y a assez de trafic) et dans le rapport Signaux Web essentiels de Search Console.

S'obséder sur le score de laboratoire est une erreur fréquente. Une boutique peut avoir 60 dans Lighthouse et réussir avec les données réelles, ou 90 et échouer parce que ses utilisateurs ont des mobiles lents. Ce que Google utilise comme signal, ce sont les données de terrain.

Les trois métriques, en langage de boutique

Elles sont évaluées sur le 75e percentile des visites : il ne suffit pas que la page fonctionne bien pour la majorité, elle doit fonctionner bien pour trois visiteurs sur quatre.

Ce qui ralentit PrestaShop sur un mobile

Temps de réponse du serveur

Si le serveur met du temps à générer la page, tout le reste démarre en retard. Dans PrestaShop, ce qui pèse, ce sont les requêtes à la base de données de chaque page, les modules qui ajoutent de la logique sur les hooks du front, un PHP ancien et un hébergement sans ressources suffisantes. Un cache de page complète, qui sert le HTML déjà généré aux visiteurs anonymes, est généralement l'amélioration isolée la plus visible sur ce point.

Du CSS et du JavaScript dont la page n'a pas besoin

Chaque module a tendance à charger ses fichiers sur toutes les pages : le CSS du formulaire de contact sur la fiche produit, le script du configurateur sur la page d'accueil. Sur un mobile, télécharger, interpréter et exécuter tout cela retarde l'affichage et, surtout, dégrade l'INP, car le processeur du téléphone est occupé au moment où l'utilisateur touche l'écran.

Scripts tiers

Chats, pixels publicitaires, cartes de chaleur, widgets d'avis. Chacun ajoute des requêtes et du travail pour le processeur. Beaucoup ne sont pas nécessaires tant que l'utilisateur n'interagit pas avec la page.

Images

Photos de produits envoyées en grand format, sans formats modernes, ou carrousel de page d'accueil qui fait télécharger au mobile une image prévue pour les écrans d'ordinateur. L'élément LCP d'une fiche est presque toujours la photo principale : si elle est lourde ou chargée en différé, le LCP en pâtit.

Polices

Plusieurs familles de polices, avec de nombreuses graisses, chargées depuis des serveurs externes. En plus du poids, elles retardent le texte ou le font sauter quand la police définitive s'applique.

Ce qui améliore vraiment, dans l'ordre

1. Serveur et PHP à jour. Une version de PHP maintenue et un PrestaShop à jour sont plus rapides en eux-mêmes, et permettent d'utiliser des outils de cache et d'optimisation actuels qui ne fonctionnent pas sur les anciennes versions.
2. Cache de page pour les visiteurs anonymes, avec les bonnes exclusions pour le panier, le paiement et le compte, et une purge automatique quand les produits ou les prix changent.
3. Retirer le CSS et le JS des pages où ils ne servent pas, au lieu de simplement les combiner et les minifier. Tout combiner dans un seul gros fichier ne réduit pas ce que le mobile doit traiter.
4. Retarder les scripts tiers jusqu'à la première interaction, avec une liste d'exceptions pour ce qui doit toujours se charger.
5. L'image principale sans chargement différé et à la bonne taille ; le reste, en différé. Réservez l'espace des images et des bannières avec leurs dimensions pour éviter les sauts.
6. Des polices servies depuis votre serveur, uniquement avec les graisses que vous utilisez et avec font-display réglé.

Comment mesurer l'avant et l'après

• Notez les données de terrain des gabarits clés (page d'accueil, catégorie, fiche) avant de commencer.
• Utilisez le laboratoire pour vérifier que le changement fait ce que vous attendez sur une URL précise.
• Attendez que les données de terrain se mettent à jour : elles reflètent une période de plusieurs semaines, l'amélioration n'apparaît donc pas le lendemain.
• Testez aussi sur un vrai mobile milieu de gamme, avec la connexion bridée depuis les outils du navigateur : c'est ce qui se rapproche le plus de ce que vivent une bonne partie de vos clients, et cela révèle des problèmes que la fibre du bureau masque, comme des menus lents à s'ouvrir ou des boutons qui bougent.
• Regardez aussi votre activité : taux de conversion sur mobile, rebond sur les fiches, paniers commencés.

La vitesse est un signal parmi beaucoup d'autres pour Google, et personne ne peut vous promettre des positions parce que vous l'améliorez. Ce qui est clair, en revanche, c'est qu'une boutique rapide sur mobile perd moins de clients en chemin.

Comment le résoudre dans PrestaShop

Le Pack Boutique rapide de Rekire réunit les éléments de cet article : All In One Cache (cache de page complète sur disque avec purge automatique à l'enregistrement des produits, catégories ou prix, cache de requêtes dans Redis à partir de PrestaShop 8 et gestion d'OPcache), son service de configuration et de formation, RKR OptiMatters et Cache Buster. OptiMatters fait l'inventaire des CSS et JS chargés par chaque type de page avec leur poids et leur module d'origine, vous permet de les retirer, de les différer ou de les retarder jusqu'à la première interaction par page, appareil ou contrôleur, sert les Google Fonts depuis votre serveur avec uniquement les graisses utilisées, et inclut un mode avant/après visible seulement par la personne connectée au back-office.