Pour évaluer la performance d'une application monopage, mesurez le chargement initial du document, les changements de route suivants et les interactions entre ces étapes. Ces expériences sont liées, mais leurs limites diffèrent. Réagir rapidement à un clic ne prouve pas que la destination a chargé. De même, une bonne note à l'entrée ne décrit pas toutes les routes ouvertes ensuite.
Définir ce que mesure réellement le rapport
Une navigation complète crée un nouveau document. Dans une SPA, un changement de route classique modifie le document actuel. Changer l'adresse avec l'API History ne définit pas, à lui seul, une nouvelle mesure de performance dans tous les navigateurs et systèmes de rapport.
Distinguez la collecte par document de celle qui prend explicitement en charge les navigations douces. Cette prise en charge varie selon les navigateurs, les collecteurs et les rapports. Lorsque ces mesures existent, gardez leur identification au lieu de les fusionner silencieusement avec les chargements conventionnels. Un chronomètre applicatif de route est utile lui aussi, mais ne devient pas automatiquement LCP, INP ou CLS.
Les explications de Google sur la mesure des SPA montrent pourquoi le modèle de navigation importe. Vérifiez la définition du jeu de données fourni par votre outil avant de comparer les résultats. Une mesure absente indique un manque de couverture, pas une route instantanée.
Examiner séparément la route d'entrée
Ouvrez directement une destination importante dans une session vierge. Observez comment le navigateur découvre le contenu principal, télécharge les ressources et exécute le code nécessaire à l'affichage. Un rendu côté serveur ou un contenu prérendu peut faciliter une découverte plus précoce. L'hydratation peut néanmoins ajouter du travail lié aux interactions.
Séparez l'attente réseau, l'exécution et le rendu. Une route peut télécharger peu de données et rester bloquée pendant l'exécution de JavaScript. À l'inverse, réduire cette exécution ne résout pas une requête d'API lancée seulement après des dépendances évitables. Le guide LCP permet d'examiner le chemin du contenu visible sans attribuer le résultat au seul framework.
Définir quand une route devient utile
Pour une fiche produit, la disponibilité peut signifier que l'identité du produit, son prix actuel et l'action principale sont accessibles. Pour un article, elle peut correspondre à l'insertion du titre et du texte principal. Choisissez une définition adaptée à la tâche du visiteur et appliquez la même règle. La disparition d'un indicateur de chargement ne suffit pas si l'action suivante reste inaccessible.
Enregistrez le départ à l'événement du routeur qui représente l'intention de naviguer. Enregistrez la fin lorsque la condition choisie est satisfaite. Distinguez annulations, échecs et redirections des transitions réussies. Si une navigation en remplace une autre, ne laissez pas la fin tardive de la première devenir le résultat de la nouvelle route.
Ajouter un signal temporel de l'application
Cet exemple crée un chronomètre pour une transition achevée. Appelez beginRouteTiming() au début de la navigation, puis la fonction renvoyée lorsque votre condition de disponibilité est satisfaite. Utilisez un nom de route normalisé, comme article, plutôt qu'une URL contenant des informations personnelles.
function beginRouteTiming(routeName) {
const id = crypto.randomUUID();
const start = `route:${id}:start`;
const end = `route:${id}:end`;
const name = `route:${id}:ready`;
performance.mark(start);
return function finishRouteTiming() {
performance.mark(end);
const result = performance.measure(name, {
start,
end,
detail: { route: routeName }
});
performance.clearMarks(start);
performance.clearMarks(end);
performance.clearMeasures(name);
return result.duration;
};
}La durée renvoyée est exprimée en millisecondes. Cette fonction mesure l'intervalle entre des signaux applicatifs. Elle ne vérifie ni la présentation effective des pixels ni le respect d'un seuil Core Web Vitals. Reliez cette mesure au routeur et au cycle de rendu réellement utilisés. Ajoutez à cette intégration la suppression des traces lors d'une annulation et le signalement des erreurs. Les noms uniques séparent les mesures réussies simultanées, puis le nettoyage évite de conserver leurs entrées temporelles.
Une validation du rendu par le framework ou un rappel requestAnimationFrame ne prouve pas que tout le contenu utile est apparu. Comparez les signaux à une trace du navigateur et au comportement visible avant de décider ce que représente la mesure.
Séparer réactivité et chargement de la destination
INP concerne la réponse aux interactions jusqu'au prochain affichage. Un clic peut immédiatement faire apparaître un état de chargement alors que la destination reste indisponible. L'interaction peut donc être réactive et la route lente en même temps. Conservez ces deux observations au lieu d'appeler INP la durée complète du changement de route.
Examinez les gestionnaires coûteux, le rendu synchrone et les recalculs de disposition répétés. Différez le travail qui ne contribue pas à la réponse immédiate et affichez un progrès fidèle à la situation. Si le thread principal est occupé après le clic, regardez la trace avant de modifier les paramètres réseau. Le guide INP aide à préciser le diagnostic.
Charger le nécessaire sans déstabiliser la vue
Découper le code par route peut réduire le travail inutile à l'entrée, mais une nouvelle chaîne de requêtes dépendantes peut retarder la destination. Lancez ensemble les tâches indépendantes de données et de code lorsque l'architecture le permet. Privilégiez un préchargement sélectif : le travail spéculatif peut concurrencer la route en cours d'utilisation.
Réservez de la place pour les images et les panneaux asynchrones. Gardez une navigation stable et évitez d'insérer tardivement du contenu avant le contenu que le visiteur lit. Un mouvement peut rester gênant même lorsqu'un déplacement particulier est exclu de CLS en raison d'une interaction récente. Évaluez aussi l'expérience visible.
Comparer des parcours et des données équivalents
Testez l'entrée directe, la navigation interne, les retours sur une route, les commandes précédent et suivant, ainsi qu'une transition avec une arrivée lente des données. Incluez une requête échouée et une transition abandonnée. Gardez comparables l'état du cache et les conditions de l'appareil. Sinon, une route déjà préparée peut sembler prouver un gain qui provient seulement d'un travail antérieur.
Les bonnes limites sont LCP inférieur ou égal à 2.5 s, INP inférieur ou égal à 200 ms et CLS inférieur ou égal à 0.1, au 75e percentile, avec mobile et ordinateur séparés. Elles s'appliquent aux mesures définies des Core Web Vitals, pas à des chronomètres applicatifs arbitraires. Vérifiez si le rapport représente une URL, une origine, des chargements de documents ou des navigations douces identifiées.
Rattachez le contexte de route à l'interaction ou à la transition qui l'a produit. N'utilisez pas simplement l'URL active au moment de l'envoi de la télémétrie. Consultez la différence entre données de terrain et de laboratoire avant de généraliser une trace locale satisfaisante à tous les visiteurs. Un rapport utile rend les parcours lents identifiables et les corrections vérifiables.
