Não há maneira mais rápida de desacelerar um site (trocadilho intencional) do que usar um monte de código JavaScript nele. Ao usar JavaScript, você deve pagar por isso com o desempenho de projetos não menos que quatro vezes. Veja como o código JavaScript do site carrega os sistemas dos usuários:
- Baixando um arquivo pela rede.
- Analisando e compilando o código-fonte descompactado após o download.
- Execução do código JavaScript.
- Consumo de memória.
Esta combinação resulta .
E incluímos cada vez mais código JS em nossos projetos. À medida que as organizações avançam em direção a sites baseados em estruturas e bibliotecas como React, Vue e outras, estamos tornando a funcionalidade principal dos sites fortemente dependente do JavaScript.
Já vi muitos sites muito pesados usando frameworks JavaScript. Mas minha visão da questão é muito tendenciosa. O fato é que as empresas com as quais trabalho recorrem a mim justamente por se depararem com problemas complexos na área de atuação do site. Como resultado, fiquei curioso sobre o quão comum é esse problema e sobre que tipo de "punições" pagamos quando escolhemos um ou outro framework como base para um determinado site.
O projeto me ajudou a descobrir isso. .
Dados
O projeto HTTP Archive rastreia um total de 4308655 links para sites de desktop regulares e 5484239 links para sites móveis. Entre as muitas métricas associadas a esses links está uma lista de tecnologias encontradas nos respectivos sites. Isso significa que podemos experimentar milhares de sites que usam várias estruturas e bibliotecas e saber quanto código eles enviam aos clientes e quanta carga esse código cria nos sistemas dos usuários.
Coletei dados de março de 2020, que foram os dados mais recentes aos quais tive acesso.
Decidi comparar dados agregados do HTTP Archive em todos os sites com dados de sites encontrados usando React, Vue e Angular, embora também tenha considerado o uso de outro material de origem.
Para torná-lo mais interessante, também adicionei sites que usam jQuery ao conjunto de dados de origem. Esta biblioteca ainda é muito popular. Ele também apresenta uma abordagem diferente para o desenvolvimento da Web do que o modelo de aplicativo de página única (SPA) oferecido por React, Vue e Angular.
Links no Arquivo HTTP representando sites que usam tecnologias de interesse
Estrutura ou biblioteca
Links para sites móveis
Links para sites regulares
jQuery
4615474
3714643
Reagir
489827
241023
vista
85649
43691
Angular
19423
18088
Esperanças e sonhos
Antes de passarmos à análise de dados, quero falar sobre o que gostaria de esperar.
Acredito que, em um mundo ideal, os frameworks deveriam ir além de atender às necessidades dos desenvolvedores e fornecer algum benefício específico ao usuário médio que trabalha com nossos sites. O desempenho é apenas um desses benefícios. É aqui que a acessibilidade e a segurança entram em jogo. Mas isso é apenas o mais importante.
Portanto, em um mundo ideal, algum tipo de estrutura deve facilitar a criação de um site de alto desempenho. Isso deve ser feito pelo fato de o framework dar ao desenvolvedor uma base decente para construir um projeto, ou pelo fato de impor restrições ao desenvolvimento, apresentar requisitos que complicam o desenvolvimento de algo que se transforma para ser lento.
Os melhores frameworks devem fazer as duas coisas: dar uma boa base e impor restrições ao trabalho, permitindo que você alcance um resultado decente.
Analisar os valores medianos dos dados não nos dará as informações de que precisamos. E, de fato, essa abordagem deixa fora de nossa atenção . Em vez disso, deduzi porcentagens dos dados que tinha. Estes são 10, 25, 50 (mediana), 75, 90 percentis.
Estou especialmente interessado nos percentis 10 e 90. O 10º percentil 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 determinada estrutura chegam a esse nível ou superior. O percentil 90, por outro lado, é o outro lado da moeda - ele nos mostra como as coisas podem ficar ruins. O 90º percentil são os sites que ficam atrás - aqueles 10% inferiores dos sites que têm mais código JS ou o tempo mais longo para processar seu código no thread principal.
Volumes de código JavaScript
Para começar, faz sentido analisar o tamanho do código JavaScript transmitido por diferentes sites na rede.
A quantidade de código JavaScript (Kb) transferida para dispositivos móveis
percentis
10
25
50
75
90
Todos os sites
93.4
196.6
413.5
746.8
1201.6
sites jQuery
110.3
219.8
430.4
748.6
1162.3
sites Vue
244.7
409.3
692.1
1065.5
1570.7
sites angulares
445.1
675.6
1066.4
1761.5
2893.2
Sites de reação
345.8
441.6
690.3
1238.5
1893.6
Quantidade de código JavaScript enviado para dispositivos móveis
Quantidade de código JavaScript (Kb) transferido para dispositivos desktop
percentis
10
25
50
75
90
Todos os sites
105.5
226.6
450.4
808.8
1267.3
sites jQuery
121.7
242.2
458.3
803.4
1235.3
sites Vue
248.0
420.1
718.0
1122.5
1643.1
sites angulares
468.8
716.9
1144.2
1930.0
3283.1
Sites de reação
308.6
469.0
841.9
1472.2
2197.8
Quantidade de código JavaScript enviado para dispositivos desktop
Se falarmos apenas sobre o tamanho do código JS que os sites enviam para os dispositivos, tudo parecerá o esperado. Ou seja, se um dos frameworks for usado, 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 de uma estrutura JavaScript a base de um site e esperar que o volume do código JS do projeto seja muito baixo.
O que é notável sobre esses dados é que alguns frameworks e bibliotecas podem ser considerados um melhor ponto de partida para um projeto do que outros. Sites com jQuery têm a melhor aparência. Nas versões de sites para desktop, eles contêm 15% a mais de JavaScript do que todos os sites e, nos dispositivos móveis, eles contêm 18% a mais. (Reconhecidamente, há alguma corrupção de dados aqui. O fato é que o jQuery está presente em muitos sites, portanto, é natural que esses sites estejam mais associados do que outros ao número total de sites. No entanto, isso não afeta o quão bruto os dados são produzidos para cada estrutura.)
Embora o aumento de 15-18% no volume de código seja um número notável, comparando-o com outros frameworks e bibliotecas, pode-se concluir que o "imposto" cobrado pelo jQuery é muito baixo. Sites angulares no 10º percentil enviam 344% mais dados para desktop do que todos os sites e 377% mais para dispositivos móveis. Os sites React são os próximos mais pesados, enviando 193% mais código para desktop do que todos os sites e 270% mais para dispositivos móveis.
Anteriormente, mencionei que, embora usar uma estrutura signifique que uma certa quantidade de código será incluída no projeto, logo no início do trabalho, espero que a estrutura seja capaz de limitar de alguma forma o desenvolvedor. Em particular, estamos falando sobre limitar a quantidade máxima de código.
Curiosamente, os sites jQuery seguem essa ideia. Embora sejam um pouco mais pesados do que todos os sites no 10º percentil (em 15-18%), eles são um pouco mais leves no 90º percentil, com cerca de 3% em computadores e dispositivos móveis. Isso não quer dizer que seja um benefício muito significativo, mas pode-se dizer que os sites jQuery, pelo menos, não possuem tamanhos de código JavaScript enormes, mesmo em suas versões maiores.
Mas o mesmo não pode ser dito sobre outros frameworks.
Assim como no caso do 10º percentil, no 90º percentil os sites no Angular e React diferem de outros sites, mas eles diferem, infelizmente, para pior.
No percentil 90, os sites Angular enviam 141% mais dados para dispositivos móveis do que todos os sites e 159% mais para desktop. Os sites React enviam 73% mais para desktop do que todos os sites e 58% mais para dispositivos móveis. O tamanho do código dos sites React no 90º percentil é 2197.8 KB. Isso significa que esses sites enviam 322.9 KB a mais de dados para dispositivos móveis do que seus concorrentes mais próximos baseados em Vue. A lacuna entre sites de desktop baseados em Angular e React e outros sites é ainda maior. Por exemplo, sites React de desktop enviam 554.7 KB a mais de código JS para dispositivos do que sites Vue equivalentes.
Tempo gasto para processar o código JavaScript no thread principal
Os dados acima indicam claramente que os sites que usam as estruturas e bibliotecas em estudo contêm grandes quantidades de código JavaScript. Mas é claro, isso é apenas uma parte da nossa equação.
Depois que o código JavaScript chega ao navegador, ele precisa ser colocado em um estado funcional. Especialmente muitos problemas são causados por essas ações que devem ser executadas com o código no thread principal do navegador. O thread principal é responsável por processar as ações do usuário, calcular estilos, construir e exibir o layout da página. Se você sobrecarregar o thread principal com tarefas JavaScript, ele não terá a oportunidade de concluir o restante das tarefas a tempo. Isso leva a atrasos e "freios" no trabalho das páginas.
O banco de dados HTTP Archive possui informações sobre quanto tempo leva para processar o código JavaScript no thread 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 do processador (em milissegundos) relacionado ao processamento de scripts em dispositivos móveis
percentis
10
25
50
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
sites Vue
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 do processador relacionado ao processamento de scripts em dispositivos móveis
Tempo do processador (em milissegundos) relacionado ao processamento de script em dispositivos de desktop
percentis
10
25
50
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
sites Vue
350.4
650.8
1280.7
2388.5
4010.8
sites angulares
482.2
777.9
1365.5
2400.6
4171.8
Sites de reação
508.0
1045.6
2121.1
4235.1
7444.3
Tempo do processador relacionado ao processamento de script em dispositivos de desktop
Aqui você pode ver algo muito familiar.
Para começar, os sites com jQuery gastam significativamente menos em processamento de JavaScript no thread principal do que outros sites. No percentil 10, em comparação com todos os sites, os sites jQuery no celular gastam 61% mais tempo processando código JS no thread principal. No caso de sites jQuery para desktop, o tempo de processamento aumenta em 37%. No percentil 90, os sites jQuery pontuam muito perto das pontuações agregadas. Especificamente, os sites jQuery em dispositivos móveis gastam 1.3% menos tempo no thread principal do que todos os sites e 0.7% menos tempo em dispositivos desktop.
Do outro lado da nossa classificação estão as estruturas caracterizadas pela maior carga na rosca principal. Isso é, novamente, Angular e React. A única diferença entre os dois é que, enquanto os sites Angular enviam mais código para os navegadores do que os sites React, os sites Angular levam menos tempo de CPU para processar o código. Muito menos.
No percentil 10, os sites Angular de desktop gastam 230% mais tempo no código JS de processamento de thread principal do que todos os sites. Para sites móveis, esse número é de 313%. Os sites React são os de pior desempenho. No desktop, eles gastam 248% mais tempo processando código do que todos os sites e 658% a mais em dispositivos móveis. 658% não é um erro de digitação. No percentil 10, os sites React gastam 2.7 segundos do tempo do thread principal processando seu código.
O percentil 90, quando comparado a esses números enormes, parece pelo menos um pouco melhor. Em comparação com todos os sites, os projetos Angular gastam 29% mais tempo em dispositivos de desktop no thread principal e 27% mais tempo em dispositivos móveis. No caso dos sites React, os mesmos números parecem 130% e 98%, respectivamente.
Desvios percentuais para o 90º percentil parecem melhores do que valores semelhantes para o 10º percentil. Mas aqui vale lembrar que os números que indicam a hora parecem bastante assustadores. Digamos 20.8 segundos no thread móvel principal para um site criado com o React. (Acho que a história do que realmente acontece durante esse período merece um artigo separado).
Há uma complicação potencial aqui (obrigado por chamar minha atenção para esse recurso e por considerar cuidadosamente os dados desse ponto de vista). O fato é que muitos sites usam várias ferramentas de front-end. Em particular, vi muitos sites usando jQuery junto com React ou Vue, já que esses sites estão migrando do jQuery para outras estruturas ou bibliotecas. Como resultado, acessei o banco de dados novamente, desta vez selecionando apenas os links que correspondem a sites que usam apenas React, jQuery, Angular ou Vue, mas não qualquer combinação deles. Aqui está o que eu tenho.
Tempo do processador (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
50
75
90
Sites que usam apenas jQuery
542.9
1062.2
2297.4
4769.7
8718.2
Sites que usam apenas Vue
944.0
1716.3
3194.7
5959.6
9843.8
Sites que usam apenas Angular
1328.9
2151.9
3695.3
6629.3
11607.7
Sites que usam apenas React
2443.2
4620.5
10061.4
17074.3
24956.3
Tempo do processador 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
Primeiro, algo que não é surpreendente: quando um site usa apenas uma estrutura ou uma biblioteca, o desempenho desse site melhora com mais frequência do que nunca. Cada instrumento tem melhor desempenho nos percentis 10 e 25. Faz sentido. Um site feito com uma estrutura deve ter um desempenho melhor do que um site feito com duas ou mais estruturas ou bibliotecas.
Na verdade, o desempenho de cada ferramenta de front-end estudada parece melhor em todos os casos, exceto por uma curiosa exceção. O que me surpreendeu foi que no percentil 50 e acima, os sites que usam o React têm um desempenho pior quando o React é a única biblioteca que eles usam. Esse, aliás, foi o motivo pelo qual apresento esses dados aqui.
Isso é um pouco estranho, mas ainda tentarei buscar uma explicação para essa estranheza.
Se um projeto usa React e jQuery, esse projeto provavelmente está no meio da transição de jQuery para React. Talvez tenha uma base de código onde essas bibliotecas são misturadas. Como já vimos que os sites jQuery gastam menos tempo no encadeamento principal do que os sites React, isso pode nos dizer que a implementação de algumas funcionalidades no jQuery ajuda o site a ter um desempenho um pouco melhor.
Mas conforme o projeto faz a transição do jQuery para o React e depende mais do React, as coisas estão mudando. Se o site for realmente de alta qualidade e os desenvolvedores do site usarem o React com cuidado, tudo ficará bem com esse site. Mas para o site médio do React, o uso extensivo do React significa que o thread principal está sob carga pesada.
A diferença entre dispositivos móveis e desktop
Outro ponto de vista a partir do qual olhei para os dados pesquisados foi estudar o tamanho da lacuna entre trabalhar com sites em dispositivos móveis e desktop. Se falamos em comparar os volumes de código JavaScript, essa comparação não revela nada terrível. Claro, seria bom ver quantidades menores de código para download, mas não há muita diferença na quantidade de código móvel e de desktop.
Mas se analisarmos o tempo necessário para processar o código, percebe-se uma lacuna muito grande entre dispositivos móveis e desktop.
Aumento no tempo (porcentagem) relacionado ao processamento de scripts em dispositivos móveis em comparação com o desktop
percentis
10
25
50
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
sites Vue
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 de se esperar alguma diferença na velocidade de processamento de código entre um telefone e um laptop, números tão grandes me dizem que as estruturas modernas não são suficientemente direcionadas a dispositivos de baixa potência e que estão se esforçando para fechar a lacuna que descobriram. Mesmo no 10º percentil, os sites React gastam 431.5% mais tempo no thread principal móvel do que no thread principal desktop. jQuery tem a menor lacuna, mas mesmo aqui o valor correspondente é de 188.2%. Quando os desenvolvedores de sites fazem seus projetos de forma que seu processamento requer mais tempo do processador (e isso acontece, e só piora com o tempo), os proprietários de dispositivos de baixa potência têm que pagar por isso.
Resultados de
Boas estruturas devem fornecer aos desenvolvedores uma boa base para criar 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 presumivelmente não a seus ).
Vale a pena notar que apenas porque os sites React ou Angular gastam mais tempo de CPU preparando o código do que outros, não significa necessariamente que os sites React consomem mais CPU do que os sites Vue durante a execução. Na verdade, os dados que analisamos dizem muito pouco sobre o desempenho operacional de frameworks e bibliotecas. Eles falam mais sobre as abordagens de desenvolvimento que, conscientemente ou não, esses frameworks podem impulsionar os programadores. Estamos falando de documentação para frameworks, de seu ecossistema, de técnicas comuns de desenvolvimento.
Vale também mencionar algo que não analisamos aqui, qual seja, quanto tempo o dispositivo gasta executando o código JavaScript ao navegar entre as páginas do site. O argumento a favor do SPA é que uma vez que o aplicativo de página única é 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 essa questão.
O que está claro é que, se você estiver usando uma estrutura ou biblioteca para criar um site, estará fazendo um compromisso em termos de carregar inicialmente o projeto e prepará-lo para uso. Isso se aplica até mesmo aos cenários mais positivos.
É perfeitamente possível fazer algumas concessões em situações apropriadas, mas é importante que os desenvolvedores façam tais concessões conscientemente.
Mas também temos motivos para otimismo. Estou animado para ver como os desenvolvedores do Chrome estão trabalhando de perto com os desenvolvedores de 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 criam problemas de desempenho com a mesma frequência com que os resolvem. E leva tempo para corrigir bugs. Assim como não devemos esperar resolverá todos os problemas de desempenho, você não deve esperar isso de novas versões de nossos frameworks favoritos.
Se você quiser usar uma das ferramentas de front-end discutidas neste artigo, isso significa que você terá que fazer um esforço extra para não prejudicar o desempenho do seu projeto nesse meio tempo. Aqui estão algumas considerações a serem consideradas antes de iniciar uma nova estrutura:
- Teste-se com bom senso. Você realmente precisa usar o framework escolhido? O JavaScript puro hoje é capaz de muito.
- Existe uma alternativa mais leve para a estrutura escolhida (como Preact, Svelte ou outra) que pode fornecer 90% dos recursos dessa estrutura?
- Se você já estiver usando uma estrutura, considere se há algo que ofereça opções padrão melhores e mais conservadoras (por exemplo, Nuxt.js em vez de Vue, Next.js em vez de React e assim por diante).
- Qual será o seu Desempenho do JavaScript?
- Como você pode um processo de desenvolvimento para tornar mais difícil injetar mais código JavaScript em um projeto do que o absolutamente necessário?
- Se você estiver usando uma estrutura para facilitar o desenvolvimento, considere enviar código de estrutura para clientes. Talvez você possa resolver todos os problemas no servidor?
Normalmente, vale a pena examinar essas ideias, independentemente do que exatamente você escolheu para o desenvolvimento front-end. Mas eles são especialmente importantes quando você está trabalhando em um projeto que carece de desempenho desde o início.
Caros leitores! Como você vê o framework JavaScript ideal?
Fonte: habr.com