SSR vs CSR

SSR (Server-Side Rendering) e CSR (Client-Side Rendering) são duas abordagens diferentes de como uma página web é montada e entregue ao usuário. Em SSR, o servidor gera o HTML completo e envia pronto ao navegador. Em CSR, o servidor envia HTML quase vazio e JavaScript que monta a página no navegador. Cada abordagem tem trade-offs em performance, SEO e custo. WordPress tradicional usa SSR; WordPress headless geralmente usa CSR ou variantes modernas.

O que é SSR (Server-Side Rendering)?

SSR é a abordagem clássica da web. Quando o usuário pede uma página, o servidor processa a requisição: roda código (PHP, Python, Node.js), consulta banco de dados, monta o HTML completo, envia ao navegador. O navegador recebe HTML pronto, renderiza imediatamente.

WordPress tradicional é exemplo perfeito de SSR. PHP recebe a requisição, consulta MySQL, gera HTML com tema e plugins, devolve. Navegador recebe e exibe. Sem JavaScript, página já está visível e funcional.

Vantagens claras de SSR. SEO funciona naturalmente — bots veem HTML completo, indexam tudo. Performance inicial é boa — primeira tela aparece rápido. Compatibilidade ampla — qualquer navegador, mesmo sem JavaScript habilitado, funciona.

Limitações: cada requisição custa CPU e banco no servidor. Em alto tráfego, escalar pode ser caro. Página inteira recarrega em navegação (sem JavaScript), gerando experiência menos fluida que apps modernos. Cache mitiga, mas não elimina.

O que é CSR (Client-Side Rendering)?

CSR move a renderização para o navegador. Servidor envia HTML mínimo (esqueleto) + grande pacote de JavaScript. JavaScript executa no navegador, busca dados via API, monta a interface dinamicamente. Páginas mudam sem recarregar — só JavaScript atualiza partes da tela.

Aplicações React, Vue e Angular tradicionais são CSR. Single Page Applications (SPAs) usam CSR. WordPress headless conectado a frontend React (Next.js em modo CSR) é CSR. Loja com Shopify Liquid usa SSR; loja com Shopify Hydrogen pode usar variantes.

Vantagens de CSR. Experiência fluida — transições rápidas sem reload. Servidor mais leve — só serve API, não monta HTML. Bom para apps interativos com muito estado. Carregamento subsequente rápido (já tem JavaScript em cache).

Limitações sérias. Carregamento inicial mais lento (precisa baixar JS, executar, fazer requests, renderizar). SEO precisa de configuração — bots antigos não rodam JavaScript bem. Bundle de JavaScript grande pode ser problema em mobile com conexão lenta. Acessibilidade pode ser menor se mal implementado.

SSR vs CSR: comparativo

Cinco dimensões diferenciam claramente as duas abordagens.

Performance inicial (TTFB e FCP)

SSR ganha em TTFB e First Contentful Paint quando bem cacheado. HTML chega pronto, renderização imediata. CSR tem TTFB rápido (servidor só serve arquivos estáticos) mas FCP atrasa porque depende de JavaScript baixar e executar antes de mostrar conteúdo.

Performance pós-carga

CSR ganha aqui. Após carregamento inicial, navegação interna é quase instantânea — só JavaScript atualiza, sem reload. SSR tradicional recarrega página inteira a cada clique, mesmo que cache mitigue parte do impacto.

SEO

SSR é amigo natural do SEO. Bots recebem HTML completo, indexam tudo. CSR exige cuidados — Googlebot moderno renderiza JavaScript, mas com delay e custo. Outros bots (Bing, sociais) são piores. Para SEO crítico, SSR ou variantes (SSG, ISR) são preferíveis.

Custo de servidor

CSR tem custo menor de servidor — só serve assets estáticos e API. SSR tradicional renderiza HTML a cada request, consumindo CPU. Cache reduz, mas não elimina. Para sites com tráfego massivo e conteúdo previsível, CSR + API pode escalar mais barato.

Complexidade

SSR é simples: navegador recebe HTML, exibe. CSR é mais complexo: navegador baixa JS, executa, busca dados, monta tela. Mais coisa para dar errado, mais bugs possíveis, mais conhecimento exigido do time.

Variantes modernas

Em 2026, a discussão SSR vs CSR é simplista. Existem variantes que combinam o melhor dos dois mundos.

SSG (Static Site Generation)

Site é gerado estaticamente em build time, não em request time. HTML é pré-renderizado e servido de CDN. Performance excelente (servir arquivo estático é o mais rápido), SEO perfeito (HTML pronto), custo mínimo (sem servidor processando). Limitação: conteúdo dinâmico precisa de rebuild ou abordagem híbrida.

ISR (Incremental Static Regeneration)

