La vitesse d'un site impacte-t-elle vraiment la conversion ?

Pourquoi Google reconnaît-il explicitement ce lien entre vitesse et conversion ?

Cette déclaration rompt avec la logique purement technique qu'on associe souvent aux Core Web Vitals. Google ne se contente pas de dire « optimisez votre LCP » — il admet que la vitesse affecte directement les KPI business : rétention, conversion, chiffre d'affaires.

En filigrane, c'est un signal fort : l'algorithme ne juge pas la performance pour le plaisir de la métrique, mais parce qu'elle corrèle avec l'expérience utilisateur réelle. Un site lent perd des clients avant même qu'ils aient vu le contenu.

Que signifie concrètement « la taille des pages » dans ce contexte ?

Martin Splitt évoque le poids total transféré : images non compressées, JavaScript inutile, polices web multiples, vidéos auto-play. Chaque kilo-octet supplémentaire rallonge le Time to Interactive (TTI) et dégrade le ressenti utilisateur.

Sur mobile 4G moyen, une page de 3 Mo peut mettre 8 secondes à charger complètement. À ce stade, 53 % des visiteurs ont déjà quitté le site (source Google/SOASTA). Le calcul est brutal.

Quels indicateurs Google utilise-t-il pour mesurer cet impact ?

• First Contentful Paint (FCP) : premier élément visible à l'écran
• Largest Contentful Paint (LCP) : élément principal chargé (< 2,5 s idéalement)
• Cumulative Layout Shift (CLS) : stabilité visuelle pendant le chargement
• Time to Interactive (TTI) : moment où la page devient réellement utilisable
• Total Blocking Time (TBT) : durée pendant laquelle le thread principal est bloqué

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui — et c'est rare. Les tests A/B menés par Amazon, Walmart ou Shopify confirment qu'une seconde de délai supplémentaire = 7 à 10 % de perte de conversion en moyenne. Google ne sort pas ce constat de nulle part.

Là où ça coince : Google ne précise pas quel seuil de vitesse suffit. Un LCP à 2,4 s est techniquement « bon », mais un concurrent à 1,2 s peut vous écraser sur le taux de conversion — sans que l'algo vous pénalise pour autant.

Quelles nuances faut-il apporter ?

La vitesse n'est pas le seul facteur de conversion. Un site rapide mais mal designé, avec un tunnel d'achat bancal ou un pricing opaque, convertira toujours moins qu'un site moyen mais bien pensé. Soyons honnêtes : Google simplifie.

Autre point : la corrélation vitesse/conversion varie selon le secteur. En e-commerce fashion, où l'image prime, un site ultra-rapide qui charge des visuels pixelisés peut décevoir. L'équilibre qualité visuelle / poids / vitesse est délicat. [À vérifier] : Google ne fournit aucune donnée sectorielle pour affiner ce constat.

Dans quels cas cette règle ne s'applique-t-elle pas strictement ?

Sur des niches à très faible concurrence ou à intention très forte (ex : plateforme B2B ultra-spécialisée), un prospect tolérera 3-4 secondes de chargement s'il n'a aucune alternative crédible. La vitesse reste un plus, mais ne devient pas bloquante.

Que faut-il faire concrètement pour réduire le poids des pages ?

Priorité absolue : compresser les images. WebP ou AVIF réduisent le poids de 30 à 50 % vs JPEG sans perte visuelle notable. Utilisez le lazy loading natif pour les images below the fold.

Ensuite, auditer le JavaScript. Un seul pixel de tracking mal configuré peut charger 200 Ko de scripts tiers bloquants. Passez au chargement asynchrone ou différé (defer/async). Supprimez tout ce qui n'est pas critique pour le above the fold.

Enfin, activer la compression Brotli côté serveur (supérieur à Gzip) et mettre en cache agressivement les ressources statiques (Cache-Control max-age=31536000). Le CDN devient indispensable dès que vous visez l'international.

Quelles erreurs éviter absolument ?

• Charger des polices web multiples (2 maximum, subset uniquement les glyphes utiles)
• Ignorer le render-blocking CSS : inline le CSS critique, defer le reste
• Utiliser des carrousels auto-play avec 10 slides en 4K non optimisées
• Négliger le preload/prefetch pour les ressources critiques (LCP image, fonts)
• Laisser trainer des plugins WordPress/Shopify inutilisés qui injectent du code

Comment vérifier que mon site respecte ces bonnes pratiques ?

Lancez un audit PageSpeed Insights ou WebPageTest (de préférence avec throttling 4G). Ciblez un LCP < 2 s, un CLS < 0,1, un TBT < 200 ms. Si vous êtes dans le orange, c'est jouable — mais le concurrent dans le vert vous piquera du trafic.

Installez Lighthouse CI en intégration continue pour bloquer tout déploiement qui dégrade les métriques. Automatisez le monitoring via CrUX (Chrome User Experience Report) pour tracker la vitesse réelle des vrais utilisateurs, pas juste en labo.