Há algo acontecendo dentro do a parte dianteira comunidade recentemente. A renderização do lado do servidor está ganhando cada vez mais força graças ao React e seu recurso de hidratação do lado do servidor integrado. Mas não é a única solução para fornecer uma experiência rápida ao usuário com uma pontuação super rápida para o primeiro byte (TTFB): a pré-renderização também é uma estratégia muito boa. Qual é a diferença entre essas soluções e um aplicativo totalmente renderizado pelo cliente?

Aplicativo renderizado pelo cliente

Como estruturas como Angular, Ember.js e Backbone existem, os desenvolvedores de front-end tendem a renderizar tudo do lado do cliente. Graças ao Google e sua capacidade de “ler” JavaScript, ele funciona muito bem e é até mesmo SEO amigável.

Com uma solução de renderização do lado do cliente, você redireciona a solicitação para um único arquivo HTML e o servidor o entregará sem nenhum conteúdo (ou com uma tela de carregamento) até que você obtenha todo o JavaScript e deixe o navegador compilar tudo antes de renderizar o conteúdo.

Com uma conexão de Internet boa e confiável, é muito rápido e funciona bem. Mas pode ser muito melhor e não tem que ser difícil torná-lo assim. Isso é o que veremos nas seções a seguir.

Renderização do lado do servidor (SSR)

Uma solução SSR é algo que costumávamos fazer muito, muitos anos atrás, mas tendemos a esquecer em favor de uma solução de renderização do lado do cliente.

Com velho soluções de renderização do lado do servidor, você construiu uma página da web - com PHP, por exemplo - o servidor compilou tudo, incluiu os dados e entregou uma página HTML totalmente preenchida ao cliente. Foi rápido e eficaz.

Mas… cada vez que você navegava para outra rota, o servidor tinha que fazer o trabalho tudo de novo: pegue o arquivo PHP, compile-o e entregue o HTML, com todo o CSS e JS atrasando o carregamento da página para algumas centenas de ms ou mesmo todo segundos.

E se você pudesse carregar a primeira página com a solução SSR e, em seguida, usar uma estrutura para fazer o roteamento dinâmico com AJAX, buscando apenas os dados necessários?

É por isso que o SSR está ganhando cada vez mais força na comunidade, porque o React popularizou esse problema com uma solução fácil de usar: RenderToString método.

Este novo tipo de aplicativo da web é chamado de aplicativo universal ou um aplicativo isomórfico . Ainda há alguma controvérsia sobre os significados exatos desses termos e a relação entre eles, mas muitas pessoas os usam de forma intercambiável.

De qualquer forma, a vantagem dessa solução é poder desenvolver um app server-side e client-side com o mesmo código e entregar uma experiência realmente rápida ao usuário com dados customizados. A desvantagem é que você precisa executar um servidor.

O SSR é usado para buscar dados e preencher previamente uma página com conteúdo personalizado, aproveitando a conexão confiável do servidor com a Internet. Ou seja, a própria conexão de internet do servidor é melhor do que a de um usuário com Lie-fi ), para que seja capaz de pré-buscar e agregar dados antes de entregá-los ao usuário.

Com os dados pré-preenchidos, o uso de um aplicativo SSR também pode corrigir um problema que os aplicativos renderizados pelo cliente têm com o compartilhamento social e o sistema OpenGraph. Por exemplo, se você tiver apenas um index.html arquivo para entregar ao cliente, eles terão apenas um tipo de metadados - provavelmente os metadados da sua página inicial. Isso não será contextualizado quando você quiser compartilhar uma rota diferente, então nenhuma das suas rotas será mostrada em outros sites com seu conteúdo de usuário adequado (descrição e imagem de visualização) que os usuários gostariam de compartilhar com o mundo.

Pré-renderização

O servidor obrigatório para um aplicativo universal pode ser um impedimento para alguns e pode ser um exagero para um aplicativo pequeno. É por isso que a pré-renderização pode ser uma alternativa muito boa.

Eu descobri esta solução com Pré-ação e sua própria CLI que permite compilar todas as rotas pré-selecionadas para que você possa armazenar um arquivo HTML totalmente preenchido em um estático servidor. Isso permite que você entregue uma experiência super-rápida ao usuário, graças à função de hidratação Preact / React, sem a necessidade de Node.js.

O problema é que, como isso não é SSR, você não tem dados específicos do usuário para mostrar neste ponto - é apenas um arquivo estático (e um tanto genérico) enviado diretamente na primeira solicitação, como está. Portanto, se você tiver dados específicos do usuário, é aqui que você pode integrar um esqueleto lindamente projetado para mostrar ao usuário que seus dados estão chegando, para evitar alguma frustração da parte dele:

Existe outro problema: para que essa técnica funcione, você ainda precisa ter um proxy ou algo para redirecionar o usuário para o arquivo certo.

Por quê?

Com um aplicativo de página única, você precisa redirecionar todas as solicitações para o arquivo raiz e, em seguida, a estrutura redireciona o usuário com seu sistema de roteamento integrado. Portanto, o carregamento da primeira página é sempre o mesmo arquivo raiz.

Para que uma solução de pré-renderização funcione, você precisa informar ao seu proxy que algumas rotas precisam de arquivos específicos e nem sempre a raiz index.html Arquivo.

