Site plus lent et baisse du taux de conversion : comment trouver la modification en cause

Un site plus lent peut-il faire baisser le taux de conversion ?

Oui, mais le ralentissement n'est la cause que s'il a commencé avant la baisse et touché les pages et les appareils où les conversions ont chuté. Les problèmes de vitesse arrivent rarement seuls : la mise en ligne qui a alourdi les pages a souvent aussi modifié la mise en page, le formulaire ou le tracking.

La vitesse compte parce que les visiteurs qui attendent le contenu principal, ou qui touchent un bouton sans réaction, partent avant d'atteindre le panier ou le formulaire de contact. Google mesure ces moments avec trois Core Web Vitals : Largest Contentful Paint (LCP) pour le chargement, Interaction to Next Paint (INP) pour la réactivité et Cumulative Layout Shift (CLS) pour la stabilité visuelle.

Cet article ne promet pas un nombre de ventes perdues par seconde de délai. Les chiffres publiés varient selon les sites et viennent souvent d'études d'éditeurs. Ce que vous pouvez faire, c'est montrer avec vos propres données qu'une modification datée a ralenti les pages et que les conversions ont baissé sur ces mêmes pages, au même moment. Pour la méthode générale face à toute baisse, voyez comment expliquer une baisse de conversions à un client.

Quelles modifications ralentissent le plus souvent un site ?

La plupart des pertes de vitesse viennent d'une modification publiée par quelqu'un, pas de Google ni de l'hébergeur. Les suspects habituels sont les nouveaux scripts, les médias plus lourds et les mises en ligne de code.

Le guide de Google sur les balises explique que le temps du thread principal sert à évaluer et exécuter le JavaScript du gestionnaire de balises et des balises elles-mêmes, et ses auteurs constatent une corrélation entre la taille des conteneurs et un INP moins bon. Les balises en double, comme un pixel codé en dur dans le HTML et injecté à nouveau par GTM, alourdissent la page sans apporter de données. Si vous soupçonnez une balise, commencez par l'historique des versions de GTM.

Comment vérifier que le site a vraiment ralenti ?

Comparez les données terrain des vrais utilisateurs avant et après la modification suspecte, et servez-vous des tests en laboratoire uniquement pour trouver la cause. Un score Lighthouse isolé ne prouve rien : Google précise que les résultats de laboratoire varient d'une exécution à l'autre selon le réseau, le matériel et la concurrence pour les ressources.

Google évalue chaque indicateur au 75e centile des pages vues. Trois outils couvrent la plupart des cas :

• PageSpeed Insights affiche les données terrain du Chrome UX Report sur les 28 jours précédents, au niveau de l'URL ou, si l'URL manque de données, au niveau de l'origine, ainsi qu'un test Lighthouse en laboratoire.
• Le rapport Core Web Vitals de la Search Console regroupe les URL similaires et indique combien sont bonnes, à améliorer ou mauvaises sur les 28 derniers jours. Les groupes sans données suffisantes n'apparaissent pas.
• Votre propre suivi des utilisateurs réels, si vous en avez un, est la seule source qui montre un saut quotidien le jour d'une mise en ligne.

La fenêtre de 28 jours compte pour la datation. Comme PageSpeed Insights agrège chaque jour les 28 jours précédents, un ralentissement commencé un mardi apparaît comme une hausse progressive sur les semaines suivantes, pas comme une marche. Repérez la date où la courbe commence à s'infléchir, puis confirmez-la par des tests en laboratoire de l'ancienne et de la nouvelle version.

Comment isoler la modification qui a causé le ralentissement et la baisse ?

Placez sur une seule frise chronologique toutes les modifications de la semaine précédant la baisse, écartez d'abord le tracking, puis testez l'hypothèse de la vitesse sur les pages qui ont ralenti. Une baisse des conversions mesurées peut aussi venir d'une balise cassée : vérifiez que la balise de conversion se déclenche toujours sur la nouvelle version avant d'accuser la vitesse.

