Renderização do lado do servidor versus renderização do lado do cliente: um guia para desenvolvimento web

1. Juni 2024 Roberto Magalhães

Existem muitas maneiras diferentes de construir uma página da web. A carga deve ser colocada no servidor ou deixada para o cliente?

mostra que 53% das visitas a sites para celular são abandonados se as páginas demoram mais de três segundos para carregar, destacando o quão crítica é a renderização rápida para manter o interesse do usuário.

Para garantir o desempenho ideal, os desenvolvedores geralmente usam SSR, CSR ou uma abordagem híbrida conhecida como renderização universal/isomórfica (falaremos sobre isso um pouco mais tarde). Cada método tem seus prós e contras em relação à otimização de SEO, tempo de carregamento inicial, velocidade de interatividade, escalabilidade e capacidade de manutenção, entre outros fatores.

O SSR fornece uma visualização imediata da página da Web porque envia arquivos HTML totalmente preenchidos do servidor para o navegador, mas pode comprometer a interatividade da página até que todo o JavaScript seja carregado completamente. Por outro lado, o CSR oferece velocidades de interação mais rápidas depois de carregado, uma vez que o JavaScript é executado diretamente no navegador do cliente, mas sofre tempos de carregamento inicial mais lentos devido ao HTML vazio enviado enquanto aguarda a execução do JavaScript.

A incorporação de tecnologias modernas, como aplicativos web progressivos (PWAs), pode ajudar a otimizar as abordagens SSR e CSR, permitindo que os sites funcionem mais como aplicativos nativos, oferecendo funcionalidade offline e melhorando a experiência geral do usuário (UX), independentemente das condições da rede, garantindo assim a retenção de clientes mesmo em situações adversas.

Mas chega de usuários – vamos falar sobre renderização.

O que é RSS?

Basicamente, o SSR envolve a geração do html renderizado pelo servidor no servidor antes de ser enviado ao cliente – o navegador do usuário final. Esse processo de renderização no servidor acontece sempre que há uma solicitação de página feita por um usuário final. Em essência, quando alguém digita ou clica no URL do seu site em seu dispositivo, cada página da web solicitada já é uma página HTML totalmente renderizada, preparada em servidores de elite espalhados por diferentes regiões do mundo.

Ao contrário da percepção de que tal abordagem pode consumir muitos recursos, as estruturas de renderização do lado do servidor são projetadas para simplificar as ações executadas pelos clientes e, ao mesmo tempo, aproveitar os recursos de processamento dos servidores de forma eficiente. Isso minimiza as solicitações frequentes do servidor, que podem ser onerosas, especialmente em uma conexão lenta à Internet.

Uma vantagem fundamental derivada da RSS reside na sua primeira pintura significativa (FMP) timings – uma métrica de desempenho que se refere à rapidez com que o conteúdo de origem crítico aparece para os usuários ao carregar um arquivo html. Com as páginas pré-renderizadas sendo entregues imediatamente, os usuários são imediatamente absorvidos pela interface do usuário, mitigando assim as chances de rejeições repentinas devido a atrasos percebidos – o que é de suma importância para plataformas de alto tráfego que buscam métricas aumentadas em relação à retenção e envolvimento do cliente índices.

Mas espere, tem mais! Uma das maiores dores de cabeça para desenvolvedores web com CSR é que, como a página inicial é quase básica, bots de mecanismos de busca como os usados pelo Google às vezes não conseguem capturar o conteúdo da página web, o que, como você poderia esperar, é uma sentença de morte para SEO. Na verdade, esta é a razão pela qual o SSR, uma estrutura de código aberto, cresceu em popularidade – ele finalmente resolveu uma das maiores dores de cabeça dos SPAs.

À primeira vista, os servidores podem não parecer o componente mais glamoroso do seu ecossistema digital – uma força invisível zumbindo nos bastidores enquanto os desenvolvedores se deleitam sob os holofotes brincando com animações CSS ou experimentando aplicativos AR/VR.

