React: explorando estratégias de renderização do Next.js

Entendendo estratégias de renderização - Apresentação

Apresentando a instrutora e o curso

Olá! Seja bem-vindo, estudante da Alura. Meu nome é Patrícia Silva.

Audiodescrição: Patrícia é uma mulher branca com cabelos cacheados. Ela está usando óculos de aro preto, mas, em algumas ocasiões, pode aparecer com óculos diferentes.

Sou tech lead e full stack engineer, com 15 anos de experiência em desenvolvimento de software. No meu dia a dia, crio soluções que integram front-end, back-end, banco de dados e arquitetura, com foco em performance e boas práticas. Neste curso, quero compartilhar esse conhecimento com vocês.

Explorando estratégias de renderização no Next.js

Vamos discutir diferentes estratégias de renderização que o Next.js oferece. Cada uma dessas estratégias impacta de maneira distinta a performance e o SEO (Search Engine Optimization), que é responsável por ranquear o site nos mecanismos de busca. Portanto, é importante conhecermos as diferenças entre essas estratégias, quando utilizá-las, seus prós e contras.

Estou com o navegador aberto, e este é o projeto que utilizaremos ao longo do curso. Ele já possui os componentes de apresentação prontos, mas ainda está sem lógica e sem dados. Vamos criar essa camada de dados do zero, incluindo banco de dados e data layer (camada de dados) dentro do Next.js, para integrar esses dados com o front-end.

Implementando e conectando páginas do e-commerce

À medida que implementamos e conectamos cada página do nosso e-commerce, vamos aplicando e entendendo cada estratégia de renderização. Por exemplo, já temos o site funcionando, então vamos dar uma olhada no que vamos trabalhar.

Nosso objetivo será renderizar a página de produtos e categorias de uma forma que seja performática e mantenha o SEO intacto. O SEO é responsável por descrever a página para os crawlers (robôs que indexam essa página nos mecanismos de busca).

Abordando rotas dinâmicas e busca interativa

Ao clicar em "ver mais" em um produto, entraremos no detalhe do produto, que é uma rota dinâmica. Nosso objetivo será implementar uma página que é gerada e pré-renderizada no momento do build. No entanto, como se trata de uma rota dinâmica, a maneira como aplicamos essa técnica é um pouco diferente.

Outro desafio é implementar uma busca interativa de produtos. Ou seja, dado um termo de busca, vamos filtrar produtos de forma interativa. À medida que digitamos, as alterações acontecem instantaneamente na página. Este é um componente que roda apenas do lado do cliente. Vamos entender por que ele não pode rodar do lado do servidor ou no momento do build.

Concluindo com pré-requisitos e próximos passos

Durante o curso, abordaremos tudo isso. O mais importante não é apenas aprender as estratégias de renderização, mas também como usá-las com criticidade, entendendo seus trade-offs e limitações para escolher a melhor solução em cada cenário.

Para realizar tudo isso, os pré-requisitos são: conhecimento em JavaScript e React, além de noções de Next.js. A partir daí, guiaremos passo a passo até a conclusão deste projeto e seu deploy em produção, onde será possível compartilhar a URL com todos.

Vamos juntos dar vida a essa aplicação. Clique na próxima aula e comece essa jornada de aprender Next.js de forma prática e aplicada. Até já!

Entendendo estratégias de renderização - Explorando o CSR e SSR

Introduzindo estratégias de renderização

Quando acessamos um site e ele aparece instantaneamente, ou, ao contrário, demora uma eternidade para carregar, a diferença está em como o conteúdo é entregue ao navegador. É nesse contexto que entram as estratégias de renderização. Conhecer diferentes estratégias de renderização e saber quando utilizá-las impacta diretamente na experiência do usuário e no planejamento da construção do nosso projeto.

Hoje, vamos abordar quatro diferentes estratégias, começando pelas duas primeiras. A primeira delas é o CSR, que é a renderização do lado do cliente. Nesse caso, o cliente é o navegador, que será responsável por renderizar a página. Tecnologias como React e Angular já nascem com padrões de client-side rendering, sendo ideais para single-page applications e aplicativos dinâmicos, como jogos, formulários, chats e páginas interativas.

Explorando o client-side rendering

