Pular navegação
Parte I Capítulo 1

JavaScript

Introdução

JavaScript é uma linguagem de script que torna possível construir experiências interativas e complexas na web. Isso inclui responder às interações do usuário, atualizar o conteúdo dinâmico em uma página e assim por diante. Qualquer coisa que envolva como uma página da web deve se comportar quando ocorre um evento é para o que o JavaScript é usado.

A especificação da linguagem em si, junto com muitas bibliotecas e estruturas construídas pela comunidade usadas por desenvolvedores em todo o mundo, mudou e evoluiu desde que a linguagem foi criada em 1995. As implementações e os interpretadores de JavaScript também continuaram a progredir, tornando a linguagem utilizável em muitos ambientes, não apenas navegadores.

O HTTP Archive rastreia milhões de páginas todos os meses e os executa por meio de uma instância privada de WebPageTest para armazenar informações importantes de cada página. (Você pode aprender mais sobre isso em nossa metodologia). No contexto do JavaScript, o HTTP Archive fornece informações abrangentes sobre o uso da linguagem em toda a web. Este capítulo consolida e analisa muitas dessas tendências.

Quanto JavaScript usamos?

JavaScript é o recurso mais caro que enviamos aos navegadores; tendo que ser baixado, analisado, compilado e finalmente executado. Embora os navegadores tenham diminuído significativamente o tempo que leva para analisar e compilar scripts, download e execução se tornaram as etapas mais caras quando o JavaScript é processado por uma página da web.

O envio de pacotes menores de JavaScript para o navegador é a melhor maneira de reduzir o tempo de download e, por sua vez, melhorar o desempenho da página. Mas quanto JavaScript realmente usamos?

Distribuição de bytes de JavaScript por página.
Gráfico de barras mostrando 70 bytes de JavaScript usados no 10º percentil, 174 bytes no 25º percentil, 373 bytes no 50º percentil, 693 bytes no 75º percentil, e 1.093 bytes no 90º percentil
Figura 1.1. Distribuição de bytes de JavaScript por página.

A Figura 1.1 acima mostra que usamos 373 KB de JavaScript no 50º percentil, ou mediana. Em outras palavras, 50% de todos os sites fornecem mais do que essa quantidade de JavaScript para seus usuários.

Olhando para esses números, é natural imaginar se isso é muito JavaScript. No entanto, em termos de desempenho da página, o impacto depende inteiramente das conexões de rede e dos dispositivos usados. O que nos leva à nossa próxima pergunta: Quanto JavaScript enviamos quando comparamos clientes móveis e de desktop?

Distribuição de JavaScript por página por dispositivo.
Gráfico de barras mostrando 76 bytes / 65 bytes de JavaScript usados no 10º percentil em computadores e dispositivos móveis, respectivamente, 186/164 bytes para 25º percentil, 391/359 bytes para 50º percentil, 721/668 bytes para 75º percentil, e 1.131 / 1.060 bytes para o 90º percentil.
Figura 1.2. Distribuição de JavaScript por página por dispositivo.

Em cada percentil, estamos enviando um pouco mais de JavaScript para dispositivos de desktop do que para dispositivos móveis.

Tempo de processamento

Depois de ser analisado e compilado, o JavaScript obtido pelo navegador precisa ser processado (ou executado) antes de ser utilizado. Os dispositivos variam e seu poder de computação pode afetar significativamente a velocidade com que o JavaScript pode ser processado em uma página. Quais são os tempos de processamento atuais na web?

Podemos ter uma ideia analisando os tempos de processamento do thread principal para V8 em diferentes percentis:

Tempos de processamento do thread principal V8 por dispositivo.
O gráfico de barras mostrando 141 ms / 377 ms de tempo de processamento é usado no 10º percentil em computadores e dispositivos móveis, respectivamente, 352/988 ms para 25º percentil, 849 / 2.437 ms para 50º percentil, 1.850 / 5.518 ms para 75º percentil e 3.543 / 10.735 ms para o percentil 90.
Figura 1.3. Tempos de processamento do thread principal V8 por dispositivo.

A cada percentil, os tempos de processamento são mais longos para páginas da web para celular do que para desktop. A mediana do tempo total do thread principal no desktop é de 849 ms, enquanto no celular está em um número maior: 2.437 ms.

Embora esses dados mostrem quanto tempo pode levar para um dispositivo móvel processar JavaScript em comparação com uma máquina de desktop mais poderosa, os dispositivos móveis também variam em termos de capacidade de computação. O gráfico a seguir mostra como os tempos de processamento em uma única página da web podem variar significativamente dependendo da classe do dispositivo móvel.

