⏏️ 🗿 🤸🏻 O preço das estruturas JavaScript 👨🏼‍🤝‍👨🏻 ☘️ 👎🏻

Não há maneira mais rápida de diminuir a velocidade de um site (como um trocadilho) do que usar um monte de código JavaScript nele. Ao usar JavaScript, você deve pagar por isso com o desempenho do projeto pelo menos quatro vezes. É assim que o código JavaScript do site carrega os sistemas do usuário:

Faça o download de um arquivo pela rede.
Análise e compilação de código-fonte descompactado após o carregamento.
Execução de código JavaScript.
Consumo de memória.

Essa combinação é muito cara . E estamos incluindo cada vez mais código JS em nossos projetos. À medida que as organizações avançam para sites baseados em estruturas e bibliotecas como React, Vue e outras, tornamos a principal funcionalidade dos sites muito dependente do JavaScript.

Eu vi muitos sites muito pesados usando estruturas JavaScript. Mas minha visão da questão é altamente tendenciosa. O fato é que as empresas com as quais trabalho me contatam exatamente porque encontram problemas complexos no campo do desempenho do site. Como resultado, fiquei curioso para descobrir quão amplo é esse problema e que tipo de “multas” pagamos quando selecionamos uma ou outra estrutura como base para um determinado site.

O projeto HTTP Archive me ajudou a descobrir isso .

Dados

O projeto HTTP Archive, no total, rastreia 4.308.655 links para sites regulares dedicados a dispositivos de desktop e 5.484.239 links para sites móveis. Entre os muitos indicadores associados a esses links, há uma lista de tecnologias encontradas nos respectivos sites. Isso significa que podemos criar uma amostra de milhares de sites que usam várias estruturas e bibliotecas, e descobrir quanto código eles enviam aos clientes e quanto os sistemas de usuários criam esse código.

Coletei dados para março de 2020, esses foram os dados mais recentes aos quais tive acesso.

Decidi comparar dados agregados do arquivo HTTP de todos os sites com dados de sites onde React, Vue e Angular foram detectados, embora eu estivesse pensando em usar outro material de origem.

Para torná-lo mais interessante - também adicionei sites que usam jQuery ao conjunto de dados de origem. Essa biblioteca ainda é muito popular. Ele também fornece uma abordagem de desenvolvimento de site que difere do modelo de aplicativo de página única (SPA) proposto por React, Vue e Angular.

Links no arquivo HTTP que representam sites que descobriram o uso de tecnologias de seu interesse

Estrutura ou biblioteca	Links para sites para celular	Links para sites regulares
jQuery	4615474	3714643
Reagir	489827	241023
Vue	85649	43691
Angular	19423	18088

Esperanças e sonhos

Antes de avançarmos para a análise de dados, quero falar sobre o que gostaria de esperar.

Acredito que, em um mundo ideal, as estruturas devem ir além da satisfação das necessidades dos desenvolvedores e dar certas vantagens concretas aos usuários comuns que trabalham com nossos sites. O desempenho é apenas um desses benefícios. Aqui, acessibilidade e segurança ainda vêm à mente. Mas isso é apenas o mais importante.

Portanto, em um mundo ideal, uma certa estrutura deve facilitar a criação de um site de alto desempenho. Isso deve ser feito devido ao fato de a estrutura dar ao desenvolvedor uma base decente sobre a qual construir o projeto ou pelo fato de impor restrições ao desenvolvimento, apresentar requisitos para ele que complicam o desenvolvimento de algo que acaba sendo lento.

As melhores estruturas devem fazer as duas coisas: fornecer uma boa base e impor restrições ao trabalho, permitindo obter um resultado decente.

A análise dos valores medianos dos dados não fornecerá as informações necessárias. E, de fato, essa abordagem deixa muito importante além da nossa atenção . Em vez disso, deduzi dos meus indicadores de dados expressos em percentis. São 10, 25, 50 (mediana), 75, 90 percentis.

Estou particularmente interessado nos percentis 10 e 90. O percentil 10 representa o melhor desempenho (ou pelo menos mais ou menos próximo do melhor) para uma estrutura específica. Em outras palavras, isso significa que apenas 10% dos sites que usam uma estrutura específica chegam a esse nível ou a um nível superior. O percentil 90, por outro lado, é o outro lado da moeda - mostra como as coisas podem ser ruins. O 90º percentil são os sites de tecelagem - os últimos 10% dos sites que são caracterizados pelos maiores volumes de código JS ou pelo tempo mais longo necessário para processar seu código no fluxo principal.

