Blazor, ce sont quatre dispositifs d'hébergement différents sous un seul nom, et l'extrait va dans un fichier différent pour chacun. La règle qui les sous-tend est la même : il appartient à la coquille qui survit à la navigation, jamais à une page.

Ce site est une application Blazor, et il est mesuré par Skomi de cette façon.

Récupérez d'abord l'extrait depuis votre tableau de bord :

<script src="https://t.skomi.com/s/YOUR-SITE-ID.js" defer></script>

Où il va

Votre projet Fichier Où dedans
Blazor Web App (.NET 8+) Components/App.razor Dans <body>, après <Routes />
Blazor WebAssembly autonome wwwroot/index.html Dans <body>, avant le script du framework
Blazor Server (.NET 6/7) Pages/_Host.cshtml ou Pages/_Layout.cshtml Dans <body>
MAUI Blazor Hybrid sans objet Pas ce guide : c'est une application, voir installation dans MAUI

Pour une Blazor Web App, cela ressemble à ceci :

<body>
    <Routes />

    <script src="https://t.skomi.com/s/YOUR-SITE-ID.js" defer></script>
    <script src="_framework/blazor.web.js"></script>
</body>

Pourquoi pas dans une mise en page ou une page

⚠ Un script inséré par la navigation améliorée n'est pas exécuté. Blazor rapièce le DOM plutôt que de recharger le document, et une balise <script> qui arrive dans le cadre de ce rapiéçage ne s'exécute pas. Un extrait placé dans MainLayout.razor ou dans un composant de page fonctionne donc au premier chargement, est silencieusement mort après la première navigation interne, et a l'air installé pendant tout ce temps.

App.razor est en dehors de tout ce que Blazor remplace. La balise se charge une fois, et reste chargée.

La navigation est comptée pour vous

Deux choses différentes se produisent selon que vous livrez ou non le runtime Blazor, et toutes deux sont déjà prises en charge.

Avec blazor.web.js. Les liens internes utilisent la navigation améliorée : le document survit et l'adresse change via history.pushState. Le script de Skomi enveloppe pushState et replaceState et écoute popstate : chacune de ces navigations est donc une page vue. Rien auquel s'abonner, rien à appeler à la navigation.

Sans lui. Une application Blazor rendue statiquement, sans interactivité, ne livre aucun runtime : chaque lien est donc un chargement de page ordinaire et compte comme sur n'importe quel autre site. Ce site est dans ce cas.

Vous n'avez pas à savoir dans lequel vous êtes : la même balise au même endroit convient aux deux.

⚠ Une navigation qui ne change pas l'adresse n'est pas comptée, dans l'un comme dans l'autre mode. Les onglets, les accordéons et les changements de filtre sans paramètre d'URL sont des interactions, pas des pages vues. Si vous voulez les mesurer, envoyez un événement.

Les modes de rendu interactifs ne changent rien ici

InteractiveServer, InteractiveWebAssembly et InteractiveAuto décident où s'exécutent vos composants, pas comment la page est livrée au navigateur. L'extrait est au-dessus de tout cela dans App.razor et se comporte de façon identique sous chacun. Les modes de rendu par composant sont tout aussi hors sujet : il y a un document et un script.

Si rien n'arrive

  • La balise est-elle dans App.razor plutôt que dans une mise en page ? Voir l'avertissement ci-dessus ; c'est l'échec pour lequel ce guide existe.
  • Est-elle à l'intérieur de <body> ? Dans <head> elle fonctionne encore, mais ne la mettez pas dans les pattes de <HeadOutlet /> : cet emplacement est fait pour le contenu que les composants apportent, et un traceur n'en est pas.
  • dotnet watch et un document en cache. La navigation améliorée et le rechargement à chaud peuvent vous laisser devant une page construite avant que vous n'ajoutiez la balise. Faites une fois un rechargement forcé.
  • localhost n'est pas compté. Déployez, ou testez contre un vrai nom d'hôte.

Voir l'extrait pour ce qu'il fait une fois chargé, et mesurer une application si ce que vous mesurez est un logiciel que les gens installent plutôt qu'un site qu'ils visitent.