Tempos de processamento de JavaScript para reddit.com. De O custo do JavaScript em 2019.
Gráfico de barras mostrando 3 dispositivos diferentes: no topo, um Pixel 3 tem uma pequena quantidade no thread principal e no thread de trabalho de menos de 400ms. Para um Moto G4, é aproximadamente 900 ms no thread principal e mais 300 ms no thread de trabalho. E a barra final é um Alcatel 1X 5059D com mais de 2.000 ms no thread principal e mais de 500 ms no thread de trabalho.
Figura 1.4. Tempos de processamento de JavaScript para reddit.com. De O custo do JavaScript em 2019.

Número de pedidos

Uma via que vale a pena explorar ao tentar analisar a quantidade de JavaScript usada por páginas da web é o número de solicitações enviadas. Com HTTP/2, enviar vários pedaços menores pode melhorar o carregamento da página em comparação ao envio de um pacote maior e monolítico. Se também dividirmos por cliente do dispositivo, quantas solicitações estão sendo buscadas?

Distribuição do total de solicitações de JavaScript.
O gráfico de barras mostrando 4/4 solicitações para desktop e celular, respectivamente, são usadas no 10º percentil, 10/9 no 25º percentil, 19/18 no 50º percentil, 33/32 no 75º percentil e 53/52 no 90º percentil.
Figura 1.5. Distribuição do total de solicitações de JavaScript.

Na mediana, 19 solicitações são enviadas para desktop e 18 para celular.

Conteúdo de origem vs. conteúdo de terceiros

Dos resultados analisados até o momento, foram considerados todo o tamanho e número de solicitações. Na maioria dos sites, no entanto, uma parte significativa do código JavaScript obtido e usado vem de fontes de terceiros.

JavaScript de conteúdo de terceiros pode vir de qualquer fonte externa de terceiros. Anúncios, ferramentas de análise e conteúdo de mídia social são casos de uso comuns para a obtenção de scripts de terceiros. Então, naturalmente, isso nos leva à nossa próxima pergunta: Quantas solicitações enviadas são para conteúdo de terceiros em vez de conteúdo de origem?

Distribuição de scripts de origem e de terceiros em dispositivos desktop.
O gráfico de barras que mostra a solicitação 0/1 no desktop são primárias e terceiras, respectivamente, no 10º percentil, 2/4 no 25º percentil, 6/10 no 50º percentil, 13/21 no 75º percentil e 24/38 no 90º percentil.
Figura 1.6. Distribuição de scripts de origem e de terceiros em dispositivos desktop.
Distribuição de scripts de origem e de terceiros em dispositivos móveis.
O gráfico de barras que mostra 0/1 solicitações em dispositivos móveis é para conteúdo de origem e conteúdo de terceiros, respectivamente, no 10º percentil, 2/3 no 25º percentil, 5/9 no 50º percentil, 13/20 em no 75º percentil e 23/36 no 90º percentil.
Figura 1.7. Distribuição de scripts de origem e de terceiros em dispositivos móveis.

Para clientes móveis e de desktop, mais solicitações são enviadas para conteúdo de terceiros do que conteúdo de origem em cada percentil. Se isso parece surpreendente, vamos descobrir quanto código real enviado vem de fornecedores terceirizados.

Distribuição do JavaScript total baixado em dispositivos desktop.
Gráfico de barras mostrando 0/17 bytes de JavaScript sendo baixado para dispositivos desktop para conteúdo de origem e conteúdo de terceiros, respectivamente, no 10º percentil, 11/62 no 25º percentil, 89/232 no 50º percentil, 200/525 no percentil 75 e 404/900 no percentil 90.
Figura 1.8. Distribuição do JavaScript total baixado em dispositivos desktop.
Distribuição do JavaScript total baixado em dispositivos móveis.
Gráfico de barras mostrando 0/17 bytes de JavaScript sendo baixados para dispositivos móveis para conteúdo de origem e conteúdo de terceiros, respectivamente, no 10º percentil, 6/54 no 25º percentil, 83/217 no 50º percentil, 189/477 no 75º percentil e 380/827 no 90º percentil.
Figura 1.9. Distribuição do JavaScript total baixado em dispositivos móveis.

Na média, 89% mais código de conteúdo de terceiros é usado do que código de conteúdo de origem criado pelo desenvolvedor para desktops e dispositivos móveis. Isso mostra claramente que o código de terceiros pode ser um dos maiores contribuintes para a inflação. Para obter mais informações sobre o impacto de terceiros, consulte o capítulo "Terceiros".

