next – Blog do next

<p>Com o crescimento dos frameworks JavaScript e a tendência em criar aplicações com o mínimo de processamento possível, programadores e arquitetos passaram a adotar o padrão SPA, renderizados no lado do cliente, para desenvolvimento de aplicações web.</p><p>Neste artigo, contaremos a nossa jornada e explicaremos o porquê votamos a processar e renderizar as páginas HTML no lado do servidor. Mostraremos o embasamento de nossas decisões e o porquê escolhemos o&nbsp;<a href="https://next.me/%22https://nextjs.org//%22">NextJS</a>&nbsp;como framework de desenvolvimento para nosso site.</p><p>Acompanhe nosso artigo e descubra os resultados e impactos dessa mudança.</p><h2>Uma breve história do next.me</h2><p>O ano é&nbsp;<b>2017&nbsp;</b>e a versão 1.0 do website&nbsp;<a href="https://next.me/%22https://next.me//%22">next.me</a>&nbsp;foi lançada como uma SPA (com renderização no lado do cliente), com as melhores tecnologias do mercado (da época),&nbsp;<a href="https://next.me/%22https://reactjs.org//%22"><b>ReactJS</b></a>&nbsp;e&nbsp;<a href="https://next.me/%22https://webpack.js.org//%22">webpack</a>.</p><p>“uma ‘Single-page application’ (aplicação de uma página) é uma implementação de aplicativo web que carrega apenas um único documento e então, o corpo da página é atualizado via API’s JavaScript...Então assim, permite o usuário a usar um website sem ter que carregar uma página completa do servidor, o que pode resultar em ganho de performance e uma experiência mais dinâmica, com algumas desvantagens em troca como SEO, maior esforço de manutenção, a implementação de navegação e um trabalho considerável para monitorar a performance”.@moozila&nbsp;SPA (Single-page application)-</p><p>Uma SPA com carregamento em&nbsp;“client side”, funciona da seguinte forma:</p><img src="{{1.jpg}}" alt="Image"><img src="{{2.jpg}}" alt="Image"><p>Com isso, sites de busca, também não indexavam nosso conteúdo.</p><img data-src-name="{{3.jpg}}" alt="Image"><h2>next.me 2.0</h2><p>Em 2020 com novas campanhas, o next decidiu remodelar seu site.&nbsp; Como não aproveitar e também atualizar as tecnologias, buscando melhorar a performance para SEO e campanhas?</p><p>Mas, como desenvolver e hospedar websites modernos, utilizando ReactJS e entrega-lo de maneira eficiente e acessível para usuários e mecanismos de busca?</p><h3>A preparação.</h3><p>Montamos um time, imprimimos e colamos todas as páginas da nova versão do site na parede da sala de reuniões.</p><p>Compramos uma garrafa térmica de 2 litros e nos trancamos por duas semanas para estudar, tanto os componentes de design (que futuramente originariam o&nbsp;<b>@nextweb/ui-kit</b>), quanto compreender os problemas da versão 1 que deveríamos evitar a todo o custo.</p><p>Entre cafés e pães-de-queijo, testamos frameworks, recursos de cloud, estudamos os “Core Web Vitals”, fizemos POC’s, POC’s e mais POC’s, até que compreendemos os requisitos técnicos iniciais para estruturarmos a arquitetura do projeto.</p><img data-src-name="{{image2022-4-1311-13-2.png}}" alt="Image"><h3>Os requisitos técnicos</h3><h5>Ser Mobile First.</h5><p>[PORCENTAGEM DE CLIENTES QUE USAM MOBILE] do nosso público utilizam dispositivos mobile para navegação na internet. Com isso, o site precisa ser otimizado para ser leve, rápido e com um excelente design para dispositivos mobile.</p><h5>First Meaningful Paint (atual FCP)</h5><p>As páginas do site deverão mostrar o conteúdo instantaneamente, sem ter que esperar ou depender de javascript.</p><h5>Conteúdo dinâmico.</h5><p>O site deve ser plugado em um CMS e precisa ser atualizado em “tempo real”.</p><h5>Tem que funcionar no I.E.</h5><p>Imprevistos acontecem [EMOJI DE OLHO].</p><h5>Imagens Otimizadas</h5><p>Imagens e vídeos são artefatos críticos para uma página ter uma boa performance</p><p>Segundo o&nbsp;“<a href="https://next.me/%22https://web.dev/codelab-serve-images-correct-dimensions//%22">Core Web Vitals</a>”, as imagens precisam ser servidas no tamanho correto, com a compressão correta e de maneira otimizada para cada dispositivo.&nbsp;&nbsp;</p><h3>Os problemas da v1</h3><p>Vamos estudar o comportamento de uma SPA dentro do site next.me 1.0, utilizando a linha de tempo de renderização do “profiler” do&nbsp;<a href="https://next.me/%22https://developers.google.com/web/tools/lighthouse//%22">Lighthouse</a>.</p><p>Na imagem abaixo temos os primeiros dez segundos de renderização da página home. Não se preocupe com o excesso de informação, mais abaixo analisaremos este relatório com você.</p><img data-src-name="{{4.jpg}}" alt="Image"><p>O que são estas linhas e o que elas representam no ciclo de vida de renderização de um site?</p><img data-src-name="{{5.jpg}}" alt="Image"><p>Em&nbsp;<b>vermelho&nbsp;</b>(ou salmão), temos a linha da&nbsp;rede. Nela está sendo exibido o&nbsp;<b>tempo</b>&nbsp;que o navegador levou para&nbsp;<b>baixar&nbsp;</b>algum arquivo (js, html, css, imagens, etc).</p><p>Em&nbsp;<b>verde</b>,&nbsp;temos a linha de&nbsp;pintura de tela.&nbsp;Nela, podemos visualizar o que está sendo&nbsp;<b>mostrado na tela do usuário</b>.</p><p>Em&nbsp;<b>amarelo</b>, temos a linha de algumas das principais métricas de performance para a web (vamos falar sobre isso já já).</p><p>Aqui estão alguns dos principais eventos da linha do tempo.</p><img data-src-name="{{6.jpg}}" alt="Image"><p>Ou seja, em&nbsp;<b>média&nbsp;</b>(com dados de laboratório) um usuário&nbsp;<b>levava&nbsp;7.6 segundos</b>&nbsp;para visualizar o primeiro frame de nosso site (o&nbsp;<b>FCP</b>).</p><p>Segundo o time do Google:</p><p>“Para fornecer uma boa experiência ao usuário, os sites devem se esforçar para ter uma First Contentful Paint de&nbsp;1,8 segundos&nbsp;ou menos.”--</p><p>Ou seja, o comportamento padrão de uma SPA (renderizada no lado do cliente) dificulta muito a pintura e entrega do primeiro frame.</p><h3>O tamanho do bundle</h3><p>Outro grande problema de uma SPA, é o tamanho do arquivo inicial do aplicativo.</p><p>Hoje é muito fácil utilizar técnicas de code-spliting (separar os códigos em multiplos bundles) e lazy loading (carregar budles por prioridade) porém, o comportamento padrão de uma SPA é colocar todo o código do seu site em um único arquivo.</p><img data-src-name="{{7.jpg}}" alt="Image"><p>O arquivo inicial (o maior quadrado em rosa, bundle.js) para montar o site é de&nbsp;<b>7.0MB&nbsp;</b>o que, num ambiente com simulação de conexão 4g (em laboratório) levou&nbsp;<b>4.77</b>&nbsp;<b>segundos</b>.</p><h3>O plano (JamStack)</h3><p>Durante os estudos de novas ferramentas e padrões do mercado, encontramos o&nbsp;<b>nextjs&nbsp;</b>e a&nbsp;<b>Jamstack</b>.</p><h4>O que é a JamStack?</h4><p>Esta arquitetura de projetos surgiu com a necessidade de modernizar e otimizar as aplicações SPA, tornando-as mais acessíveis e performáticas.</p><p>A ideia central é de que, além de possuir uma CDN para tornar a distribuição de conteúdo mais rápida, o conteúdo precisa ser pré-renderizado no lado do servidor, sendo entregue ao usuário o HTML já “pintado”.</p><p>Ela pode trazer todos os benefícios de uma SPA, somados aos benefícios de devolver um html já montado para o client.</p><p>Você pode saber mais sobre esse padrão de arquitetura&nbsp;<a href="https://next.me/%22https://jamstack.org//%22">aqui</a>.</p><p>Os princípios desta arquitetura são:</p><ul><li>JavascriptPor ser uma linguagem extensível, poderosa e dinâmica, o JavaScript permite (com ressalvas) que algoritmo rode tanto no lado do cliente (navegador) quanto no lado do servidor (com NodeJS e Deno).</li><li>Por ser uma linguagem extensível, poderosa e dinâmica, o JavaScript permite (com ressalvas) que algoritmo rode tanto no lado do cliente (navegador) quanto no lado do servidor (com NodeJS e Deno).</li><li>Pré renderingPara entregar o conteúdo de maneira otimizada para navegadores e buscadores, o arquivo HTML precisa ser entregue pré-renderizado, evitando assim a dependência direta de arquivos javascript para mostrar o conteúdo de uma página.</li><li>Para entregar o conteúdo de maneira otimizada para navegadores e buscadores, o arquivo HTML precisa ser entregue pré-renderizado, evitando assim a dependência direta de arquivos javascript para mostrar o conteúdo de uma página.</li></ul><p>Veja como funciona:</p><img data-src-name="{{8.jpg}}" alt="Image"><p>Em algumas sessões, mostraremos como isso funcionou no mundo real.</p><ul><li>CDNPara entrega de conteúdo de maneira eficiente e distribuída, será necessário servir o site através de uma CDN.</li><li>Para entrega de conteúdo de maneira eficiente e distribuída, será necessário servir o site através de uma CDN.</li></ul><p>Segundo a&nbsp;<a href="https://next.me/%22http://www.akamai.com//%22"><b>@akamai</b></a>, no artigo&nbsp;<a href="https://next.me/%22https://www.akamai.com/pt/our-thinking/cdn/what-is-a-cdn/%22">"<b>O que é uma CDN?</b>" (akamai.com)</a></p><p>“Uma CDN (Rede de Entrega de Conteúdo) é um grupo de servidores geograficamente distribuídos que aceleram a entrega do conteúdo da Web, aproximando-o de onde os usuários estão.&nbsp;“</p><ul><li>Micro Serviços</li></ul><h4>A Execução</h4><h5>A evolução da infraestrutura.</h5><p>Em 2020 o next iniciou a migração para a cloud da Azure, e uma das premissas iniciais (quanto ao site), foi levar o ambiente equivalente&nbsp;“on-premises”&nbsp;e colocá-lo em num cluster na cloud.</p><img data-src-name="{{9.jpg}}" alt="Image"><ol><li>Na imagem,&nbsp;em vermelho, temos a infraestrutura “atual” (no momento de criação) do site, a qual deverá hospedar o site nos primeiros deploys. Usuários e buscadores solicitariam a um servidor apache os arquivos que foram atualizados com a ferramenta de CI &amp; CD Bamboo, buscado o conteúdo do StaffChannel (que seria alimentado pelo marketing.</li><li>Em&nbsp;azul,&nbsp;temos o&nbsp;novo modelo&nbsp;de infraestrutura, aonde o cliente e os buscadores solicitam há um&nbsp;Cache&nbsp;(uma CDN) os conteúdos, indexados e cacheados de&nbsp;um servidor NodeJS, que por si, atualiza seu próprio conteúdo em um tempo pré-agendado, buscando-o seus dados através de um&nbsp;API middleware.</li></ol><h3>O resultado</h3><p>Vamos fazer a mesma analise que fizemos na versão 1.</p><p>Na imagem abaixo, temos os primeiros dez segundos de renderização do novo site com os principais eventos.</p><img data-src-name="{{10.jpg}}" alt="Image"><h5>Nosso tempo de pintura reduziu 844% o tempo de primeira pintura (FCP)</h5><p>&nbsp; O tempo de primeira pintura passou de&nbsp;<b>7.6&nbsp;para&nbsp;0.9 segundos</b>.&nbsp;Uma melhora considerável para os indicadores de performance.</p><p><b>Antes</b></p><img data-src-name="{{11.jpg}}" alt="Image"><p>Na imagem, o tempo de carregamento médio era&nbsp;<b>7.6 segundos</b></p><p><b>Depois</b></p><img data-src-name="{{12.jpg}}" alt="Image"><p>Com renderização no lado do servidor, o tempo de carregamento passou para&nbsp;<b>0.9 segundos.</b></p><h5>&nbsp; Buscadores passaram a gostar de nossas páginas</h5><p>Por exemplo, com nossa página de&nbsp;<b>mimos</b>, passamos a ser o primeiro resultado orgânico.</p><img data-src-name="{{14.jpg}}" alt="Image"><p>Buscando por&nbsp;<b>"renda fixa"</b>, junto de&nbsp;<b>"banco next"</b>, nossa página de investimentos e nosso post de blog também passaram a ser o primeiro resultado orgânico</p><img data-src-name="{{13.jpg}}" alt="Image"><h5>Nossos arquivos Javascript ficaram menores.</h5><img data-src-name="{{15.jpg}}" alt="Image"><p>Somando o peso de todos arquivos da aplicação (ignorando arquivos de analytics), nosso bundle ficou com&nbsp;<b>~830kb (0.8MB)</b>.&nbsp;</p><p>Isso ocorre porque o&nbsp;<b>NextJs&nbsp;</b>cria um build individual e otimizado para cada página, contendo apenas o javascript necessário para cada uma delas renderizar.</p>

Um pouco da nossa experiência com websites e frameworks javascript e o caminho que nos levou até "voltar" a renderizar html's do lado do servidor.

Voltamos a renderizar html no servidor