SSG

SSG é Static Site Generation, ou seja, você tem um modelo que provavelmente administra o conteúdo que vai usar no site, mais ou menos como um CMS faz, mas esse conteúdo é gerado estaticamente, portanto, principalmente o HTML é gerado de acordo com o que vai sendo trabalhado no backend e quando o acesso é feito o servidor HTTP só tem que entregar arquivos estáticos.

Eventualmente podem ter outros arquivos de imagens, CSS e JavaScript, mas raramente eles são gerados estaticamente, eles já estão lá e/ou já eram estáticos.

A performance de acesso é fenomenal e se o servidor HTTP não estiver sobrecarregado não tem como ter resultado melhor, ajudando inclusive o SEO.

Além disso ele é bem econômico em recursos porque não tem que ficar gerando o resultado final em cada acesso, só faz isso quando há uma atualização desse conteúdo.

Também costuma ser mais seguro por expor só arquivos que não tem interação com os usuários e que podem ter vulnerabilidades.

Algumas pessoas usam do jeito errado, até porque a tecnologia que escolherem tomaram a decisão errada, e fica com problemas de atualização. Em vez de toda escrita gerar um evento que faz a geração, a tecnologia determina que a atualização será feita de tempos em tempos ou outro critério, que faz o conteúdo estar quase sempre defasado. Isso costuma ser um erro e em fora raros casos é um erros adotar isso. Conhece algum site que faz isso? Não me pergunte porque adotam isso, eu só sei responder questões técnicas. E não me pergunte porque a maioria das tecnologias optaram por um sistema claramente problemático (até entendo se for algo opcional).

Em sites muito complexos já existe uma forma de build incremental.

Se for possível fazer assim, é muita vantagem para não usar. E boa parte dos sites podem. Só opte pela tecnologia certa.

SSR

SSR é Server Side Rendering, ou seja, os dados que você tem no backend, provavelmente através de Content Management System, é usado para gerar o resultado final, provavelmente o HTML, que é usado em cada vez que alguém acessa um determinado conteúdo.

Obviamente que é mais lento, consome mais recursos e tem mais chance de ter brechas.

Se você muda muito o conteúdo, tem muita interação e cada acesso já pode ser um conteúdo diferente para mostrar, pode ser mais vantajoso porque a geração é sob demanda.

Se a página gerada é diferente para cada usuário ele tende ser mais vantajoso, porque aí não precisa gerar um monte de páginas em versões diferentes deixando armazenadas desperdiçando espaço e processamento sem uso na maioria dos casos.

Esta e o modelo anterior te dão grande controle sobre como renderizar. E protege intelectualmente a parte da aplicação que usa para entregar o resultado. Se souber fazer dificilmente o usuário terá problemas para usar as páginas.

Alguns sites são feitos com CSR em mente e usa tecnologia assim, mas também usa alguma ferramenta para gerar no SSR e contornar os problemas do CSR. Nem sempre isso dá certo e gera o resultado esperado.

Para sites, se não houver um motivo muito forte, costuma ser o melhor modelo quando o conteúdo é muito dinâmico. Mas na maior parte dos casos é o que tem mais custo de servidor. Cuidado porque isso nem sempre é verdade. Na maioria dos casos pouco importa.

CSR

CSR é Client Side Rendering, ou seja, ele delega para o navegador (em geral) para ele renderizar o conteúdo que é fornecido pelo servidor.

O servidor ainda tem que entregar boa parte do conteúdo e tem carga bem maior que o SSG, mas é menos que o SSR. Há um ganho no tráfego que costuma ser o menor de todos. Se é uma porcentagem alta ou não depende do conteúdo e da estrutura da página. Quase sempre o ganho geral é pequeno.

O cliente é que monta a página final tirando boa parte do esforço que o servidor teria que fazer.

Em alguns casos sabendo melhor qual é o browser ele pode tomar algumas decisões melhores.

Mas em alguns casos pode piorar o SEO porque essa geração pode não poder ser reproduzida pelos motores de busca, mesmo que a crença popular diga que pode, depende da situação, e quase sempre as pessoas não sabem quando acontece ou não.

Pode ser que não renderize do jeito que espera dependendo da marca e modelo do navegador.

O ganho pode ser maior quando em vez de um site você tem uma aplicação, então o CSR na verdade costuma ser um SPA (Single Page Application). Porque a estrutura é transferida só uma vez e os dados várias, aí o ganho pode ser maior.

Obviamente que você tem que entregar parte do código da sua aplicação para as pessoas receberam do outro lado. Isso pode expor propriedade intelectual. Há técnicas de ofuscação ou até mesmo o uso do WebAssembly que já protege o código original, mas não o algoritmo.

E, eventualmente, pode ter problemas de privacidade com dados que não são seus, mas é mais por falha do programador, claro que poderia acontecer até nos outros modelos, mas aqui é mais comum.

Se as melhores técnicas forem aplicadas e for usado no contexto certo pode dar respostas mais rápidas nas interações com o usuário. Se não souber fazer pode piorar, e muito.

A maior vantagem é quando a página muda demais com interação com o usuário sem precisar de muita interferência do usuário. Casos assim talvez fossem melhor funcionar sem usar tecnologias web.

Uma enorme desvantagem é quando o browser não é capaz de executar o que a página tenta fazer e não renderiza do jeito que é esperado.

Outra desvantagem é quando roda em dispositivos mais limitados, como celulares por exemplo. A carga muito grande usando uma tecnologia que não é das melhores para performance pode cobrar um preço alto.

Uma das grandes desvantagens é o usuário ter uma percepção de que está em uma aplicação, não espera pela transição das páginas, se a pessoa souber o que fazer (já vi casos que fica pior).

A carga inicial pode ser bem maior, especialmente se usar WebAssembly ou um desses frameworks pesados que a maioria das pessoas usam.

Em essência só deveria ser usado para aplicações.

Híbrido

Já vi usarem um pouco de cada um dos três em certos sites. Há páginas estáticas, eventualmente geradas, há páginas geradas no momento que são requisitas e há páginas que são renderizadas no cliente. Tem casos até de uma página estática ou renderizada no servidor depois comece fazer renderizações no cliente.

Mais de um modo

Alguns casos para resolver o problema de SEO ou de dificuldades do navegador também está disponível o SSR além do CSR para as mesmas páginas.

Cada um tem sua opinião sobre isso. Pode ter casos em que faça sentido, mas em geral usam para resolver um problema de decisão errada.

Conclusão

A melhor estratégia pode ser a diferença entre o que dá melhor resultado para o usuário final, para o cliente do projeto, ou que pode ser mais fácil de lidar e ter custos mais baixos.

Farei algo que muitos pedem para aprender programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).