Volumes de código JavaScript

Para começar, faz sentido analisar o tamanho do código JavaScript transmitido por sites diferentes na rede.

A quantidade de código JavaScript (Kb) transferida para dispositivos móveis

	10	25	50	75	90
	93.4	196.6	413.5	746.8	1201.6
jQuery-	110.3	219.8	430.4	748.6	1162.3
Vue-	244.7	409.3	692.1	1065.5	1570.7
Angular-	445.1	675.6	1066.4	1761.5	2893.2
React-	345.8	441.6	690.3	1238.5	1893.6

JavaScript-,

JavaScript- (),

	10	25	50	75	90
	105.5	226.6	450.4	808.8	1267.3
jQuery-	121.7	242.2	458.3	803.4	1235.3
Vue-	248.0	420.1	718.0	1122.5	1643.1
Angular-	468.8	716.9	1144.2	1930.0	3283.1
React-	308.6	469.0	841.9	1472.2	2197.8

A quantidade de código JavaScript transmitida para dispositivos de desktop

Se falamos apenas sobre o tamanho do código JS enviado pelos sites aos dispositivos, tudo parece o que você esperaria. Ou seja, se uma das estruturas for usada, isso significa que, mesmo em uma situação ideal, o volume do código JavaScript do site aumentará. Isso não é surpreendente - você não pode fazer da estrutura JavaScript a base do site e esperar que o volume do código JS do projeto seja muito baixo.

É digno de nota nesses dados que algumas estruturas e bibliotecas podem ser consideradas um ponto de partida mais bem-sucedido do projeto do que outras. Os sites JQuery ficam melhores. Nas versões para computadores dos sites, eles contêm 15% a mais de JavaScript do que todos os sites e nas versões para celular - 18% a mais. (Devo admitir que aqui é possível observar alguma distorção dos dados. O fato é que o jQuery está presente em muitos sites, por isso é natural que esses sites estejam mais próximos do que outros do número total de sites. No entanto, isso não afeta a maneira como os dados de origem são exibidos para cada estrutura.)

Embora um aumento de 15 a 18% no volume de código seja um número notável, comparando-o com outras estruturas e bibliotecas, podemos concluir que o "imposto" cobrado pelo jQuery é muito baixo. Sites no angular do 10º percentil enviam 344% mais dados para dispositivos de desktop do que todos os sites e celulares - 377% mais. Sites de reação, os próximos em termos de gravidade, enviam 193% a mais de código para dispositivos de desktop do que todos os sites e 270% a mais de dispositivos móveis.

Eu já mencionei que, embora o uso da estrutura signifique que uma certa quantidade de código seja incluída no projeto, no início do trabalho, espero que a estrutura seja capaz de limitar de alguma forma o desenvolvedor. Em particular, estamos falando em limitar a quantidade máxima de código.

Curiosamente, os sites jQuery seguem essa idéia. Embora eles, no nível do 10º percentil, sejam um pouco mais pesados que todos os sites (15 a 18%), eles, no nível do 90º percentil, são um pouco mais leves que todos - cerca de 3% nas versões para computador e celular. Isso não pode ser considerado um benefício muito significativo, mas pode-se dizer que os sites jQuery pelo menos não diferem no tamanho enorme do código JavaScript, mesmo em suas versões maiores.

Mas o mesmo não pode ser dito sobre outras estruturas.

Assim como no 10o percentil, os sites de 90º no Angular e no React são diferentes de outros sites, mas infelizmente diferem para pior.

No percentil 90, os sites angulares enviam 141% mais dados para dispositivos móveis do que todos os sites e 159% mais para computadores. Sites de reação enviam 73% a mais para dispositivos de desktop do que todos os sites e 58% a mais para dispositivos móveis. O tamanho do código dos sites React no percentil 90 é 2197,8 Kb. Isso significa que esses sites enviam 322,9 Kb mais dados para dispositivos móveis do que seus concorrentes mais próximos com base no Vue. A diferença entre os sites de desktop baseados em Angular e React e entre outros sites é ainda maior. Por exemplo, sites React para desktop enviam 554,7 KB a mais de código JS para dispositivos do que sites similares do Vue.