No entanto, imagine ter uma apresentação de balé habilmente coreografada sem qualquer acompanhamento musical – a nuance e a profundidade serão acentuadamente diminuídas. Esse é precisamente o vazio que uma abordagem medíocre para entender os servidores criaria em seu modelo de negócios.

O SSR opera como um maestro de orquestra responsável por gerenciar sinfonias a pedido de visitantes, batutas em nossos sites. Esses pedaços de código ajudam a pintar as telas do navegador com soluções de renderização processadas no lado do servidor muito antes de chegarem aos dispositivos dos usuários. Pense em completar as peças do quebra-cabeça com antecedência para que os usuários finais gastem menos tempo esperando.

A solução SSR interpreta todas as solicitações feitas pelos navegadores em uma rede de protocolo HTTP e entrega páginas HTML finalizadas diretamente ao usuário. Isso elimina a necessidade de analisar a biblioteca JavaScript do lado do cliente e o trabalho complicado de processar o javascript do lado do servidor. Como não dependemos mais do javascript do lado do cliente, temos muito mais controle sobre nosso site ou aplicativo, mas isso obviamente tem um custo.

Atender algumas centenas de usuários não é problema para um servidor pequeno, mas e se você estiver atendendo milhões de usuários? Lembre-se de que alguns dos maiores sites recebem centenas de milhões de usuários por dia – de repente, todas essas solicitações estão pedindo aos nossos servidores “Ei, por favor, crie uma visualização”. Se apenas solicitar informações é suficiente para derrubar um site, ter que renderizar a página de milhões de usuários é uma tarefa difícil.

Nos bastidores: a mecânica da renderização do lado do cliente

A RSC surgiu como uma estratégia altamente eficaz para desenvolvedores web, principalmente devido à sua capacidade de fornecer experiências de usuário interativas e simplificadas.

O primeiro passo para compreender a RSE é reconhecer que todas as ações principais ocorrem dentro do seu navegador. Ao contrário dos processos do lado do servidor, onde os cálculos ocorrem em servidores poderosos antes de entregar HTML estático aos navegadores, o CSR aproveita uma estrutura JavaScript de código aberto para alimentar esses mecanismos: o V8 do Chrome ou o Spidermonkey do Firefox, por exemplo.

Sim, sites renderizados no lado do cliente têm um custo de carregamento inicial relativamente maior do que seus equivalentes renderizados no servidor porque precisam baixar mais ativos, incluindo um único arquivo JavaScript, em vez de apenas documentos de uma única página. Mas lembre-se de que isso acontece apenas uma vez; à medida que as informações são armazenadas em cache no hardware do usuário, a navegação subsequente se torna mais suave e rápida, proporcionando uma experiência de navegação perfeita — exatamente o que o usuário impaciente de hoje exige!

Tradicionalmente, com o CSR, a busca de dados ocorre por meio de APIs após downloads iniciais de JavaScript, permitindo o carregamento assíncrono de dados e a atualização de partes de forma independente, em vez de recarregar páginas inteiras, uma melhoria significativa em relação à maneira antiga de fazer as coisas. E para ajudar a melhorar o compartilhamento de conteúdo web na web, os desenvolvedores também podem implementar Protocolo Open Graph do Facebook para uma melhor representação nas plataformas de mídia social (ei, Django e WordPress, estou olhando para você).

Como mencionamos antes, pode-se argumentar que os problemas de SEO eram um ponto fraco para os CSRs porque os mecanismos de pesquisa tinham dificuldade para interpretar o código JavaScript de maneira eficaz. No entanto, com os avanços e a integração de componentes de UI reutilizáveis, isso melhorou um pouco. O Googlebot, por exemplo, agora é capaz de “ler” tipos dependentes de JavaScript. Não é uma solução perfeita por nenhuma métrica – quanto mais criativo você for com seu JavaScript, maior será a probabilidade de condenar seu site ao inferno do SEO. Mas está muito melhor do que há alguns anos.

