Renderização do lado do servidor com React

Publicados: 2021-05-27

Um pouco sobre o React

React é uma biblioteca JavaScript de front-end de código aberto, que é criada e mantida pela Comunidade de Desenvolvedores do Facebook. Ele é usado para construir interfaces de usuário ou componentes de interface do usuário.

No entanto, esta definição pode não ser completamente compreensível para os novatos. Nós temos o post perfeito no blog que o guia através de uma breve explicação do React, até uma descrição técnica muito detalhada dele, que você pode encontrar aqui.

A jornada de uma página da Web | Do servidor para o seu navegador

Para entender o que é a renderização do lado do servidor, primeiro é importante obter uma visão geral de como uma página da Web aparece na tela, o que é elucidado pelo diagrama abaixo:

ssr-with-react-webpage-server-to-browser
  1. Sempre que você digita a URL de um site ou clica em um link para o site, seu navegador envia uma solicitação de alguns arquivos para o servidor apropriado, identificado pela URL.
  2. O servidor envia alguns arquivos, como os arquivos HTML e JavaScript, entre outros, para o seu navegador.
  3. Seu navegador baixa e 'renderiza' ou processa esses arquivos e você pode ver e interagir com a página da web que solicitou.

Esta é uma simplificação muito grande da jornada de uma página da Web, mas é um prefácio bom o suficiente para explicar as diferentes subetapas e diferentes maneiras (incluindo a renderização do lado do servidor) para realizar essa tarefa.

Jornada de uma página da Web de renderização do lado do cliente 'normal'

Aprofundando no processo mencionado na seção anterior, temos uma técnica conhecida como Client Side Rendering ou CSR, que está em uso há muito tempo, para exibir um site nas telas do usuário. Isso é explicado no diagrama a seguir:

ssr-with-react-csr-webpage-rendering
  1. Ao digitar a URL de um site ou clicar em um link para o site, seu navegador envia uma solicitação de alguns arquivos ao servidor apropriado, identificado pela URL.
  2. O servidor envia o arquivo HTML que contém as referências a outros ativos, como arquivos de imagem, arquivos CSS e arquivos JavaScript.
  3. O navegador envia uma solicitação novamente ao servidor e baixa todos os arquivos, incluindo os arquivos CSS e JavaScript referenciados no arquivo HTML.
    1. Isso pode ser um fator que contribui para aumentar o tempo de carregamento de um site se os usuários estiverem em uma conexão ruim e o arquivo JavaScript for grande.
  4. Depois que esses arquivos são baixados pelo navegador, o navegador executa o framework ou biblioteca (por exemplo, React) e analisa os arquivos JavaScript, que são responsáveis ​​por tornar a página da web interativa.
    1. De uma perspectiva de otimização de velocidade, esse ponto depende da máquina cliente e, se o cliente for um hardware de baixa potência, isso pode levar um tempo significativo.
    2. O usuário ainda vê a tela de carregamento quando essas etapas estão em andamento
  5. A página da web é finalmente carregada completamente e o usuário pode ver e interagir com a página da web.

Como fica claro com as etapas mencionadas acima, do ponto de vista do usuário, ele só pode ver e interagir com o site na etapa final, após todos os arquivos necessários terem sido baixados e renderizados pela máquina cliente.

Isso pode levar muito tempo, pois depende do desempenho da máquina cliente na execução da estrutura e na análise dos arquivos JavaScript.

A jornada da página da Web de renderização do lado do servidor

Explicando em uma única linha, Server Side Rendering ou SSR é o processo de pegar um site de estrutura JavaScript do lado do cliente e renderizá-lo em HTML e CSS estático no servidor em vez do cliente, como era o caso do CSR.

Abaixo está uma representação pictórica da jornada que uma página da web leva com o Server Side Rendering, com React:

ssr-with-react-ssr-webpage-rendering-with-react
  1. Ao digitar a URL de um site ou clicar em um link para o site, seu navegador envia uma solicitação de alguns arquivos ao servidor apropriado, identificado pela URL.
  2. Servidor, em vez de apenas enviar arquivos HTML como no CSR, renderiza o aplicativo em string usando a função renderToString importada do react-dom/server
    1. Isso é então injetado no arquivo index.html e enviado ao navegador.
    2. Este é o ponto crucial do SSR, funcionalmente falando, pois é onde o servidor renderiza a página, e não a máquina cliente.
  3. O navegador renderiza esse arquivo HTML, resultando no preenchimento da visualização no navegador.
    1. No entanto, isso ainda não é interativo, mas o usuário pode ver a visualização final da página da web.
  4. O navegador envia uma solicitação novamente ao servidor e baixa todos os arquivos referenciados no arquivo HTML, incluindo arquivos JavaScript.
  5. Depois que todos os scripts são baixados, o componente React é novamente renderizado no cliente. No entanto, desta vez, ele hidrata a visão existente em vez de sobrescrevê-la.
    1. 'Hidratar' uma visão significa que ela anexa quaisquer manipuladores de eventos aos elementos renderizados do DOM (Document Object Model), mas mantém os elementos renderizados do DOM intactos. Dessa forma, o estado dos elementos DOM é preservado e não ocorre a redefinição da visão.
  6. A página da web está finalmente completamente carregada e o usuário agora pode interagir com a página que ele conseguiu ver na etapa 3.

