- Renderização Estática vs Dinâmica
- Prós e Contras com renderização no servidor
- Server Components vêm com benefícios adicionais
- Server Components não são perfeitos
- Conclusão
Renderização Estática vs Dinâmica
Como revelado anteriormente, Server Components podem ser renderizados tanto em tempo de construção (estático) quanto em tempo de execução quando uma requisição chega (dinâmico). Isso é apenas o que você deve saver, mas que, infelizmente, tem muitos "ses" e "poréns".
Next.js faz uma tentativa de gerenciar isso automáticamente para você. O que eles fazem é renderizar de forma estática por padrão e automáticamente ativar a renderização dinâmica quando necessário ou quando você configurar. A renderização dinâmica será usada quando:
- Funções dinâmicas são usadas, que são funções nativas para ler cookies, headers ou parâmetros de busca
- Você Desativar o cache para a função fetch nativa
- Você manualmente mudar o comportamento com uma configuração de segmento de rota
Eu tenho certeza que você lerá esses links para entender isso, esse artigo já está longo o suficiente sem isso. Uma coisa que você deve anotar, é que o comportamento difere quando você usa as funções nativas do Next.js para busca (fetch) de dados, cookies, headers e parâmetros de busca, em comparação com quando usa soluções próprias ou bibliotecas externas.
O Next.js não irá saber quando seu componente precisa ser dinâmico se você não usar as suas próprias features. Nesses casos, vocẽ deve configurar manualmente o comportamento de cache.
Prós e Contras com renderização no servidor
Como prometido há um tempo ao longo do artigo, nós vamos agora ver os prós e contras de renderização no lado do servidor. SSR tem muitos benefícios e poucos malefícios. As vantages podem vairar ligeiramente dependendo do tipo de renderização no servidor escolhido. Note que as vantagens de SSG podem ser diferentes das de SSR. Esses prós e contras são, em termos gerais, para conteúdos renderizados no lado do servidor.
Vantagens de renderizar dados no lado do servidor
- Servidores normalmente têm menos latência com o banco de dados que os clientes, especialmente se a conexão ao banco de dados de um cliente passa por um servidor
- Um ou alguns servidores podem aproveitar melhor o cache do que milhares ou milhões de usuários
- Analizar (parse) JavaScript é uma operação lenta e uma das maiores razões de sites lentos. Renderizar dados no servidor reduz o tamanho do bundle de JavaScript enviado para o cliente
- O carregamento inicial da página é mais rápido com server side rendering, o que é ótimo para UX e SEO
- Server Side Rendering é melhor para SEO em geral, devido à menor participação do JavaScript, que tem uma relação longa e problemática com os web crawlers
- Você pode usar dados sensíveis como API keys no conteúdo renderizado no lado do servidor, pois informações sensíveis como essa nunca devem ser usadas no lado do cliente
- Com server side rendering, você pode manter suas APIs e bancos de dados privados e inacessíveis para a internet, pois não precisa deles no lado do cliente. Sem autenticação que é mais ou menos impossível de ser alcançado quando um cliente depende desses recursos
- Quando dados são buscados no servidor, não é necessário mostrar spinners ou skeletons
- Quando dados são buscados no servidor, layout shift cumulativo não será um problema
- Conteúdos renderizados no servidor são mais previsíveis quando uma aplicação deve suportar diferentes navegadores e dispositivos, porque o servidor interpreta o JavaScript. No lado do cliente, JavaScript sempre pode ser desabilitado.
Desvantagens de Renderizar dados no lado do servidor
- Renderizando conteúdos nos servidores leva a uma carga maior, que resulta em despesas maiores com servidores
- Servidores geralmente tem pouco suporte para bibliotecas de terceiros
- Você não pode acessar funcionalidades do navegador, a localização do usuário, dispositivo e etc em um servidor.
- O tempo de carregamento para navegação pode ser lento se os dados não são reutilizados e cada navegação resulta em uma página completamente nova (Essa desvantagem era um problema maior com soluções tradicionais de renderização no lado do servidor onde o conteúdo renderizado era raramente reutilizado).
Server components vêm com benefícios adicionais
Quando se trata de React Server Components, todos os prós e contras acima listados para SSR são aplicados, mas Server Components também tem algumas vantagens adicionais.
Um detalhe interessante é que todo Server Components já é pré-renderizado quando o cliente recebe uma aplicação. Isso significa que Server Components renderizados condicionalmente podem ser renderizados instantâneamente, mesmo quando dependem de dados da rede. Não é necessário esperar uma resposta da rede e gerenciar o estado de carregamento, mesmo nos casos onde o componente é renderizado condicionalmente em resposta a uma ação do usuário.
Lendo isso você deve estar preocupado com o tamanho do bundle. Mas as suas preocupações são injustificadas, pois código HTML não tem um grande impacto no tempo de carregamento. HTML é armazenável em cache, mais rápido para analisar (parse) e rodar que JavaScript e só uma fração do tamanho de imagens.
E como cereja do bolo, Server Components adicionam tamanho zero de bundle para dependências de JavaScript! Mesmo se você usar uma biblioteca não otimizada para remoção de código não utilizado (tree-shacking) de 250 kB, o código HTML resultante ainda incluirá 0 kB de JavaScript.
Server Components não são perfeitos
Que Server Components são incríveis todos estão de acordo, certo? A resposta é não. Existem algumas potenciais desvantages incovenientes.
Server Components precisam de novos conhecimentos. A migração do velho Pages Router para o novo App Router vem com uma completa nova forma de pensar que a maioria dos desenvolvedores não estão acostumados.
Não apenas o conhecimento dos desenvolvedores torna-se obsoleto, o código também. Apesar das novas versões do Next.js estarem totalmente compatíveis com o antigo Pages Router, os código que o usam vão virar código legado, assim como os antigos Class Components do React.
Algumas outras desvantagens também existem em relação à qualidade de código. Compartilhar código torna-se mais difícil quando a renderização é dividida ainda mais em renderização no cliente e no servidor. Código marcado com use client e a importanção de recursos exclusivos de servidor tornam mais trabalhoso aplicar DRY ao código.
Eu devo admitir também, apesar de opinativo, que a prop drilling dos Server Components não é a melhor solução em termos de legibilidade. No Next.js, Server Components não podem ser importados em um Client Component, o que significa que Server Components renderizados em Client Components devem ser passados como children e renderizados dessa forma. Isso funciona e não é novo, mas pode ser um pouco complicado de se adaptar.
Conclusão
A web começou com HTML recebido de um servidor com muito pouco JavaScript. O tempo passou e depois de várias voltas e quatro diferentes soluções, como single page applications (SPAs), server side rendering (SSR) e static site generation (SSG), o React agora evoluiu com o uso dos Server Components.
O Next.js oferece o Pages Router como legado que usa as velhas opções de renderização juntas com uma estratégia de geração estática incremental (ISR). Com o advento dos Server Components, ele agora oferece o novo App Router que permite otimizar a renderização a nível de componente com os Server Components.
Entre todos os benefícios dos Server Components, nós temos o pequeno tamanho de bandle, rápido tempo de carregamento das páginas, ótima compatibilidade com SEO e suporte de navegadores, melhoras de UX e a possibilidade de usar dados sensíveis no servidor. Além disso, podemos obter renderização instantânea para componentes renderizados condicionalmente, sem a necessidade de exibir qualquer spinner ou skeleton para indicar carregamento.