Dimension Core/Dash : Origine de la navigation

Ce que mesure l'Origine de la navigation

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

• Même origine (Same Origin - 1) — la page précédente était sur le même domaine.
• Origine croisée (Cross Origin - 2) — l'utilisateur est arrivé depuis un domaine différent, un moteur de recherche, un réseau social, ou a saisi l'URL directement.

Cette distinction est cruciale car les conditions de départ du navigateur sont radicalement différentes dans chaque cas. Une navigation same-origin peut réutiliser une connexion existante, s'appuyer sur le cache HTTP pour les sous-ressources, et bénéficier de tout prefetching configuré sur votre site. Une navigation cross-origin repart de zéro.

Pourquoi les navigations cross-origin 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 requêter 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 — compléter le handshake HTTPS.

Ensemble, ces étapes ajoutent généralement 200 à 500 ms sur une connexion mobile avant même que le premier octet de votre page ne soit demandé. Ce coût se répercute directement sur 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, il entraîne également un moins bon Largest Contentful Paint (LCP).

Les sous-ressources 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 qui vient de quitter votre page d'accueil possède probablement déjà tout cela.

Les navigations same-origin et le back-forward cache

Les navigations same-origin ouvrent la porte à deux avantages de performance que les navigations cross-origin ne peuvent pas exploiter de manière aussi fiable.

Premièrement, la Speculation Rules API vous permet de précharger (prefetch) ou de pré-rendre (prerender) des 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 same-origin.

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

Comment lire cette dimension dans CoreDash

Dans CoreDash, utilisez l'Origine de la navigation comme filtre ou comme dimension de répartition (breakdown) aux côtés de n'importe quelle métrique. La comparaison la plus utile est le LCP par origine de navigation. Un grand écart entre le LCP same-origin et cross-origin vous indique l'une de ces trois choses :

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

Les données cross-origin représentent 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 cross-origin. Si votre LCP cross-origin réussit alors que votre LCP same-origin échoue, c'est inhabituel et mérite d'être investigué. L'inverse est beaucoup plus fréquent.

Réduire la pénalité cross-origin

Vous ne pouvez pas éliminer complètement la pénalité du démarrage à froid (cold-start), 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. Visez un TTFB inférieur à 200 ms pour le document HTML.
• Préchargez l'image LCP. Un <link rel="preload"> dans la balise <head> lance la récupération de l'image le plus tôt possible, réduisant ainsi le temps entre la livraison du HTML et l'affichage (paint) de l'élément LCP.
• Intégrez (inline) le CSS critique. L'absence de requête de feuille de style bloquant le rendu signifie que le navigateur peut afficher la page 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 same-origin, la Speculation Rules API est l'amélioration ayant le plus d'impact disponible aujourd'hui. Pré-rendre (prerendering) la page suivante la plus probable réduit le LCP à presque zéro pour ces transitions.

L'Origine de la navigation en contexte

L'Origine de la navigation fonctionne bien avec la dimension Type de navigation (qui sépare navigate, reload, back-forward, et prerender) et la dimension Type de connexion effective (Effective Connection Type). Une navigation cross-origin 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.