Por exemplo, event handlers são eventos associados a elementos, como um botão com um evento de on-click ou um campo de entrada com um evento de on-change. Para implementar funcionalidades como arrastar e soltar elementos na tela, utilizamos JavaScript, pois o navegador entende HTML, CSS e JavaScript. Esses event handlers existem apenas no lado do cliente, no navegador, e não no servidor. Portanto, quando há event handlers, sabemos que eles precisam ser trabalhados no lado do cliente.

O navegador inicialmente carrega um HTML vazio. Ele começa recebendo um HTML vazio e, após receber o JavaScript, é que a página é renderizada. O navegador realiza um trabalho significativo de renderização, juntando tudo e exibindo na tela.

Analisando os pilares do client-side rendering

Existem três pilares fundamentais: o build, que gera um HTML vazio, o script JavaScript e o CSS. O servidor estático armazena esses arquivos, sem processá-los, aguardando que um usuário solicite o recurso. Quando o navegador faz o download do JavaScript, a página ganha vida. Ele entende que existe uma referência, como a tag root, onde deve renderizar os elementos. Durante a navegação fluida, quando a página muda sem recarregar, é o client-side rendering que está renderizando o novo conteúdo dentro da tag.

Os benefícios dessa estratégia incluem a proximidade com o usuário. Quanto mais próximo do usuário, melhor. O navegador, após o computador físico, é o que está mais próximo do usuário, proporcionando interatividade rápida. Os eventos ocorrem na camada do cliente, no navegador, melhorando a experiência de carregamento após o inicial, pois tudo acontece no navegador. Isso significa menos carga para o servidor, que não precisa processar nada além de servir os arquivos estáticos, ou assets.

Considerando as limitações do client-side rendering

Entretanto, existem contras. O carregamento inicial da página pode ser mais lento, especialmente com internet lenta, resultando em uma página em branco até que o JavaScript seja carregado e executado. Isso também prejudica o SEO (Search Engine Optimization), pois o HTML não é pré-renderizado no servidor. Ferramentas de busca, como os crawlers, enfrentam dificuldades para indexar páginas que dependem do JavaScript para serem renderizadas.

Quando um e-commerce ou blog não está bem ranqueado, ele não terá conversão nem muitos acessos, o que é importante. Portanto, devemos ser críticos ao escolher a estratégia. Isso depende de dispositivos mais modernos. Se o navegador faz todo o trabalho pesado e o usuário possui um celular básico, o poder de processamento é menor, resultando em lentidão. Se unirmos isso a uma internet lenta e a um dispositivo com limitações de recursos, a experiência do usuário será prejudicada. Devemos ter isso em mente, pois, conhecendo as ferramentas, seus prós e contras, saberemos exatamente o que usar quando surgir um problema.

Aplicando o client-side rendering em diferentes contextos

Existem páginas que são apenas single SPAs (Aplicações de Página Única). Às vezes, temos uma página que não necessita de muito SEO (Otimização para Motores de Busca). Podemos ter uma página inteira como single SPA sem nos preocuparmos muito com SEO. No entanto, em aplicações onde o SEO é prioridade, como em e-commerce, é crucial estar bem ranqueado. Caso contrário, será desclassificado pelos crawlers (robôs de busca), e os clientes não terão acesso. Com o Next.js, a boa notícia é que conseguimos uma abordagem mais híbrida, misturando com server-side rendering (renderização do lado do servidor). Vamos demonstrar isso.

No desenvolvimento de jogos, que são dinâmicos, é necessário o client-side rendering (renderização do lado do cliente). A analogia que podemos fazer é a seguinte: ao comprar um móvel em uma loja, ele vem desmontado em uma caixa de papelão. Levamos para casa e montamos, que é o trabalho do navegador. Essa analogia ajuda a lembrar do processo.

Explorando o server-side rendering

Temos também o conhecido server-side rendering. Anos atrás, tudo era processado do lado do servidor, com tecnologias como PHP, JSP, ASP, entre outras. No Next.js, por padrão, tudo é renderizado no servidor. Não precisamos fazer nada, pois ele já carrega dessa forma. O servidor recebe a requisição e gera o HTML completo para cada solicitação do usuário. Isso é muito bom para SEO e compatibilidade com dispositivos mais simples.

