Renderização do lado do cliente vs. do lado do servidor #ÚltimasNotícias #tecnologia

Tempos de carregamento mais rápidos de páginas da web desempenham um papel importante na experiência do usuário e no SEO, sendo a velocidade de carregamento da página um fator determinante para o algoritmo do Google.

Um desenvolvedor web front-end deve decidir a melhor maneira de renderizar um site para que ele ofereça uma experiência rápida e conteúdo dinâmico.

Dois métodos de renderização populares incluem renderização do lado do cliente (CSR) e renderização do lado do servidor (SSR).

Todos os sites têm requisitos diferentes, portanto, entender a diferença entre renderização do lado do cliente e do lado do servidor pode ajudar você a renderizar seu site de acordo com seus objetivos comerciais.

Google e JavaScript

O Google tem uma ampla documentação sobre como ele lida com JavaScript, e os Googlers oferecem insights e respondem perguntas sobre JavaScript regularmente por meio de vários formatos — oficiais e não oficiais.

Por exemplo, em um podcast Search Off The Record, foi discutido que o Google renderiza todas as páginas para a Pesquisa, incluindo aquelas com muito JavaScript.

Isso gerou uma conversa substancial no LinkedIn, e outras conclusões do podcast e das discussões subsequentes são:

• O Google não rastreia quanto custa renderizar páginas específicas.
• O Google renderiza todas as páginas para ver o conteúdo, independentemente de usar JavaScript ou não.

A conversa como um todo ajudou a dissipar muitos mitos e equívocos sobre como o Google pode ter abordou JavaScript e alocou recursos.

O comentário completo de Martin Splitt no LinkedIn sobre isso foi:

“Não mantemos o controle de “quão cara foi essa página para nós?” ou algo assim. Sabemos que uma parte substancial da web usa JavaScript para adicionar, remover, alterar conteúdo em páginas da web. Só precisamos renderizar, para ver tudo. Realmente não importa se uma página usa ou não JavaScript, porque só podemos ter certeza razoável de ver todo o conteúdo depois que ele for renderizado.”

Martin também confirmou uma fila e um possível atraso entre o rastreamento e a indexação, mas não apenas porque algo é JavaScript ou não, e não é um problema “opaco” que a presença do JavaScript seja a causa raiz de URLs não serem indexadas.

Melhores práticas gerais de JavaScript

Antes de entrarmos no debate entre cliente e servidor, é importante que também sigamos as melhores práticas gerais para que qualquer uma dessas abordagens funcione:

• Não bloqueie recursos JavaScript por meio de Robots.txt ou regras do servidor.
• Evite bloqueio de renderização.
• Evite injetar JavaScript no DOM.

O que é renderização do lado do cliente e como ela funciona?

A renderização do lado do cliente é uma abordagem relativamente nova para renderizar sites.

Tornou-se popular quando bibliotecas JavaScript começaram a integrá-lo, com Angular e React.js sendo alguns dos melhores exemplos de bibliotecas usadas neste tipo de renderização.

Ele funciona renderizando o JavaScript de um site no seu navegador e não no servidor.

O servidor responde com um documento HTML básico contendo os arquivos JS em vez de obter todo o conteúdo do documento HTML.

Embora o tempo de upload inicial seja um pouco lento, os carregamentos de páginas subsequentes serão rápidos, pois não dependem de uma página HTML diferente por rota.

Do gerenciamento da lógica à recuperação de dados de uma API, os sites renderizados pelo cliente fazem tudo “independentemente”. A página fica disponível depois que o código é executado porque cada página que o usuário visita e sua URL correspondente são criadas dinamicamente.

O processo de RSC é o seguinte:

• O usuário insere a URL que deseja visitar na barra de endereço.
• Uma solicitação de dados é enviada ao servidor na URL especificada.
• Na primeira solicitação do cliente ao site, o servidor entrega os arquivos estáticos (CSS e HTML) ao navegador do cliente.
• O navegador do cliente baixará o conteúdo HTML primeiro, seguido pelo JavaScript. Esses arquivos HTML conectam o JavaScript, iniciando o processo de carregamento exibindo símbolos de carregamento que o desenvolvedor define para o usuário. Nesse estágio, o site ainda não está visível para o usuário.
• Após o download do JavaScript, o conteúdo é gerado dinamicamente no navegador do cliente.
• O conteúdo da web se torna visível à medida que o cliente navega e interage com o site.

O que é renderização do lado do servidor e como ela funciona?

A renderização do lado do servidor é a técnica mais comum para exibir informações em uma tela.

O navegador da web envia uma solicitação de informações do servidor, buscando dados específicos do usuário para preencher e enviando uma página HTML totalmente renderizada ao cliente.

Toda vez que o usuário visita uma nova página no site, o servidor repetirá todo o processo.

Veja como o processo de SSR ocorre passo a passo:

• O usuário insere a URL que deseja visitar na barra de endereço.
• O servidor fornece uma resposta HTML pronta para ser renderizada ao navegador.
• O navegador renderiza a página (agora visualizável) e baixa o JavaScript.
• O navegador executa o React, tornando a página interativa.

Quais são as diferenças entre renderização do lado do cliente e do lado do servidor?

A principal diferença entre essas duas abordagens de renderização está nos algoritmos de sua operação. CSR mostra uma página vazia antes de carregar, enquanto SSR exibe uma página HTML totalmente renderizada no primeiro carregamento.

Isso dá à renderização do lado do servidor uma vantagem de velocidade sobre a renderização do lado do cliente, pois o navegador não precisa processar grandes arquivos JavaScript. O conteúdo geralmente fica visível em alguns milissegundos.

