Apps

Padrões de renderização para apps web

Maurício Bruno da Silva

• 9 min read
Padrões de renderização para apps web

Com o crescimento exponencial das aplicações web e a busca contínua por experiências de usuário cada vez mais dinâmicas e interativas, têm surgido diversas técnicas e estratégias de renderização para otimizar o desempenho e a eficiência das aplicações. Com isso, os desenvolvedores encontram desafios sobre qual escolher, em meio ao hype de novas ferramentas e tecnologias.

Por isso, neste artigo, exploraremos esses diferentes padrões de renderização, seus princípios fundamentais e os benefícios que cada um oferece. Analisaremos as nuances de cada abordagem e discutiremos cenários de uso adequados para cada uma delas, permitindo que você faça escolhas informadas na hora de desenvolver suas aplicações web.


O que são padrões de renderização?

Antes de começar a listar e explicar os diferentes padrões, é importante que você entenda bem do que estamos falando. Os rendering patterns, de forma similar aos design patterns, são formas comuns que as aplicações web são projetadas para serem construídas, carregadas e exibidas. Eles se referem a perguntas do tipo: “Como e onde o conteúdo deve ser renderizado? Ele deve ser renderizado no servidor da Web, na borda (edge) ou diretamente no cliente? Deve ser processado de uma só vez, parcialmente ou progressivamente?”

Escolher o padrão correto pode levar a carregamentos mais rápidos e até baixo custo de processamento. Tendo entendido isso, vamos agora listar os padrões comuns de renderização.


Renderização estática

A renderização estática envolve a geração de HTML no momento da construção ou compilação do aplicativo web e a entrega desse HTML renderizado aos clientes. Sendo assim, o conteúdo é pré-renderizado e o servidor da web simplesmente envia o HTML final para o navegador.

Esse modelo é eficiente em termos de desempenho, pois os navegadores podem carregar e exibir o conteúdo imediatamente. É um padrão simples, e podemos dizer que este foi o primeiro tipo de renderização da Web, mas não é por isso que está ultrapassado. Vejamos prós e contras desse modelo de renderização:

Prós

  • Carregamento rápido: O HTML pré-renderizado é enviado diretamente aos clientes, reduzindo o tempo de carregamento.
  • Facilmente "cacheável": Como o conteúdo é estático, ele pode ser armazenado em cache facilmente em servidores de borda (edge servers) ou CDNs (Content Delivery Networks).

Contras

  • Dificuldade de atualizar dados: Como o conteúdo é pré-renderizado, a atualização dos dados requer a reconstrução e o novo envio do HTML.

Quando utilizar?

A renderização estática é ideal para aplicações com conteúdo estático ou que não precisam de atualizações frequentes. Se você possui um site informativo, blog, portfólio, ou loja virtual pequena, a renderização estática pode ser a melhor escolha. Pois como listado acima, esse padrão é eficiente em termos de desempenho e pode ser facilmente armazenado em cache.

Ferramentas

Existem diversas ferramentas disponíveis que facilitam a criação e o desenvolvimento de sites estáticos. Essas ferramentas geralmente fornecem recursos avançados para compilar, gerenciar e implantar sites estáticos de forma eficiente. Algumas das ferramentas populares são: Jekyll, Hugo, Gatsby, 11ty, Gridsome e Pelican.

Renderização do lado do servidor (SSR)

A renderização do lado do servidor (SSR - Server-Side Rendering) envolve a geração do HTML no servidor web antes de enviá-lo ao cliente. Nesse padrão, o servidor é responsável por renderizar o conteúdo e enviar a página completa para o navegador.

Isso permite que as aplicações tenham dados dinâmicos, enquanto o cliente recebe uma página já pronta para ser exibida. Vejamos aqui um exemplo de SSR, usando o framework Rails:

<h1>Listing Books</h1>

<table>
  <thead>
    <tr>
      <th>Title</th>
      <th>Content</th>
      <th colspan="3"></th>
    </tr>
  </thead>

  <tbody>
    <% @books.each do |book| %>
      <tr>
        <td><%= book.title %></td>
        <td><%= book.content %></td>
        <td><%= link_to "Show", book %></td>
        <td><%= link_to "Edit", edit_book_path(book) %></td>
        <td><%= link_to "Destroy", book, data: { turbo_method: :delete, turbo_confirm: "Are you sure?" } %></td>
      </tr>
    <% end %>
  </tbody>
</table>

<br>

<%= link_to "New book", new_book_path %>

Esse é um layout de página, onde, num cenário típico, o servidor processa a cada requisição os livros e retorna uma lista com todos eles.

