React SEO Estratégias e Melhores Práticas

O React foi desenvolvido para criar UIs interativas que são declarativas , modulares e multiplataforma . Hoje, é uma das estruturas JavaScript mais populares, se não a mais popular, para escrever aplicativos front-end de alto desempenho. Desenvolvido inicialmente para escrever aplicativos de página única (SPAs), o React agora é usado para criar sites e aplicativos móveis completos.

Se você tem uma vasta experiência em desenvolvimento web convencional e migra para React, notará uma quantidade crescente de seu código HTML e CSS migrando para JavaScript. Isso ocorre porque o React não recomenda criar ou atualizar diretamente os elementos da interface do usuário, mas sim descrever o “estado” da interface do usuário. O React atualizará o DOM para corresponder ao estado da maneira mais eficiente.

Como resultado, todas as alterações na UI ou DOM devem ser feitas via engine do React. Embora conveniente para os desenvolvedores, isso pode significar tempos de carregamento mais longos para os usuários e mais trabalho para os mecanismos de pesquisa encontrarem e indexarem o conteúdo.

Neste artigo, abordaremos os desafios enfrentados ao criar aplicativos e sites React com desempenho de SEO e descreveremos várias estratégias usadas para superá-los.

Como o Google rastreia e indexa páginas da Web

O Google recebe mais de 90% de todas as pesquisas online. Vamos dar uma olhada em seu processo de rastreamento e indexação.

Este instantâneo tirado da documentação do Google pode nos ajudar. Observe que este é um diagrama de blocos simplificado. O Googlebot real é muito mais sofisticado.

Pontos a observar:

1. O Googlebot mantém uma fila de rastreamento contendo todos os URLs necessários para rastrear e indexar no futuro.
2. Quando o rastreador está ocioso, ele pega o próximo URL na fila, faz uma solicitação e busca o HTML.
3. Depois de analisar o HTML, o Googlebot determina se ele precisa buscar e executar o JavaScript para renderizar o conteúdo. Se sim, a URL é adicionada a uma fila de renderização.
4. Posteriormente, o renderizador busca e executa JavaScript para renderizar a página. Ele envia o HTML renderizado de volta para a unidade de processamento.
5. A unidade de processamento extrai todas as <a> tags mencionadas na página da Web e as adiciona de volta à fila de rastreamento.
6. O conteúdo é adicionado ao índice do Google.

Observe que há uma distinção clara entre o estágio Processing que analisa HTML e o estágio Renderer que executa JavaScript.

Essa distinção existe porque a execução do JavaScript é cara , já que os Googlebots precisam analisar mais de 130 trilhões de páginas da web. Assim, quando o Googlebot rastreia uma página da Web, ele analisa o HTML imediatamente e enfileira o JavaScript para execução posterior. A documentação do Google menciona que uma página permanece na fila de renderização por alguns segundos, embora possa demorar mais.

Também vale a pena mencionar o conceito de orçamento de rastreamento. O rastreamento do Google é limitado pela largura de banda, tempo e disponibilidade das instâncias do Googlebot. Ele aloca um orçamento ou recursos específicos para indexar cada site. Se você estiver criando um site grande e cheio de conteúdo com milhares de páginas (por exemplo, um site de comércio eletrônico) e essas páginas usarem muito JavaScript para renderizar o conteúdo, o Google poderá ler menos conteúdo do seu site.

Observação: você pode ler as diretrizes do Google para gerenciar seu orçamento de rastreamento aqui.

Por que otimizar o React para SEO é desafiador

Nossa breve visão geral do Googlebot, rastreamento e indexação apenas arranha a superfície. No entanto, os engenheiros de software devem identificar possíveis problemas enfrentados pelos mecanismos de pesquisa que tentam rastrear e indexar páginas do React. Agora podemos examinar mais de perto o que torna o React SEO desafiador e o que os desenvolvedores podem fazer para enfrentar e superar alguns desses desafios.

Conteúdo de primeira passagem vazio

Sabemos que os aplicativos React dependem muito do JavaScript e geralmente enfrentam problemas com os mecanismos de pesquisa. Isso ocorre porque o React emprega um modelo de shell de aplicativo por padrão. O HTML inicial não contém nenhum conteúdo significativo e um usuário ou um bot deve executar o JavaScript para ver o conteúdo real da página.