1. Notez le jour de la baisse et l'endroit : panier sur mobile, une landing page ou tout le site.
2. Listez toutes les modifications des 7 à 14 jours précédents : mises en ligne, mises à jour de thème ou d'extension, versions GTM, nouveaux scripts et changements de consentement, ainsi que les modifications publicitaires comme les enchères, les budgets et les URL finales.
3. Marquez les modifications qui ont touché les pages en baisse. Un nouveau script sur toutes les pages et une baisse limitée au panier mobile orientent vers la réactivité sur mobile.
4. Testez en laboratoire l'ancienne et la nouvelle version de la page et cherchez le script ou le fichier qui ajoute le plus de temps.

Exemple : une boutique de meubles en ligne demande pourquoi les ventes mobiles ont chuté mardi alors que l'ordinateur a tenu. En alignant les modifications, on voit une balise de chat ajoutée dans GTM vendredi, une nouvelle vidéo principale sur les fiches produit samedi et aucune modification publicitaire. Les tests en laboratoire montrent que la vidéo est devenue l'élément LCP et se charge bien plus tard que l'ancienne image. L'équipe remplace la vidéo par une image fixe et les ventes mobiles reviennent la semaine suivante. Noms et chiffres sont fictifs.

Avec toutes les modifications sur une seule frise chronologique, vous verriez que la vidéo a été mise en ligne trois jours avant la baisse, sur le gabarit même où les ventes mobiles ont chuté. Dans Changeline, vous enregistrez chaque mise en ligne, balise et changement de consentement avec la date, le responsable et la raison, et les modifications Google Ads sont importées automatiquement : la liste de l'étape 2 existe déjà quand la question arrive.

Comment prouver que c'est le ralentissement, et rien d'autre, qui a fait baisser les conversions ?

Vous le prouvez en montrant que trois éléments concordent : le ralentissement a commencé avec la modification, les conversions n'ont baissé que sur les pages et les appareils concernés, et elles sont revenues après l'annulation ou la correction.

1. Vérifier que le tracking se déclenche
2. Dater le ralentissement sur le terrain
3. Comparer pages touchées et autres
4. Annuler ou corriger la modification
5. Suivre le retour des conversions

• Segmentez par appareil et par page. Si le taux de conversion sur ordinateur a tenu, que celui du mobile a baissé et que le ralentissement concerne surtout le mobile, c'est un indice solide. Une baisse sur tous les appareils et toutes les pages oriente ailleurs.
• Vérifiez la répartition du trafic. Une nouvelle campagne, audience ou un nouveau budget peut amener des visiteurs moins qualifiés le même jour. Regardez le taux de conversion par source avant d'accuser la vitesse. Les autres causes sont détaillées dans pourquoi le taux de conversion baisse.
• Utilisez un groupe témoin. Les pages qui n'ont pas reçu le nouveau script ou fichier forment votre groupe témoin. Si elles sont restées stables, la modification est la cause la plus probable.
• Annulez et observez. Retirer le script ou revenir à la version précédente est le test le plus net. Enregistrez l'annulation comme une modification à part entière pour que le retour soit daté lui aussi.

Gardez les preuves par écrit : la modification, la date, les mesures de laboratoire avant et après, et le taux de conversion sur les pages touchées et les autres. C'est ce que demandera le client ou votre responsable, et cela évite que le même débat reprenne un mois plus tard.

Comment éviter que le ralentissement revienne ?

Intégrez la vitesse à chaque mise en ligne et à chaque nouvelle balise, et gardez une trace de ce qui a été publié et quand. La plupart des régressions reviennent parce qu'un script est ajouté à nouveau ou que plus personne ne sait pourquoi il avait été retiré.

Google recommande de mettre en pause ou de supprimer les balises inutilisées plutôt que de les bloquer par une exception de déclencheur, car une balise bloquée reste dans le code du conteneur. Un journal des modifications marketing partagé donne aux développeurs et aux équipes marketing une seule source à consulter, et le journal des modifications du site détaille la partie site.