Tempo gasto processando código JavaScript no thread principal

Os dados acima indicam claramente que sites que usam as estruturas e bibliotecas estudadas contêm grandes quantidades de código JavaScript. Mas, é claro, essa é apenas uma parte da nossa equação.

Após a chegada do código JavaScript no navegador, ele precisa ser trazido para um estado de funcionamento. Especialmente muitos problemas são causados por essas ações que precisam ser executadas com o código no fluxo principal do navegador. O thread principal é responsável pelo processamento de ações do usuário, pelo cálculo de estilos, pela construção e exibição do layout da página. Se você preencher o fluxo principal com assuntos de JavaScript, ele não poderá resolver outras tarefas a tempo. Isso leva a atrasos e "freios" no trabalho das páginas.

O banco de dados HTTP Archive contém informações sobre quanto tempo leva para processar o código JavaScript no encadeamento principal do mecanismo V8. Isso significa que podemos coletar esses dados e descobrir quanto tempo o thread principal leva para processar o JavaScript de vários sites.

Tempo de CPU (em milissegundos) relacionado ao processamento de script em dispositivos móveis

Percentis	10	25	cinquenta	75	90
Todos os sites	356,4	959,7	2372,1	5367,3	10485,8
sites jQuery	575,3	1147,4	2555,9	5511,0	10349,4
Vue Sites	1130,0	2087,9	4100,4	7676,1	12849,4
Sites angulares	1471,3	2380,1	4118,6	7450,8	13296,4
Sites de reação	2700.1	5090,3	9287,6	14509,6	20813,3

Tempo de CPU relacionado ao processamento de scripts em dispositivos móveis

Tempo da CPU (em milissegundos) relacionado ao processamento de scripts em dispositivos de desktop

Percentis	10	25	cinquenta	75	90
Todos os sites	146,0	351,8	831,0	1739,8	3236,8
sites jQuery	199,6	399,2	877,5	1779,9	3215.5
Vue-	350.4	650.8	1280.7	2388.5	4010.8
Angular-	482.2	777.9	1365.5	2400.6	4171.8
React-	508.0	1045.6	2121.1	4235.1	7444.3

Tempo de CPU relacionado ao processamento de scripts em dispositivos de mesa

Aqui você pode ver algo muito familiar.

Para iniciantes, os sites com jQuery gastam significativamente menos com o processamento de JavaScript no thread principal do que outros. No 10º percentil, em comparação com todos os sites, os sites jQuery em dispositivos móveis gastam 61% mais tempo processando o código JS no thread principal. No caso de sites jQuery para desktop, o tempo de processamento aumenta em 37%. No nível do percentil 90, as métricas do site jQuery estão muito próximas das métricas agregadas. Ou seja, sites jQuery em dispositivos móveis passam 1,3% menos tempo no fluxo principal do que todos os sites e em dispositivos desktop - 0,7% menos tempo.

Do outro lado da nossa classificação, existem estruturas que são caracterizadas pela maior carga na rosca principal. Isso, novamente, é Angular e Reage. A única diferença é que, enquanto sites Angular enviam quantidades maiores de código para navegadores do que sites React, leva menos tempo de CPU para processar o código de sites Angular. Muito menos.

No 10º percentil, os sites Angular para desktop gastam 230% mais tempo em thread principal processando o código JS do que todos os sites. Para sites para celular, esse número é de 313%. Sites de reação têm o pior desempenho. Em dispositivos de mesa, eles gastam 248% mais tempo no processamento de código do que em todos os sites e em dispositivos móveis - 658% a mais. 658% não é um erro de digitação. No 10º percentil, os sites React gastam 2,7 segundos do tempo do thread principal para processar o código que possuem.

O percentil 90, quando comparado com esses grandes números, parece pelo menos um pouco melhor. Projetos angulares, em comparação com todos os sites, gastam 29% mais tempo em dispositivos de desktop no segmento principal e 27% mais em dispositivos móveis. No caso dos sites React, indicadores semelhantes parecem, respectivamente, 130% e 98%.