Dada a sua forte dependência de recursos locais (ou seja, navegadores dos usuários), os recursos avançados de interatividade tornam os CSRs ideais para aplicações web que exigem interações constantes, como atualizações ou animações em tempo real, cenários típicos, incluindo SPAs, sites de análise pós-primeira renderização, e -plataformas de comércio com muitas opções de detalhes de produtos, etc.

Prós e contras da renderização no lado do servidor

Quando se trata de uma empresa de desenvolvimento web, escolher entre SSR e CSR muitas vezes pode parecer como navegar por um labirinto. No entanto, tentaremos nos aprofundar nas complexidades de ambas as abordagens e ver se podemos ajudá-lo a descobrir qual delas se adapta melhor a você.

Acessibilidade aos motores de busca – uma vantagem sobre a RSE

Uma vantagem inegável que o SSR tem sobre seu equivalente é sua excelente acessibilidade para rastreadores de mecanismos de pesquisa. Isso significa que o Googlebot ou Bingbot pode indexar rapidamente o seu conteúdo, à medida que os mecanismos de pesquisa recebem uma página totalmente renderizada do servidor. Portanto, se você deseja um excelente desempenho de SEO, o SSR pode marcar essa caixa de forma convincente.

Experiência de usuário protegida – Catering First Contentful Paint

Os usuários hoje são notoriamente impacientes quando se trata de sites lentos; eles querem suas informações ali mesmo. Com o SSR em ação, o usuário não ficará olhando para uma tela em branco até que todos os scripts sejam carregados – uma armadilha comum no CSR – à medida que os servidores enviam o HTML pronto para exibição, alcançando instantaneamente o que é conhecido como “a primeira pintura com conteúdo” mais rapidamente.

Uma opção econômica para usuários

Pense nos usuários finais com dispositivos de baixo custo ou naqueles que sofrem com uma conectividade de Internet inferior. Ao separar as operações pesadas em componentes prontamente renderizáveis no lado do servidor, em vez de terceirizá-las totalmente nas máquinas dos clientes, como faz o CSR, garantimos uma experiência justa do usuário, independentemente das capacidades do dispositivo, sem quebrar seus bancos de dados!

O outro lado…

Por mais virtuosas que pareçam estas vantagens, nenhuma tecnologia é perfeita – e a SSR também não o é – portanto, ela aponta algumas desvantagens dignas de consideração juntamente com os seus pontos positivos:

Preocupações com a carga do servidor – uma possível pressão sobre o desempenho?

Em termos de arquitetura operacional – especificamente em termos de carga – os SSRs impõem pressão extra sobre os servidores e podem ter um impacto profundo nas velocidades e custos de carregamento. Os serviços baseados em nuvem podem ser dimensionados dinamicamente para lidar com o problema, mas isso, por sua vez, significa que você precisa ter muito cuidado com sua estrutura de custos.

Lidando com atualizações frequentes

Sites que precisam de atualizações dinâmicas contínuas podem enfrentar desafios em um ambiente SSR porque cada nova interação exige um novo HTML obtido do servidor. Recarregar páginas dificultará a interatividade em tempo real, algo que é crucial em sites como portais de leilões ao vivo ou aplicativos de jogos de esportes de fantasia.

O bom, o ruim e o feio: avaliando a renderização do lado do cliente

Para começar, vamos revelar alguns aspectos que tornam a renderização do lado do cliente tão atraente.

Interação Dinâmica

Um aspecto fundamental da RSE é a sua capacidade de interação mais dinâmica do usuário em comparação com aplicações renderizadas em servidor. Como as ações baseadas em eventos são processadas mais rapidamente no navegador do usuário do que em viagens de ida e volta ao servidor, os visitantes desfrutam de uma experiência de navegação incrivelmente contínua e fluida.