No servidor, durante o build, temos apenas arquivos, sem vida. Empacotamos isso, e ele vive no servidor. Quando o usuário faz uma requisição via navegador, o servidor a recebe e gera a página HTML estática, pronta, com os componentes, HTML e CSS. O navegador recebe essa página já pré-renderizada, o que é vantajoso, pois a exibição é rápida no carregamento inicial. O navegador não precisa unir todos os elementos para renderizar, pois já está pronto.

Avaliando os benefícios e desafios do server-side rendering

O SEO é melhor porque a página foi pré-renderizada. Os crawlers entendem melhor, pois a página já está pronta. Isso também reduz o esforço para dispositivos com limitações de hardware, pois o navegador consome menos memória ao baixar o HTML pronto. No entanto, a carga agora está do lado do servidor, que precisa processar tudo. Em aplicações com muitos acessos, o servidor pode ficar sobrecarregado. Existem formas de trabalhar para aumentar recursos e melhorar o tempo de resposta do navegador, mas a carga recai sobre o servidor, o que pode aumentar os custos com infraestrutura.

Se o servidor não tiver recursos suficientes ou estiver sobrecarregado, pode haver atrasos e lentidão na resposta, especialmente em eventos como a Black Friday. Além disso, a localização do servidor influencia na velocidade de acesso. Se o servidor estiver na Europa e o usuário no Brasil, o acesso será mais lento. Um servidor na América Latina seria mais rápido. No server-side rendering, o recarregamento da página é total, sem navegação fluida. Ao mudar de página ou link, tudo é renderizado novamente.

Entendendo estratégias de renderização - Explorando o SSG e ISR

Introduzindo a geração de páginas estáticas

Já abordamos as estratégias de renderização do lado do servidor e do lado do cliente no navegador. No entanto, é possível gerar páginas estáticas, ou seja, HTML, CSS e JavaScript prontos no momento do build. Isso significa que não geramos nem no servidor nem no navegador, mas sim durante o build. Empacotamos, fazemos o deploy e tudo já está preparado para o navegador renderizar.

Existem duas estratégias para que isso aconteça, e começaremos pelo SSG, o Static Site Generation (Geração de Site Estático). Com essa estratégia, conseguimos configurar para que as páginas sejam geradas no momento do build. Por exemplo, páginas institucionais muitas vezes não mudam o texto ou conteúdo por meses, semanas ou até anos, como páginas de termos de uso ou blogs, onde os posts raramente mudam. Portfólios também são exemplos perfeitos para serem gerados estaticamente e deixados prontos. No entanto, essa estratégia requer que, toda vez que o conteúdo mudar, ele precise ser atualizado e reconstruído.

Explorando o Static Site Generation (SSG)

Vamos analisar mais a fundo. Nos nossos três pilares, no build, no momento em que empacotamos esses arquivos, já pré-renderizamos e geramos o HTML. Quando o conteúdo vai para o servidor, colocamos lá páginas HTML estáticas. No build, podemos ver que um HTML foi gerado, e ao clicar duas vezes, ele abre, mostrando que é estático e contém tudo o que precisa. Ele permanece no servidor, pronto para ser entregue diretamente ao navegador quando requisitado. Essa abordagem combina o melhor do server-side com velocidade, pois o carregamento é muito rápido. O servidor não é afetado, pois as páginas estáticas foram geradas no momento do build, e ele só precisa entregar o HTML pronto. O SEO também está otimizado, pois o HTML estático é semelhante ao que acontece no server-side rendering, indo para o navegador pronto.

Essa estratégia é mais segura, pois não precisamos acessar dados de servidores dinâmicos ou estar conectados a um banco de dados. Tudo é estático e já foi empacotado assim, eliminando problemas de brechas de segurança em servidores dinâmicos. A hospedagem é barata, pois qualquer provedor consegue servir esses assets estáticos de forma econômica.

Discutindo as limitações do SSG

No entanto, existem contras. Como o conteúdo é estático, não há atualização em tempo real. Se for necessário atualizar os termos de uso, por exemplo, será preciso fazer o build novamente, colocar no servidor e só então o usuário terá acesso à atualização. A cada mudança, é necessário reconstruir tudo e fazer o deploy, colocando em produção no servidor. A escalabilidade é limitada, pois é conteúdo estático. Usamos essa estratégia para conteúdos que não mudam com frequência. Se o conteúdo precisa ser sempre atualizado ou ter interatividade, como adicionar um produto ao carrinho com preço variável, essa abordagem é limitada para sites muito grandes. Utilizamos essa estratégia apenas para conteúdos que sabemos que são estáticos e não mudam.