Prós

  • Dados dinâmicos no servidor: O servidor pode processar os dados e incluí-los no HTML antes de enviá-lo para o cliente, permitindo que os dados sejam atualizados a cada requisição.
  • Melhor SEO (Search Engine Optimization): Os motores de busca podem rastrear e indexar o conteúdo renderizado no lado do servidor com mais facilidade do que o conteúdo renderizado no lado do cliente.

Contras

  • Carregamento inicial mais lento: Como o servidor precisa processar o HTML antes de enviá-lo, o tempo de resposta inicial pode ser mais lento em comparação com a renderização do lado cliente.
  • Maior carga no servidor: O servidor precisa executar a renderização para cada requisição, o que pode exigir mais recursos do servidor em comparação com a renderização do lado cliente.

Quando utilizar?

A renderização do lado do servidor é uma boa opção para aplicações que requerem dados dinâmicos e têm uma necessidade significativa de SEO. É adequada para aplicações que possuem conteúdo atualizado frequentemente e precisam fornecer informações consistentes aos mecanismos de busca. Além disso, é uma boa escolha quando o tempo de carregamento inicial não é um fator crítico.

Ferramentas

Existem ferramentas para (provavelmente) todas as linguagens comumente usadas no desenvolvimento web, como Next.js, Remix, Nuxt.js, Angular Universal (todos baseados em Javascript), Django (Python), Rails (Ruby), Laravel (PHP), etc. Essas ferramentas facilitam a implementação da renderização do lado do servidor em suas aplicações.

Renderização do lado cliente (CSR)

A renderização do lado do cliente (CSR - Client-Side Rendering) envolve o envio de um arquivo HTML básico para o cliente, juntamente com o código JavaScript necessário para renderizar e atualizar o conteúdo no navegador.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <link rel="icon" type="image/svg+xml" href="/icon.svg" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>CSR</title>
  </head>
  <body>
    <div id="app"></div>
    <script type="module" src="/src/main.js"></script>
  </body>
</html>

Esse é o típico arquivo raiz em web apps renderizados do lado do cliente. Apenas uma div, que será o container para toda a aplicação que será construída via Javascript no navegador.

Nesse modelo, o cliente é responsável pela renderização e manipulação do DOM (Document Object Model). Tornou-se popular como um método de construir aplicações de página única (SPAs).

Prós

  • Experiência suave após o carregamento: Uma vez que o aplicativo é carregado, as interações com o usuário são rápidas e responsivas, pois a renderização ocorre no cliente.
  • Não há carga de trabalho no servidor: O servidor envia apenas os arquivos iniciais, e o processamento adicional é feito no cliente.

Contras

  • Carregamento inicial leva muito tempo: O cliente precisa baixar todo o código JavaScript necessário para renderizar o aplicativo antes que ele possa ser exibido, o que pode resultar em tempos de carregamento mais longos.
  • Dificuldades com SEO: Os motores de busca têm dificuldade em rastrear e indexar aplicativos renderizados no lado do cliente, o que pode afetar a descoberta e classificação nos resultados de pesquisa.

Quando utilizar?

  • Quando não há necessidade de otimizar para motores de busca (por exemplo, aplicativos internos ou painéis de administração).
  • Aplicações que exigem interações e atualizações frequentes de dados.
  • Aplicações que carregam dados sob demanda à medida que o usuário navega.

Ferramentas

Existem várias ferramentas disponíveis para facilitar o desenvolvimento de aplicações que utilizam CSR. Algumas das mais populares são React, Vue.js e Angular. Todas essas ferramentas fornecem uma maneira fácil de criar componentes e gerenciar o estado do aplicativo.

Renderização estática incremental

A renderização estática incremental é uma variação da renderização estática em que o conteúdo é gerado sob demanda, à medida que o usuário interage com o aplicativo. Em vez de pré-renderizar todas as páginas, apenas as partes relevantes são renderizadas conforme necessário.

Prós

  • Carregamento mais rápido: A renderização ocorre apenas quando necessário, evitando o carregamento desnecessário de conteúdo.
  • Melhor experiência do usuário: A resposta rápida às interações do usuário cria uma experiência mais fluida e responsiva.

Contras

  • Complexidade adicional: Implementar a renderização estática incremental pode exigir uma lógica mais sofisticada para determinar quais partes do conteúdo devem ser renderizadas em tempo real.

Quando utilizar?

A renderização estática incremental é ideal para aplicações que possuem um grande volume de conteúdo, mas onde apenas partes específicas são relevantes em determinados momentos. Isso é comumente visto em feeds de notícias, mídias sociais ou aplicativos de e-commerce, onde o conteúdo é atualizado continuamente e exibir todas as informações de uma só vez pode ser desnecessário e prejudicial ao desempenho.