Por exemplo, digamos que você tenha quatro rotas (/, /about, /jobs e blog) e todas elas tenham layouts diferentes. Você precisa de quatro arquivos HTML diferentes para entregar o esqueleto ao usuário que, então, permitirá Reagir / Preact / etc. hidrate-o com dados. Portanto, se você redirecionar todas essas rotas para a raiz index.html arquivo, a página terá uma sensação desagradável e irregular durante o carregamento, por meio da qual o usuário verá o esqueleto da página errada até que termine de carregar e substitua o layout. Por exemplo, o usuário pode ver o esqueleto de uma página inicial com apenas uma coluna, quando pede uma página diferente com uma galeria semelhante ao Pinterest.

A solução é informar ao seu proxy que cada uma dessas quatro rotas precisa de um arquivo específico:

• https://my-website.com → Redirecionar para a raiz index.html Arquivo
• https://my-website.com/about → Redirecionar para o /about/index.html Arquivo
• https://my-website.com/jobs → Redirecionar para o /jobs/index.html Arquivo
• https://my-website.com/blog → Redirecionar para o /blog/index.html Arquivo

É por isso que essa solução pode ser útil para pequenos aplicativos - você pode ver como seria doloroso se tivesse algumas centenas de páginas.

Estritamente falando, não é obrigatório fazer dessa forma - você pode apenas usar um arquivo estático diretamente. Por exemplo, https://my-website.com/about/ funcionará sem qualquer redirecionamento porque procurará automaticamente por um index.html dentro de seu diretório. Mas você precisa desse proxy se tiver param urls— https://my-website.com/profile/guillaume precisará redirecionar a solicitação para /profile/index.html com layout próprio, porque profile/guillaume/index.html não existe e causará um erro 404.

---

Em suma, existem três visualizações básicas em jogo com as estratégias de renderização descritas acima: uma tela de carregamento, um esqueleto e a página inteira depois de finalmente renderizada.

Dependendo da estratégia, às vezes usamos todas essas três visualizações, e às vezes saltamos direto para uma página totalmente renderizada. Apenas em um caso de uso somos forçados a usar uma abordagem diferente:

Método	Aterragem (por exemplo, /)	Estático (por exemplo, /about)	Dinâmico fixo (por exemplo, /news)	Dinâmico parametrizado (por exemplo, /users/:user-id)
Renderizado pelo cliente	Carregando → Completo	Carregando → Completo	Carregando → Esqueleto → Completo	Carregando → Esqueleto → Completo
Pré-renderizado	Cheio	Cheio	Esqueleto → Completo	HTTP 404 (página não encontrada)
Pré-renderizado com proxy	Cheio	Cheio	Esqueleto → Completo	Esqueleto → Completo
SSR	Cheio	Cheio	Cheio	Cheio

A renderização apenas para cliente muitas vezes não é suficiente

Aplicativos renderizados pelo cliente são algo que devemos evitar agora, porque podemos fazer melhor para o usuário. E fazer melhor, neste caso, é tão fácil quanto a solução de pré-renderização. É definitivamente uma melhoria em relação à renderização apenas do cliente e mais fácil de implementar do que um aplicativo totalmente renderizado do lado do servidor.

Um aplicativo SSR / universal pode ser realmente poderoso se você tiver um aplicativo grande com muitas páginas diferentes. Ele permite que seu conteúdo seja focado e relevante ao falar com um rastreador social. Isso também é verdadeiro para robôs de mecanismo de pesquisa, que agora levam em consideração o desempenho do seu site ao classificá-lo.

Fique ligado em um tutorial de acompanhamento, no qual examinarei a transformação de um SPA em versões pré-renderizadas e SSR e compararei seu desempenho.

Relacionado: Visão geral dos geradores de sites estáticos populares

Compreender o básico

O que é renderização do lado do cliente?

A renderização do lado do cliente permite que os desenvolvedores tornem seus sites inteiramente renderizados no navegador com JavaScript. Em vez de ter uma página HTML diferente por rota, um site renderizado do lado do cliente cria cada rota dinamicamente, diretamente no navegador. Essa abordagem se espalhou quando os frameworks JS tornaram mais fácil de usar.

Qual é a renderização do lado do servidor?

A renderização do lado do servidor permite que os desenvolvedores preencham previamente uma página da web com dados personalizados do usuário diretamente no servidor. Geralmente é mais rápido fazer todas as solicitações em um servidor do que fazer viagens de ida e volta extras de navegador para servidor para eles. Isso é o que os desenvolvedores costumavam fazer antes da renderização do lado do cliente.

Qual é a diferença entre a renderização do lado do cliente e do lado do servidor?

A renderização do lado do cliente gerencia o roteamento dinamicamente sem atualizar a página sempre que um usuário solicita uma rota diferente. Mas a renderização do lado do servidor é capaz de exibir uma página totalmente preenchida no primeiro carregamento para qualquer rota do site, enquanto a renderização do lado do cliente exibe uma página em branco primeiro.

O que é pré-renderização?

A pré-renderização é uma troca entre a renderização do lado do cliente e do lado do servidor. Cada página pré-renderizada exibe um modelo de esqueleto enquanto os dados aguardam para serem reidratados com solicitações AJAX / XHR. Depois que a página é buscada, o roteamento interno é feito dinamicamente para tirar proveito de um site renderizado do lado do cliente.

O que é um aplicativo universal?

Um aplicativo universal envia ao navegador uma página preenchida com dados. Em seguida, o aplicativo carrega seu JavaScript e reidrata a página para obter um aplicativo totalmente renderizado do lado do cliente. Essa abordagem combina as vantagens das técnicas mais recentes disponíveis hoje.