Skip to main content

SSG, CSR e SSR

  • SSG, CSR e SSR

Verifique as Funções de Carregamento de Dados​

Next.js usa funções específicas para carregar dados para suas páginas, o que pode indicar o tipo de renderização utilizado:

  • SSR (Server-Side Rendering): Se a página exporta uma função getServerSideProps, ela está usando SSR. Esta função é chamada em cada requisição ao servidor para buscar dados necessários antes de renderizar a página.
info

Na primeira carga, os componentes do cliente são renderizados uma vez pelo servidor para gerar HTML estático. Quando o cliente os recebe, o HTML estático é hidratado com uma renderização da árvore de componentes. Nas navegações subsequentes, o Next funciona como um aplicativo de página única, os componentes do cliente serão renderizados apenas pelo navegador


export async function getServerSideProps(context) {
  // Carregamento de dados para SSR
  return {
    props: {}, // será passado ao componente da página
  }
}

  • alt text

  • SSG (Static Site Generation): Se a página utiliza getStaticProps (e opcionalmente getStaticPaths para páginas dinâmicas), ela está usando SSG. getStaticProps é executado no momento da construção (build time) para gerar uma versão estática da página.


    export async function getStaticProps(context) {
      // Carregamento de dados para SSG
      return {
        props: {}, // será passado ao componente da página
        revalidate: // tempo em segundos
      }
    }
    danger

    Cuidado ao usar revalidate, em modo debug / dev não conseguimos testar. Precisamos rodar npm run build e depois npm run start

  • CSR (Client-Side Rendering): Se uma página ou componente não usa getServerSideProps ou getStaticProps para carregar dados, e em vez disso, carrega dados no lado do cliente (por exemplo, usando o hook useEffect para buscar dados de uma API), ela está utilizando CSR.


    useEffect(() => {
      // Carregamento de dados no lado do cliente
    }, []);

    • alt text

Verifique a Rota ou a Página​

A abordagem de renderização também pode ser determinada pela forma como a rota ou página é estruturada no Next.js:

  • Páginas em pages/: O diretório pages do Next.js é especial. O nome do arquivo e sua estrutura de diretórios definem automaticamente as rotas da sua aplicação. A presença de getStaticProps ou getServerSideProps em um arquivo dentro de pages/ indica se a página é SSG ou SSR, respectivamente.
  • Componentes Dinâmicos: O uso de next/dynamic para importar componentes pode indicar uma estratégia de CSR, especialmente se usado para otimizar o carregamento de componentes com base em interações do usuário ou outras condições do lado do cliente.

Analise as Importações e o Uso de Hooks​

  • Uso de useRouter ou useEffect: O uso do hook useRouter do Next.js ou do useEffect do React para carregar dados ou manipular rotas pode ser um indicador de que a página ou componente depende de lógica do lado do cliente, característica do CSR.

Processo de renderização​

No contexto do Next.js, uma estrutura de desenvolvimento web baseada em React, o processo de renderização pode ocorrer tanto no lado do servidor (server-side) quanto no lado do cliente (client-side). Para entender como o Next.js gerencia esses processos, é importante primeiro definir o que é considerado "servidor" e "cliente" em uma aplicação web.

  • Servidor: Em uma aplicação web, o servidor é o ambiente de computação que hospeda a aplicação. Ele é responsável por processar solicitações HTTP, executar lógica de back-end (como interações com bancos de dados), e servir arquivos e recursos necessários para que a aplicação funcione. No contexto do Next.js, o servidor também pode renderizar componentes React e servir o resultado como HTML para o navegador, processo conhecido como renderização no lado do servidor (SSR - Server-Side Rendering).
  • Cliente: O cliente é tipicamente o navegador web do usuário (embora possa ser qualquer agente de usuário que consome a aplicação web, como um aplicativo móvel ou uma ferramenta de automação). O cliente solicita páginas ao servidor, recebe o HTML, CSS, e JavaScript, e renderiza a página na tela do usuário. Além disso, o cliente pode executar JavaScript para manipular a DOM (Document Object Model) e interagir com a aplicação dinamicamente, processo conhecido como renderização no lado do cliente (CSR - Client-Side Rendering).

Processo de Renderização no Next.js​

