O Blazor são quatro arranjos de alojamento diferentes a usar um só nome, e o fragmento vai num ficheiro diferente em cada um. A regra por baixo deles é a mesma: pertence à carcaça que sobrevive à navegação, nunca a uma página.

Este sítio é uma aplicação Blazor, e é medido pela Skomi desta maneira.

Vai buscar primeiro o fragmento ao teu painel:

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

Onde vai

O teu projeto Ficheiro Onde dentro dele
Blazor Web App (.NET 8+) Components/App.razor No <body>, a seguir a <Routes />
Blazor WebAssembly autónomo wwwroot/index.html No <body>, antes do script da framework
Blazor Server (.NET 6/7) Pages/_Host.cshtml ou Pages/_Layout.cshtml No <body>
MAUI Blazor Hybrid não se aplica Não é este guia: isso é uma aplicação, vê instalar no MAUI

Para um Blazor Web App tem este aspeto:

<body>
    <Routes />

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

Porque não num layout ou numa página

⚠ Um script inserido pela navegação melhorada não é executado. O Blazor remenda o DOM em vez de recarregar o documento, e uma etiqueta <script> que chegue como parte desse remendo não corre. Portanto um fragmento posto no MainLayout.razor ou num componente de página funciona no primeiro carregamento, fica morto em silêncio depois da primeira navegação interna, e parece instalado o tempo todo.

O App.razor está fora de tudo o que o Blazor substitui. A etiqueta carrega uma vez, e fica carregada.

A navegação é contada por ti

Acontecem duas coisas diferentes conforme entregues ou não o runtime do Blazor, e as duas já estão tratadas.

Com o blazor.web.js. As ligações internas usam a navegação melhorada: o documento sobrevive e o endereço muda através do history.pushState. O script da Skomi embrulha o pushState e o replaceState e escuta o popstate, portanto cada uma dessas é uma página vista. Nada a que te subscrever, nada para chamar na navegação.

Sem ele. Uma aplicação Blazor apresentada estaticamente e sem interatividade não entrega runtime nenhum, portanto todas as ligações são um carregamento de página normal e contam como em qualquer outro sítio. Este sítio é esse caso.

Não tens de saber qual dos dois és: a mesma etiqueta no mesmo sítio está certa para os dois.

⚠ Uma navegação que não muda o endereço não é contada, em nenhum dos modos. As tiras de separadores, os acordeões e as mudanças de filtro sem parâmetros são interações, não páginas vistas. Se as quiseres medidas, envia um evento.

Os modos de apresentação interativos não mudam nada aqui

O InteractiveServer, o InteractiveWebAssembly e o InteractiveAuto decidem onde os teus componentes correm, não como a página é entregue ao navegador. O fragmento fica acima de tudo isso no App.razor e comporta-se de forma idêntica em cada um. Os modos de apresentação por componente são igualmente irrelevantes; há um documento e um script.

Se não chegar nada

  • A etiqueta está no App.razor e não num layout? Vê o aviso acima; é para esta falha que este guia existe.
  • Está dentro do <body>? No <head> continua a funcionar, mas mantém-na fora do caminho do <HeadOutlet />: essa saída é para conteúdo que os componentes contribuem, e um rastreador não é isso.
  • dotnet watch e um documento em cache. A navegação melhorada e o recarregamento a quente podem deixar-te a olhar para uma página que foi construída antes de teres acrescentado a etiqueta. Faz uma recarga forçada uma vez.
  • O localhost não é contado. Publica-o, ou testa contra um nome de anfitrião verdadeiro.

Vê o fragmento para saber o que ele faz depois de carregar, e medir uma aplicação se o que estás a medir é software que as pessoas instalam em vez de um sítio que visitam.