Introdução:

Hoje, estamos entusiasmados em apresentar um recurso inovador que irá redefinir o desempenho do seu site. Imagine desbloquear as baixas latências da borda, eliminando a dependência de APIs de terceiros - bem-vindo à era do Renderização Assíncrona.

Compreendendo o Processo de Renderização Atual do React:

No mundo das aplicações React, a abordagem convencional para a Renderização do Lado do Servidor (SSR, na sigla em inglês) é o modelo fetch-then-render, onde a renderização é dividida em dois passos, um para busca de dados e outro para geração de html. Para ilustrar, vamos imaginar um cenário típico na página inicial de um site de comércio eletrônico. Esta página é composta por duas prateleiras, cada uma exibindo uma coleção de produtos. Para preencher essas prateleiras, a aplicação precisa fazer duas requisições à API de comércio eletrônico.

Aqui está onde surge o desafio: o React, seguindo o paradigma fetch-then-render, insiste que ambas as requisições devem ser concluídas antes que qualquer renderização do lado do servidor (SSR) possa ocorrer. Imagine isso - um usuário chega à página inicial, ansioso para explorar os últimos produtos, e duas requisições à API são iniciadas pelo servidor de borda. Se, por qualquer motivo, uma dessas requisições ficar pendente ou encontrar um atraso, todo o processo de SSR fica paralisado, deixando o usuário em um jogo frustrante de espera.

Esse gargalo de latência se torna particularmente evidente em aplicações ricas em dados, prejudicando a experiência do usuário e potencialmente levando ao abandono. É um cenário onde o tempo de resposta mais lento da API dita a velocidade geral de renderização, introduzindo atrasos desnecessários que impactam a satisfação do usuário.

Para os nerds na plateia, podemos derivar uma equação simples que pode nos dar o tempo de espera esperado para o modelo fetch-then-render. Digamos que, para renderizar uma página, realizamos n requisições em paralelo, e cada requisição tem uma probabilidade p de ser considerada uma requisição "rápida". Então, para que a página seja "rápida", todas as requisições precisam ser "rápidas", assim a probabilidade da página ser "rápida" é:

p_rápido = p^n

99% das requisições geralmente respondem em menos de 500ms, e as requisições lentas levam cerca de 3 segundos. Vamos chamar essas quantidades de lrápido e llento, respectivamente. Assim, a latência esperada para uma página da web no modelo fetch-then-render é:

l_página = l_rápido * p_rápido + l_lento * (1-p_rápido)

Devido a problemas com APIs de comércio, temos alguns clientes que, para renderizar uma página, realizam 97 requisições. Ao inserir esses números na equação, temos uma latência esperada da página de cerca de 2 segundos, mesmo que 99% do tempo as requisições respondam em menos de 500ms! Isso significa que mesmo se melhorarmos as APIs, o modelo matemático por trás dessa abordagem nos impede de sermos rápidos. Note que este modelo também pode ser usado para caching. Se nossa taxa de acerto no cache for de 99% (o que é cerca de 30% na prática), a latência esperada é dominada pelas APIs lentas. A matemática é cruel, meu amigo, mas há esperança!

Carregamento Progressivo: Uma Abordagem Mais Inteligente:

Introduza o Carregamento Progressivo - uma técnica que é imune a requisições lentas. Em vez de esperar que todo o conteúdo esteja pronto no servidor antes de responder ao cliente, o Carregamento Progressivo renderiza o conteúdo das requisições rápidas, recorrendo a esqueletos e estados de carregamento para o conteúdo de requisições lentas, oferecendo aos usuários uma experiência visual imediata.

Esta abordagem diminui a ansiedade do usuário, mostrando feedback visual de que o sistema está trabalhando para o estado desejado. Sistemas altamente dinâmicos como YouTube e Instagram implementam esse tipo de abordagem baseada em esqueletos, então os usuários da internet estão acostumados a esse tipo de interação. No entanto, implementar manualmente o Carregamento Progressivo em seu site pode ser desafiador e trabalhoso.

Apresentando a Renderização Assíncrona: O Recurso que Muda o Jogo:

Aqui vem a Renderização Assíncrona, nosso recurso mais recente projetado para simplificar o paradigma de Carregamento Progressivo. A magia está na integração estreita do carregamento progressivo em nosso framework. Veja como funciona:

Os carregadores agora estão vinculados a um orçamento de tempo. Uma vez atingido esse limite, os carregadores que concluíram seu trabalho terão seu conteúdo renderizado no html final como de costume. Os carregadores que consomem APIs lentas levantarão uma exceção e um estado de carregamento será renderizado nas seções que consomem este carregador. Este estado de carregamento usará nosso recurso Partials para hidratar e substituir a seção ausente preguiçosamente.

Isso significa que não há necessidade de adicionar manualmente a seção Deferred mais. Qualquer seção agora é adiada dependendo da API que estão consumindo.

Personalização dos Estados de Carregamento Facilitada:

Para tornar seu site verdadeiramente seu, simplificamos a personalização dos estados de carregamento. Basta exportar um componente LoadingFallback da sua seção e este será usado como seu estado de carregamento. Um estado de carregamento em branco padrão será usado se nenhum componente LoadingFallback for exportado.

Por exemplo, vamos pegar esta Seção

export default function Section(props: Props) { ... }

Para adicionar um estado de carregamento personalizado:

export default function Section(props: Props) { ... }

export function LoadingFallback () {
  return <div>carregando...</div>
}

Dica: tente exportar um componente chamado ErrorFallback para lidar com qualquer possível erro que esta seção possa encontrar

Para saber mais, confira nossos docs

SEO

Como você deve saber, renderizar parcialmente o conteúdo de uma página não é ideal para SEO. Por esse motivo, sempre que nosso sistema detectar que é o Google ou qualquer outro mecanismo de busca solicitando sua página, nosso sistema recorrerá à abordagem fetch-then-render, oferecendo o melhor SEO possível.

Faça um Tour pela Renderização Assíncrona no Admin da Deco.cx:

Pronto para experimentar o poder da Renderização Assíncrona em primeira mão? Junte-se a nós para um tour guiado sobre como ativar este recurso dentro da interface de administração da Deco.cx. Descubra como é fácil melhorar o desempenho do seu site com alguns passos simples.

1. Certifique-se de que seu projeto esteja atualizado para as últimas versões do deco e dos aplicativos executando:

deno run -A https://deco.cx/update

2. Abra o aplicativo do seu site no admin da deco.cx e procure pela opção de Renderização Assíncrona. Defina-o como 0 para desativar ou qualquer outro valor para ativá-lo.

É isso! agora suas seções estão sendo renderizadas de forma assíncrona!

Impactos nos Principais Indicadores da Web

A renderização assíncrona torna o seu site mais responsivo, reduzindo a ansiedade dos usuários e melhorando a experiência geral. No entanto, pode afetar os indicadores principais da Web. Vamos analisar como a renderização assíncrona influencia sua pontuação final.

FCP (First Contentful Paint)

O FCP é significativamente melhorado porque a página não precisa esperar por respostas de APIs de terceiros lentas.

LCP (Largest Contentful Paint)

O LCP pode melhorar ou piorar dependendo da origem do seu elemento LCP. Se as imagens vêm de APIs, isso pode diminuir a pontuação. No entanto, se as imagens forem carregadas via administração da Deco, isso aumentará consideravelmente. Por exemplo, em páginas iniciais onde o banner é carregado usando o CMS da Deco, o LCP será muito melhor. No entanto, em páginas de produtos, a pontuação do LCP pode diminuir, já que precisamos esperar por algumas viagens antes de baixar a imagem do produto.

CLS (Cumulative Layout Shift)

O CLS deve permanecer inalterado. Componentes LoadingFallback bem projetados não devem contribuir para nenhum deslocamento de layout. Se observar quaisquer mudanças no CLS, consulte seu desenvolvedor para aprimorar os componentes LoadingFallback.

FID (First Input Delay)

O FID pode aumentar ligeiramente, já que a página não é renderizada de uma vez, utilizando melhor o tempo da CPU.

Em geral, uma melhora nos indicadores do Web Vitals deve ser percebido

Curioso para ver a Renderização Assíncrona em ação? Visite nosso modelo de loja e veja o impacto transformador no desempenho do site.