Réponses aux questions fréquentes sur les SPA, les Core Web Vitals et la façon dont ces dernières les traitent.
Publié le 14 septembre 2021, dernière mise à jour le 11 août 2026
Depuis le lancement de l'initiative Web Vitals en mai 2020, l'équipe Chrome a reçu de nombreuses questions et commentaires intéressants sur le programme.
Le sujet qui a suscité le plus de questions, et qui est aussi probablement le plus difficile à aborder, est celui de la mesure des Core Web Vitals dans une application monopage (SPA), ainsi que de l'impact des architectures SPA sur les scores Core Web Vitals.
Il est difficile de répondre à ces questions, car le problème est assez nuancé. Dans cet article, nous allons faire de notre mieux pour répondre aux questions les plus fréquentes, en fournissant autant de détails et de contexte que possible.
Avant d'entrer dans les détails, il est important de préciser que Google n'a aucune préférence quant à l'architecture ou à la technologie utilisées pour créer un site. Nous pensons que les SPA et les applications multipages (MPA) sont toutes deux capables d'offrir une expérience de qualité aux utilisateurs. Notre objectif avec l'initiative Web Vitals est de fournir des métriques qui mesurent l'expérience indépendamment de la technologie.
Questions fréquentes
Voici quelques-unes des questions les plus fréquentes que nous recevons à ce sujet. N'hésitez pas à nous faire part de vos commentaires pour compléter cette FAQ dans notre groupe de commentaires ou en signalant un problème.
Les métriques Core Web Vitals incluent-elles les transitions de route SPA ?
Lors de leur introduction, chacune des métriques Core Web Vitals était mesurée par rapport à la navigation de la page de premier niveau actuelle. Si une page chargeait dynamiquement du nouveau contenu et mettait à jour son URL dans la barre d'adresse, cela n'aurait aucun effet sur la façon dont les métriques Core Web Vitals sont mesurées.
Les valeurs des métriques n'étaient pas réinitialisées, et l'URL associée à chaque mesure de métrique est celle vers laquelle l'utilisateur a navigué et qui a lancé le chargement de page.
Chrome 151 a introduit de nouvelles API qui permettent de mesurer les Core Web Vitals lors des transitions de route SPA. Au moment de la rédaction de cet article (août 2026), ces API commencent tout juste à être utilisées dans des bibliothèques de mesure telles que web-vitals, des solutions RUM et des outils tels que les Outils pour les développeurs Chrome. Chrome n'a pas encore publié de calendrier d'intégration de ces API dans le rapport sur l'expérience utilisateur de Chrome (CrUX). De plus, d'autres moteurs de navigateur ne sont pas encore compatibles avec ces nouvelles API. Par conséquent, les Core Web Vitals ne peuvent être mesurées que lors du chargement complet des pages pour ces navigateurs.
Pourquoi ce problème était-il difficile à résoudre ?
Il n'existe pas de méthode standardisée pour créer une SPA aujourd'hui. Même parmi les bibliothèques de routage et de SPA populaires, l'expérience utilisateur peut être très différente d'une application à l'autre :
- Certaines SPA ne mettent à jour l'URL que lors du chargement d'un nouveau contenu de "page complète", tandis que d'autres sites mettent à jour l'URL pour de petites modifications de contenu ou même simplement pour des changements d'état de l'interface utilisateur.
- Certaines SPA mettent à jour l'URL à l'aide de l'API History, tandis que d'autres utilisent des modifications de hachage pour prendre en charge les anciens navigateurs (et d'autres ne mettent pas du tout à jour l'URL).
- Certaines SPA chargent le contenu, puis mettent à jour l'URL, tandis que d'autres mettent à jour l'URL avant de charger le contenu.
- Certaines SPA chargent le contenu en une seule fois, de manière synchrone, dans une seule tâche JavaScript, tandis que d'autres font passer le contenu de manière asynchrone sur plusieurs tâches (sans événement de fin de transition clair).
- Certaines SPA chargent toujours le contenu à partir du réseau, tandis que d'autres préchargent tout le contenu à l'avance afin que les modifications de route se chargent instantanément à partir de la mémoire.
Ces différences rendent très difficile la définition et l'identification de ce qui constitue une modification de route SPA, voire une SPA elle-même, à grande échelle.
Dans certains cas, une modification de route SPA est logiquement identique à un chargement de page MPA. Dans ce cas, il serait intéressant que les métriques Core Web Vitals existantes puissent être appliquées.
Toutefois, sans heuristique solide pour identifier de manière fiable les modifications de route "réelles" par rapport à toutes les autres modifications d'URL, ainsi que des signaux clairs marquant le début et la fin de ces transitions, le reporting des métriques Core Web Vitals dans ces cas brouillerait les données et les rendrait moins utiles ou représentatives de l'expérience utilisateur réelle sur le site.
Le travail sur la navigation douce a fourni une solution à ce problème avec deux nouvelles API de performances :
PerformanceSoftNavigation, qui mesure le moment où une interaction de l'utilisateur entraîne à la fois un paint et une modification d'URL. La combinaison de ces trois éléments fournit une définition standardisée d'une "navigation douce", quel que soit le framework utilisé et certaines des différences mentionnées précédemment. Cela permet de diviser la chronologie des performances en "navigations" distinctes, ce qui permet de mesurer le CLS et l'INP pour chaque navigation.InteractionContentfulPaint, qui mesure les "paints de contenu" après une interaction, ce qui permet de mesurer le FCP et le LCP pour ces navigations douces.
La combinaison de ces deux API permet de mesurer les Core Web Vitals lors du chargement complet des pages et des navigations douces.
Les modifications de route SPA sont-elles identiques au chargement complet des pages pour les Core Web Vitals ?
Non, il existe encore de nombreuses différences entre ces types de navigation, ce qui peut entraîner des métriques Core Web Vitals différentes.
Une navigation douce contient du contenu sur la page et met à jour une partie ou la totalité de ce contenu pour afficher la nouvelle "page". À bien des égards, cela ressemble à la différence entre un chargement complet de page non mis en cache et un chargement de page lorsque certaines ou toutes les ressources de la page sont mises en cache, mais à un état encore plus extrême, car certains contenus peuvent rester affichés.
En théorie, la principale différence réside dans le fait que les navigations douces peuvent être beaucoup plus rapides. Mais il existe d'autres différences plus subtiles.
Les nouvelles API de navigation douce ne prennent en compte que le nouveau contenu. Par conséquent, une page qui met à jour le <h1> et le contenu textuel, mais qui laisse la même image héros entre les pages, ne considérera pas l'image héros comme un candidat LCP si elle n'a pas été repeinte. Cela entraînera des différences dans les éléments utilisés pour calculer le temps LCP selon que la même page est chargée comme un chargement complet de page ou comme une navigation douce à partir d'une autre page existante.
De même, l'INP peut être inférieur pour les navigations douces, car une grande partie du code JavaScript nécessaire à l'exécution du site sera déjà chargée. De la même manière, une navigation douce peut avoir un CLS inférieur (ou supérieur !) si le même contenu provoque un CLS lors d'un chargement complet de page, mais n'a pas besoin d'être chargé ou rendu à nouveau lors d'une navigation douce.
Il existe également de légères différences dans le moment où les mesures sont prises lors du chargement complet des pages (mesurées après le traitement de l'interaction de navigation) par rapport aux navigations douces (mesurées à partir de l'heure de début de l'interaction).
Comme indiqué précédemment, bon nombre de ces différences sont similaires à celles entre les pages non mises en cache et celles mises en cache, et le concept de ce que les Core Web Vitals tentent de mesurer s'applique toujours. Toutefois, il est utile de comprendre ces subtilités lors de l'examen des problèmes liés aux Core Web Vitals.
Est-il plus difficile pour les SPA d'obtenir de bons résultats sur les Core Web Vitals que pour les MPA ?
L'architecture SPA n'a rien d'inhérent qui empêcherait une page d'une SPA de se charger aussi rapidement qu'une page similaire dans une MPA et d'obtenir un score aussi bon sur toutes les métriques Core Web Vitals.
Toutefois, les MPA correctement optimisées présentent certains avantages pour atteindre les seuils Core Web Vitals que les SPA n'ont pas. Cela a été largement atténué par le travail sur les navigations douces évoqué précédemment, mais cela peut toujours être le cas lorsque ces nouvelles API ne sont pas encore utilisées. En effet, avec l'architecture MPA, chaque "page" est chargée comme une navigation en plein écran (plutôt que de récupérer dynamiquement du contenu et de l'insérer dans la page existante). Cela signifie que les utilisateurs qui visitent une MPA sont plus susceptibles de charger plusieurs pages du site, ce qui signifie qu'un pourcentage plus élevé de la distribution de tous les chargements de page pour une MPA impliquera la mise en cache de certaines ou de toutes les sous-ressources.
Certes, pour qu'une MPA obtienne de meilleurs résultats sur les métriques Core Web Vitals qu'une SPA, plusieurs conditions doivent être remplies :
- La MPA doit avoir optimisé la mise en cache des sous-ressources afin de s'assurer que les chargements de page de même origine sont effectivement plus rapides que les chargements de page interorigines au 75e centile.
- Les utilisateurs qui visitent des MPA doivent consulter plusieurs pages pour que le site bénéficie des avantages de la mise en cache qui se traduisent par des chargements de page plus rapides.
Étant donné que les évaluations Core Web Vitals tiennent compte du 75e centile des visites de page, plus le nombre de visites de page performantes est élevé dans l'ensemble de données, plus il est probable que la visite au 75e centile de la distribution se situe dans les seuils recommandés.
Notez qu'un élément important à prendre en compte lors de la comparaison des scores Core Web Vitals est la façon dont les données sont agrégées, c'est-à-dire si l'ensemble de données de la distribution inclut toutes les pages de votre site ou de votre origine, ou uniquement les chargements de page pour une URL de page spécifique.
Lorsque vous agrégez les scores de toutes les pages d'une origine, les pages individuelles rapides peuvent améliorer le 75e centile de l'origine dans son ensemble. Toutefois, lorsque vous agrégez par page individuelle, les scores d'une page n'affectent pas les scores de la page suivante. En d'autres termes, lorsque vous agrégez les scores d'une MPA par page, les chargements rapides du cache observés sur la page de paiement n'amélioreront pas les scores des chargements initiaux lents observés sur la page de destination du site.
Vous pouvez vérifier le score de votre site pour différentes méthodes d'agrégation à l'aide de PageSpeed Insights ou l'API du rapport sur l'expérience utilisateur de Chrome, qui indique les scores pour les URL de pages individuelles et pour l'ensemble de l'origine.
L'architecture SPA peut également affecter les scores Core Web Vitals pour les métriques qui tiennent compte de la durée de vie complète d'une page. Étant donné que les utilisateurs qui visitent des SPA ont tendance à rester sur la même "page" pendant toute la session, les métriques qui s'accumulent au fil du temps peuvent être plus sévères pour les SPA que pour les MPA.
Grâce au travail sur les navigations douces, nous pensons qu'il ne devrait pas y avoir d'inconvénients pour les SPA en termes de mesure des Core Web Vitals. Toutefois, l'intégration complète de ces API dans tous les outils et solutions de reporting prendra du temps.
Si les architectures SPA améliorent l'expérience utilisateur, cette amélioration ne devrait-elle pas se refléter dans les métriques ?
Oui, elle devrait. Il était difficile de quantifier l'amélioration de l'expérience à grande échelle, compte tenu des différentes façons dont les SPA sont implémentées sur le Web aujourd'hui. Nous avons maintenant une solution au problème de mesure, et lorsque ces nouvelles API sont utilisées, toutes les améliorations apportées par le passage aux SPA devraient se refléter dans les métriques.
En réalité, le secteur des performances Web (y compris Google) n'a historiquement pas investi autant de temps et d'efforts dans le développement de métriques centrées sur l'utilisateur pour les performances post-chargement d'une page que pour le chargement de page elle-même. Ce n'est pas parce que les performances post-chargement ne sont pas importantes, mais parce que l'UX et les interactions post-chargement sont beaucoup plus variées et moins bien définies, ce qui rend difficile la conception de métriques pour elles.
Mais même maintenant que nous disposons de plus de métriques post-chargement pour mesurer les performances des SPA, nous ne voulons pas ignorer l'expérience de chargement simplement parce que l'expérience post-chargement s'est améliorée.
L'un des objectifs de l'initiative Web Vitals est de promouvoir et d'encourager les bonnes expériences utilisateur dans autant d'aspects que possible du chargement et de l'utilisation d'une page Web. Nous ne voulons pas encourager les scénarios dans lesquels les mauvaises expériences sont justifiées si vous pouvez avoir suffisamment de bonnes expériences pour les compenser. Les utilisateurs veulent que les pages se chargent rapidement et passent rapidement à un nouveau contenu. Nous avons donc essayé de concevoir des métriques qui favorisent ces types d'expériences.
Nous avons migré notre site d'une MPA vers une SPA et nos scores ont régressé. Est-ce normal ?
Cela dépend. Plusieurs raisons peuvent expliquer pourquoi vos scores peuvent changer après une migration d'architecture majeure, mais une diminution du nombre de chargements de cache chaud peut expliquer une partie de ce changement.
Pour vérifier rapidement, testez une version MPA et une version SPA de l'une de vos pages de destination avec Lighthouse. Si le score Lighthouse est inférieur pour l'une des métriques Core Web Vitals de la version SPA, il est probable que l'expérience de chargement se soit détériorée après la mise à jour.
Dois-je passer mon site d'une SPA à une MPA pour obtenir de meilleurs scores sur les Core Web Vitals ?
Probablement pas. Vous ne devez passer d'une SPA à une MPA que si vous n'êtes pas satisfait de votre pile SPA et que vous avez des raisons de croire qu'une MPA offrira une meilleure expérience utilisateur.
Grâce au travail sur les navigations douces, nous pensons avoir résolu les problèmes de mesure. Il n'est donc pas judicieux de migrer pour cette seule raison.
Toutefois, si vous avez des raisons de montrer que les performances s'amélioreront, plutôt que de simplement améliorer les mesures, cela peut être une raison de passer d'une SPA à une MPA (ou inversement).
Si les scores Core Web Vitals ne sont signalés que pour les pages de destination d'une SPA, comment puis-je déboguer les problèmes qui se produisent sur les "pages" après une transition de route ?
Les outils Google qui signalent les données de terrain pour la métrique Core Web Vitals (comme la Search Console et PageSpeed Insights) obtiennent leurs données du rapport d'expérience utilisateur Chrome (CrUX). CrUX agrège les données par origine ou par URL de page (c'est-à-dire l'URL de la page au moment du chargement).
Nous travaillons à permettre à CrUX d'inclure des données par route SPA dans ses données agrégées. Toutefois, en tant que propriétaire de site, vous pouvez désormais utiliser les nouvelles API pour mesurer les Core Web Vitals par route SPA à l'avance afin de comprendre comment vos scores peuvent changer.
Pour en savoir plus et découvrir les bonnes pratiques, consultez Mesurer les navigations douces.
Que fait Google pour s'assurer que les MPA ne bénéficient pas d'un avantage injuste par rapport aux SPA ?
Comme mentionné précédemment, grâce au travail sur les navigations douces, nous pensons que le travail que nous avons entrepris signifie qu'il ne devrait pas y avoir d'inconvénients pour les SPA à cet égard, bien que l'intégration complète dans tous les outils et solutions de reporting prendra du temps.
Évaluer séparément les visites de page interorigines et de même origine
Aujourd'hui, les métriques Core Web Vitals agrègent toutes les visites de page dans un seul bucket. Elles ne font pas la distinction entre les nouvelles visites et les visites récurrentes, les pages de destination et les pages de paiement, ni aucun autre type d'agrégation où l'état du cache pourrait avoir un effet sur les performances.
Une façon de normaliser les différences entre les performances des SPA et des MPA consiste à appliquer une pondération différente à différents types de visites, voire à des recommandations de seuil complètement différentes.
Bien que nous souhaitions récompenser les implémentations de cache efficaces, nous ne voulons pas que les navigations rapides sur le site puissent compenser les chargements lents des pages de destination. Nous ne voulons pas non plus inciter les sites à diviser les longues pages en une collection de pages plus courtes dans le seul but d'améliorer les scores des métriques.
En évaluant séparément les visites de page interorigines et de même origine, nous pouvons nous assurer que les deux types d'expériences sont importants sans laisser la popularité relative d'un type sur un site donné fausser la distribution d'une métrique particulière.
Conclusions
Google s'engage pleinement à améliorer les métriques Web Vitals et à s'assurer qu'elles mesurent et encouragent les expériences de qualité qui sont importantes pour les utilisateurs. Cela dit, nous reconnaissons qu'il existe aujourd'hui des lacunes en matière de mesure. Les métriques peuvent désormais couvrir les transitions de route SPA, ce qui résout l'une des principales lacunes.
Nous pensons également que ces nouvelles API (en particulier InteractionContentfulPaint) ont d'autres utilisations et avantages potentiels au-delà de la mesure des Core Web Vitals pour les navigations douces. Nous sommes très heureux de continuer à développer ces API maintenant que la principale raison de leur introduction a été résolue.
J'espère que cet article vous a éclairé sur ce sujet complexe et nuancé. Comme toujours, si vous avez des commentaires sur les métriques Web Vitals actuelles ou futures, envoyez un e-mail à web-vitals-feedback@googlegroups.com.