Os desvios percentuais para o percentil 90 parecem melhores que valores semelhantes para o percentil 10. Mas aqui vale lembrar que os números que indicam a hora parecem bastante assustadores. Diga - 20,8 segundos no fluxo principal de um dispositivo móvel para um site criado no React. (Acredito que a história do que realmente acontece durante esse período é digna de um artigo separado).

Existe uma dificuldade em potencial (obrigadoJeremy por chamar minha atenção para esse recurso e por considerar cuidadosamente os dados deste ponto de vista). O fato é que muitos sites usam várias ferramentas de front-end. Particularmente, vi muitos sites que usam o jQuery junto com o React ou o Vue, pois esses sites migram do jQuery para outras estruturas ou bibliotecas. Como resultado, voltei-me novamente ao banco de dados, escolhendo desta vez apenas os links que correspondem a sites que usam apenas React, jQuery, Angular ou Vue, mas não uma combinação deles. Isso é o que eu fiz.

Tempo de CPU (em milissegundos) relacionado ao processamento de scripts em dispositivos móveis em uma situação em que os sites usam apenas uma estrutura ou apenas uma biblioteca

Percentis	10	25	cinquenta	75	90
, jQuery	542.9	1062.2	2297.4	4769.7	8718.2
, Vue	944.0	1716.3	3194.7	5959.6	9843.8
, Angular	1328.9	2151.9	3695.3	6629.3	11607.7
, React	2443.2	4620.5	10061.4	17074.3	24956.3

Tempo de CPU relacionado ao processamento de scripts em dispositivos móveis em uma situação em que apenas uma estrutura é usada em sites ou apenas uma biblioteca

Primeiro, isso não é surpreendente: quando apenas uma estrutura ou uma biblioteca é usada em um site, o desempenho desse site é mais frequentemente melhorando do que não melhorando. Os indicadores para cada instrumento têm melhor aparência nos percentis 10 e 25. Faz sentido. Um site criado usando uma estrutura deve ser mais produtivo do que um site criado usando duas ou mais estruturas ou bibliotecas.

De fato, os indicadores para cada instrumento front-end estudado parecem melhores em todos os casos, menos uma curiosa exceção. Fiquei surpreso que, no nível do percentil 50 e superior, os sites que usam o React têm desempenho pior se o React é a única biblioteca usada neles. A propósito, esse foi o motivo pelo qual trago aqui esses dados.

Isso é um pouco estranho, mas ainda tento procurar uma explicação para essa estranheza.

Se um projeto usa o React e o jQuery, é mais provável que ele esteja no meio da transição do jQuery para o React. Talvez tenha uma base de código na qual essas bibliotecas são misturadas. Como já vimos que os sites jQuery passam menos tempo no thread principal do que os sites React, isso pode nos dizer que implementar algumas funcionalidades no jQuery ajuda a melhorar um pouco o desempenho do site.

Mas, como o projeto, passando do jQuery para o React, depende mais do React, a situação muda. Se o site for realmente de alta qualidade, e os desenvolvedores do site usarem o React com prudência, então com este site tudo ficará bem. Mas para o site médio do React, o uso generalizado do React significa que o encadeamento principal está sob carga aumentada.

A diferença entre dispositivos móveis e computadores

Outro ponto de vista do qual observei os dados em estudo foi estudar a amplitude da diferença entre trabalhar com sites em dispositivos móveis e computadores. Se falamos em comparar os volumes do código JavaScript, essa comparação não revela nada de terrível. Obviamente, seria bom ver quantidades menores de código baixado, mas não há muita diferença nos volumes de código móvel e de desktop.

Mas se você analisar o tempo necessário para processar o código, notará uma lacuna muito grande entre os dispositivos móveis e os computadores.

O aumento no tempo (em porcentagem) relacionado ao processamento de scripts em dispositivos móveis em comparação com computadores

Percentis	10	25	cinquenta	75	90
Todos os sites	144,1	172,8	185,5	208,5	224,0
sites jQuery	188,2	187,4	191,3	209,6	221,9
Vue Sites	222,5	220,8	220,2	221,4	220,4
Sites angulares	205,1	206,0	201,6	210,4	218,7
Sites de reação	431,5	386,8	337,9	242,6	179,6

