Quando falamos de Nuxt, Next e outras ferramentas, geralmente encontramos algumas siglas difíceis de entender num primeiro momento: CSR, SSG e SSR. E juntamente com elas, surgem alguns questionamentos: Qual a diferença entre renderizar minha aplicação no lado do cliente ou no lado do servidor? Por qual motivo, geralmente, é recomendado eu fazer o uso da pré-renderização?

O objetivo deste post é explicar os conceitos de Client Side Rendering (CSR), Static Site Generation (SSG) e Server Side Rendering (SSR) elucidando tais questões, apresentando suas vantagens e desvantagens e alguns casos de uso.

Antes de entrarmos nos conceitos, segue abaixo uma pequena relação de algumas ferramentas no mercado para a implementação destas técnicas em seu framework de escolha:

• Angular Universal - ecossistema Angular
• Next - ecossistema React
• Nuxt - ecossistema Vue.js
• Sapper - ecossistema Svelte

Client-Side Rendering (CSR)

É um formato de renderização em que a parte de renderização do conteúdo é feito no lado do cliente (browser). A tecnologia que mais utiliza esta técnica é a Single Page Application. Neste formato, o servidor é responsável apenas por entregar os assets necessários para a aplicação, mas o HTML não é servido com o seu conteúdo preenchido. Isso fica a cargo do browser.

Toda SPA faz o trabalho de renderização no lado do cliente, mas nem toda aplicação que faz esse trabalho é uma SPA. Explico: antigamente, era comum o uso da técnica AJAX para a requisição de informações do servidor e exibição dessas mesmas informações para o cliente. Como essas informações eram exibidas? Através de manipulação do DOM, seja com jQuery ou outra biblioteca. O ponto é: tais aplicações não eram uma SPA (principalmente porque o roteamento da aplicação ainda era no servidor), apesar de executarem um trabalho de renderização no lado do cliente.

Para saber mais sobre SPAs, confira o post Single Page Applications: Onde vivem e o que comem escrito por [Vinicius Reis]

Server-Side Rendering (SSR)

É um formato de renderização de páginas já bastante conhecido. Como o nome diz, é uma renderização do lado do servidor. Desta forma, haverá a necessidade de uma estrutura no servidor responsável não apenas por servir os assets, mas também por gerar as páginas HTML já completas, com o conteúdo populado. As ferramentas citadas possuem em seu core tal funcionalidade, geralmente com um servidor em Node.js.

Quais problemas o SSR resolve?

Primeiramente, questões relacionadas a SEO (Search Engine Optimization). Como numa SPA a renderização é feita no browser, e alguns web crawlers não tem capacidade de executar código JavaScript, apenas HTML, o web crawler captura uma página com praticamente nenhuma informação semântica, o que é ruim para o SEO.

Segundo, há as questões relacionadas a performance. Uma página com o HTML com o conteúdo necessário já servido é bem melhor do que você ter este mesmo conteúdo em um JavaScript que será baixado, parseado e executado em um momento posterior. Não só isso, em um contexto em que as pessoas usam mais os seus smartphones do que seus computadores para ter acesso a informação na internet, ter uma menor quantidade de código JavaScript é melhor. Lembre-se: performance também é uma métrica para a experiência do usuário.

Porém, o SSR possui um questão na sua implementação: ele exige um servidor que execute a sua aplicação e sirva o código HTML. Atualmente, existem inúmeras formas gratuitas para se fazer isso, com um certo limite, como no caso da Vercel.

Static Site Generation (SSG)

Você pode encontrar este mesmo conceito como pré-render.

É um formato de renderização em que as páginas da aplicação são renderizadas na fase de build da aplicação e com isso, é possível usar qualquer servidor de páginas estáticas (Vercel, Netlify, Github Pages...) para disponibilizar seu conteúdo.

Existem algumas ferramentas que são focados nesse tipo de formato, como o Gatsby para o React e o Gridsome para Vue.js.

A performance, neste formato, é superior ao do SSR pelo fato de que não há um trabalho de renderização das páginas por demanda em algum servidor. Todas as páginas HTML da sua aplicação já foram populadas com as informações necessárias.

Porém, há uma ressalva a ser feita: o tempo de build. Em algumas aplicações, geralmente blogs, há uma quantidade enorme de conteúdo. Dessa forma, se toda a alteração feita em uma página exigir que todas as outras páginas sejam novamente geradas, isso leva a aumento no tempo de build. O Gatsby, por exemplo, já possui uma solução para esse problema através de builds incrementais.

É possível combinar estas técnicas?

Sim, e geralmente se você está usando o Nuxt ou Next, você já combina elas. Por exemplo, com o SSG no Nuxt, ao acessar a primeira página, toda a navegação e renderização continuará seguindo pelo lado do cliente. Isso é positivo pelo fato de que não será necessário, uma vez carregado o site, buscar por novas páginas no servidor.

Um outro caso de combinação é usando o Next, em que é possível ter uma renderização híbrida da página, com partes dela sendo pré-renderizadas e outras sendo renderizadas no browser. Ou ainda, no mesmo projeto, possuir páginas pré-renderizadas e outras renderizadas no servidor.

Qual escolher?

Depende do seu objetivo e propósito. Geralmente, para sites de conteúdo como blogs, uma pré-renderização das páginas (SSG) pode ser uma boa escolha por questões de SEO e performance, haja vista que o conteúdo não muda com muita frequência. Em casos de aplicações complexas, geralmente tem-se optado pelo uso de SPAs, e consequentemente de CSG, também por questões de performance.

Conclusão

Espero que este texto possa ter servido para esclarecer suas dúvida. Se possui algum comentário, não deixe de fazê-lo. Até a próxima!

Para saber mais sobre o assunto:

• Post da Google sobre os formatos de renderização na Web
• Documentação do Angular Universal
• Vídeo do Willian Justen sobre o assunto
• Documentação do Next.js sobre Pages
• Texto do IMasters explicando a diferença entre Multi/Single Page Applications
• Post oficial da equipe do Gatsby sobre os Incremental Builds