Blazor son cuatro disposiciones de alojamiento distintas con un solo nombre, y el fragmento va en un archivo distinto en cada una. La regla que hay debajo es la misma: pertenece a la carcasa que sobrevive a la navegación, nunca a una página.

Este sitio es una aplicación Blazor, y Skomi lo mide de esta manera.

Consigue primero el fragmento desde tu panel:

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

Dónde va

Tu proyecto Archivo Dónde dentro
Blazor Web App (.NET 8+) Components/App.razor En <body>, después de <Routes />
Blazor WebAssembly autónomo wwwroot/index.html En <body>, antes del script del framework
Blazor Server (.NET 6/7) Pages/_Host.cshtml o Pages/_Layout.cshtml En <body>
MAUI Blazor Hybrid no aplica No es esta guía: eso es una aplicación, véase instalación en MAUI

Para una Blazor Web App tiene esta pinta:

<body>
    <Routes />

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

Por qué no en una maquetación o en una página

Un script insertado por la navegación mejorada no se ejecuta. Blazor parchea el DOM en vez de recargar el documento, y una etiqueta <script> que llega como parte de ese parche no se ejecuta. Así que un fragmento puesto en MainLayout.razor o en un componente de página funciona en la primera carga, está muerto en silencio después de la primera navegación interna, y parece instalado todo ese tiempo.

App.razor está fuera de todo lo que Blazor sustituye. La etiqueta carga una vez, y se queda cargada.

La navegación se cuenta por ti

Pasan dos cosas distintas según publiques o no el runtime de Blazor, y las dos están ya resueltas.

Con blazor.web.js. Los enlaces internos usan la navegación mejorada: el documento sobrevive y la dirección cambia mediante history.pushState. El script de Skomi envuelve pushState y replaceState y escucha popstate, así que cada una de esas navegaciones es una página vista. Nada a lo que suscribirse, nada que llamar al navegar.

Sin él. Una aplicación Blazor dibujada de forma estática, sin interactividad, no publica ningún runtime, así que cada enlace es una carga de página normal y cuenta como en cualquier otro sitio. Este sitio es ese caso.

No tienes que saber en cuál estás: la misma etiqueta en el mismo sitio vale para los dos.

Una navegación que no cambia la dirección no se cuenta, en ninguno de los dos modos. Las pestañas, los acordeones y los cambios de filtro sin parámetro de URL son interacciones, no páginas vistas. Si quieres medirlos, manda un evento.

Los modos de dibujado interactivos no cambian nada aquí

InteractiveServer, InteractiveWebAssembly e InteractiveAuto deciden dónde se ejecutan tus componentes, no cómo se entrega la página al navegador. El fragmento está por encima de todo eso en App.razor y se comporta igual con cada uno. Los modos de dibujado por componente son igual de irrelevantes; hay un documento y un script.

Si no llega nada

  • ¿Está la etiqueta en App.razor y no en una maquetación? Véase el aviso de arriba; es el fallo para el que existe esta guía.
  • ¿Está dentro de <body>? En <head> sigue funcionando, pero no la pongas en medio de <HeadOutlet />: ese hueco es para el contenido que aportan los componentes, y un rastreador no es uno.
  • dotnet watch y un documento en caché. La navegación mejorada y la recarga en caliente pueden dejarte mirando una página construida antes de que añadieras la etiqueta. Haz una vez una recarga forzada.
  • localhost no se cuenta. Despliega, o prueba contra un nombre de host de verdad.

Véase el fragmento para lo que hace una vez cargado, y medir una aplicación si lo que estás midiendo es software que la gente instala y no un sitio que visita.