Embora seja esperada alguma diferença na velocidade de processamento do código entre o telefone e o laptop, números tão grandes me dizem que as estruturas modernas não estão suficientemente focadas em dispositivos de baixa energia e no desejo de fechar a lacuna. Mesmo no 10º percentil, os sites React gastam 431,5% mais tempo no fluxo principal de dispositivos móveis do que no fluxo principal de dispositivos de desktop. A menor diferença é observada no jQuery, mas mesmo aqui o indicador correspondente é 188,2%. Quando os desenvolvedores de sites fazem seus projetos para levar mais tempo do processador para processá-los (e isso acontece e com o tempo tudo fica pior), os proprietários de dispositivos de baixa energia precisam pagar por isso.

Sumário

Boas estruturas devem fornecer aos desenvolvedores uma base de alta qualidade para a criação de projetos da Web (em termos de segurança, acessibilidade, desempenho) ou devem ter restrições internas que dificultem a criação de algo que viole essas restrições.

Isso não parece se aplicar ao desempenho de projetos da web (e, aparentemente, à sua disponibilidade ).

Vale ressaltar que o fato de os sites React ou Angular gastarem mais tempo de CPU na preparação do código do que outros não significa necessariamente que os sites React no decorrer do trabalho carregam o processador mais do que os sites Vue. De fato, os dados que analisamos dizem muito pouco sobre o desempenho de estruturas e bibliotecas. Eles falam mais sobre abordagens de desenvolvimento para as quais, conscientemente ou não, essas estruturas podem impulsionar os programadores. Estamos falando de documentação para estruturas, sobre seu ecossistema, sobre técnicas comuns de desenvolvimento.

Vale ressaltar que não analisamos aqui, a saber, quanto tempo o dispositivo gasta para executar o código JavaScript ao navegar entre as páginas do site. O argumento a favor do SPA é que, assim que um aplicativo de página única for carregado no navegador, o usuário, teoricamente, poderá abrir as páginas do site mais rapidamente. Minha própria experiência me diz que isso está longe de ser um fato. Mas não temos dados para esclarecer esse problema.

É claro que, se você usar uma estrutura ou biblioteca para criar um site, comprometerá-se em termos de carregamento inicial do projeto e prepará-lo para o trabalho. Isso se aplica mesmo aos cenários mais positivos.

Em situações apropriadas, é bem possível fazer alguns compromissos, mas é importante que os desenvolvedores façam compromissos conscientes.

Mas temos motivos para ser otimistas. Sinto-me encorajado pela proximidade com que os desenvolvedores do Chrome interagem com algumas das ferramentas front-end que analisamos em um esforço para ajudar a melhorar o desempenho dessas ferramentas.

No entanto, sou uma pessoa pragmática. Novas arquiteturas sempre criam problemas de desempenho à medida que os resolvem. E leva tempo para consertar as falhas. Assim como não devemos esperar que as novas tecnologias de rede resolvam todos os problemas de desempenho, não devemos esperar isso das novas versões de nossas estruturas favoritas.

Se você deseja usar uma das ferramentas de front-end discutidas neste material, isso significa que você precisará fazer esforços adicionais para garantir que, enquanto isso, não prejudique a produtividade do seu projeto. Aqui estão algumas considerações a serem consideradas antes de começar a usar a nova estrutura:

Teste a si mesmo em termos de bom senso. Você realmente precisa usar a estrutura escolhida? Hoje, o JavaScript puro é capaz de muito.
Existe uma alternativa mais fácil à estrutura escolhida (como Preact, Svelte ou outra coisa) que pode fornecer 90% dos recursos dessa estrutura?
Se você já estiver usando algum tipo de estrutura, pense se há algo que ofereça parâmetros padrão melhores e mais conservadores (por exemplo, Nuxt.js em vez de Vue, Next.js em vez de React etc.).
Qual será o seu orçamento de desempenho em JavaScript?
Como você pode limitar o processo de desenvolvimento para complicar a implementação de uma quantidade maior de código JavaScript no projeto do que o absolutamente necessário?
Se você usar a estrutura para conveniência do desenvolvimento, considere se precisa enviar o código da estrutura para seus clientes. Talvez você possa resolver todos os problemas no servidor?

Geralmente, essas idéias valem uma olhada, independentemente do que exatamente você escolheu para desenvolver o frontend. Mas eles são especialmente importantes quando você está trabalhando em um projeto que, desde o início, carece de produtividade.

Queridos leitores! Como você vê a estrutura JavaScript perfeita?