Os custos de linha de base dos frameworks JavaScript

Ankur Sethi Blocked Unblock Seguir Seguindo 27 de novembro de 2018

Fui mais ou menos muda nas últimas quatro semanas porque de alguma forma consegui ferir- me na garganta . Não ser capaz de falar significa sair e conhecer pessoas não é muito divertido (imagine o que isso diz sobre mim), então passei muito tempo mexendo em casa.

… E alguns dias eu faço isso

Estou curioso há algum tempo sobre o impacto que apenas a inclusão de uma estrutura JavaScript tem no desempenho de uma página da web. Comecei a pensar sobre isso alguns meses atrás, quando passei uma tarde bastante frustrante tentando melhorar o tempo de análise e avaliação de um pacote de JavaScript em um telefone barato, apenas para descobrir que a maioria do tamanho do pacote era ocupada pela React e sua bibliotecas associadas.

A verdade é que, quando você cria seu aplicativo sobre uma estrutura JavaScript moderna, você concorda em pagar um determinado custo de desempenho de linha de base que nunca pode ser otimizado . Em troca de pagar esse custo, você ganha capacidade de manutenção, eficiência do desenvolvedor e (espero) melhor desempenho durante o tempo de execução.

Bem, duh. Você não precisa de mim para lhe dizer isso.

No entanto, vamos dizer isso de forma diferente: quando você cria seu aplicativo em cima de uma estrutura JavaScript, você está fazendo as pazes com o fato de que seu aplicativo nunca carregará em menos de X segundos, por algum valor de X que varia de estrutura a estrutura .

Então, o que exatamente é esse custo inicial de desempenho, esse X? Que bom que você perguntou! Eu tive uma tarde livre e um Redmi 6A por aí, então eu corri alguns números usando React, Vue e Angular.

Metodologia

Veja como eu cheguei aos resultados de benchmark que você verá abaixo:

  1. Inicializei novos projetos React, Vue e Angular usando create-react-app, Vue CLI e Angular CLI. Não fiz alterações nos projetos gerados por essas ferramentas.
  2. Instalou bibliotecas de roteamento e gerenciamento de dados em cada projeto e garantiu que elas fizessem parte do pacote JavaScript.
  3. Implantou todos os três projetos no Netlify. Aqui estão as páginas: Reagir , Vue , Angular .
  4. Conectei um Xiaomi Redmi 6A ao meu computador e executei um perfil em todas as três páginas usando o Chrome DevTools.

As bibliotecas de roteamento e gerenciamento de dados que usei para cada projeto foram: react-router e redux para React, vue-router e vuex para Vue, e o roteador Angular e ngrx para Angular.

Quando corri meus benchmarks, estava interessado em dois números:

  1. O tempo gasto para baixar todo o JavaScript necessário para renderizar a página. Só levei em conta o tempo de download de conteúdo e ignorei a latência da rede, o tempo necessário para configurar uma conexão SSL, etc., porque não tenho tanto controle sobre esses fatores quanto o tamanho do meu pacote.
  2. Tempo gasto para analisar, compilar e avaliar o pacote JavaScript

Eu devo mencionar que o Redmi 6A é um dispositivo muito novo, e a maioria dos usuários indianos ainda está usando o antigo Redmi 5A com um processador mais lento.

Os números

Aqui estão os números, começando com os tamanhos dos pacotes para cada aplicativo.

Tamanhos de pacotes compactados para todos os três frameworks, além de suas bibliotecas de roteamento e gerenciamento de dados

O pacote JavaScript do Angular é duas vezes maior que os pacotes do Vue e React! Meu palpite é que isso acontece porque o Angular tem uma superfície de API muito maior e vem com a totalidade do RxJS. Espero que alguém mais familiarizado com o Angular possa me esclarecer aqui.

Tempo requer para analisar e avaliar o pacote JavaScript para cada estrutura

Embora sejam necessários 200 milissegundos respeitáveis para o Chrome analisar e avaliar os pacotes React e Vue, leva mais de meio segundo para avaliar o pacote Angular. Esse intervalo é grande o suficiente para os usuários perceberem e pode realmente reduzir seu orçamento de desempenho.

Tempo de download de conteúdo, sem levar em conta a latência da rede e outros fatores

Não é surpresa que os pacotes React e Vue sejam baixados em menos de um segundo, mas o pacote Angular leva mais de dois segundos para ser baixado.

O que é importante aqui não é o quão grande ou pequeno os números são, ou o desempenho relativo dos três frameworks comparados entre si. O que é digno de nota é o fato de que seu aplicativo React nunca carregará mais rápido do que cerca de 1,1 segundo em um telefone comum na Índia, não importa o quanto você o otimize . Seu aplicativo Angular sempre levará pelo menos 2,7 segundos para inicializar. Os usuários do seu aplicativo Vue precisarão esperar pelo menos 1 segundo antes de começar a usá-lo.

Isto é, quando nem sequer começamos a olhar para algumas das outras bibliotecas essenciais que a maioria dos projetos acabam usando. Isso inclui polyfills, bibliotecas de gerenciamento de formulários, bibliotecas de data e hora, bibliotecas de utilitários como lodash, bibliotecas de arrastar e soltar, bibliotecas de gráficos, etc.

Se você quiser que seu aplicativo se torne interativo nos dispositivos de seus usuários em menos de 5 segundos, você pode gastar um quinto desse tempo apenas inicializando o React?

As estruturas são más?

Eu não estou defendendo que os frameworks são maus, ou que você deve escrever todos os seus aplicativos no VanillaJS. Isso desperdiçaria muito tempo produtivo do desenvolvedor, e o resultado provavelmente acabará tendo um mau desempenho em tempo de execução. Estruturas existem por um motivo.

Mas é importante considerar seu público. Se você está construindo dispositivos com recursos restritos – o que você certamente tem, se o seu produto tiver como alvo um país como a Índia -, considere usar uma estrutura mais leve, como Riot ou Preact. Seus usuários vão agradecer.

Ou considere não usar um framework. Para sites que exibem principalmente conteúdo , é mais eficiente e econômico apenas enviar algum HTML renderizado pelo servidor. Se houver áreas do seu site que exigem interatividade, você sempre poderá usar o JavaScript para criar essas partes específicas.

No final, é importante encontrar um equilíbrio entre a produtividade do desenvolvedor e a experiência do usuário. A resposta varia de projeto para projeto, então não aceite o conselho de ninguém como evangelho.

Construa para o seu próprio público, não de outra pessoa. Execute benchmarks em dispositivos que representam cenários do mundo real e, em seguida, decida quais tecnologias fazem sentido para você.

Texto original em inglês.