O Next.js é projetado para oferecer o melhor dos dois mundos (SSR e CSR) através de diferentes funções e métodos de renderização:

  1. Renderização no Lado do Servidor (SSR): Quando uma página é solicitada, o Next.js pode pré-renderizar essa página no servidor, gerando o HTML correspondente aos componentes React. Esse HTML é enviado ao navegador do cliente, onde é exibido imediatamente, proporcionando um carregamento rápido da página e uma boa otimização para motores de busca. Isso é especialmente útil para páginas que necessitam de dados dinâmicos, como a renderização de posts de um blog que são buscados de um banco de dados.
  2. Renderização Estática (Static Generation): O Next.js também suporta a geração estática de páginas (SSG - Static Site Generation), onde as páginas são pré-renderizadas em tempo de build e servidas como arquivos estáticos. Isso é ideal para páginas que não mudam frequentemente e podem ser servidas rapidamente a partir de um CDN.
  3. Renderização no Lado do Cliente (CSR): Após a página inicial ser carregada pelo SSR ou SSG, o Next.js pode utilizar o CSR para navegações subsequentes dentro da aplicação. Isso é feito através de um aplicativo de página única (SPA - Single Page Application) que roda no navegador. O Next.js pré-carrega os arquivos JavaScript necessários para essas páginas, permitindo transições de página suaves e rápidas sem necessidade de voltar ao servidor.

getServerSideProps e getStaticProps​

Para controlar onde a renderização ocorre, o Next.js oferece funções especiais como getServerSideProps (para SSR) e getStaticProps (para SSG). Essas funções permitem especificar quais dados precisam ser buscados para renderizar uma página, e o Next.js cuida de executá-las no ambiente correto (servidor para SSR e em tempo de build para SSG).

Em resumo, o Next.js abstrai a complexidade de escolher entre renderização no lado do servidor e no lado do cliente, permitindo que desenvolvedores construam aplicações web otimizadas tanto para performance quanto para SEO, sem ter que se preocupar detalhadamente com a implementação desses processos.

Documentação do dynamic no Next.js​

O Next.js oferece a função dynamic() para carregar componentes de forma dinâmica e assíncrona. Isso significa que o Next.js carrega o componente apenas quando necessário, o que pode melhorar o desempenho, especialmente para componentes pesados ou dependentes de recursos do navegador.

O que é o dynamic?​

A função dynamic() permite que você carregue componentes de forma assíncrona no lado do cliente, ao invés de incluí-los no bundle inicial, economizando recursos de carregamento.

Sintaxe Básica:​

import dynamic from 'next/dynamic';

const DynamicComponent = dynamic(() => import('./DynamicComponent'));

Usando dynamic com { ssr: false }​

O Next.js realiza renderização no servidor (SSR - Server-Side Rendering) por padrão, o que pode causar erros se o componente que você está carregando interagir com APIs do navegador, como o document ou o window (por exemplo, bibliotecas de animação como Lottie). Para evitar erros no servidor, como document is not defined, você pode desabilitar o SSR para componentes específicos usando o parâmetro { ssr: false }.

Exemplo:​

import dynamic from 'next/dynamic';

// Carregar o componente Lottie somente no lado do cliente
const Lottie = dynamic(() => import('react-lottie'), { ssr: false });

Como Funciona:​

  • Por padrão, o Next.js tenta renderizar o componente no servidor durante o processo de pré-renderização.
  • Se o componente depende de APIs do navegador (como o document ou window), ele pode gerar erros durante a renderização no servidor, porque essas APIs não estão disponíveis no ambiente do servidor.
  • Usando { ssr: false }, você desativa a renderização no servidor, forçando o componente a ser carregado somente no lado do cliente, onde essas APIs estão disponíveis.

Exemplo Prático:​

Imagine que você tem um componente de animação que depende do document para ser renderizado corretamente. Se você tentar renderizá-lo no servidor, ocorrerá o erro document is not defined. Para corrigir isso:

import { useState, useEffect } from 'react';
import dynamic from 'next/dynamic';

// Carregar Lottie de forma dinâmica, mas desabilitar SSR
const Lottie = dynamic(() => import('react-lottie'), { ssr: false });

export default function MyComponent() {
  const [copied, setCopied] = useState(false);
  const options = {
    loop: copied,
    autoplay: copied,
    animationData: myAnimationData, // Dados da animação
    rendererSettings: {
      preserveAspectRatio: 'xMidYMid slice',
    },
  };

  return (
    <div>
      <h1>Minha Animação Lottie</h1>
      <Lottie options={options} height={400} width={400} />
    </div>
  );
}

Resumo:​

  • dynamic() é utilizado para carregar componentes dinamicamente.
  • { ssr: false } desativa a renderização no servidor, garantindo que o componente só seja carregado no lado do cliente.
  • Isso é útil para evitar erros de execução no servidor quando o componente interage com o DOM ou outras APIs do navegador, como no caso do Lottie que precisa do document.

Ao usar dynamic(() => import('componente'), { ssr: false }), você pode evitar problemas como document is not defined e melhorar a performance, carregando componentes apenas quando necessário, no lado do cliente.