Introduzindo o Incremental Site Regeneration (ISR)

Podemos aproveitar a facilidade do Next.js para gerar conteúdo estático. Além disso, existe o melhor dos dois mundos: o Incremental Site Regeneration (Regeneração Incremental de Site). É a evolução do Static Site Generation, pois permite atualizar o conteúdo de acordo com um intervalo de tempo definido, garantindo que o conteúdo não fique desatualizado.

Temos novamente os nossos três pilares. Assim como no SSG, no momento do build, geramos as páginas HTML, colocamos essas páginas no servidor para serem servidas, e o navegador recebe a página pronta. A diferença é que há uma estratégia adicional.

Explicando o funcionamento do ISR

A cada determinado período, podemos configurar para que uma área da página seja atualizada. Por exemplo, uma seção com elementos em azul, que pode conter produtos, pode ser atualizada incrementalmente a cada cinco minutos, uma hora, dois dias, três dias ou um mês. Essa área é gerada de forma estática, mas o servidor, que possui os arquivos estáticos, está configurado para, quando o tempo expira, gerar em background uma nova página atualizada. Assim, o próximo cliente que acessar essa página no navegador verá a versão atualizada.

Essa abordagem é vantajosa porque a performance é excelente. Existe uma atualização programada de um conteúdo específico, como uma área de produtos ou publicidade, que será regenerada em background periodicamente. O próximo cliente que acessar esses dados verá a página e os assets atualizados. Isso ocorre sem a necessidade de um rebuild total, ou seja, não é necessário reconstruir tudo e colocar no servidor. Esse processo ocorre de forma automática, melhorando o tempo de build. Se tivermos mil páginas, por exemplo, não precisamos gerar todas as páginas estáticas, o que economiza tempo. Apenas o que for necessário será gerado, tornando o build mais rápido.

Avaliando as vantagens e desafios do ISR

A escalabilidade é muito boa para blogs, e-commerce e catálogos, especialmente se utilizarmos uma estratégia bem direcionada. Por exemplo, em um blog, algumas áreas podem ser estáticas, mas certos conteúdos, como testemunhos ou avaliações de clientes, podem ser revalidados periodicamente. O SEO é preservado, pois o HTML estático ainda é indexável, e as partes que precisam de atualização serão atualizadas de tempos em tempos em background.

No entanto, existem algumas dificuldades com essa estratégia. Por exemplo, em um e-commerce, se um cliente adiciona um produto de 10 reais ao carrinho e a página é revalidada, o valor pode mudar, causando confusão. Em um blog, um carrossel de posts pode mostrar um título que muda após a revalidação. Isso pode complicar o processo de debugging, pois as atualizações ocorrem em background. Embora seja possível identificar o que está acontecendo, é importante mencionar essas questões.

O primeiro acesso também pode ser mais lento, pois a página pode estar obsoleta enquanto é revalidada. O primeiro usuário a acessar enfrentará lentidão, pois o conteúdo não está em cache, resultando em um pequeno atraso. Além disso, as atualizações não são 100% em tempo real. Se configurarmos para atualizar a cada hora, por exemplo, é necessário esperar esse tempo. Se um gerente solicitar uma atualização imediata, será preciso aguardar o tempo de revalidação.

Nem toda infraestrutura suporta a revalidação. Existem provedores cuja infraestrutura não suporta o ISG, então é importante estar atento a isso. Essa estratégia é menos adequada para dados sensíveis e dinâmicos. Por exemplo, em um dashboard de vendas em tempo real, onde é crucial que a equipe de vendas monitore constantemente, a revalidação a cada cinco minutos ou uma hora não é suficiente. Nesse caso, sugerimos a estratégia de server-side rendering, pois a cada requisição, tudo será atualizado, assim como o client-side rendering.

Sobre o curso React: explorando estratégias de renderização do Next.js

O curso React: explorando estratégias de renderização do Next.js possui 283 minutos de vídeos, em um total de 40 atividades. Gostou? Conheça nossos outros cursos de React em Front-end, ou leia nossos artigos de Front-end.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Entendendo estratégias de renderização
• Implementação da página home com SSR
• Utilizando ISR
• Utilizando CSR - Client Side Rendering