Compressão de recursos

No contexto das interações navegador-servidor, a compactação de recursos se refere ao código que foi modificado usando um algoritmo de compactação de dados. Os recursos podem ser compactados estaticamente com antecedência ou em tempo real, conforme solicitado pelo navegador, e para ambas as abordagens o tamanho do recurso transferido é reduzido significativamente, melhorando o desempenho da página.

Existem vários algoritmos de compactação de texto, mas apenas dois são usados ​​principalmente para compactação (e descompressão) de solicitações de rede HTTP:

  • Gzip (gzip): O formato de compactação mais amplamente usado para interações de servidor e cliente.
  • Brotli (br): Um algoritmo de compressão mais recente que visa melhorar ainda mais as taxas de compressão. 90% dos navegadores eles suportam a codificação Brotli.

Scripts compactados devem sempre ser descompactados pelo navegador depois de transferidos. Isso significa que seu conteúdo permanece o mesmo e os tempos de execução não são otimizados de forma alguma. No entanto, a compactação de recursos sempre melhorará os tempos de download, que também é um dos estágios mais caros do processamento de JavaScript. Garantir que os arquivos JavaScript sejam compactados corretamente pode ser um dos fatores mais importantes para melhorar o desempenho do site.

Quantos sites estão compactando seus recursos JavaScript?

Porcentagem de sites que compactam recursos JavaScript com gzip ou brotli.
Gráfico de barras mostrando 67% / 65% dos recursos JavaScript são compactados com gzip em desktops e dispositivos móveis, respectivamente, e 15% / 14% são compactados com Brotli.
Figura 1.10. Porcentagem de sites que compactam recursos JavaScript com gzip ou brotli.

A maioria dos sites está compactando seus recursos JavaScript. A codificação Gzip é usada em ~ 64-67% dos sites e Brotli em cerca de 14%. As taxas de compressão são semelhantes para computadores desktop e dispositivos móveis.

Para uma discussão mais aprofundada sobre compressão, veja o capítulo sobre "Compressão".

Bibliotecas e estruturas de código aberto

Código-fonte aberto ou código com licença permissiva que qualquer pessoa pode acessar, visualizar e modificar. De pequenas bibliotecas a navegadores completos, como Chromium e Firefox, o código-fonte aberto reproduz um papel crucial no mundo do desenvolvimento web. No contexto do JavaScript, os desenvolvedores contam com ferramentas de código aberto para incluir todos os tipos de funcionalidade em suas páginas da web. Independentemente de o desenvolvedor decidir usar uma pequena biblioteca de utilitários ou uma estrutura enorme que dita a arquitetura de todo o seu aplicativo, confiar em pacotes de código aberto pode tornar o desenvolvimento de recursos mais fácil e rápido. Então, quais bibliotecas de código aberto JavaScript são mais usadas?

Biblioteca Área de Trabalho Móvel
jQuery 85.03% 83.46%
jQuery Migrate 31.26% 31.68%
jQuery UI 23.60% 21.75%
Modernizr 17.80% 16.76%
FancyBox 7.04% 6.61%
Lightbox 6.02% 5.93%
Slick 5.53% 5.24%
Moment.js 4.92% 4.29%
Underscore.js 4.20% 3.82%
prettyPhoto 2.89% 3.09%
Select2 2.78% 2.48%
Lodash 2.65% 2.68%
Hammer.js 2.28% 2.70%
YUI 1.84% 1.50%
Lazy.js 1.26% 1.56%
Fingerprintjs 1.21% 1.32%
script.aculo.us 0.98% 0.85%
Polyfill 0.97% 1.00%
Flickity 0.83% 0.92%
Zepto 0.78% 1.17%
Dojo 0.70% 0.62%
Figura 1.11. Principais bibliotecas JavaScript em computadores desktop e dispositivos móveis.

jQuery, a biblioteca JavaScript mais popular já criada, é usada em 85,03% das páginas de desktop e 83,46% das páginas móveis. O advento de muitas APIs e métodos de navegador, como Fetch e querySelector, eles padronizaram muitas das funcionalidades fornecidas pela biblioteca em um formato nativo. Embora a popularidade do jQuery pareça estar diminuindo, por que ele ainda é usado na grande maioria da web?

Existem vários motivos possíveis:

  • WordPress, usado por mais de 30% dos sites, inclui jQuery por padrão.
  • Mudar de jQuery para uma biblioteca mais recente do lado do cliente pode levar algum tempo, dependendo do tamanho do aplicativo, e muitos sites podem consistir em jQuery e bibliotecas do lado do cliente mais novas.

