WEB Rendering

Web Rendering diz a respeito da forma de renderização, o processo/estratégia de geração de uma página web visual e interativa. Ou seja, o momento e o local onde o html final é montado.

CSR - Client-Side Rendering

Definição: página é renderizado no browser/ client do usuário.

As SPA - Single Page Applications utilizam CSR por padrão. O server envia apenas um HTML básico (quase vazio) junto com os arquivos JavaScript. O React (ou outro framework) monta/renderiza a interface depois que o JS é carregado, construindo o DOM (elementos do html).

CSR é ideal para web apps com muita interatividade, complexos. Um Figma, Editor de fotos, Excalidraw. Na "nossa" maioria dos casos de uso não é o "certo" usar CSR. Não compensa. Blogs, e-commerce, sites de marketing,... não requerem esse tanto de interatividade, "são sites de leitura de dados".

O Excalidraw é um ótimo exemplo: CSR é perfeito para esse caso de uso. Nele o usuário digita texto, faz drag and drop, muda a cor, redimensiona objetos, etc. A carga de trabalho dos milhares de usuários está toda no próprio device de cada usuário, e não centralizado nos servidores.

Vantagens:

• Menor carga de trabalho no servidor. (Não precisa ficar buscando página por página html).
• Experiência mais interativa depois do carregamento inicial

Desvantagens:

• Carregamento inicial mais lento (é preciso montar o DOM no browser)
• SEO piorado. (Os robôs que indexam - no google, por exemplo - os sites podem não conseguir renderizar o conteúdo todo, já que ele é renderizado posteriormente com a execução do JavaScript).
• É mais difícil de codificar corretamente. (A maioria das SPAs que vemos por aí são cheias de problemas: mudanças de estados, testes, detectar erros e etc)

SSR - Server-Side Rendering

Definição: página é montada/renderizada no servidor, em tempo de execução.

Quando uma página é requisitada ao servidor, o servidor busca dados relevantes para a página no backend e constrói o html completo e o envia para o cliente.

Existe basicamente

Vantagens:

• SEO melhorado (facilita a indexação pelos motores de busca)
• Tempo de carregamento rápido

Desvantagens:

• Alta carga de trabalho no servidor (ele precisa construir) a página a cada request
• transição mais lenta entre páginas do site

O SSR pode ser usado em sites nos quais o SEO é crucial em situações em que cada usuário possuí conteúdo exclusivo mostrado no carregamento inicial.

SSG - Static Site Generation

Definição: página é montada/renderizada no servidor, em tempo de build.

São sites inteiramente estáticos, ou seja, não há processamento no backend/servidor. Geralmente esses arquivos estáticos são servidos por ==CDNs==. É criado layouts base (ex: default.html, post.html) com header, footer, estilos e etc. Depois escreve o conteúdo em Markdown, YAML, JSON ou html simples.

Uma aplicação SSG é diferente de arquivos estáticos simplesmente (exemplo: os html, css, js servidos em uma api em /public/*). Ser SSG envolve automaticamente processar templates/dados para criar (em muitos caso, múltiplas) páginas html durante a build. Não é simplesmente um site estático tradicional.

Um exemplo de SSG é no GitHub Pages (um serviço gratuito para hospedar sites estáticos a partir de um repositório). Nele é possível escrever manualmente os statics files (html, css e js), ou usar o SSG do próprio GitHub Pages (utiliza o Jekyll) para gerar.

meu-repo/
├── _config.yml       # Configuração do site
├── _posts/           # Posts do blog (em Markdown)
├── _layouts/         # Layouts HTML
├── _includes/        # Partes reutilizáveis
├── _data/            # Dados (YAML, JSON, CSV)
├── assets/           # CSS, JS, imagens
├── index.md          # Página inicial
└── _site/            # Saída gerada (HTML final)

Depois do push o site está no ar em https://usuario.github.io/meu-repo (E se criar o GitHub Pages no repositório com nome de usuario.github.io, irá criar na URL https://usuario.github.io. Abaixo, segue exemplo de repositórios que podem ser forkados para criação facilitada de sites estáticos.

Vantagens:

• Performance maximizada (os statics files são servidor instantaneamente)
• SEO excelente (todo conteúdo disponível para os crawlers indexadores)
• Exige menor trabalho na codificação (separa o conteúdo do layout/lógica, não precisa de backend e utiliza templates que são reaproveitados em todas as páginas).

Desvantagens:

• Mudanças requerem rebuild
• Dificuldade em renderizar conteúdo dinâmico (pode até usar fetch no client, mas exige mais lógica no frontend e pode afetar o SEO. Tipo, você pega o pior dos dois mundos (SSR e CSR): Por ser MPA (Multi-page Application) não gera uma UX boa depois do primeiro loading - (Sempre que muda de página o browser faz requests para o servidor que precisa renderizar essa nova página do zero. Diferentemente se fosse uma SPA que iria trocar apenas a parte do conteúdo da tela, mantendo o header, menu e footer intactos). E, por fazer client fetching traz o loading inicial alto, junto com a complexidade de gerenciar o estado dos componentes enquanto carrega, SEO e etc).

SSG é ideal para sites que seu conteúdo não muda muito, como blog pessoal, documentação, landing page e portfólio.

ISR - Incremental Static Regeneration

Definição: Evolução do SSG. O melhor dos

Criada inicialmente pelo Next js, ISR é tipo o "melhor dos dois mundos" entre SSG e SSR.

Um exemplo é

Vantagens:

• Performance maximizada (os statics files são servidor instantaneamente)
• SEO excelente (todo conteúdo disponível para os crawlers indexadores)

Desvantagens:

• Mudanças requerem rebuild
• Dificuldade em renderizar conteúdo dinâmico (pode até usar fetch no client, mas exige mais lógica no frontend e pode afetar o SEO).

Comparação

SPAs (single page applications) que utilizam do [[WEB Rendering#CSR - Client-Side Rendering|CSR]] possuem um tempo de carga inicial muito alto (precisa montar todo o conteúdo no cliente). Ou seja, no primeiro load demora e o carregamento dos dados dinâmicos pode acabar sendo um pouco disruptivo na tela (se não tratados da maneria correta, com bons feedbacks como spinners, skeletons e etc). Porém, depois que carregado, a UX entre as "páginas" (muda na tela apenas o que precisa) é muito fluída, se assemelhando a app desktop/mobile.

MPAs (multi-page application) que utilizam do SSR clássico e SSG possuem um tempo de caraga inicial muito menor. Porém, sempre que precisam mudar de página, precisam fazer um fetch de html novo (mais pesado que se fosse apenas consumir os dados necessários em json como é comum com SPAs) e um loading do novo conteúdo (o que causa aquela "piscadinha na tela"/ quebra de UX).

Conceitos Relacionados

• Content Layout Shift
• Hydration
• Streaming
• Bundle splitting
• Data fetching
• Routing
• Initial State

Referências

• YT - Conhecendo os tipos de renderização (CSR, SSR, SSG e ISR)
• YT - How To Build A Website | GitHub Pages | Jekyll | Template
• YT - WTF Do These Even Mean