Pourquoi les moyennes CWV sont un piège
On a passé trois jours à auditer un site e-commerce dont le LCP affiché dans la Search Console oscillait autour de 2,8 secondes. Un score correct, dans le vert selon les seuils documentés par Google. En surface, les Core Web Vitals semblaient sous contrôle. Le problème, c’est qu’en ouvrant les segments par âge dans GA4, l’indicateur volait en éclats. Pour les 18-24 ans sur mobile, le LCP atteignait 1,9 seconde. Pour les 55 ans et plus, toujours sur mobile, il grimpait à 4,7 secondes. La moyenne donnait une illusion de performance homogène.
L’agrégation noie les goulets d’étranglement que vous devez résoudre en priorité. Si votre site voit défiler un trafic majoritairement jeune, la moyenne restera flatteuse alors qu’une part significative de vos clients potentiels subit un temps de chargement dissuasif. À l’inverse, un site dont l’audience vieillit peut voir son LCP global se dégrader sans que personne ne comprenne pourquoi. Les moyennes empêchent de nommer le chantier. Elles offrent une fausse sécurité.
Quand on parle d’expérience utilisateur comme signal de classement, ce n’est pas l’expérience moyenne qui compte. Les systèmes de classement s’appuient sur les données de terrain Chrome, et ces données sont segmentables par origine, mais pas par âge ou genre. Pourtant, c’est exactement le croisement démographique qui révèle si votre dette technique impacte une population déjà mal équipée en matériel ou en bande passante. C’est ce croisement qui transforme un audit CWV en diagnostic social de votre performance réelle.
Activer les rapports démographiques dans GA4 sans trahir la conformité
La peur du tracking démographique, elle est légitime. Mais la technique ne pose aucun verrou insurmontable si on respecte les règles de consentement. Les données d’âge, de genre et de centres d’intérêt dans Google Analytics 4 proviennent du cookie publicitaire Google et des signaux de session. Leur collecte exige que l’utilisateur ait consenti aux fonctionnalités publicitaires via votre bandeau CMP, et que vous ayez activé l’option dans les paramètres de la propriété GA4.
Voici ce qu’on fait à chaque fois qu’on hérite d’un compte : on va dans Administration > Paramètres de la propriété > Collecte des données, et on bascule l’option « Activer les données démographiques et les centres d’intérêt ». Une fois cette option cochée, les dimensions Âge, Genre et Centres d’intérêt apparaissent dans les rapports standard. On paramètre aussi une conservation des données qui ne descende pas en dessous de 2 mois, pour pouvoir croiser les tendances sur un trimestre. Enfin, on documente dans la bannière de consentement une mention explicite pour « données de mesure d’audience étendue avec analyse démographique agrégée ».
Les équipes légal freinent souvent parce qu’elles imaginent un transfert de données personnelles. Mais GA4 ne délivre jamais d’informations individuelles sur un utilisateur : les rapports démographiques sont tous agrégés, avec des seuils minimaux de volume pour éviter la déduction d’identité. Si un segment ne contient pas assez d’utilisateurs, les données sont masquées. Ce n’est pas un piège réglementaire, c’est un garde-fou intégré.
Croiser âge, appareil et LCP : la méthode en trois étapes
La plupart des tableaux de bord qu’on voit en agence affichent le LCP par navigateur ou par pays. Les données démographiques restent enfermées dans un onglet « Audience » que personne ne croise avec les métriques de performance. Voici la méthode qu’on applique pour en faire un outil de debugging.
Étape 1 : créer un rapport personnalisé dans la section « Explorations » de GA4. On sélectionne la dimension « Âge » en ligne, et on ajoute en colonnes la métrique « Temps de chargement moyen de la page » (disponible depuis l’intégration avec les signaux Web). On filtre sur les pages stratégiques : la fiche produit la plus visitée, la landing de campagne, la page de checkout. Ne noyez pas le rapport sous cent URL.
Étape 2 : ajouter une dimension secondaire « Catégorie d’appareil » pour séparer mobile, tablette, desktop. Un LCP de 4,5 secondes chez les 45-54 ans en desktop n’a pas la même cause qu’un LCP identique chez les 25-34 ans sur mobile. Le croisement évite de se tromper de cible.
Étape 3 : exporter les données dans un tableur et calculer le ratio entre le LCP du segment le plus lent et le segment le plus rapide. Un rapport supérieur à 2 déclenche une investigation immédiate. On a vu des ratios dépasser 3,5 sur des boutiques en ligne grand public, sans que le propriétaire ne l’ait jamais soupçonné.
Ce que nous a appris un segment 55+ sur un site e-commerce
Je vais vous raconter un cas précis. Un site de prêt-à-porter, 200 000 pages indexées, Next.js 14, déploiement Vercel, un LCP global annoncé à 2,9 secondes. Le propriétaire voulait descendre sous 2,5 secondes pour rassurer son board. On a commencé par ouvrir les données démographiques. Le segment 55+ sur mobile affichait 5,4 secondes de LCP en moyenne. Un écart de plus de 2,5 secondes par rapport aux 25-34 ans sur desktop.
Le goulet d’étranglement ne venait ni du serveur ni du bundle JavaScript. En fouillant les enregistrements de session, on a repéré que les utilisateurs plus âgés arrivaient massivement sur la page d’accueil avec des terminaux Android 4G à mémoire limitée. Le LCP de la page d’accueil était une image plein écran chargée tardivement parce qu’elle dépendait d’un IntersectionObserver trop conservateur sur les viewports réduits. Les 55+ activaient rarement le scroll rapide, ce qui retardait le déclenchement du chargement de l’image principale.
Le correctif a été simple : appliquer fetchpriority="high" sur l’image critique et supprimer le lazy-loading conditionnel pour les viewports inférieurs à 600 pixels. Résultat : un LCP sur le segment 55+ ramené à 2,8 secondes, et un LCP moyen qui passe sous la barre des 2,5 sans même modifier le reste de l’application. Si on avait optimisé à partir de la moyenne, on aurait ciblé le mauvais problème, probablement en réduisant le bundle JS global plutôt qu’en corrigeant la priorité de chargement d’un seul élément. Croiser les données démographiques a fait économiser six semaines de développement.
💡 Conseil : Vérifiez dans GA4 le volume d’utilisateurs par segment 55+ avant de lancer un chantier. Si le segment représente moins de 5 % du trafic, un gain de 2 secondes ne modifiera pas significativement votre LCP moyen. L’analyse démographique ne remplace pas l’analyse de volume.
Pourquoi l’INP des moins de 25 ans peut cacher une catastrophe silencieuse
Pendant qu’on se focalise sur les segments lents, le profil jeune peut sembler performant. Sur le même site e-commerce, l’INP des 18-24 ans sur mobile s’établissait à 180 ms. Un score honorable. Pourtant, quand on a reproduit leur parcours sur un Moto G6 throttlé via DevTools, l’interaction sur le menu de navigation filtrait par saison prenait 420 ms. L’écart venait d’une librairie de state management qui déclenchait un re-rendu complet du catalogue au moindre clic sur un checkbox de filtre.
Les données de terrain Chrome masquaient le problème parce que les 18-24 ans équipés d’un iPhone récent faisaient baisser la moyenne. Mais l’appareil median de cette tranche d’âge n’est pas un flagship iOS : c’est un milieu de gamme Android livré avec un navigateur Chrome mal optimisé pour les boucles JavaScript synchrones. Si on se fie uniquement aux rapports standard, le problème est invisible. Si on segmente par âge et qu’on croise avec le type d’appareil, on le voit.
Ici, la correction n’a pas été de réécrire le code de filtrage, mais de le déplacer dans un Web Worker. Une librairie comme Zustand, qu’on utilise sur nos propres projets React, facilite ce découpage car son architecture zustand/vanilla permet de souscrire aux changements d’état sans forcer un rendu composant. Le tout, raccordé au worker via un proxy, a fait tomber l’INP sous les 150 ms même sur les terminaux d’entrée de gamme de 2019.
Dépasser l’analyse démographique : coupler avec les données de navigation réelles
Les données démographiques GA4 ont une faiblesse structurelle : elles ne fournissent pas la distribution des temps de réponse, seulement des moyennes. Un LCP moyen de 3 secondes sur un segment peut cacher une moitié d’utilisateurs à 1,8 seconde et une autre moitié à 5 secondes. Pour ne pas tomber dans le piège de la moyenne à l’intérieur même du segment, il faut systématiquement croiser les informations démographiques avec les données de navigation réelles issues de Chrome UX Report (CrUX) ou de la Search Console.
L’astuce consiste à utiliser l’API CrUX pour requêter les performances au niveau de l’origine en injectant un filtre par pays, par type de connexion (effectiveType) et par plage de temps. On n’obtient pas l’âge ni le genre, certes, mais on peut superposer la distribution des performances par pays ou par niveau de réseau avec ce qu’on observe dans GA4. Si un segment âgé sur mobile dégradé coïncide avec une forte proportion de connexions 3G en zone périurbaine, on a isolé la cause matérielle du goulet.
Sur un projet d’optimisation continue, on automatise ce croisement en exportant les données GA4 vers BigQuery, puis en joignant les tables avec les exports quotidiens de CrUX. C’est une infrastructure de suivi que peu d’équipes mettent en place, mais qui coûte moins de 20 euros par mois en requêtes BigQuery une fois le pipeline rodé. Si vous gérez un site où le ratio LCP varie de plus de 50 % entre deux segments d’âge, l’investissement vaut mieux que n’importe quel audit manuel.
Questions fréquentes
Est-ce que Google tient compte des données démographiques pour le classement ?
Non. Aucun signal documenté n’indique que les algorithmes de classement utilisent l’âge ou le genre des utilisateurs. En revanche, le score Core Web Vitals mesuré sur le terrain est une agrégation par segment d’appareil et de connexion, et ces segments sont corrélés aux données démographiques. Optimiser pour une population lente améliore le score CWV global et donc, indirectement, le classement.
Les données démographiques sont-elles disponibles pour tous les sites GA4 ?
Elles le sont uniquement si vous activez la fonctionnalité et que les utilisateurs consentent aux cookies publicitaires. Les sites à faible trafic, en dessous de 100 sessions par jour sur un segment, ne verront pas les rapports pour cause de seuils de confidentialité. Mais même avec 500 sessions quotidiennes, les tendances deviennent exploitables pour un diagnostic WCV segmenté.
Peut-on utiliser ces données pour améliorer le LCP sans développeur ?
Vous pouvez identifier les segments à problème, mais la correction nécessitera du développement. L’apport des données démographiques, c’est la priorisation du backlog : elles permettent d’obtenir un argument irréfutable auprès de la direction produit ou des développeurs en nommant précisément le segment d’utilisateurs qui subit le ralentissement.