Outras bibliotecas JavaScript comumente usadas incluem variantes jQuery (jQuery migrate, jQuery UI), Modernizr, Moment.js, Underscore.js e assim por diante.

Frameworks e bibliotecas de UI

Conforme mencionado em nossa metodologia, a biblioteca de detecção de terceiros usada no HTTP Archive (Wappalyzer) tem uma série de limitações com relação à maneira como detecta certas ferramentas. Há um problema aberto para melhorar a detecção de bibliotecas e frameworks JavaScript, que terá impactado os resultados apresentados aqui.

Nos últimos anos, o ecossistema JavaScript tem visto um aumento em bibliotecas e frameworks de código aberto para facilitar a construção de aplicativos de página única (SPAs por sua sigla em Inglês). Um aplicativo de página única é caracterizado como uma página da web que carrega uma única página HTML e usa JavaScript para modificar a página na interação do usuário em vez de procurar novas páginas no servidor. Embora essa continue sendo a premissa principal dos aplicativos de página única, diferentes abordagens de renderização de servidor ainda podem ser usadas para aprimorar a experiência de tais sites. Quantos sites usam este tipo de framework?

Os frameworks mais usados no desktop.
Gráfico de barras mostrando que 4,6% dos sites usam React, 2.0% AngularJS, 1.8% Backbone.js, 0.8% Vue.js, 0.4% Knockout.js, 0.3% Zone.js, 0.3% Angular, 0.1% AMP, 0.1% Ember.js.
Figura 1.12. Os frameworks mais usados no desktop.

Apenas um subconjunto de estruturas populares é discutido aqui, mas é importante observar que todos eles seguem uma das duas abordagens:

Embora tenha havido uma mudança em direção a um modelo baseado em componentes, muitos frameworks mais antigos que seguem o paradigma MVC (AngularJS, Backbone.js, Ember) ainda estão sendo usados em milhares de páginas. Contudo, React, Vue e Angular são frameworks baseadas em componentes mais populares (Zone.js é um pacote que agora faz parte do núcleo Angular).

Carregamento diferencial

Módulos JavaScript, ou módulos ES, são suportados em todos os principais navegadores. Os módulos fornecem a capacidade de criar scripts que você pode importar e exportar de outros módulos. Isso permite que qualquer pessoa crie seus aplicativos projetados em um padrão de módulo, importando e exportando quando necessário, sem depender de carregadores de módulo de terceiros.

Para declarar um script como um módulo, a tag do script deve ter o código type="module":

<script type="module" src="main.mjs"></script>

Quantos sites usam type="module" para scripts em suas páginas?

Porcentagem de sites usando type=module.
Gráfico de barras mostrando 0,6% dos sites de desktop usam 'type=module', e 0.8% de sites mobile.
Figura 1.13. Porcentagem de sites usando type=module.

O suporte de nível de navegador para módulos ainda é relativamente novo, e os números aqui mostram que muito poucos sites atualmente usam type="module" para seus scripts. Muitos sites ainda dependem de carregadores de módulo (2,37% de todos os sites de desktop usam RequireJS por exemplo) e bundlers (webpack por exemplo) para definir módulos em seu código-fonte.

Se estiver usando módulos nativos, é importante garantir que um script de backup apropriado seja usado para navegadores que ainda não suportam módulos. Isso pode ser feito incluindo um script adicional com um atributo nomodule.

<script nomodule src="fallback.js"></script>

Quando usados ​​juntos, os navegadores que suportam módulos irão ignorar completamente qualquer script que contenha o atributo nomodule. Por outro lado, navegadores que ainda não suportam módulos não irão baixar nenhum script com type="module". Como eles também não reconhecem nomodule, eles normalmente baixam scripts com o atributo. O uso dessa abordagem pode permitir que os desenvolvedores empurrem código moderno para navegadores modernos para carregamentos de página mais rápidos. Então, quantos sites usam nomodule para os scripts em sua página?

Porcentagem de sites usando nomodule.
Gráfico de barras mostrando 0,8% dos sites para desktop usam 'nomodule' e 0,5% dos sites para celular.
Figura 1.14. Porcentagem de sites usando nomodule.

Da mesma forma, poucos sites (0,50% - 0,80%) usam o atributo nomodule para qualquer script.

Preload e prefetch