Assim, uma das maiores mudanças visuais da perspectiva do usuário é que a página da web se torna 'visível' bem rápido, já que renderizar HTML não é tão intensivo em recursos, falando da perspectiva do navegador.

Isso não torna o carregamento da página inerentemente mais rápido do que um aplicativo não SSR, mas fornece aos usuários a visualização da página da Web à medida que os arquivos JavaScript são baixados e analisados ​​em segundo plano, após o que a página da Web se torna interativa. Isso significa que o TTI, ou seja, o tempo de interação (é o tempo que a página da Web leva para ser completamente interativa a partir do momento em que o usuário solicita a página da Web) é um pouco mais do que o tempo necessário para a página da Web ficar visível no navegador.

Assim, em um cenário SSR, para um primeiro tempo de renderização mais rápido, seu HTML e CSS precisam ser significativos para os usuários, e JavaScript pode ser o aprimoramento para HTML e CSS, já que seu carregamento é adiado.

Um equívoco comum sobre o funcionamento do SSR com React é que após cada alteração, como um usuário solicitando novos dados, o servidor novamente completa todas as etapas e envia o arquivo HTML com a nova interface do usuário para o navegador, mas esse não é o caso . Apenas uma atualização parcial da página é feita. Embora a renderização seja feita pelo servidor, a saída finalizada é inserida no DOM 'hidratando-o', conforme explicado anteriormente.

ssr-com-reagir-prós-contras-de-ssr

Renderização do lado do servidor | Quando e quando não usar

  • Se você precisa de um SEO forte, opte pelo SSR, pois é mais fácil para os mecanismos de pesquisa rastrearem.
  • Para sites focados em conteúdo e não focados em interação, como blogs, sites de notícias, sites estáticos e sites com texto pesado, o SSR pode ser uma benção, pois carregará o cerne do seu site, ou seja, o conteúdo rapidamente.
  • Leva tempo e esforço do lado do servidor para renderizar e gerar os arquivos a serem enviados para o navegador. Portanto, se você estiver com baixo orçamento de servidor e operações, é melhor não implementar o SSR, pois haverá muitas solicitações enviadas ao seu servidor.
    • No entanto, com provedores como Firebase, podemos gerar conteúdo dinamicamente com funções de nuvem e o servidor pode armazená-lo no cache da CDN
    • O que isso faria é que na próxima vez que o usuário solicitasse, a geração dos arquivos não fosse feita novamente pelo servidor. Em vez disso, ele é servido apenas a partir de uma borda CDN local, melhorando os tempos de carregamento do ponto de vista do usuário e, ao mesmo tempo, usando menos recursos do servidor.

Como o React é bom para SSR?

React é uma excelente escolha para implementar SSR porque incorpora o conceito de um DOM virtual (Document Object Model).

Isso permite que os desenvolvedores criem uma versão virtual do aplicativo React e a tenham no próprio servidor.

Isso torna mais fácil renderizá-lo em um HTML usando a função renderToString conforme discutido anteriormente, envie-o para o navegador para que o navegador possa renderizá-lo rapidamente e criar uma versão virtual na máquina cliente.

Portanto, considerando o fato de que esta versão virtual corresponde ao HTML que enviamos do servidor, o React não a renderizará novamente, diminuindo assim o Time To Interactive (TTI), resultando em uma página web de carregamento 'mais rápido'.

SSR, o dia todo, todos os dias!

Gostaríamos que houvesse uma solução de tamanho único para tudo, mas isso está longe de ser o caso, especialmente com as novas tecnologias. Embora o SSR tenha muitos benefícios, existem alguns casos, conforme discutido anteriormente, para os quais o SSR pode não ser uma boa escolha; sites altamente interativos estão na vanguarda disso.

É aí que entram os Creole Studios. Temos uma variedade de especialistas em tecnologia, sempre a par de quase todas as novas tecnologias que surgem no techverse. Vamos entender suas necessidades de negócios e fornecer soluções personalizadas, seja um aplicativo SSR ou CSR, e fique tranquilo, você não terá que se preocupar com nada enquanto fazemos o trabalho pesado para você. Entre em contato conosco e tire suas ideias da cabeça para um app!