Os mecanismos de busca podem rastrear o site para melhor SEO, facilitando a indexação de suas páginas da web. Essa legibilidade na forma de texto é precisamente a maneira como os sites SSR aparecem no navegador.

No entanto, a renderização do lado do cliente é uma opção mais barata para proprietários de sites.

Ele alivia a carga em seus servidores, passando a responsabilidade de renderização para o cliente (o bot ou usuário tentando visualizar sua página). Ele também oferece interações ricas no site, fornecendo interação rápida do site após o carregamento inicial.

Menos solicitações HTTP são feitas ao servidor com CSR, diferentemente de SSR, onde cada página é renderizada do zero, resultando em uma transição mais lenta entre as páginas.

O SSR também pode falhar sob alta carga do servidor se o servidor receber muitas solicitações simultâneas de diferentes usuários.

A desvantagem do CSR é o tempo de carregamento inicial mais longo. Isso pode impactar o SEO; os rastreadores podem não esperar o conteúdo carregar e sair do site.

Essa abordagem de duas fases aumenta a possibilidade de ver conteúdo vazio na sua página por falta de conteúdo JavaScript após o primeiro rastreamento e indexação do HTML de uma página. Lembre-se de que, na maioria dos casos, o CSR requer uma biblioteca externa.

Quando usar renderização do lado do servidor

Se você deseja melhorar sua visibilidade no Google e obter uma classificação alta nas páginas de resultados dos mecanismos de busca (SERPs), a renderização do lado do servidor é a escolha número um.

Sites de e-learning, mercados on-line e aplicativos com uma interface de usuário simples, com menos páginas, recursos e dados dinâmicos, todos se beneficiam desse tipo de renderização.

Quando usar renderização do lado do cliente

A renderização do lado do cliente geralmente é pareada com aplicativos da web dinâmicos, como redes sociais ou mensageiros online. Isso ocorre porque as informações desses aplicativos mudam constantemente e devem lidar com dados grandes e dinâmicos para executar atualizações rápidas para atender à demanda do usuário.

O foco aqui é um site rico com muitos usuários, priorizando a experiência do usuário em detrimento do SEO.

O que é melhor: renderização do lado do servidor ou do lado do cliente?

Ao determinar qual abordagem é melhor, você precisa levar em consideração não apenas suas necessidades de SEO, mas também como o site funciona para os usuários e agrega valor.

Pense no seu projeto e em como a renderização escolhida impactará sua posição nos SERPs e na experiência do usuário do seu site.

Geralmente, o CSR é melhor para sites dinâmicos, enquanto o SSR é mais adequado para sites estáticos.

Frequência de atualização de conteúdo

Sites que apresentam informações altamente dinâmicas, como sites de apostas ou FOREX, atualizam seu conteúdo a cada segundo, o que significa que você provavelmente escolheria CSR em vez de SSR nesse cenário – ou escolheria usar CSR para páginas de destino específicas e não para todas as páginas, dependendo da sua estratégia de aquisição de usuários.

O SSR é mais eficaz se o conteúdo do seu site não exigir muita interação do usuário. Ele influencia positivamente a acessibilidade, os tempos de carregamento da página, o SEO e o suporte de mídia social.

Por outro lado, o CSR é excelente para fornecer renderização econômica para aplicativos da web, além de ser mais fácil de criar e manter; é melhor para o First Input Delay (FID).

Outra consideração de RSC é que meta tags (descrição, título), URLs canônicas e tags Hreflang devem ser renderizadas no lado do servidor ou apresentadas na resposta HTML inicial para que os rastreadores as identifiquem o mais rápido possível, e não apenas apareçam no HTML renderizado.

Considerações sobre a plataforma

A tecnologia de RSC tende a ser mais cara de manter porque a taxa horária para desenvolvedores qualificados em React.js ou Node.js é geralmente mais alta do que para desenvolvedores PHP ou WordPress.

Além disso, há menos plugins prontos ou soluções prontas para uso disponíveis para estruturas de CSR em comparação ao ecossistema maior de plugins ao qual os usuários do WordPress têm acesso.

Para aqueles que estão considerando uma configuração headless do WordPress, como usar o Frontity, é importante observar que você precisará contratar desenvolvedores React.js e desenvolvedores PHP.

Isso ocorre porque o WordPress headless depende do React.js para o front-end, mas ainda requer PHP para o back-end.

É importante lembrar que nem todos os plugins do WordPress são compatíveis com configurações headless, o que pode limitar a funcionalidade ou exigir desenvolvimento personalizado adicional.

Funcionalidade e propósito do site

Às vezes, você não precisa escolher entre os dois, pois soluções híbridas estão disponíveis. Tanto SSR quanto CSR podem ser implementados em um único site ou página da web.

Por exemplo, em um mercado online, páginas com descrições de produtos podem ser renderizadas no servidor, pois são estáticas e precisam ser facilmente indexadas pelos mecanismos de busca.

Continuando com o comércio eletrônico, se você tiver altos níveis de personalização para usuários em diversas páginas, não será possível renderizar o conteúdo por SSR para bots, então será necessário definir alguma forma de conteúdo padrão para o Googlebot que rastreie sem cookies e sem estado.

Páginas como contas de usuário não precisam ser classificadas nas páginas de resultados dos mecanismos de busca (SERPs), então uma abordagem de CRS pode ser melhor para UX.

Tanto CSR quanto SSR são abordagens populares para renderizar sites. Você e sua equipe precisam tomar essa decisão no estágio inicial do desenvolvimento do produto.

Mais recursos:

---

Imagem em destaque: TipPatt/Shutterstock