Pourquoi la vitesse se lit dans le chiffre d’affaires
La vitesse n’est pas qu’une question de confort. En 2019, l’étude Milliseconds Make Millions, menée par Deloitte et 55 pour Google sur 37 marques et plus de 30 millions de sessions, a mesuré l’effet d’un gain de 0,1 seconde sur mobile. Sur les sites marchands, le taux de conversion a progressé de 8,4 % et le panier moyen de 9,2 %. Le passage de la fiche produit à l’ajout au panier est l’étape qui a le plus réagi : +9,1 %.
Un test A/B est encore plus parlant. Vodafone a comparé deux versions identiques d’une même page, l’une optimisée, l’autre non. En réduisant de 31 % le temps d’affichage du contenu principal, la version rapide a généré 8 % de ventes en plus. Les leviers employés étaient classiques : moins de JavaScript bloquant, un HTML préparé côté serveur, des images redimensionnées.
Côté référencement, Google est clair : ses systèmes de classement utilisent les Core Web Vitals, mais la pertinence du contenu passe d’abord. Selon Google Search Central, de bons scores ne garantissent pas la première place. Ils font plutôt la différence entre plusieurs pages d’intérêt équivalent, ce qui est souvent le cas des fiches produits concurrentes.
Les trois indicateurs à surveiller et leurs seuils
Google résume l’expérience de chargement en trois mesures, les Core Web Vitals. Les seuils officiels sont publiés par web.dev et la limite basse par l’article de définition des seuils :
- LCP (affichage du plus grand élément visible, souvent la photo produit) : bon jusqu’à 2,5 secondes, mauvais au-delà de 4 secondes.
- INP (délai de réaction à un clic ou une saisie) : bon jusqu’à 200 millisecondes, mauvais au-delà de 500. Il remplace depuis 2024 l’ancien indicateur FID.
- CLS (stabilité de la mise en page, ces boutons qui « sautent ») : bon jusqu’à 0,1, mauvais au-delà de 0,25.
Ces seuils s’appliquent au 75e centile : au moins trois visites sur quatre doivent être dans le vert, sur mobile comme sur ordinateur. Le mobile est le vrai sujet. D’après le Web Almanac 2024 de HTTP Archive, seuls 43 % des sites passent les trois tests sur mobile, contre 54 % sur ordinateur. Le LCP est le plus souvent en cause : 59 % seulement des sites ont un bon LCP sur mobile. Le chapitre e‑commerce du même rapport ne compte que 34 % de boutiques WooCommerce avec un bon LCP sur mobile.
1. Un hébergement à la hauteur
Tout commence par le serveur. Avant d’afficher quoi que ce soit, le navigateur attend le premier octet de la page (TTFB). Selon le guide d’optimisation du LCP, ce délai représente environ 40 % du LCP d’une page bien optimisée ; s’il est trop long, tenir 2,5 secondes devient presque impossible. Or seuls 42 % des sites ont un bon TTFB sur mobile, selon le Web Almanac 2024.
Concrètement :
- Un hébergement dimensionné pour votre trafic et vos pics (soldes, Black Friday), pas un mutualisé saturé.
- Un serveur proche de vos clients : en France pour une clientèle française.
- Une version de PHP encore maintenue pour PrestaShop ou WooCommerce. Au moment où nous écrivons, php.net ne maintient plus que les versions 8.2 à 8.5, et la 8.2 ne reçoit plus de correctifs de sécurité après le 31 décembre 2026.
- Le moins de redirections possible avant d’arriver sur la page.
C’est le rôle de notre hébergement en France : un serveur réglé pour la plateforme, surveillé en continu.
2. Des images au bon format
Sur mobile, le plus grand élément visible est une image sur 68 % des pages, d’après le chapitre Médias du Web Almanac 2024. Pourtant, les formats récents restent minoritaires : 12 % d’images en WebP et 1 % en AVIF, contre 32 % en JPEG. Selon Google, une image WebP pèse 25 à 34 % de moins qu’un JPEG de qualité comparable. L’AVIF va souvent plus loin, mais le gain dépend de l’image, comme le rappelle web.dev : testez sur vos propres photos.
- Servez vos photos en WebP ou en AVIF, en gardant un JPEG de secours.
- Proposez plusieurs tailles (
srcset) : un téléphone n’a pas besoin d’une photo de 2 000 pixels. - Indiquez toujours la largeur et la hauteur : la place est réservée et la page ne bouge plus (CLS).
- Chargez à la demande (
loading="lazy") les images situées plus bas dans la page. - Jamais pour l’image principale : le guide du LCP le déconseille formellement, et recommande au contraire
fetchpriority="high"sur cette image. Le Web Almanac relève pourtant cette erreur sur 16 % des pages mobiles concernées.
3. Des polices bien servies
Les polices retardent l’affichage du texte et peuvent faire bouger la page quand elles arrivent. Les bonnes pratiques de web.dev se résument ainsi :
- Le format WOFF2, le mieux compressé.
- Peu de graisses, et des fichiers allégés des caractères inutiles.
- Un préchargement réservé aux polices du haut de page.
- Un réglage
font-displayadapté, et une police de remplacement aux proportions proches (size-adjust) pour éviter que le texte « saute ».
Héberger les polices sur votre propre serveur évite une connexion supplémentaire vers un autre domaine et vous rend maître du cache. web.dev précise que ce n’est pas toujours plus rapide en soi : mesurez avant et après.
4. Moins de scripts tiers
Outils de suivi, chat, avis clients, pixels publicitaires : chaque script externe occupe le navigateur, retarde l’affichage et ralentit la réaction aux clics (INP). Le guide d’optimisation de l’INP insiste sur ce point : tout code exécuté pendant le chargement retarde les premières interactions.
- Faites l’inventaire, page par page, et retirez ce qui n’apporte plus rien.
- Chargez les autres avec
asyncoudefer, comme le recommande web.dev, sauf s’ils sont indispensables à l’affichage. - Reportez au moment utile les contenus lourds : une vidéo ou un chat peuvent attendre que le visiteur s’en approche.
- Limitez qui peut ajouter des balises dans votre gestionnaire de tags.
5. Le cache, à tous les niveaux
Activez le cache de la plateforme et la compression des fichiers. Côté navigateur, le guide HTTP Cache de web.dev recommande une durée d’un an pour les images, polices, styles et scripts dont l’adresse change à chaque nouvelle version, et une revalidation systématique pour les pages HTML. Les visiteurs qui reviennent voient alors la page presque instantanément, sans jamais recevoir une version périmée.
Sur PrestaShop, la documentation officielle conseille de garder le cache Smarty activé, de ne pas forcer la recompilation des templates en production et d’activer le cache intelligent des CSS. Celui des JavaScript se teste avant d’être activé. Selon votre serveur, un cache Memcached ou APC allège aussi la base de données.
6. Des modules et extensions en nombre raisonnable
Chaque module installé peut ajouter des requêtes, des styles et des scripts sur toutes les pages, y compris là où il ne sert pas. Désactivez ceux qui ne servent plus, et préférez une fonctionnalité bien intégrée à trois modules qui se chevauchent. PrestaShop permet aussi de couper les fonctions inutilisées, comme les déclinaisons ou les groupes clients, d’après sa documentation. Si votre boutique accumule les extensions au fil des années, une refonte e‑commerce est souvent l’occasion de repartir sur une base saine, comme pour LG Motoculture.
7. Mesurer, puis surveiller
Distinguez deux types de mesures. PageSpeed Insights affiche des données de terrain, issues de vrais visiteurs de Chrome sur les 28 derniers jours, et une simulation de laboratoire sur un téléphone de milieu de gamme. Seules les premières comptent pour l’évaluation des Core Web Vitals ; la simulation sert à trouver les causes.
- Mesurez sur mobile vos pages clés : accueil, catégories, fiches produits, panier.
- Commencez par l’indicateur le plus rouge, souvent le LCP des fiches produits.
- Corrigez un levier à la fois et notez la date.
- Vérifiez l’effet dans Search Console : comptez environ quatre semaines pour que les données de terrain se renouvellent.
- Recommencez à chaque nouveau module, script ou thème.
Nous appliquons cette méthode sur accessoire-guitare.com, la boutique PrestaShop que nous exploitons nous-mêmes. Et si vous préparez un changement de plateforme, la vitesse fait partie des critères de notre comparatif PrestaShop, Shopify et WooCommerce, tout comme la préservation de vos positions dans notre guide sur la refonte sans perte de référencement.
À retenir
- Visez un LCP sous 2,5 s, un INP sous 200 ms et un CLS sous 0,1, pour au moins 75 % des visites mobiles.
- Hébergement, image principale et scripts tiers sont les trois premiers leviers à examiner.
- Jugez sur les données de terrain, page par page, et laissez-leur quatre semaines pour bouger.
- La vitesse n’est pas un chantier ponctuel : chaque nouveau module ou script doit être pesé.
Sources
- Milliseconds make millions, Deloitte et 55 pour Google, présenté sur web.dev
- Vodafone: A 31% improvement in LCP increased sales by 8%, web.dev
- Understanding page experience in Google Search results, Google Search Central
- Web Vitals et Defining the Core Web Vitals metrics thresholds, web.dev
- Optimize Largest Contentful Paint et Optimize Interaction to Next Paint, web.dev
- Web Almanac 2024 : Performance, Media et Ecommerce, HTTP Archive
- An image format for the Web (WebP), Google for Developers, et Using AVIF to compress images, web.dev
- Best practices for fonts, Efficiently load third-party JavaScript et Prevent unnecessary network requests with the HTTP Cache, web.dev
- Performance (Paramètres avancés), documentation PrestaShop 8
- Supported Versions, PHP.net
- About PageSpeed Insights, Google for Developers
Votre boutique est lente ? Nous l’hébergeons en France, la surveillons et l’optimisons en continu. Voir notre offre d’hébergement ou demander un audit.