Essa abordagem significa que o Googlebot detecta uma página vazia durante a primeira passagem. O conteúdo é visto pelo Google apenas quando a página é renderizada. Isso atrasará a indexação do conteúdo ao lidar com milhares de páginas.

Tempo de carregamento e experiência do usuário

Buscar, analisar e executar JavaScript leva tempo. Além disso, o JavaScript pode precisar fazer chamadas de rede para buscar o conteúdo, e o usuário pode precisar esperar um pouco antes de poder visualizar as informações solicitadas.

O Google estabeleceu um conjunto de sinais vitais da web relacionados à experiência do usuário, usados ​​em seus critérios de classificação. Um tempo de carregamento mais longo pode afetar a pontuação da experiência do usuário, levando o Google a classificar um site mais baixo.

Analisamos o desempenho do site em detalhes na seção a seguir.

Metadados da página

Meta tags <meta> são úteis porque permitem que o Google e outros sites de mídia social mostrem títulos, miniaturas e descrições apropriados para as páginas. Mas esses sites contam com a tag <head> da página da Web buscada para obter essas informações. Esses sites não executam JavaScript para a página de destino.

O React renderiza todo o conteúdo, incluindo meta tags, no cliente. Como o shell do aplicativo é o mesmo para todo o site/aplicativo, pode ser difícil adaptar os metadados para páginas individuais.

Mapa do site

Um mapa do site é um arquivo onde você fornece informações sobre as páginas, vídeos e outros arquivos em seu site e as relações entre eles. Mecanismos de pesquisa como o Google leem esse arquivo para rastrear seu site de maneira mais inteligente.

O React não possui uma maneira integrada de gerar sitemaps. Se você estiver usando algo como o React Router para lidar com o roteamento, poderá encontrar ferramentas que podem gerar um mapa do site, embora possa exigir algum esforço.

Outras Considerações de SEO

Essas considerações estão relacionadas à configuração de boas práticas de SEO em geral.

1. Tenha uma estrutura de URL ideal para dar aos humanos e aos mecanismos de pesquisa uma boa ideia sobre o que esperar na página.
2. A otimização do arquivo robots.txt pode ajudar os bots de pesquisa a entender como rastrear páginas em seu site.
3. Use um CDN para servir todos os ativos estáticos como CSS, JS, fontes etc. e use imagens responsivas para reduzir o tempo de carregamento.

Podemos resolver muitos dos problemas descritos acima usando renderização do lado do servidor (SSR) ou pré-renderização. Analisaremos essas abordagens a seguir.

Digite Reação isomórfica

A definição do dicionário de isomórfico é “correspondente ou semelhante em forma”.

Em termos de React, isso significa que o servidor tem um formato semelhante ao do cliente. Em outras palavras, você pode reutilizar os mesmos componentes React no servidor e no cliente.

Essa abordagem isomórfica permite que o servidor renderize o aplicativo React e envie a versão renderizada para nossos usuários e mecanismos de pesquisa para que eles possam visualizar o conteúdo instantaneamente enquanto o JavaScript é carregado e executado em segundo plano.

Frameworks como Next.js ou Gatsby popularizaram essa abordagem. Devemos notar que os componentes isomórficos podem parecer substancialmente diferentes dos componentes convencionais do React. Por exemplo, eles podem incluir código executado no servidor em vez do cliente. Eles podem até incluir segredos de API (embora o código do servidor seja removido antes de ser enviado ao cliente).

Um ponto a ser observado é que essas estruturas abstraem muita complexidade, mas também introduzem uma maneira opinativa de escrever código. Vamos nos aprofundar nas compensações de desempenho neste artigo.

Também faremos uma análise matricial para entender a relação entre os caminhos de renderização e o desempenho do site. Mas antes disso, vamos ver algumas noções básicas sobre como medir o desempenho do site.

Métricas de desempenho do site

Vamos examinar alguns dos fatores que os mecanismos de busca usam para classificar sites.

Além de responder a consulta de um usuário com rapidez e precisão, o Google acredita que um bom site deve ter os seguintes atributos:

• Deve carregar rapidamente.
• Os usuários devem poder acessar o conteúdo sem muito tempo de espera.
• Ele deve se tornar interativo com as ações de um usuário desde o início.
• Ele não deve buscar dados desnecessários ou executar códigos caros para evitar o esgotamento dos dados ou da bateria de um usuário.

Esses recursos mapeiam aproximadamente para as seguintes métricas:

• TTFB : Time to First Byte – O tempo entre clicar em um link e o primeiro bit de conteúdo que chega.
• LCP : Largest Contentful Paint – O momento em que o artigo solicitado se torna visível. O Google recomenda manter esse valor abaixo de 2,5 segundos.
• TTI : Time To Interactive – O momento em que uma página se torna interativa (um usuário pode rolar, clicar, etc.).
• Tamanho do pacote – O número total de bytes baixados e código executado antes que a página se tornasse totalmente visível e interativa.

Revisitaremos essas métricas para entender melhor como vários caminhos de renderização podem afetar cada uma delas.

Em seguida, vamos entender os diferentes caminhos de renderização disponíveis para desenvolvedores React.

Caminhos de renderização

Podemos renderizar um aplicativo React no navegador ou no servidor e produzir saídas variadas.

Duas funções mudam significativamente entre aplicativos renderizados do lado do cliente e do lado do servidor, ou seja, roteamento e divisão de código . Vamos dar uma olhada mais de perto nestes abaixo.

Renderização do lado do cliente (CSR)

A renderização do lado do cliente é o caminho de renderização padrão para um React SPA. O servidor servirá um aplicativo shell que não contém nenhum conteúdo. Depois que o navegador baixa, analisa e executa as fontes JavaScript incluídas, o conteúdo HTML é preenchido ou renderizado .

A função de roteamento é gerenciada pelo aplicativo cliente gerenciando o histórico do navegador. Isso significa que o mesmo arquivo HTML é servido independentemente de qual rota foi solicitada, e o cliente atualiza seu estado de visualização após a renderização.

A divisão de código é relativamente simples. Você pode dividir seu código usando importações dinâmicas ou React.lazy de forma que apenas as dependências necessárias sejam carregadas com base na rota ou nas ações do usuário.

Se a página precisar buscar dados do servidor para renderizar conteúdo – digamos, um título de blog ou descrição de produto – ela poderá fazê-lo somente quando os componentes relevantes forem montados e renderizados.

O usuário provavelmente verá um sinal ou indicador "Carregando dados" enquanto o site busca dados adicionais.

Renderização do lado do cliente com dados de inicialização (CSRB)

Considere o mesmo cenário que o CSR, mas em vez de buscar dados após o DOM ser renderizado, digamos que o servidor enviou dados relevantes inicializados dentro do HTML servido.

Poderíamos incluir um nó que se parece com isso:

 <script type="application/json"> {"title": "My blog title", "comments":["comment 1","comment 2"]} </script>

E analise-o quando o componente for montado:

 var data = JSON.parse(document.getElementById('data').innerHTML);

Acabamos de nos poupar uma viagem de ida e volta para o servidor. Veremos as compensações daqui a pouco.

Renderização do lado do servidor para conteúdo estático (SSRS)

Imagine um cenário em que precisamos gerar HTML em tempo real.

Por exemplo, se estivermos construindo uma calculadora online e o usuário emitir uma consulta do tipo /calculate/34+15 (deixando de fora o escape de URL). Precisamos processar a consulta, avaliar o resultado e responder com o HTML gerado.

Nosso HTML gerado é bastante simples em estrutura e não precisamos do React para gerenciar e manipular o DOM uma vez que o HTML gerado é servido.

Então, estamos apenas servindo conteúdo HTML e CSS. Você pode usar o método renderToStaticMarkup para conseguir isso.

O roteamento será totalmente tratado pelo servidor, pois ele precisa recalcular o HTML para cada resultado, embora o cache da CDN possa ser usado para fornecer respostas mais rapidamente. Os arquivos CSS também podem ser armazenados em cache pelo navegador para carregamentos de página subsequentes mais rápidos.

Renderização do lado do servidor com reidratação (SSRH)

Imagine o mesmo cenário descrito acima, mas desta vez precisamos de um aplicativo React totalmente funcional no cliente.