Carga reduzida do servidor

Com as tarefas computacionais descarregadas nos dispositivos dos clientes, em vez de ficarem apenas nos servidores, isso resulta em menor carga do servidor, o que poderia diminuir potencialmente os custos operacionais associados à manutenção de servidores de alto desempenho.

Considerações sobre escalabilidade

Devido à dependência reduzida de servidores para renderização de páginas devido à mudança de cálculos diretamente nos navegadores dos clientes, as complexidades de escalabilidade, especialmente durante períodos de pico de visitação, podem ser atenuadas ao longo do tempo, proporcionando assim oportunidades de economia de custos e melhorando a robustez do site.

O outro lado…

Complicações de SEO

Nem todos os rastreadores de mecanismos de pesquisa estão acostumados, ou suficientemente adaptados, a indexar sites implementados em torno de estruturas JavaScript complexas amplamente utilizadas em arquiteturas renderizadas no lado do cliente; isso pode comprometer a visibilidade da página web, levando a baixas taxas de descoberta orgânica.

Advertências de desempenho

Embora as conversas sobre velocidades de carregamento muitas vezes se concentrem na rapidez com que os elementos estáticos aparecem (que de fato tende a ser mais rápido devido às respostas iniciais leves do servidor), quando levamos em consideração outros fatores, como o tempo total necessário antes da renderização de uma página da web totalmente habilitada para interatividade – a imagem não é tão bonita. Graças a uma maior dependência das condições da rede e dos recursos de computação do usuário, as atualizações de conteúdo pós-carregamento inicial podem, na verdade, se tornar um ponto sensível para os usuários.

Segurança e Vulnerabilidade

Infelizmente, fazer com que o cliente gerencie tantas coisas pode ser um risco à segurança cibernética. Para ser justo, esse não é realmente um problema com o qual você deva se preocupar se seus desenvolvedores tiverem um bom conhecimento das práticas de segurança cibernética. Mas tenha em mente que erros acontecem e que às vezes a biblioteca que usamos em nossos projetos pode compartilhar mais dados do que pretendíamos. Nestes casos, a informação está aí para qualquer um ver.

O que é isso sobre JavaScript isomórfico?

SSR com Javascript Isomórfico ou renderização universal é uma técnica que combina o melhor de dois mundos: a velocidade da SSR e a interatividade da RSE.

Com a renderização universal, a página é renderizada primeiro no servidor e, em seguida, um pequeno arquivo JavaScript é enviado ao navegador para finalizar a renderização da página. Isso proporciona a velocidade do SSR, porque o navegador não precisa fazer nenhum trabalho para renderizar a página inicial, e a interatividade do CSR, porque o navegador pode atualizar a página sem precisar recarregar a página inteira.

Benefícios da renderização universal:

Tempos de carregamento inicial mais rápidos: A página é renderizada no servidor antes de ser enviada ao navegador, para que possa carregar instantaneamente.
Melhor SEO: As páginas SSR são indexadas mais facilmente pelos mecanismos de pesquisa, o que pode ajudar a melhorar a classificação de pesquisa do seu site.
Mais interatividade: O navegador pode atualizar a página sem precisar recarregar a página inteira, o que pode melhorar a experiência do usuário.
Mais flexibilidade: Você pode usar qualquer estrutura JavaScript para renderizar a página, tanto no servidor quanto no navegador.

Desvantagens da renderização universal:

Mais complexo de implementar: A renderização universal é mais complexa de implementar do que SSR ou CSR.
Pode ser mais lento para carregamentos de página subsequentes: Depois que a página inicial for carregada, o carregamento da página subsequente será mais lento do que com o CSR, porque o navegador terá que baixar o arquivo JavaScript do servidor.

