Lado do cliente vs. Renderização 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 a renderização do lado do cliente (CSR) e a renderização do lado do servidor (SSR).

Todos os sites têm requisitos diferentes, portanto, compreender a diferença entre a renderização do lado do cliente e do lado do servidor pode ajudá-lo a renderizar seu site de acordo com seus objetivos de negócios.

Google e JavaScript

O Google possui uma extensa documentação sobre como lidar com JavaScript, e os Googlers oferecem insights e respondem regularmente a perguntas sobre JavaScript 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 Pesquisa, incluindo aquelas com muito JavaScript.

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

• O Google não monitora o custo de 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 poderia ter abordou JavaScript e alocou recursos.

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

“Não monitoramos “quão cara esta página foi para nós?” ou algo assim. Sabemos que uma parte substancial da web usa JavaScript para adicionar, remover e alterar conteúdo em páginas da web. Só temos que 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 de 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 de JavaScript seja a causa raiz da não indexação de URLs.

Práticas recomendadas gerais de JavaScript

Antes de entrarmos no debate do lado do cliente versus do lado do servidor, é importante que também sigamos as práticas recomendadas gerais para que qualquer uma dessas abordagens funcione:

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

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

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

Tornou-se popular quando as bibliotecas JavaScript começaram a integrá-lo, sendo Angular e React.js alguns dos melhores exemplos de bibliotecas utilizadas 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ágina 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 “de forma independente”. A página fica disponível após a execução do código 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 o URL que deseja visitar na barra de endereço.
• Uma solicitação de dados é enviada ao servidor no URL especificado.
• Na primeira solicitação do cliente para o site, o servidor entrega os arquivos estáticos (CSS e HTML) ao navegador do cliente.
• O navegador cliente fará download do 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. Nesta fase, 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 torna-se visível à medida que o cliente navega e interage com o site.

O que é renderização no servidor e como funciona?

A renderização no 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.

Cada vez que o usuário visitar uma nova página do site, o servidor repetirá todo o processo.

Veja como o processo de SSR ocorre passo a passo:

• O usuário insere o 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 visível) e baixa o JavaScript.
• O navegador executa React, tornando a página interativa.

Quais são as diferenças entre a 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. O CSR mostra uma página vazia antes do carregamento, enquanto o SSR exibe uma página HTML totalmente renderizada no primeiro carregamento.

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

Os mecanismos de pesquisa podem rastrear o site para obter um melhor SEO, facilitando a indexação de suas páginas da web. Essa legibilidade na forma de texto é justamente a forma 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 dos seus servidores, passando a responsabilidade da renderização para o cliente (o bot ou usuário que está tentando visualizar sua página). Ele também oferece interações ricas com o site, fornecendo interação rápida com o site após o carregamento inicial.

Menos solicitações HTTP são feitas ao servidor com CSR, ao contrário do 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 uma alta carga do servidor se o servidor receber muitas solicitações simultâneas de usuários diferentes.

A desvantagem do CSR é o maior tempo de carregamento inicial. Isso pode impactar o SEO; os rastreadores podem não esperar que o conteúdo carregue e saia do site.

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

Quando usar a renderização do lado do servidor

Se você deseja melhorar sua visibilidade no Google e obter uma classificação elevada nas páginas de resultados do mecanismo de pesquisa (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 a renderização do lado do cliente

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

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

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

Ao determinar qual abordagem é a melhor, você precisa não apenas levar em consideração 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 nas 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 jogos de azar ou FOREX, atualizam seu conteúdo a cada segundo, o que significa que você provavelmente escolheria CSR em vez de SSR neste cenário – ou optaria por usar CSR para páginas de destino específicas e não para todas as páginas, dependendo do seu 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. Influencia positivamente a acessibilidade, o tempo 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 aplicações web e é mais fácil de construir e manter; é melhor para First Input Delay (FID).

Outra consideração de CSR é que meta tags (descrição, título), URLs canônicos 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 na renderizada. HTML.

Considerações sobre plataforma

A manutenção da tecnologia CSR tende a ser mais cara porque a taxa horária para desenvolvedores qualificados em React.js ou Node.js é geralmente mais alta do que para desenvolvedores de PHP ou WordPress.

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

Para aqueles que estão considerando uma configuração WordPress sem cabeça, como usar 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, embora ainda exija PHP para o back-end.

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

Funcionalidade e finalidade do site

Às vezes, você não precisa escolher entre os dois, pois estão disponíveis soluções híbridas. Tanto o SSR quanto o 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 várias páginas, não será possível renderizar SSR o conteúdo para bots, portanto, será necessário definir alguma forma de conteúdo padrão para o Googlebot que rastreia sem cookies e apátrida.

Páginas como contas de usuário não precisam ser classificadas nas páginas de resultados do mecanismo de pesquisa (SERPs), portanto, uma abordagem CRS pode ser melhor para UX.

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

Mais recursos:

---

Imagem em destaque: TipPatt/Shutterstock