Les Core Web Vitals s'appliquent-ils au sous-domaine ou au domaine principal ?

Qu'entend-on exactement par "origine" dans le contexte des Core Web Vitals ?

Dans l'univers des navigateurs et de la sécurité web, l'origine se définit par trois composantes : le protocole (http ou https), le nom d'hôte complet (incluant le sous-domaine), et le port. Pour les Core Web Vitals, Google applique cette logique strictement via le Chrome User Experience Report (CrUX).

Cela signifie que https://www.exemple.com, https://blog.exemple.com et https://shop.exemple.com sont trois origines distinctes. Chacune collecte ses propres métriques d'expérience utilisateur, indépendamment des autres. Cette séparation n'est pas un choix de Google — c'est une contrainte technique du modèle de sécurité du web.

Pourquoi cette granularité au niveau du sous-domaine plutôt qu'au domaine racine ?

Le CrUX collecte des données réelles d'utilisateurs Chrome dans le monde entier. Ces données sont agrégées par origine pour respecter les normes de confidentialité et la logique de segmentation des navigateurs. Google n'a pas construit CrUX spécifiquement pour le SEO — c'est d'abord un outil de mesure d'expérience utilisateur générique.

Du coup, chaque sous-domaine hérite de sa propre stack technique, de son propre hébergement parfois, et donc de performances potentiellement très différentes. Un blog WordPress hébergé sur un VPS modeste et une application React sur un CDN premium ne peuvent pas être jugés avec les mêmes métriques. La granularité par origine reflète cette réalité technique.

Comment cette séparation impacte-t-elle le classement dans la recherche Google ?

Google utilise les données CrUX comme signal de ranking dans le cadre de la "Page Experience". Chaque origine étant évaluée séparément, un sous-domaine peut recevoir un boost de classement lié aux Core Web Vitals tandis qu'un autre sous-domaine du même domaine racine n'en bénéficie pas.

Soyons honnêtes : ce n'est pas un signal dominant. Mais dans des contextes concurrentiels où les autres facteurs sont équivalents, cette différence peut faire basculer une position. Un sous-domaine performant ne compense pas un sous-domaine principal à la traîne si la majorité du trafic SEO passe par ce dernier.

• Chaque sous-domaine est mesuré comme une entité distincte pour les Core Web Vitals
• Le protocole (http vs https) compte aussi — deux origines différentes
• Les données CrUX ne s'agrègent jamais au niveau du domaine racine
• Un sous-domaine sans trafic Chrome suffisant n'aura pas de données CrUX exploitables
• Cette logique s'applique aussi bien en desktop qu'en mobile, avec des datasets séparés

Cette déclaration est-elle cohérente avec ce qu'on observe sur le terrain ?

Oui, et c'est vérifiable facilement. Si tu interroges l'API CrUX ou que tu consultes le rapport PageSpeed Insights pour différents sous-domaines d'un même site, tu constateras des métriques totalement indépendantes. Un sous-domaine peut afficher "Bon" en LCP tandis qu'un autre est "À améliorer" — et c'est le cas sur des milliers de sites e-commerce où le blog est sur un sous-domaine distinct.

Ce qui est moins clair, c'est l'impact réel sur le ranking. Google reste très évasif sur le poids exact du signal Page Experience. Dans mes audits, j'ai vu des sites avec des Core Web Vitals catastrophiques sur leur sous-domaine principal continuer à ranker correctement grâce à d'autres signaux forts (autorité, contenu, backlinks). Le boost existe, mais il n'est pas miraculeux. [À vérifier] : Google n'a jamais publié de données chiffrées sur la pondération exacte de ce signal.

Quelles nuances faut-il apporter à cette règle ?

Premier point : si un sous-domaine ne reçoit pas assez de trafic Chrome, il n'aura tout simplement pas de données CrUX. Google exige un seuil minimum de données collectées sur 28 jours glissants. Dans ce cas, le sous-domaine n'est ni pénalisé ni favorisé — il est juste absent du dataset.