Variante de SSG com regeneração incremental. Páginas são estáticas mas regeneradas em background quando dados mudam. Combinação rara: performance de estático + frescor de SSR. Next.js popularizou esse padrão.

Hybrid rendering

Mesma aplicação usa estratégia diferente por página. Home estática (SSG), área logada SSR, busca CSR. Frameworks modernos (Next.js, Nuxt, Astro) suportam essa flexibilidade nativamente.

WordPress tradicional usa SSR ou CSR?

WordPress tradicional é puro SSR. PHP renderiza HTML, devolve ao navegador. Não há JavaScript framework no meio. Cache de página (via WP Rocket, LiteSpeed Cache, etc.) acelera servindo HTML pré-renderizado, mas o modelo permanece SSR.

Por isso WordPress tem SEO naturalmente forte. Cada post é HTML completo, fácil para Google indexar. Cada página renderiza imediatamente, sem dependência de JavaScript. É um dos motivos da popularidade do WordPress: a base SSR já entrega bom SEO sem esforço técnico extra.

Em sites WordPress com Elementor ou outros builders, há JavaScript ativo na página (animações, sliders, sticky headers), mas o HTML inicial vem completo do servidor. É SSR com enhancements no cliente, padrão moderno mas ainda fundamentalmente server-rendered.

Quem quer adicionar capacidades de CSR em WordPress sem virar headless usa Alpine.js, htmx ou JavaScript vanilla para interatividade pontual. Mantém base SSR, ganha fluidez moderna onde precisa. Veja htmx para detalhes.

WordPress headless e CSR/SSR

WordPress headless separa backend (WordPress como CMS via API) de frontend (qualquer tecnologia). Permite escolher abordagem de renderização do frontend independentemente do backend.

Frontend Next.js consumindo WordPress REST API pode usar SSR (gera HTML em cada request com dados frescos), SSG (gera HTML em build), ISR (combinação) ou CSR puro. Decisão depende do tipo de conteúdo: blog estático com regeneração ocasional combina com SSG; e-commerce com estoque variando combina com ISR ou SSR.

Next.js WordPress é o stack mais comum em headless brasileiro. Frontend em Next.js (SSR/SSG/ISR conforme página), backend em WordPress (REST API ou GraphQL). Combina performance moderna com facilidade do CMS.

Trade-off de headless: complexidade técnica maior. Time precisa entender duas tecnologias (WordPress + Next.js, ou similar). Plugins WordPress podem não funcionar (especialmente os que injetam HTML no front). Vale para projetos com necessidade real de performance ou diferenciação de stack.

Quando escolher cada abordagem

SSR puro (WordPress tradicional, Laravel, Django) faz sentido quando: SEO é crítico, conteúdo muda mas não constantemente, time não quer complexidade de SPA, custo de hospedagem precisa ser previsível. Cobre 90% dos sites web em 2026.

CSR puro faz sentido para apps internos, dashboards, ferramentas onde SEO não importa e onde experiência fluida é prioridade. Aplicações tipo Figma, Notion, Linear são CSR. Sites públicos puros raramente justificam CSR puro.

SSG faz sentido para blogs estáticos, documentação, sites institucionais. Performance excelente, SEO impecável, custo quase zero. Limitação: rebuild em mudanças (mas em sites estáveis, OK). Frameworks: Astro, Hugo, Jekyll, Next.js em modo SSG. Veja Astro vs WordPress.

ISR/Hybrid faz sentido para e-commerces médios, portais com conteúdo misto, projetos com partes dinâmicas e partes estáticas. Combina vantagens conforme necessidade. Mais complexo, mas escala bem. Combine com performance WordPress para resultado completo.

Perguntas frequentes

WordPress tradicional é SSR ou CSR? SSR. Toda página WordPress é renderizada no servidor (PHP) e enviada como HTML completo ao navegador. JavaScript ativo na página é enhancement, não a base. É um dos motivos do bom SEO natural do WordPress.

SSR é melhor para SEO? Geralmente sim. HTML pré-renderizado facilita indexação por bots, especialmente os que não executam JavaScript bem (Bing, redes sociais, SEO tools). Para SEO crítico, SSR ou variantes (SSG, ISR) são preferíveis a CSR puro.

Posso usar SSR e CSR juntos? Sim, padrão moderno. Frameworks como Next.js, Nuxt e Astro suportam SSR para algumas páginas, SSG para outras, CSR para terceiros, na mesma aplicação. Hybrid rendering é a abordagem dominante em projetos web sérios em 2026.

WordPress moderno com performance otimizada: conheça os planos PRO da FULL Services. Entregamos WordPress tradicional ou headless conforme necessidade do projeto, com infraestrutura adequada para cada modelo.