Uma visão geral do Blazor

Primeira requisição e HTML completo

Ao abrir a página inicial, o navegador faz a requisição e recebe o documento inteiro. A imagem abaixo mostra esse primeiro carregamento na aba de rede do DevTools.

Esse comportamento acontece em praticamente todas as aplicações em um primeiro momento, e no modelo SSR ou Server não é diferente. Como o conteúdo veio do servidor, todo o HTML da página já está inserido no documento.

O trecho que mais interessa, além do cabeçalho, é o corpo da página. Nesse exemplo, ele contém o seguinte HTML:

<h1>Hello, world!</h1>

Welcome to your new app.
</article></main></div>

Esse conjunto de cabeçalho e corpo facilita a indexação da aplicação pelos mecanismos de busca. Por isso, o SEO tende a funcionar bem nesse cenário.

Navegação entre páginas com Enhanced Navigation

O problema clássico desse modelo é que uma simples atualização exigiria renderizar a página inteira de novo. No entanto, o Blazor não faz isso por padrão.

Para observar, navegue até a página Counter, que vem no template padrão. A aba de rede mostra o que o navegador baixou nessa troca de página.

Apenas um item chamado counter apareceu na lista. Isso significa que o navegador não baixou todo o HTML e o CSS novamente, somente o miolo da página.

Mesmo assim, o código fonte da página também mudou, como mostra a próxima imagem.

O corpo do HTML agora traz o conteúdo da página Counter:

<h1>Counter</h1>

<p role="status">Current count: 0</p>

<button class="btn btn-primary">Click me</button><!--Blazor:{"prerenderId":"854296b6197a4490b2661c463ae16e78"}--></article></main></div>

Isso se deve a um recurso chamado Enhanced Navigation, ou navegação aprimorada. Conforme a documentação de navegação do Blazor, o framework intercepta a requisição, faz um fetch e aplica a resposta diretamente no DOM.

Com isso, a página carrega mais rápido e preserva mais estado, sem um recarregamento completo. A documentação também informa que esse recurso fica ativo por padrão quando a página carrega o script blazor.web.js.

Vale lembrar que esse comportamento muda de acordo com o modo de renderização escolhido para a página ou o componente. Portanto, o render mode influencia diretamente o que trafega na rede.

Interatividade do Blazor Server com SignalR

O próximo teste é clicar no botão Click me da página Counter, que incrementa o número exibido acima dele. A imagem mostra o resultado.

Nesse momento, não há carregamento, nem loading, nem nada. Na prática, a página sequer pisca.

Isso ocorre porque, no modelo Blazor Server, os componentes ficam interativos depois que a página termina de carregar. Assim, o clique no botão apenas troca dados com o servidor.

De fato, o servidor incrementa o contador e devolve o valor atualizado, mas todo o processamento acontece do lado do servidor. Para isso, as aplicações Blazor Server mantêm uma conexão aberta via SignalR, que transporta as mensagens entre navegador e servidor.

Impacto no SEO

Repare que, embora a tela tenha mudado, o HTML por baixo dela continua igual. A imagem a seguir mostra o código fonte depois do clique.

Na seção que interessa, o texto Current count: continua com o valor 0:

<h1>Counter</h1>

<p role="status">Current count: 0</p>

<button class="btn btn-primary">Click me</button></article></main></div>
        <!--Blazor:{"prerenderId":"896ed21729c044739ddfbefcddc7d428"}-->

Esse é o comportamento normal de cenários SPA, nos quais o JavaScript gera o HTML dinamicamente. Por isso, o conteúdo gerado dessa forma não aparece em Exibir código fonte da página, o que afeta o SEO.

Ainda assim, você pode forçar a renderização completa da página quando necessário. Então, a decisão depende do que a aplicação precisa naquele momento.

O tamanho da aplicação

Ao iniciar uma aplicação WebAssembly, a aba de rede revela arquivos que não existiam no modelo Server.

O destaque é o arquivo dotnet.runtime, que faz o .NET rodar dentro do navegador. Ou seja, antes de exibir a interface, o navegador precisa baixar o runtime e os assemblies da aplicação.

Além disso, o conteúdo visual da página é igual ao que você viu no modelo Server. Para o usuário, a tela parece a mesma.

O HTML de uma SPA no Blazor WASM

A maior diferença está por baixo dos panos, no HTML, onde aparece o comportamento padrão de qualquer SPA. Nesse modelo, o documento inicial é básico, feito para carregar o mais rápido possível.

Depois disso, o Blazor WASM troca o miolo da página sem recarregá-la. A imagem mostra o código fonte resultante.

O corpo da página fica praticamente em branco, e o resultado é apenas este HTML:

<div id="app">
    <svg class="loading-progress">
        <circle r="40%" cx="50%" cy="50%" />
        <circle r="40%" cx="50%" cy="50%" />
    </svg>
    <div class="loading-progress-text"></div>
</div>

Não importa qual página você acesse nem quantos componentes renderize na tela. No modelo WASM puro, o HTML de origem será sempre este, e por isso o SEO fica prejudicado.

A mágica do render mode Auto

Quando uma página ou componente usa a renderização automática, o framework considera duas coisas. Primeiro, os componentes WebAssembly respondem mais rápido porque rodam localmente.

Por outro lado, o WebAssembly demora mais na primeira renderização, por causa do download do runtime do .NET. Então, o modo Auto renderiza o componente pela primeira vez no servidor, com o modelo Server.

Enquanto o usuário interage normalmente com esse componente, uma tarefa em segundo plano baixa o runtime do .NET e o pacote da aplicação. Segundo a documentação de render modes, esses arquivos ficam em cache para as visitas seguintes.

Na próxima vez que o framework renderizar o componente, o runtime já estará disponível, e o Blazor aproveita toda a performance do WASM. É uma saída inteligente para manter performance e usabilidade, e para você basta trocar uma linha de código.

A documentação faz uma ressalva importante: o modo Auto nunca troca dinamicamente o render mode de um componente que já está na página. Ele toma a decisão inicial e mantém o mesmo tipo de interatividade enquanto o componente estiver na tela.

Como aplicar o render mode

Na prática, a configuração fica no arquivo Program.cs e no próprio componente. Primeiro, a aplicação precisa registrar os dois tipos de interatividade:

builder.Services.AddRazorComponents()
    .AddInteractiveServerComponents()
    .AddInteractiveWebAssemblyComponents();

app.MapRazorComponents<App>()
    .AddInteractiveServerRenderMode()
    .AddInteractiveWebAssemblyRenderMode();

Em seguida, o componente declara o modo desejado com a diretiva @rendermode. O exemplo abaixo segue o modelo da documentação oficial:

@page "/render-mode-auto"
@rendermode InteractiveAuto

<button @onclick="UpdateMessage">Click me</button> @message

@code {
    private string message = "Not updated yet.";

    private void UpdateMessage()
    {
        message = "Somebody updated me!";
    }
}

A documentação também alerta que componentes no modo Auto precisam ficar no projeto cliente, cujo nome termina em .Client. Afinal, esse projeto configura o host WebAssembly que roda no navegador.