Deuxième nuance : les pages individuelles peuvent aussi avoir leurs propres données CrUX si elles génèrent suffisamment de trafic. Mais le signal de ranking, lui, s'applique généralement au niveau de l'origine. Si ton origine est "Mauvais", une page isolée avec de bonnes perfs ne suffit pas à renverser la tendance pour l'ensemble du sous-domaine.

Dans quels cas cette logique pose-t-elle problème ?

Pour les architectures multi-sous-domaines, c'est un casse-tête. Imagine un site e-commerce avec www pour le catalogue, account pour l'espace client, blog pour le contenu éditorial, et m pour le mobile. Chacun a sa propre stack, son propre hébergement, ses propres scripts tiers. Résultat : des performances hétérogènes qui se traduisent par des signaux de ranking fragmentés.

Et c'est là que ça coince : tu ne peux pas compenser une origine lente avec une origine rapide. Si 80 % de ton trafic SEO arrive sur www et que ce sous-domaine est en échec sur les Core Web Vitals, le fait que ton blog soit impeccable ne te sauvera pas. Il faut traiter chaque origine comme un projet d'optimisation distinct.

Que faut-il faire concrètement pour optimiser les Core Web Vitals par sous-domaine ?

Commence par cartographier tes origines. Liste tous les sous-domaines qui reçoivent du trafic SEO significatif. Pour chacun, interroge l'API CrUX ou utilise PageSpeed Insights pour récupérer les métriques réelles. Concentre-toi d'abord sur les sous-domaines qui génèrent le plus de pages vues organiques — c'est là que l'impact sera le plus direct.

Ensuite, traite chaque origine comme un projet technique distinct. Un blog WordPress lent nécessite des optimisations spécifiques (lazy loading, cache serveur, CDN pour les images). Une application React sur un autre sous-domaine aura besoin de code-splitting, de preload stratégique et d'optimisation du JavaScript. Ne cherche pas de solution unique — chaque stack a ses propres goulots d'étranglement.

Quelles erreurs éviter dans ce contexte ?

Erreur classique : optimiser aveuglément le mauvais sous-domaine. J'ai vu des équipes passer des semaines à améliorer un sous-domaine de staging ou un vieux blog abandonné qui ne reçoit plus de trafic, pendant que le sous-domaine principal restait catastrophique. Vérifie toujours la répartition du trafic organique avant de prioriser tes efforts.

Autre piège : croire qu'un bon score Lighthouse suffit. Lighthouse teste en environnement contrôlé — les Core Web Vitals se mesurent avec les données terrain de CrUX. Un site peut scorer 95/100 sur Lighthouse et être "Mauvais" en CrUX si les utilisateurs réels ont des connexions lentes, des devices faibles, ou interagissent avec des éléments lourds que Lighthouse ne teste pas.

Comment vérifier que chaque sous-domaine est correctement optimisé ?

Utilise la Search Console — elle agrège les données CrUX par origine et te montre quelles URLs sont "Bonnes", "À améliorer" ou "Mauvaises". C'est ton tableau de bord de priorisation. Pour chaque origine en échec, identifie les métriques problématiques (LCP, INP, CLS) et leurs causes profondes via des outils comme WebPageTest ou Chrome DevTools en mode throttling.

Surveille aussi les tendances sur 28 jours. Les Core Web Vitals sont des moyennes glissantes — une amélioration ne se reflète pas instantanément. Si tu déploies un fix, attends au minimum 2-3 semaines avant de juger son efficacité dans CrUX. Et garde un œil sur les régressions : un script tiers ajouté par le marketing peut ruiner tes efforts en 24h.

• Cartographier tous les sous-domaines recevant du trafic organique significatif
• Interroger l'API CrUX ou PageSpeed Insights pour chaque origine distincte
• Prioriser les optimisations selon le volume de trafic SEO par sous-domaine
• Traiter chaque stack technique séparément — pas de solution unique multi-origines
• Monitorer la Search Console pour détecter les régressions par origine
• Attendre 28 jours après un déploiement pour évaluer l'impact réel dans CrUX