Neste post, veremos como o vue, o React e o Angular se comparam em termos de desempenho e o que pode ser feito para otimizar os spas de comércio eletrônico executados nesses frameworks frontend para a melhor experiência do usuário.
Como é que o Angular, o Reacto e o Vue se comparam em termos de desempenho
Gerir um site rápido leva a um crescimento de resultados através de um melhor ranking de SEO, mais visitantes, sessões mais longas e, como resultado, mais receitas. Muitos líderes de comércio eletrônico que entendem o papel da velocidade já mudaram para a arquitetura de comércio sem cabeça, permitindo a adoção de interfaces modernas, como aplicativos progressivos da web e spas. As frentes DE SPA leves estão a ganhar popularidade porque são uma forma infalível de resolver vários problemas de desempenho inerentes às modernas plataformas de comércio eletrónico, para que os operadores possam fornecer lojas extremamente rápidas.
Bem, essa é a teoria. Para verificar estas afirmações elevadas, fizemos uma pequena análise interna de desempenho. Para isso, testámos cerca de 2 000 sites de comércio eletrónico populares a funcionar nos principais frameworks e avaliamos o seu desempenho com base nas pontuações do Lighthouse 6. As descobertas foram surpreendentes – a pontuação média do farol para as fachadas testadas foi de apenas 24, com uma mediana de 19 (de 100)! Tão baixo quanto parece, isto ainda era 26% mais alto do que a pontuação média dos 500 principais retalhistas de Internet dos EUA em receitas.
Os sites vue.js foram os mais rápidos, com uma média de 27 pontos com uma mediana de 20. Os sites Angular viram uma média de 23; no entanto, os seus resultados de desempenho foram mais dispersos, com uma mediana de apenas 18. Os sites React foram os mais lentos testados, com uma média de pontuação do farol de 22 e uma média de 18. Isso foi surpreendente, especialmente porque o framework é usado por alguns dos maiores jogadores, incluindo sites como PayPal, Grammarly e Vimeo, para citar alguns.
A conclusão do teste era bastante clara, enquanto os spas são considerados mais rápidos do que os sites tradicionais, ainda há espaço para melhorias. Além disso, o Google crux e outras ferramentas de medição não acompanham as transições de página de aplicações de página única (SPAs), deturpando-as como sendo muito mais lentas do que elas e penalizando as suas pontuações. Escrevemos mais sobre esta questão noutro post no blog.
O impactos do tempo de arranque e do desempenho em tempo de execução nas pontuações do farol
O desempenho dos aplicativos é definido por duas métricas: Tempo de inicialização e desempenho de tempo de execução . O tamanho do pacote de código influencia principalmente o primeiro, ou seja, o código do aplicativo e o código do framework combinados. O desempenho do tempo de execução depende dos recursos específicos de otimização do framework e da forma como ele lida com a manipulação e atualização do DOM.
Tamanho do pacote
Todos os três frameworks têm pacotes de código mínimos e de tamanho semelhante. Embora o tamanho do pacote da estrutura tenha impactos no tempo de arranque, a métrica não deve ser o foco principal na comparação do desempenho do Angular, React e vue.
De forma mais precisa, o tamanho do pacote angular é ligeiramente maior do que os tamanhos dos pacotes vue e React, com os pacotes vue um pouco mais pequenos do que os pacotes React. Além disso, vale a pena notar que a equipa de desenvolvimento angular está constantemente a otimizar o tamanho dos seus pacotes de código (fonte).
Veja o gráfico abaixo para ver os números aproximados.
As métricas TTI e LCP da Lighthouse
O Lighthouse é uma excelente ferramenta de testes que devolve valiosas informações de velocidade. Identifica possíveis problemas de desempenho e ajuda a otimizar os vários aspetos de um site. Uma pontuação de farol é calculada com base numa média ponderada de múltiplas métricas (vá aqui para um resumo completo). Ainda assim, o maior Contentful Paint (LCP), o Time to Interactive (TTI) e o Cumulative Layout Shift (CLS) são muito provavelmente os mais importantes da perspetiva do usuário. O TTI e o LCP estão diretamente ligados à velocidade de carga percebida. O TTI é uma boa representação do impactos do tamanho do pacote de um framework na velocidade do SPA, já que o pacote precisa ser avaliado inteiramente antes que um usuário possa interagir com o aplicativo. Sites com um TTI longo mostrarão várias partes do site enquanto carregam, mas não permitirão que os usuários interajam com ele, o que pode levar à frustração. A métrica LCP, por outro lado, mede quanto tempo demora até que o maior elemento do conteúdo da página seja apresentado no ecrã.Farol vs. Crux dados de navegação na vida real
Vale a pena notar que as ferramentas de medição de velocidade sintéticas (como o farol) não contam a história completa. A velocidade do site é mais sobre como o site “se sente” quando os usuários navegam por ele. Uma pontuação de desempenho do farol é um bom ponto de referência, mas é um pouco arbitrário e difícil de correlacionar com uma experiência do mundo real. Por exemplo, é difícil traduzir quanto melhor seria uma pontuação de desempenho de 60, em termos de experiência do utilizador, em comparação com uma pontuação de 50. Os testes sintéticos também tendem a simular dispositivos e conexões mais antigos (por exemplo, o Lighthouse simula conexões 3G), enquanto na realidade, a maioria dos usuários móveis está em redes LTE rápidas ou até mesmo em redes 5G. Um site rodando em uma estrutura específica pode “sentir” mais rápido, mas perder para outros sites em relação à sua pontuação de desempenho bruta e vice-versa. Isto deve-se principalmente a truques específicos (por exemplo, carregamento lento) que cada framework emprega para melhorar a velocidade com que o site “se sente” para os utilizadores. Nas próximas secções, analisaremos as oportunidades que cada um destes frameworks oferece para melhorar o desempenho do website.Angular
O Angular estende o código HTML com novas tags e atributos e interpreta os atributos para executar a vinculação de dados. Devido às suas ricas funcionalidades, a aplicação de trabalho pode ser muito maior (cerca de 500 KB) em comparação com o Vue ou o React, o que pode ter um ligeiro impactos no desempenho.
Abstração MVC do Angular ( fonte )
Aqui está um resumo rápido dos principais benefícios do Angular.
- Geração de código. O Angular gera código altamente otimizado para máquinas virtuais JavaScript, dando os benefícios do código escrito à mão. Modelos HTML combinados com JavaScript abrem a porta para otimizações impossíveis em outros frameworks, por exemplo, React.
- Divisão de códigos. Graças ao Component Router, as aplicações Angular carregam rapidamente, oferecendo divisão automática de códigos. Desta forma, os utilizadores carregam o código necessário para renderizar a vista que pedem.
- Real DOM. O Angular usa o DOM real; portanto, é mais adequado para aplicações de página única em que o conteúdo é atualizado apenas de tempos em tempos, não aqueles que mudam frequentemente, como a maioria dos sites de comércio eletrônico. Manipular o DOM virtual é muito mais rápido porque nada é desenhado na tela.
Reaja
Criado e desenvolvido pelo Facebook, o React é um dos mais populares frameworks de aplicativos móveis de código aberto. Ele não fornece uma ampla gama de bibliotecas; portanto, seu tamanho é significativamente menor do que o do Angular.
Com dados de direção única, o React permite um melhor controlo sobre o projeto. Ao desenhar uma aplicação, os programadores do React podem aninhar componentes filhos dentro de componentes principais de ordem superior.
O React oferece algumas funcionalidades interessantes, incluindo:
- Virtual DOM: Os nós são re-renderizados apenas conforme necessário. O React compara os novos dados com o DOM original e atualiza a visualização automaticamente. Isto melhora o desempenho de aplicações de todos os tamanhos que precisam de atualizações regulares de conteúdo.
- Vinculação de dados unidirecionais: O React usa a vinculação de dados unidirecionais com a arquitetura de aplicativos do Flux Controls. O ReactJS ajuda a atualizar a Visualização para o utilizador, e o Flux controla o fluxo de trabalho da aplicação. O Virtual DOM acrescenta vantagens à medida que compara os novos dados com o original e atualiza a View automaticamente.
- Suporte para agregação e agitação de árvores: Minimiza a carga de recursos do utilizador final.
- Suporte a renderização do lado do servidor (SSR): Oferecendo ganhos de velocidade em implementações específicas.
Em maior medida do que o Angular e o Vue, o React utiliza certas técnicas que tornam a página mais rápida para os utilizadores finais. Por exemplo, a estrutura prioriza a entrada do usuário sobre a renderização de conteúdo na página.
Vue
O VUE é rápido e muito pequeno com cerca de 30 KB (gzipado), o que resulta em primeiras cargas mais rápidas. Isto torna-o o mais pequeno de todos os três frameworks e acelera significativamente o desempenho dos sites que estão a ser executados no Vue.
O VUE oferece:
- Renderização do lado do servidor (SSR)
- Árvore a tremer
- Empacotar
- Virtual DOM: As alterações dentro de um projeto não afetam o DOM corretamente. Modificar o DOM real é uma tarefa intensiva em recursos, portanto as atualizações são aplicadas primeiro ao DOM virtual.
Veja este relatório detalhado de referência para comparar tempos de arranque, alocação de memória e a duração de operações específicas nos principais frameworks e bibliotecas JavaScript. Comparado com o React, o Vue é um pouco melhor em termos de alocação de memória e tempos de inicialização, embora o React seja um pouco mais rápido em termos de tempo de execução.
O Angular e o Vue usam modelos HTML combinados com JavaScript. Isto dá-lhes espaço extra para otimização que o React não oferece. Por exemplo, o vue rastreia dependências impedindo renderizações desnecessárias de componentes filhos.
Otimização de VUE vs. React vs. Angular SPA
Sabemos que as referências e as pontuações de desempenho não contam toda a história. A velocidade do website pode variar dependendo do tamanho da aplicação e dos esforços de otimização. Aqui estão algumas ideias para ajudar a otimizar as termas vue, React e angular para velocidade.
1. Representação do lado do servidor (SSR)
No geral, existem quatro benefícios chave de usar o SSR com SITES DE SPA:
- O SSR permite carregar rapidamente um MODELO DE SPA e exibir conteúdo para o utilizador (embora o utilizador possa não ser capaz de interagir com ele imediatamente). Sem o SSR, os utilizadores olhavam para uma tela vazia, à espera que o conteúdo fosse carregado e renderizado no navegador.
- O SSR reduz a carga na máquina do utilizador final.
- Como o Google pode agora rastrear adequadamente o conteúdo DO SPA, a renderização do lado do servidor pode não ser tão importante para o SEO como costumava ser. Mas o benefício de usar o SSR é que muitos outros motores de busca ainda não entendem o JavaScript e não conseguem rastrear sites pesados em JavaScript corretamente.
- As redes sociais muitas vezes não conseguem exibir adequadamente o conteúdo compartilhado a partir de sites DE SPA renderizados pelo cliente. Por exemplo, o raspador do Facebook só depende das meta tags definidas pelo servidor e não funciona com meta tags renderizadas do lado do cliente. Para controlar melhor a aparência do seu SITE DE SPA quando partilhado através do Open Graph, a SSR é uma obrigação.
- AMP acelera as primeiras cargas em dispositivos móveis, mas não permite que você use JavaScript. É impossível renderizar AMP do React no cliente, ele deve ser feito no servidor. No entanto, mesmo com o SSR no lugar, há muitos arcos para saltar para converter um aplicativo React em um aplicativo AMP válido. Felizmente, alguns frameworks frontend, como o React Storefront, podem lidar com tudo para você.
O SSR funciona melhor para sites estáticos, mas os sites DE eCommerce SPA ainda são armazenados em cache, com a infraestrutura certa. Com o Layer0, o conteúdo é renderizado no lado do servidor e depois armazenado em cache no limite com o nosso CDN-as-JavaScript. Desta forma, sites em larga escala baseados em bases de dados, como os spas de comércio eletrónico com milhares ou milhões de páginas, personalização, inventário em tempo real e muito mais, podem deliciar os utilizadores com carregamentos de páginas inferiores a segundos desde a aterragem até ao check-out.
O service worker CDN-as-JavaScript (chamado Layer0 Workers) busca de forma inteligente dados dinâmicos da borda antes que o visitante toque em um link e o transmita para o navegador, com base no que eles provavelmente irão tocar.
A rede Layer0 e as ferramentas de monitorização asseguram que os dados dinâmicos são armazenados em cache pelo menos 95% do tempo, protegendo a sua base de dados dos pedidos extra criados por pré-busca. Desta forma, você pode fornecer cargas de páginas de sub-segundos, oferecendo aos seus visitantes uma experiência perfeita desde o desembarque até o check-out.
Rede Layer0 e ferramentas de monitorização
No geral, em relação aos recursos de SSR e à documentação detalhada, o Vue é superior ao React, que precisa de bibliotecas de terceiros (por exemplo, Next.js) para renderizar páginas do lado do servidor.
2. AMP
Amp cria experiências melhores e mais rápidas na web móvel simplificando o HTML e aplicando limitações rigorosas no CSS e JavaScript. Essas páginas são então armazenadas em cache e pré-renderizadas no servidor do Google, o que torna a transição para o seu aplicativo quase instantânea.
A desvantagem é que é diferente de como você escreve um PWA/SPA e significa uma reescrita completa do aplicativo a menos que você use um framework dedicado com suporte AMP embutido, como React Storefront.
As PÁGINAS AMP têm 500 ms de carga média de páginas para tráfego proveniente do SERP do Google. Essas velocidades são possíveis porque os servidores do Google pré-obtêm e pré-renderizam o conteúdo AMP para o navegador de um usuário antes de clicar no link da página AMP. O site médio de comércio eletrónico recebe uma grande parte do seu tráfego através da pesquisa do Google (tanto orgânica como paga), para que estes ganhos possam ter um enorme impactos.
Os sites que usam AMP também veem taxas de rejeição reduzidas, já que os utilizadores que normalmente podem saltar enquanto esperam que uma página seja carregada agora terão uma experiência extremamente rápida.
3. Divisão de código
A sua aplicação de página única irá crescer ao longo do tempo à medida que continuar a adicionar funcionalidades. Mas sabemos que cada aplicação tem algumas funcionalidades que dificilmente são usadas e desnecessariamente desaceleram. Você deve implementar a divisão de código para manter seu aplicativo o mais rápido possível.
A divisão de código envolve a criação de pacotes separados para cada componente de nível superior no seu aplicativo. No caso de um eCommerce Spa, haverá pacotes separados para a página inicial, listas de produtos e páginas de descrição de produtos. Desta forma, quando um utilizador chega à sua aplicação através de um link para um produto específico, o navegador não precisa de descarregar e executar o código para todas as páginas anteriores, reduzindo assim os tempos do TTI e do FID.
Com a divisão de código, o aplicativo pode carregar outros componentes de página em segundo plano e usá-los se o usuário decidir navegar neles. Isto poupa largura de banda e diminui o primeiro atraso de entrada ou o ID (nota que o DIF é frequentemente aproximado pelo tempo à métrica interativa ou TTI), melhorando a velocidade do seu website e a classificação do motor de busca.
4. Carregamento lento
Vue, React e Angular suportam carregamento lento, o que, em combinação com SSR, pode proporcionar melhorias significativas na velocidade.
O carregamento lento representa um desafio ao implementar o SSR. O servidor deve saber quais componentes foram usados para renderizar o HTML de saída e enviar o código para esses componentes ao lado do HTML. Caso contrário, o aplicativo precisará montar no navegador e executar dois ciclos de renderização antes de estar pronto para ser interativo, o que aumentará o FID (e o TTI), o que pode levar ao conteúdo flash ou jank.
Carregamento lento e SSR estão ligados. A biblioteca que você escolher para carregamento lento (por exemplo, React Loadable ) afetará como você gera o HTML final enviado de volta na resposta. Para capturar os pacotes que precisam ser carregados para hidratar o HTML que foi renderizado no servidor, você precisará <adicionar loadable.capture></loadable.capture> para o seu código SSR, depois use a função getBundles do React Loadable para descobrir qual <script><>as etiquetas /script precisam ser adicionadas ao corpo do documento.
Como as dicas do cliente de carregamento lento ainda não são suportadas globalmente por todos os navegadores, existem algumas soluções alternativas para implementar o carregamento lento sem problemas.
Solução n.º 1
Em vez de renderizar as imagens do lado do servidor, você pode deixá-las preencher o lado do cliente quando o aplicativo for montado.
Solução n.º 2
Use apenas carregamento lento para imagens “abaixo da dobra”, ou seja, aquelas que você sabe não serão visíveis imediatamente após o carregamento. Isto é um desafio porque a linha de dobragem pode subir e descer dependendo do dispositivo do utilizador e do tamanho do ecrã. No entanto, algumas heurísticas ajudam. Por exemplo, em uma página de categoria de comércio eletrônico, você pode desativar o carregamento lento para o primeiro conjunto de imagens de produtos (eles provavelmente estarão “acima da dobra”). E para os itens que você sabe que estarão consistentemente acima da dobra (por exemplo, cabeçalhos, logotipos da empresa, ícones de carrinho), você não deve habilitar o carregamento lento de qualquer maneira e sempre pode renderizá-los do lado do servidor.
Solução n.º 3
Detectar o agente do usuário pode ajudar a fornecer uma versão apropriada da página renderizada pelo SSR. A deteção de user-agent não é geralmente recomendada para implementar melhorias progressivas, mas faz o truque como uma solução temporária enquanto os navegadores detetam e implementam dicas de clientes.
Esta solução requer que normalize as chaves de cache adequadamente; caso contrário, poderá fragmentar a sua cache significativamente.
5. CDN moderna
Otimizar o seu SPA para velocidade e usar uma boa CDN em cima disso irá impulsionar o seu site, mas não é suficiente para atingir velocidades abaixo de segundo. Isso acontece porque a maioria dos CDNs tradicionais só são bons em armazenar arquivos estáticos, mas no geral eles não lidam tão bem com dados de json/html/ssr, enquanto isso é exatamente disso que os sites DE eCommerce SPA são feitos. Tornar estes sites mais rápidos requer várias tecnologias web a trabalhar de forma eficiente em uníssono. Ao contrário de outros CDNs, a CDN com reconhecimento de aplicativos Layer0 funciona bem com os spas de comércio eletrônico. Ele otimiza as taxas de acerto do cache para níveis inéditos e traz inteligência para o limite. Isso ajuda os empresários a decifrar tendências e oportunidades de otimização categorizando páginas semelhantes como tais (por exemplo, PDP, PLP e carrinho) em vez de simplesmente exibir uma lista interminável de URLs. Isso permite que você tome medidas e veja uma diferença nos tempos de carregamento do site.
Mas o mais importante, o CDN-as-JavaScript usa técnicas avançadas de pré-busca preditivas para transmitir dados armazenados em cache da borda para os navegadores dos usuários antes que eles toquem em qualquer coisa. Isso mantém os sites 5 segundos à frente dos toques dos compradores, permitindo-lhes deliciar os utilizadores com uma experiência de navegação instantânea.
6. Ferramentas móveis
O Angular é ótimo para a construção de aplicações móveis. Você pode usar a estrutura para criar uma aplicação web que roda em qualquer dispositivo ou desenvolver aplicativos nativos do iOS e Android combinando o Angular com o NativeScrip. Isso permite reutilizar conceitos angulares, como vinculação de dados, injeção de dependência, serviços e roteamento.
O React Native é considerado o rei do desenvolvimento multiplataforma. Permite que os desenvolvedores reutilizem até 99% do código JavaScript entre o Android e o iOS com componentes semelhantes ao React. Isso significa que os desenvolvedores podem criar 100% de widgets nativos que controlam seu próprio estilo. A estrutura lida com a camada View como uma saída de estado puro, o que torna mais fácil criar aplicativos complementares para iOS/Android com um visual e desempenho nativos.
Embora o vue esteja atrás do React, ainda oferece várias soluções valiosas para o desenvolvimento móvel. Por exemplo, o NativeScript permite que você escreva aplicativos vue e compile-os em aplicativos nativos iOS/Android.
Depois vem o VUE Native. O framework combina as vantagens dos ecossistemas vue e rn, renderização declarativa, ligação bidirecional e um conjunto de componentes básicos para criar um aplicativo nativo multiplataforma.
Os spas são mais rápidos, mas ainda têm problemas de velocidade
O fascínio original de uma aplicação de página única é que as páginas subsequentes não são recarregadas durante a navegação, levando a uma experiência de navegação mais rápida e sem atrito. Mas as frentes modernas DE SPA são apenas parte da solução de velocidade do local, e alguns problemas ainda precisam ser abordados:
- Referências e testes de velocidade sintéticos não contam necessariamente toda a história. A velocidade destes frameworks pode variar dependendo do tamanho da aplicação e dos esforços de otimização.
- Embora várias tecnologias de vanguarda, incluindo aplicações web progressivas, spas e AMP, possam melhorar drasticamente a experiência do cliente, a velocidade do website é um problema de pilha completa. Abrange o navegador, a borda e o servidor. É por isso que é necessária uma solução completa para acelerar qualquer website, SPA e aplicação de várias páginas.
- Todas estas tecnologias podem melhorar as velocidades, mas funcionam melhor quando aplicadas em uníssono. Fazer com que todas estas tecnologias funcionem em conjunto é uma tarefa complexa que as equipas internas podem não conseguir lidar (por exemplo, requer a criação de uma camada de Node.js).
Layer0: Tornando a Web instantânea e simples
Layer0 é uma solução completa para tornar sites de comércio eletrônico mais rápidos e fáceis de desenvolver. Ele combina técnicas avançadas de otimização para acelerar sites em grande escala, baseados em banco de dados, como os eCommerce Spa, juntamente com ferramentas poderosas que dão aos desenvolvedores um dia por semana, colocando o código no centro de seus fluxos de trabalho. Layer0 essencialmente traz Jamstack para grandes sites de comércio eletrônico.
Instantâneo: Combinando frontends modernos com um CDN-como-JavaScript com uma taxa de acerto de 95% de cache para conteúdo dinâmico na borda e um backend-for-frontend do Node.js, o Layer0 ajuda sites complexos a otimizar a velocidade através da pilha. É a única plataforma que garante tempos médios de sub-segunda maior pintura de conteúdo (LCP) para sites de comércio eletrónico em grande escala.
Simples: Layer0 (agora Edgio) é a sua plataforma tudo-em-um para desenvolver, implantar, visualizar, experimentar, monitorar e executar o frontend que permite que você:
- Utilizar Jamstack para eCommerce através de renderização pré e just-in-time
- Ative a rede de latência zero através de pré-busca de dados das suas APIs de catálogo de produtos
- Configure o Edge nativamente no seu aplicativo (CDN-as-JavaScript)
- Execute regras de borda localmente e em pré-produção
- Crie URLs de visualização a partir do GitHub, GitLab ou BitBucket a cada nova ramificação e envio
- Execute divisões na borda para testes A/B de desempenho, implanta o canary e personalização
- JavaScript sem servidor que é muito mais fácil e mais confiável do que o AWS Lambda
Conclusão
Gerir um site mais rápido não é apenas um truque extravagante. No final do dia, você não está apenas tentando impressionar seus usuários, mas também tentando agradar o maior motor de busca do mundo. Como a classificação do Google em breve será determinada, em parte, pela velocidade da página, não pode ser tomada de ânimo leve. Um site rápido significa que aumenta as suas classificações e conversões de SEO, o que, por sua vez, gera mais receita.
Embora muito possa ser dito sobre o desempenho de cada framework, há três pontos a lembrar:
- As diferenças reais no desempenho do framework podem ser minúsculas. O desempenho dos SITES DE SPA depende de tantas variáveis que é impossível comparar estes frameworks lado a lado de uma forma significativa.
- Quer esteja no Angular, no VUE ou no React, ainda há muito espaço para melhorias.
Tornar os spas mais rápidos requer uma combinação de tecnologias web avançadas que funcionam em uníssono, e as suas equipas internas podem não ser capazes de implementá-los de forma eficiente. Felizmente, alguns vendedores inovadores, incluindo o Layer0, fizeram o trabalho pesado para vocês.
O Layer0 combina a renderização do lado do servidor com pré-busca preditiva avançada e pré-armazenamento em cache na borda. Como os dados dinâmicos são armazenados em cache pelo menos 95% do tempo, a sua base de dados está protegida das solicitações extra criadas por pré-busca. Layer0 CDN-as-JavaScript service worker busca inteligentemente suas páginas dinâmicas antes que o visitante toque em um link. Desta forma, você pode fornecer carregamentos de páginas em aplicações de uma única página, oferecendo aos seus visitantes uma experiência perfeita desde o desembarque até o check-out.