Preload e prefetch são dicas de recursos que permitem que você ajude o navegador a determinar quais recursos precisam ser baixados.

  • Pré-carregar um recurso com <link rel="preload"> diz ao navegador para baixar este recurso o mais rápido possível. Isso é especialmente útil para recursos críticos que são descobertos no final do processo de carregamento da página (por exemplo, JavaScript localizado na parte inferior de seu HTML) e, caso contrário, são baixados por último.
  • Usar <link rel="prefetch"> diz ao navegador para tirar vantagem de qualquer tempo ocioso que ele tenha para buscar esses recursos necessários para navegações futuras.

Então, quantos sites usam diretivas de preload e prefetch?

Porcentagem de sites usando rel=preload para scripts.
Gráfico de barras mostrando 14% dos sites para desktop usam 'rel=preload' para scripts e 15% dos sites para celular.
Figura 1.15. Porcentagem de sites usando rel=preload para scripts.

Para todos os sites medidos no arquivo HTTP, 14,33% dos sites de desktop e 14,84% dos sites móveis usam <link rel="preload"> para scripts em suas páginas.

Para prefetch, temos o seguinte:

Porcentagem de sites usando rel=prefetch para scripts.
Gráfico de barras mostrando 0,08% dos sites para desktop usam 'rel=prefetch', e 0,08% dos sites para celular.
Figura 1.16. Porcentagem de sites usando rel=prefetch para scripts.

Para dispositivos móveis e desktops, 0,08% das páginas aproveitam a pré-busca para qualquer um de seus scripts.

Novas APIs

JavaScript continua a evoluir como linguagem. A cada ano uma nova versão do padrão da linguagem, conhecida como ECMAScript, é lançada com novas APIs e recursos que passam pelas etapas da proposta de se tornar parte da própria linguagem.

Com o HTTP Archive, podemos dar uma olhada em qualquer API mais recente que seja suportada (ou prestes a ser) e ver o quão difundida ela está em uso. Essas APIs já podem ser usadas em navegadores que as suportam ou com um polyfill anexado para garantir que ainda funcionem para todos os usuários.

Quantos sites usam as seguintes APIs?

Uso de novas APIs JavaScript.
Gráfico de barras mostrando 25,5% / 36,2% dos sites em computadores e dispositivos móveis usam WeakMap, 6,1% / 17,2% usam WeakSet, 3.9%/14.0% usa Intl, 3.9%/4.4% usa Proxy, 0.4%/0.4% usa Atomics, e 0.2%/0.2% usa SharedArrayBuffer.
Figura 1.17. Uso de novas APIs JavaScript.

Atomics (0.38%) e SharedArrayBuffer (0.20%) eles mal são visíveis neste gráfico, pois são usados ​​em tão poucas páginas.

É importante notar que os números aqui são aproximações e não aproveitam UseCounter para medir o uso de recursos.

Mapas de origem

Em muitos sistemas de construção, os arquivos JavaScript são minificados para minimizar seu tamanho e transpilar para recursos de linguagem mais recentes que ainda não são suportados em muitos navegadores. Além disso, os superconjuntos de linguagem como TypeScript são compilados para uma saída que pode parecer visivelmente diferente do código-fonte original. Por todos esses motivos, o código final fornecido ao navegador pode ser ilegível e difícil de decifrar.

Um mapas de origem é um arquivo adicional que acompanha um arquivo JavaScript que permite a um navegador mapear a saída final para sua fonte original. Isso pode tornar a depuração e análise de pacotes configuráveis de produção muito mais simples.

Embora úteis, existem vários motivos pelos quais muitos sites podem não querer incluir mapas de origem em seu site de produção final, como a escolha de não expor o código-fonte completo ao público. Então, quantos sites realmente incluem mapas de origem?

Porcentagem de sites usando mapas de origem.
Gráfico de barras mostrando 18% dos sites para desktop e 17% dos sites para celular usam mapas de origem.
Figura 1.18. Porcentagem de sites usando mapas de origem.

Para páginas de desktop e móveis, os resultados são quase os mesmos. 17-18% incluem um mapa de origem para pelo menos um script na página (detectado como um script primário com sourceMappingURL).

Conclusão

O ecossistema JavaScript continua mudando e evoluindo a cada ano. APIs mais recentes, motores de navegador aprimorados e bibliotecas e estruturas novas são coisas que podemos esperar que aconteçam indefinidamente. O HTTP Archive nos fornece informações valiosas sobre como os sites locais usam a linguagem.

Sem o JavaScript, a web não estaria onde está hoje, e todos os dados coletados para este artigo apenas provam isso.

Autor(a)