SSR, SSG ou híbrido: a pregunta que case ninguén fai ben
A pregunta que nos fan é “que é mellor, SSR ou estático?”, e esa pregunta xa está mal formulada. É como preguntar se é mellor un coche ou unha furgoneta sen dicir que vas transportar.
A resposta correcta non depende do que soe máis moderno, senón de con que frecuencia cambia o contido e se depende de quen visita a páxina. A grandes trazos: estático (SSG) para o que case non cambia, servidor (SSR) para o que cambia todo o tempo ou varía segundo o usuario, e híbrido cando conviven ambos os casos no mesmo proxecto.
SSG (sitio estático, xerado en build) significa que as páxinas se constrúen unha vez e se serven sempre iguais ata o próximo despregamento. É rapidísimo, barato de aloxar e case imposible de tombar con tráfico, porque non hai nada que calcular en cada visita. O prezo é que o contido non cambia só: se algo se actualiza na orixe, hai que reconstruír o sitio.
SSR (renderizado en servidor en cada petición) ten sentido cando o contido cambia todo o tempo ou depende de quen visita a páxina: unha listaxe de propiedades con filtros, un prezo que varía segundo o stock, un panel onde cada usuario ve algo distinto. Aquí si precisas un servidor a correr, non só ficheiros estáticos, e iso ten un custo de infraestrutura e de complexidade que hai que asumir.
O híbrido, parte do sitio estático e parte renderizado en servidor, é o que usamos na maioría dos proxectos serios, aínda que case ninguén o pida así explicitamente. Nun proxecto inmobiliario que levamos, por exemplo, as páxinas de contido fixo (quen somos, política de privacidade) son estáticas, e as fichas de propiedade, que cambian co stock dispoñible, levan SSR.
O erro que vexo repetirse é elixir a arquitectura polo que soa máis moderno no canto de por como cambia o contido real do proxecto, o mesmo erro de fondo que xa comentamos ao falar de como eliximos stack. Vin sitios enteiramente SSR para contido que se actualiza unha vez ao mes, pagando servidor as 24 horas para renderizar exactamente o mesmo unha e outra vez. E vin tamén o erro contrario: sitios estáticos aos que alguén tenta meterlle funcionalidade dinámica a base de JavaScript no cliente, cando o que precisaban desde o principio era SSR.
A pregunta correcta, antes de mirar frameworks, é con que frecuencia cambia cada parte deste sitio e quen precisa velo actualizado ao segundo. Esa resposta decide a arquitectura, non o framework de moda do trimestre.