SSR não existe! Por que a ideia do Server Side Render é um equívoco?

A renderização de páginas web é um aspecto fundamental que pode não apenas influenciar a experiência dos usuários, mas também a forma como uma página é avaliada pelo sistema de indexação de buscas.

Nos últimos anos, muito se ouve falar no Server Side Render (SSR) como algo moderno, avançado, revolucionário e incrível que pode resolver todos os problemas de usabilidade e SEO de um site, mas será mesmo verdade?

Com o avanço das tecnologias relacionadas à web, as formas de se desenvolver e entregar uma página foram mudando, novos frameworks surgiram e vários detalhes e recursos técnicos envolvidos podem influenciar no resultado.

Mas uma coisa nunca mudou, um detalhe básico que faz o conceito "moderno" do SSR parecer um equívoco e que me permite fazer a seguinte pergunta:

Server Side Render realmente existe?

O que é o SSR?

Basicamente, Server Side Render é o nome moderno dado à prática de processar o HTML de uma página em um backend no servidor em tempo de execução (no acesso do usuário) e entregá-lo compilado para o navegador.

Resumindo desta forma bem objetiva, já é possível perceber o óbvio: não há nada de moderno e revolucionário nisso! É exatamente assim que muitos sites são entregues desde os primórdios da Internet, desde antes da existência de frameworks para desenvolvimento web. É exatamente assim que os clássicos frameworks MVC e até mesmo o famoso veterano Wordpress sempre fizeram.

Mas o termo como o conhecemos hoje foi cunhado após uma grande revolução dos frameworks de frontend modernos baseados em componentes, que apostaram fortemente no processamento dinâmico de páginas no lado cliente, aproveitando os recursos dos navegadores modernos e da capacidade de máquina dos dispositivos pessoais dos usuários, que são cada vez mais avançados e poderosos, geralmente muito superiores aos servidores web.

Então, para diferenciar a forma de entrega das páginas, passou-se a classificá-las como "renderizadas" do lado cliente ou servidor, e isso então cunhou o termo Server Side Render (SSR).

E por que o SSR é tão falado?

A "renderização" do lado cliente, trouxe novas possibilidades de usabilidade muito interessantes e uma experiência de desenvolvimento incrível para o programador, mas tornou-se uma preocupação de SEO devido aos indexadores de buscas terem dificuldade para entender o conteúdo dessas páginas, pois os buscadores eram basicamente aplicações que tentavam ler o conteúdo das páginas como um servidor.

Então surgiram variações dos frameworks frontend modernos baseados em componentes com a capacidade de processar o HTML do lado servidor antes de entregá-lo ao navegador, propagando esse recurso como um diferencial sob a bandeira do SSR e entregando a página de forma que os robôs de busca conseguissem ler o texto do conteúdo no código da página.

Mas isso mudou com uma grande revolução do Google alguns anos atrás, ao fazer seu robô de indexação de busca passar a ler todas as páginas na web renderizando-as com o navegador Google Chrome. Sim, atualmente o Google "lê" as páginas web exatamente como um usuário faria no navegador e ainda o faz testando como ela se comporta no computador e no celular.

E este fato já deveria ser suficiente para perceber que o SSR talvez não seja lá tudo isso que dizem por aí. Na verdade, já é um forte sinal de que...

SSR não existe

Para entender isso, é necessário:

1. Definir o que significa "renderizar"
2. Entender as limitações do que o servidor é capaz de entregar
3. Perceber as capacidades únicas do navegador web
4. Responder a pergunta: Por que o Google lê páginas web usando o navegador?

1. Renderizar

De forma geral, no mundo da tecnologia, renderizar significa produzir um resultado que possa ser visualizado por um usuário final.

O termo inclusive é muito usado por designers e criadores de áudio e vídeo para se referir ao processo de gerar o arquivo final no formato que pode ser distribuído para usuários.

O SSR faz isso com páginas web? Quase, só que não...

2. Limitações do backend no servidor

Aqui é onde talvez ocorra o equívoco do conceito.

O backend no servidor pode gerar um resultado pronto para ser carregado por um cliente (um navegador web) mas não pronto para ser visualizado por um usuário final (uma pessoa).

Confuso? Sim, o conceito pode causar essa confusão porque talvez o nome usado (Server Side Render) esteja incorreto.

O backend no servidor na verdade não renderiza nada, ele não produz um resultado visual pronto para o usuário final. A partir de um código-fonte na programação, ele gera outro código HTML/CSS/JS final que pode ser visualizado de várias formas possíveis, inclusive em um programa editor de código por outros desenvolvedores.

Essa transformação de um código-fonte original em um outro código final para ser executado por outros programas também é um conceito muito conhecido e que já existe a muito tempo no mundo da tecnologia e pode ser chamado de compilação ou transpilação, dependendo do caso.

O código-fonte original é processado para gerar um outro código mais próximo da realidade do ambiente de tecnologia onde ele será executado. Ou seja, enquanto o código-fonte original está mais próximo da realidade do trabalho de desenvolvimento do programador, o código gerado para a execução final está mais próximo do meio tecnológico em que ele será servido para o usuário.