No geral, a renderização universal é uma boa escolha para sites que precisam ser rápidos e compatíveis com SEO. Se você estiver disposto a fazer um esforço extra para implementá-la, a renderização universal pode oferecer o melhor dos dois mundos.

Aqui estão alguns exemplos de sites que usam renderização universal:

Pesquisa do Google: A Pesquisa Google usa renderização universal para garantir que a página de resultados da pesquisa carregue rapidamente para usuários com conexões lentas à Internet.
Twitter: O Twitter usa renderização universal para garantir que os tweets sejam carregados instantaneamente para os usuários.
Médio: O Medium usa renderização universal para fornecer uma experiência de leitura suave e interativa.

Se você está pensando em usar renderização universal em seu site, há algumas coisas que você precisa ter em mente:

Certifique-se de que seu servidor seja rápido o suficiente: O servidor precisa ser capaz de renderizar a página rapidamente para que ela possa carregar instantaneamente para os usuários.
Use uma boa estrutura JavaScript: A estrutura JavaScript que você usa deve ser bem otimizada para desempenho.
Teste seu site completamente: Certifique-se de que seu site funcione corretamente com renderização universal antes de implantá-lo em produção.

Exemplos de estruturas para renderização universal

Embora qualquer estrutura possa ser potencialmente usada por um desenvolvedor para criar uma página de renderização universal, temos visto um aumento em estruturas extremamente poderosas e amigáveis que estão mudando o cenário do desenvolvimento web.

React.JS: um pioneiro em arquitetura baseada em componentes

React.js remodelou o cenário do desenvolvimento web moderno com sua filosofia centrada em componentes. Além disso, a renderização do lado do servidor no React melhora o desempenho e o SEO dos aplicativos. Projetado para construir interfaces de usuário ricas, ele apresenta um DOM virtual que garante atualizações e renderização eficientes.

O foco desta estrutura em componentes reutilizáveis agiliza o código e acelera o desenvolvimento. A ampla adoção do React por gigantes da tecnologia e startups destaca sua importância nas discussões sobre tecnologia.

Next.JS: Robustez aliada à versatilidade

Next.js é o que uma estrutura deve se esforçar para ser: é flexível, bem documentado e oferece uma infinidade de abordagens para implantar nossas páginas da web.

Next.js se destaca devido ao seu recurso de divisão automática de código – resultando em carregamentos de página mais rápidos – o que impacta diretamente e positivamente as taxas de engajamento do usuário – uma métrica crítica frequentemente discutida durante reuniões de diretoria!

Svelte: abordagem preparada para o futuro

Svelte adota uma abordagem pronta para o futuro para a construção de aplicativos da web responsivos. Ele compila seu código em pequenos módulos JavaScript autônomos em tempo de construção, em vez de interpretá-lo em tempo de execução, fornecendo vantagens significativas de velocidade, cruciais para se manter competitivo no cenário atual de mercado acelerado.

Fresco: resposta de Deno

Para aqueles que estão prontos para deixar o NodeJS para trás, Deno é um poderoso runtime criado pelo mesmo desenvolvedor do NodeJS, e Fresh é sua resposta aos modernos frameworks web JavaScript, com uma abordagem minimalista e construído para Typescript. Fresh pode ser um novato, mas tem potencial para crescer e conquistar o mundo.

Eu adoraria dar uma declaração definitiva sobre qual abordagem você deve adotar. Mas a realidade dos serviços de desenvolvimento JavaScript é que não existe uma resposta única para todos. Cada projeto representa seu próprio conjunto exclusivo de requisitos. Portanto, nosso conselho mais valioso é deliberar cuidadosamente, informado pelo que discutimos até agora. Qual solução se alinha melhor com você, seu projeto e sua equipe? Não importa sua escolha, tenha certeza de que uma infinidade de ferramentas e soluções estão disponíveis para reforçar sua jornada de desenvolvimento.

Se você gostou disso, não deixe de conferir nossos outros artigos sobre desenvolvimento web.