Dimension Core/Dash : Origine de navigation

Ce que mesure l'origine de navigation

La dimension Origine de navigation divise vos données de terrain en deux groupes :

• Même origine (1) — la page précédente se trouvait sur le même domaine.
• Origine croisée (2) — l'utilisateur est arrivé depuis un domaine différent, un moteur de recherche, une plateforme sociale, ou a saisi l'URL directement.

Cette distinction est importante car les conditions de départ du navigateur sont complètement différentes dans chaque cas. Une navigation de même origine peut réutiliser une connexion existante, s'appuyer sur le cache HTTP pour les sous-ressources, et bénéficier de tout préchargement configuré sur votre site. Une navigation d'origine croisée part de zéro.

Pourquoi les navigations d'origine croisée sont plus lentes

Lorsqu'un utilisateur clique sur un lien depuis un site externe, le navigateur a du travail à faire avant même de pouvoir demander votre HTML :

1. Recherche DNS — résoudre votre domaine en une adresse IP.
2. Handshake TCP — ouvrir une connexion avec votre serveur.
3. Négociation TLS — terminer le handshake HTTPS.

Ensemble, ces étapes ajoutent généralement 200 à 500 ms sur une connexion mobile avant que le premier octet de votre page ne soit demandé. Ce coût se reflète directement dans le Time to First Byte (TTFB), et si votre élément LCP dépend d'une ressource chargée après l'arrivée du HTML, cela se répercute en un Largest Contentful Paint (LCP) dégradé également.

Les sous-ressources mises en cache sont également indisponibles. Un visiteur ayant cliqué depuis Google ne possède aucune copie en cache de vos polices, de votre image hero ou de votre CSS critique. Un visiteur venant tout juste de votre page d'accueil possède probablement tous ces éléments.

Navigations de même origine et back-forward cache

Les navigations de même origine ouvrent la porte à deux avantages en termes de performances que les navigations d'origine croisée ne peuvent pas utiliser de manière aussi fiable.

Premièrement, l'API Speculation Rules vous permet de précharger ou de pré-rendre les pages internes avant que l'utilisateur ne clique. Le navigateur peut avoir la page suivante entièrement rendue dans un onglet en arrière-plan, rendant la navigation instantanée. Cela ne s'applique qu'aux destinations de même origine.

Deuxièmement, le back-forward cache (bfcache) restaure une page depuis la mémoire lorsque l'utilisateur appuie sur le bouton retour. Les succès du bfcache sont extrêmement rapides et obtiennent d'excellents scores sur tous les Core Web Vitals. Ils apparaissent dans vos données comme des navigations de même origine. Si votre LCP de même origine est significativement meilleur que votre LCP d'origine croisée, le bfcache et le prefetch contribuent probablement à cet écart.

Comment lire cette dimension dans CoreDash

Dans CoreDash, utilisez l'Origine de navigation comme filtre ou comme dimension de répartition aux côtés de n'importe quelle métrique. La comparaison la plus utile est le LCP par origine de navigation. Un écart important entre le LCP de même origine et d'origine croisée vous indique l'une des trois choses suivantes :

• Vos pages d'entrée d'origine croisée ont un TTFB lent qui gonfle le LCP.
• Les navigations de même origine bénéficient du prefetch ou du bfcache, contrairement à vos pages d'origine croisée.
• Vos sous-ressources en cache aident les visiteurs récurrents, mais pas les nouveaux arrivants provenant de sources externes.

Les données d'origine croisée constituent généralement le chiffre le plus important pour le SEO. Le Chrome UX Report (CrUX) de Google inclut tous les types de navigation, mais le trafic de recherche organique est presque entièrement d'origine croisée. Si votre LCP d'origine croisée réussit alors que votre LCP de même origine échoue, c'est inhabituel et mérite d'être examiné. L'inverse est beaucoup plus fréquent.

Réduire la pénalité d'origine croisée

Vous ne pouvez pas éliminer entièrement la pénalité de démarrage à froid, mais vous pouvez la réduire :

• Utilisez un CDN avec un TTFB rapide. La surcharge de connexion diminue lorsque votre serveur est géographiquement proche de l'utilisateur et répond rapidement. Ciblez un TTFB inférieur à 200 ms pour le document HTML.
• Préchargez l'image LCP. Une balise <link rel="preload"> dans le <head> démarre la récupération de l'image le plus tôt possible, réduisant le temps entre la livraison du HTML et le rendu de l'élément LCP.
• Intégrez le CSS critique (inline). L'absence de requête de feuille de style bloquant le rendu signifie que le navigateur peut peindre plus tôt, même sur une connexion à froid.
• Ajoutez des indications preconnect pour les origines tierces. Si votre image LCP ou une ressource bloquant le rendu est hébergée sur un domaine différent, une indication rel="preconnect" démarre le travail TCP et TLS plus tôt.

Pour les navigations de même origine, l'API Speculation Rules est l'amélioration ayant le plus fort impact disponible aujourd'hui. Le pré-rendu de la page suivante la plus probable réduit le LCP à près de zéro pour ces transitions.

L'origine de navigation dans son contexte

L'origine de navigation fonctionne bien avec la dimension Type de navigation (qui sépare la navigation, le rechargement, le back-forward et le pré-rendu) et la dimension Type de connexion effectif (Effective Connection Type). Une navigation d'origine croisée sur une connexion lente est le scénario le plus difficile auquel votre site est confronté. Filtrer sur ces deux conditions simultanément vous montrera vos véritables performances dans le pire des cas et où se trouvent les plus grandes améliorations possibles.