Ferramentas

Geralmente é um método suportado por frameworks, como Next.js, Nuxt e SvelteKit. Essas ferramentas possuem recursos e técnicas que permitem a renderização seletiva de componentes ou seções, facilitando a implementação desse padrão.

Renderização do lado do servidor em tempo real

Essa técnica, conhecida como streaming server-side rendering, envolve a geração e entrega dinâmica de conteúdo renderizado diretamente no servidor para os clientes, permitindo que os usuários vejam o conteúdo sendo exibido antes que todo o processamento seja concluído.

Esse método é particularmente útil em sites ou aplicativos que exigem páginas com muitos elementos complexos, como gráficos ou tabelas, pois a renderização no lado do servidor pode lidar com essas tarefas de forma mais eficiente do que a renderização no lado do cliente.

Prós

  • Carregamento rápido do conteúdo inicial: O servidor envia imediatamente o conteúdo renderizado para os clientes, reduzindo o tempo de resposta percebido pelo usuário.
  • Experiência do usuário aprimorada: Os usuários podem interagir com o conteúdo enquanto o processamento adicional ocorre no servidor, resultando em uma experiência mais responsiva.

Contras

  • Maior carga no servidor: A renderização em tempo real requer recursos computacionais adicionais no servidor, especialmente em cenários com grande volume de usuários simultâneos.
  • Complexidade adicional na implementação: A renderização em tempo real requer uma infraestrutura adequada para lidar com a entrega dinâmica de conteúdo e a comunicação em tempo real com os clientes.

Quando utilizar?

A renderização do lado do servidor em tempo real é adequada para aplicações em que se faz necessário algum processamento no servidor, mas é desejável fornecer aos usuários uma prévia imediata do conteúdo, mesmo antes que todo o processamento seja concluído. Alguns exemplos podem ser: resultados de uma busca ou páginas de listagem.

Ferramentas

Existem várias tecnologias e frameworks que podem ser utilizados para implementar a renderização do lado do servidor em tempo real, como o Node.js com frameworks, como Express.js e Socket.io. Essas ferramentas fornecem recursos para facilitar a comunicação em tempo real entre o servidor e os clientes, permitindo uma experiência interativa e em tempo real.

Arquitetura em ilhas

É um método que visa reduzir o volume de JavaScript, enviado por meio de "ilhas" de interatividade que podem ser entregues independentemente em cima de um HTML estático.

As regiões estáticas da página consistem em HTML puro e não interativo, e as regiões dinâmicas são compostas por HTML e scripts permitindo a interatividade.

Fonte: https://jasonformat.com/islands-architecture/

Prós

  • Redução do volume de JavaScript: Ao separar as partes estáticas e dinâmicas da aplicação, é possível enviar apenas o necessário para as ilhas de interatividade, reduzindo o tamanho geral do arquivo JavaScript.
  • Melhor desempenho: Ao evitar a necessidade de carregar e executar todo o JavaScript em cada interação, a arquitetura em ilhas pode resultar em um desempenho mais rápido e responsivo.

Contras

  • Complexidade de implementação: A arquitetura em ilhas introduz uma camada adicional de complexidade na estrutura da aplicação, exigindo uma boa compreensão da separação entre as partes estáticas e dinâmicas, bem como do processo de hidratação dos componentes.
  • Escalabilidade: A arquitetura não é adequada para páginas altamente interativas, como aplicativos de mídia social, que provavelmente exigiriam milhares de ilhas.

Quando utilizar?

A arquitetura em ilhas é mais adequada para aplicações em que é possível identificar claramente partes da página que são estáticas e não interativas, bem como áreas que requerem interatividade dinâmica. É especialmente útil em cenários em que o tamanho do JavaScript precisa ser otimizado, como em aplicativos móveis ou em redes com largura de banda limitada.

Ferramentas

Alguns frameworks hoje são capazes de suportar a arquitetura em ilhas. Os mais notáveis entre eles são Marko e Astro.


Finalizando

Como pode ver, existem diversos padrões de renderização disponíveis para desenvolvedores de aplicações web. Cada um desses padrões tem seus próprios benefícios e considerações a serem levadas em conta ao decidir qual utilizar em um projeto, então faça bom uso desse conhecimento!

Até logo!

💡
As opiniões e comentários expressos neste artigo são de propriedade exclusiva de seu autor e não representam necessariamente o ponto de vista da Revelo.

A Revelo Content Network acolhe todas as raças, etnias, nacionalidades, credos, gêneros, orientações, pontos de vista e ideologias, desde que promovam diversidade, equidade, inclusão e crescimento na carreira dos profissionais de tecnologia.