Vamos realizar a primeira renderização no servidor e enviar de volta o conteúdo HTML junto com os arquivos JavaScript. O React irá reidratar a marcação renderizada pelo servidor e o aplicativo se comportará como um aplicativo CSR a partir deste ponto.

O React fornece métodos internos para executar essas ações.

A primeira solicitação é tratada pelo servidor e as renderizações subsequentes são tratadas pelo cliente. Portanto, esses aplicativos são chamados de aplicativos React universais (renderizados no servidor e no cliente). O código para lidar com o roteamento pode ser dividido (ou duplicado) no cliente e no servidor.

A divisão de código também é um pouco complicada, pois o ReactDOMServer não suporta o React. preguiçoso, então você pode ter que usar algo como Loadable Components.

Deve-se notar também que o ReactDOMServer executa apenas uma renderização superficial. Em outras palavras, embora o método render para seus componentes seja invocado, os métodos de ciclo de vida como componentDidMount não serão chamados. Portanto, você precisará refatorar seu código para fornecer dados aos seus componentes usando um método alternativo.

É aqui que frameworks como NextJS aparecem. Eles mascaram as complexidades associadas ao roteamento e divisão de código no SSRH e proporcionam uma experiência de desenvolvedor mais suave.

Essa abordagem produz resultados mistos quando se trata de desempenho da página, como veremos em breve.

Pré-renderização para conteúdo estático (PRS)

E se pudéssemos renderizar uma página da web antes que um usuário a solicitasse? Isso pode ser feito em tempo de compilação ou dinamicamente quando os dados são alterados.

Podemos então armazenar em cache o conteúdo HTML resultante em um CDN e servi-lo muito mais rápido quando um usuário o solicitar.

Isso é chamado de pré-renderização antes de renderizarmos o conteúdo, solicitação de pré-usuário. Essa abordagem pode ser usada para blogs e aplicativos de comércio eletrônico, pois seu conteúdo normalmente não depende de dados fornecidos pelo usuário.

Pré-renderização com reidratação (PRH)

Podemos querer que nosso HTML pré-renderizado seja um aplicativo React totalmente funcional quando um cliente o renderizar.

Após a primeira solicitação ser atendida, o aplicativo se comportará como um aplicativo React padrão. Este modo é semelhante ao SSRH, descrito acima, em termos de funções de roteamento e divisão de código.

Matriz de Desempenho

O momento que você estava esperando finalmente chegou. É hora de um confronto. Vamos ver como cada um desses caminhos de renderização afeta as métricas de desempenho da Web e determinar o vencedor.

Nesta matriz, atribuímos uma pontuação a cada caminho de renderização com base no desempenho em uma métrica de desempenho.

A pontuação varia de 1 a 5:

• 1 = Insatisfatório
• 2 = Pobre
• 3 = Moderado
• 4 = Bom
• 5 = Excelente

Principais conclusões

A pré-renderização para conteúdo estático (PRS) leva a sites de melhor desempenho , enquanto a renderização do lado do servidor com hidratação (SSRH) ou renderização do lado do cliente (CSR) pode levar a resultados abaixo do esperado.

Também é possível adotar várias abordagens para diferentes partes do site . Por exemplo, essas métricas de desempenho podem ser críticas para páginas da Web voltadas para o público, para que possam ser indexadas com mais eficiência, embora possam ser menos importantes quando o usuário fizer login e visualizar os dados da conta privada.

Cada caminho de renderização representa compensações em onde e como você deseja processar seus dados. O importante é que uma equipe de engenharia seja capaz de ver e discutir claramente essas compensações e escolher uma arquitetura que maximize a felicidade de seus usuários.

Leituras e Considerações Adicionais

Embora eu tenha tentado cobrir as técnicas atualmente populares, esta não é uma análise exaustiva. Eu recomendo a leitura deste artigo onde os desenvolvedores do Google discutem outras técnicas avançadas, como renderização de servidor de streaming, renderização trisomórfica e renderização dinâmica (servindo respostas diferentes para rastreadores e usuários).

Alguns outros fatores que você precisa considerar ao criar sites com conteúdo pesado incluem a necessidade de um bom sistema de gerenciamento de conteúdo (CMS) para seus autores e a capacidade de gerar/modificar facilmente visualizações de mídia social e otimizar imagens para tamanhos de tela variados.