Esse código HTML/CSS/JS resultado do processo não é o que o usuário final realmente espera ver, ele ainda precisa ser renderizado na tela de um navegador web.

Portanto, talvez Server Side Render não seja a melhor forma de nomear o que ocorre de fato, porque o backend no servidor não renderiza um resultado visual para o usuário final. Talvez o terno mais apropriado seria Server Side Processing ou Pre-Render (mas este último também tem sido usado equivocadamente para outra coisa).

3. A mágica do navegador

A rederização de fato acontece apenas quando o código final chega ao navegador, que então o processa mais uma vez e enfim apresenta na tela o resultado que o usuário realmente espera ver: cores, design, imagens, elementos interativos... Isso sim é o que deve ser entendido como renderização. E isso apenas o navegador web consegue fazer, tranformando o código final em um resultado visual interativo SEMPRE do lado cliente, ou seja, no dispositivo do usuário final.

A renderização ocorre da seguinte forma:

1. O navegador envia uma solicitação ao servidor, que responde com o código HTML, CSS e JavaScript que compõem a página.
2. O navegador então analisa o código HTML recebido e constrói uma representação virtual da estrutura lógica do documento.
3. Com base nessa estrutura, o navegador cria a "árvore de renderização", que é uma representação estrutural do conteúdo na página.
4. Em seguida, o navegador começa a aplicar o CSS para estilizar a página de acordo com as definições de estilo para a apresentação do conteúdo.
5. Depois que o CSS é aplicado, o navegador sabe exatamente como cada elemento da página deve ser exibido e só então a página toma a forma final que vemos na tela.
6. Finalmente, o navegador executa qualquer código JavaScript que estiver presente na página, o que ainda pode alterar dinamicamente a renderização.
7. Ao final de tudo isso, temos então a página totalmente renderizada e pronta para as interações do usuário na tela do navegador.

Como pode ser visto nos passos acima, tudo isso é feito pelo navegador. Essa renderização do código HTML/CSS/JS no navegador é SEMPRE necessária e não existe nisso qualquer participação do servidor.

Portanto, a renderização de fato só é possível (até o momento) do lado cliente e nunca do lado servidor.

4. O robô do Google navega na Internet?

Sim, usando o navegador Google Chrome, exatamente como uma pessoa faz. E agora que sabemos como páginas web são renderizadas é fácil entender o motivo.

Antigamente os buscadores entendiam apenas o texto escrito no código das páginas. Eles não precisavam identificar mais nada além disso e era só o que conseguiam buscar no conteúdo, bastando para isso apenas ler o texto presente no código HTML entregue pelo servidor.

O tempo passou, a web evoluiu, a forma como as pessoas a usam também... A maioria das pessoas passou a utilizar a Intenet muito mais no celular do que no computador e passou a ser importante detectar se uma página responde bem em Internet móvel e se entrega uma boa experiência de uso em telas pequenas.

Conhecer apenas o texto no código HTML de uma página web passou a não ser o suficiente para os buscadores. Óbvio que ainda é muito importante, mas a única forma de saber se uma página realmente entrega um bom resultado ao usuário é a renderização da página no único meio onde ela acontece de verdade: no navegador web.

Por isso, atualmente (na verdade desde 2016) o bot do Google navega pelas páginas na internet usando o navegador Google Chrome e simulando acessos por computador e celular.

Assim, ele pode analisar muito mais do que apenas o texto presente no código HTML da página e pode avaliar questões como performance e acessibilidade, por exemplo.

Mas é óbvio que a qualidade do conteúdo entregue e a autoridade do site no assunto ainda contam muito.

Além disso...

Uma das métricas mais importantes analisadas pelo Google ao carregar uma página é a performance do tempo de carregamento, desde o tempo de resposta do servidor até o carregamento completo da página no navegador.

Para a tristeza dos entusiastas do SSR, uma página que precisa ser processada no servidor antes de ser renderizada no navegador, dificilmente será bem avaliada na métrica de performance. Ainda que aos seus olhos esse tempo de processamento pareça rápido, o Google é bastante exigente e mede isso não como uma pessoa mas sim como uma máquina, ao nível de milissegundos.

Conclusão

Após analisar o conceito de Server Side Render (SSR) e compreender a dinâmica da renderização de páginas web, é possível concluir que o termo "Server Side Render (SSR)" pode ser equivocado.

O processo de renderização de fato ocorre no navegador, e o servidor realiza apenas o processamento e entrega do código final para ser interpretado pelo navegador. Entender que a renderização ocorre no lado cliente, no navegador, é fundamental para apresentar uma boa experiência aos usuários.

Além disso, o fato de o Google utilizar o navegador para indexar páginas web reforça a importância da renderização no navegador. Portanto, é crucial considerar a otimização da renderização de páginas web no lado cliente e a performance da página no navegador, levando em consideração essa preferência dos buscadores.

Eu já escrevi outro artigo anteriormente falando um pouco sobre isso, com foco em como desenvolver um site para ser bem avaliado nas métricas de análise do Google. Siga o link abaixo caso queira saber mais:

Como ter um site nota 100