Mesurer une application monopage (SPA)

Les applications monopages — React, Vue, Svelte, Angular et consorts — ont changé la façon dont les sites se chargent. Au lieu de demander une nouvelle page au serveur à chaque clic, elles réécrivent le contenu directement dans le navigateur. L’expérience est plus fluide, mais elle déroute les outils de mesure conçus pour un web fait de rechargements complets. Résultat : une SPA mal instrumentée donne l’illusion que les visiteurs ne consultent qu’une seule page. Voyons pourquoi, et comment mesurer une SPA correctement sans rien sacrifier à la vie privée.

Pourquoi une SPA fausse la mesure classique

La mesure d’audience historique repose sur un signal simple : le chargement d’une page. Chaque fois que le navigateur récupère un nouveau document HTML, le script de mesure s’exécute et enregistre une vue. Ce modèle colle parfaitement à un site multipage traditionnel, où naviguer signifie recharger.

Dans une SPA, ce signal disparaît. Le premier chargement récupère bien un document, mais toutes les navigations suivantes — passer de l’accueil à une fiche produit, ouvrir un onglet, filtrer une liste — se font sans nouvelle requête de page. Le script ne s’exécute qu’une fois, au démarrage. Tout ce qui suit lui est invisible. On se retrouve avec un nombre de pages vues artificiellement bas et une durée de visite incohérente, simplement parce que l’outil ne « voit » pas l’utilisateur changer d’écran.

Le rôle des événements d’historique

La bonne nouvelle, c’est que les navigations d’une SPA ne sont pas réellement silencieuses : elles passent par l’API History du navigateur. Quand l’application change d’écran, elle appelle pushState (ou replaceState) pour mettre à jour l’URL sans recharger, et l’événement popstate signale les retours en arrière. Ces appels sont le point d’accroche d’une mesure correcte.

Suivre une SPA consiste donc à écouter ces transitions et à enregistrer une vue à chaque changement d’URL signifiant, exactement comme un rechargement l’aurait fait sur un site classique. L’URL reste la clé : c’est elle qui identifie l’écran consulté, qui alimente le rapport des pages les plus vues, et qui permet de reconstituer un parcours.

Comment Takt suit les vues d’une SPA

Le script de Takt est pensé pour ce modèle. Au-delà de la vue initiale, il s’accroche aux transitions de l’API History et enregistre automatiquement une nouvelle vue à chaque changement de route côté client. Concrètement, une fois le snippet posé, une SPA est mesurée comme un site multipage : chaque écran compte, sans configuration supplémentaire dans la plupart des cas.

Pour les frameworks, les wrappers officiels s’intègrent au routeur et déclenchent la mesure au bon moment, sans que vous ayez à brancher manuellement les événements d’historique. Et lorsqu’une interaction mérite d’être suivie sans pour autant changer d’URL — l’envoi d’un formulaire, l’ouverture d’une modale clé — un appel d’événement explicite via takt() permet de l’enregistrer comme une action nommée.

Les pièges à éviter

Trois écueils reviennent souvent. Le premier : compter deux fois la première vue, en laissant le suivi automatique enregistrer le chargement initial alors qu’on l’enregistre aussi à la main. Une seule source de vérité suffit ; laissez le script gérer la vue initiale.

Le deuxième : mesurer des changements d’URL non signifiants. Une SPA met parfois à jour l’URL pour des raisons techniques — paramètres de tri, ancres, état d’un filtre — qui ne correspondent pas à un nouvel écran pour l’utilisateur. Enregistrer chacun de ces micro-changements gonfle les pages vues sans rien apprendre. Mieux vaut ne compter que les transitions qui changent réellement de contenu.

Le troisième : oublier que localhost est exclu par défaut. En développement, l’absence de données ne signifie pas que l’instrumentation est cassée ; testez sur un domaine réel, ou avec un build de script qui n’exclut pas localhost.

En résumé

Une SPA n’émet pas de rechargement à chaque navigation, ce qui rend invisible aux outils classiques tout le parcours après le premier écran. La solution n’est pas de revenir au multipage, mais d’écouter les transitions de l’API History et d’enregistrer une vue à chaque changement de route signifiant. Le script de Takt et ses wrappers font ce travail automatiquement, et takt() permet de nommer les interactions qui comptent. En évitant les doubles comptages et les changements d’URL parasites, on obtient d’une SPA une mesure aussi fidèle que celle d’un site multipage — et toujours sans cookie ni pistage individuel.