🥓 💆🏼 🤦🏻 JavaScript Preço 2018 🥁 🌇 👩🏿‍✈️

A experiência do usuário com sites interativos pode incluir a etapa de enviá-los código JavaScript. Muitas vezes - muito desse código. Se o site usa muito JavaScript, isso afeta especialmente os usuários móveis. Por exemplo, você já esteve em páginas da Web para dispositivos móveis que parecem estar prontas para ir, mas não respondem a cliques em links ou a tentativas de rolar a página?

O código JavaScript que entra nos navegadores móveis ainda é o recurso mais caro, pois, de várias maneiras, pode atrasar a transição das páginas para um estado no qual você pode interagir com elas. Que tipo de carga nos sistemas é hoje o JavaScript? Como analisar sites? Como acelerar o carregamento e o processamento pelos navegadores de páginas da web interativas? Eddie Osmani, cuja tradução estamos publicando hoje, decidiu encontrar respostas para essas e muitas outras perguntas que surgem com aqueles que usam JavaScript para desenvolver sites em 2018.

Disposições Gerais

Dê uma olhada neste relatório, que demonstra o tempo necessário para processar o código JavaScript da CNN para vários dispositivos. Ele é construído com base nas medições realizadas por meio do projeto WebPageTest.org ( aqui está uma tabela com os dados de origem deste relatório, também há dados no site do Walmart).

O tempo necessário para processar o código JS do cnn.com para vários dispositivos

Como você pode ver, um telefone high-end (iPhone 8) lida com a tarefa de processar o código JS em cerca de 4 segundos. Um telefone de gama média (Moto G4) precisa de cerca de 13 segundos para resolver o mesmo problema. Um orçamento, embora um dispositivo moderno, como o Alcatel 1X, leve cerca de 36 segundos.

Hoje, falaremos sobre as estratégias que os desenvolvedores da Web podem aplicar para criar sites convenientes e modernos, por um lado, e por outro lado, para garantir o carregamento, o processamento e o funcionamento efetivos do componente JavaScript desses sites. Aqui estão, resumidamente, os principais pontos de nossa conversa, que, a propósito, se baseiam em meu discurso recente :

Para que os projetos da Web funcionem rapidamente, você só precisa fazer o download do código JavaScript necessário para a página atual. O uso de tecnologias de divisão de código permite que você organize o carregamento o mais rápido possível do que o usuário definitivamente precisará e aplique a técnica de carregamento lento para outros fragmentos de código. Graças a essa abordagem, a página tem a chance de carregar mais rapidamente do que em outros casos e atingir rapidamente um estado em que pode ser interagida. Se você usa sistemas que, por padrão, usam separação de código baseada em rota, isso faz a diferença.
Respeite os limites estabelecidos para os parâmetros do projeto, o chamado "orçamento de desempenho", e aprenda a cumpri-los. Portanto, por exemplo, espere que o tamanho do código JS minificado e compactado necessário para páginas projetadas para dispositivos móveis não exceda 170 Kb . Ao converter esses materiais para sua forma normal, são obtidos aproximadamente 700 Kb de código. Tais restrições são de grande importância para o sucesso do projeto, no entanto, somente elas sozinhas não conseguem milagrosamente tornar rápido um site lento. A cultura da equipe , a estrutura e os meios de monitorar a implementação das regras desempenham um papel aqui. O desenvolvimento do projeto sem orçamento contribui para um declínio gradual da produtividade e pode levar a conseqüências desagradáveis.
Aprenda a auditar pacotes configuráveis JavaScript (assemblies) e reduza seu tamanho. É muito provável que os clientes tenham que baixar versões completas das bibliotecas , enquanto apenas partes delas são necessárias para o projeto funcionar. Talvez o projeto inclua polyfills para navegadores que eles não precisam e a duplicação de código não seja excluída.
Cada interação do usuário com o site é o início de um novo período de espera, após o qual será possível trabalhar com o site (isso é chamado de “tempo para interatividade”, TTI, Tempo para interativo). A otimização vale a pena considerar neste contexto. O tamanho do código transmitido é muito importante para redes móveis lentas, e o tempo necessário para analisar o código JavaScript é para dispositivos com recursos de computação modestos.
Se o uso de JavaScript do lado do cliente não melhorar sua experiência do usuário, considere usar JS nessa situação. Talvez, nesse caso, seja mais rápido renderizar o código HTML no servidor. Pense em limitar o uso de estruturas da web do cliente, em usá-las apenas para formar páginas que absolutamente não podem ficar sem ela. Tanto a renderização no servidor quanto a renderização no cliente, se essas tecnologias forem usadas incorretamente, tornam-se uma fonte de problemas sérios.

Projetos web modernos e o problema do uso excessivo de JavaScript

Quando um usuário acessa seu site, você provavelmente está enviando a ele um monte de arquivos, muitos dos quais são scripts. Do ponto de vista do navegador da Web, é algo parecido com isto.

É assim que um navegador é, cheio de arquivos

Não importa o quanto eu goste do JavaScript, não posso deixar de admitir que é sempre a parte mais cara e mais difícil do site para o processamento dos navegadores. Na verdade, eu gostaria de falar sobre por que o JavaScript pode se tornar o principal problema do site.

JavaScript é a parte mais difícil do site

De acordo com o relatório do JavaScript Archive de julho sobre o uso do JavaScript, a página da Web média atualmente usa aproximadamente 350 KB de código JavaScript compactado e compactado. Esse código é descompactado em algo como um script de 1 MB que o navegador precisa processar. Para que um usuário móvel possa interagir com essa página, ele precisará esperar mais de 14 segundos .

Uma página média contendo 350 KB de código JS compactado se torna interativa em um dispositivo móvel em cerca de 15 segundos

Se você não sabe exatamente como seus pacotes JavaScript afetam por quanto tempo os usuários precisam esperar até que eles possam interagir com o site, consulte a ferramenta Farol .

O tempo de download dos dados em redes móveis e seu processamento em um processador não rápido contribuem seriamente enquanto aguarda a página estar preparada para o trabalho em dispositivos móveis.

Vamos analisar o estado das coisas no campo das redes móveis, observando os dados do OpenSignal . A figura a seguir, à esquerda, mostra a disponibilidade de redes 4G no mundo (quanto mais escura a cor com a qual o território do país é pintado - quanto maior a disponibilidade), as velocidades de transferência de dados são mostradas à direita (novamente - quanto mais escura, maior a velocidade). Os países cujo território está esmaecido não são incluídos no estudo. Vale ressaltar que nas áreas rurais, mesmo nos EUA, a velocidade da transferência de dados móveis pode ser 20% mais lenta que nas cidades.

Disponibilidade de rede 4G e taxa de dados

Dissemos acima que leva um certo tempo para baixar e analisar 350 KB de código JS compactado e compactado. No entanto, se você olhar para sites populares, eles enviam muito mais código aos usuários. Os dados mostrados na figura abaixo são retirados daqui . Eles são do tamanho dos pacotes JavaScript descompactados de vários recursos conhecidos da Web, como o Google Sheets, cujo código JS descompactado nas plataformas de desktop ocupa 5,8 MB.

Tamanhos de montagem JavaScript descompactados para vários recursos

Como você pode ver, nas plataformas desktop e móvel, os navegadores às vezes precisam processar vários megabytes de código JS para trabalhar com vários sites. A principal questão aqui é - você pode usar volumes tão grandes de JavaScript?

JavaScript não é grátis

De acordo com Alex Russell, sites que exigem quantidades muito grandes de JavaScript para funcionar simplesmente não são acessíveis a grandes camadas de usuários. Segundo as estatísticas, os usuários não esperam (e não esperam) pelo carregamento de tais recursos.

Você pode pagar?

Se você precisar enviar quantidades muito grandes de código JS para os usuários, considere usar a tecnologia de divisão de código para dividir pacotes em pequenas partes ou reduza a quantidade de código usando o algoritmo de agitação de árvore .

Os pacotes JS de sites modernos geralmente incluem o seguinte:

Estrutura da Web do cliente ou biblioteca de interface do usuário.
Uma ferramenta para gerenciar o estado de um aplicativo (por exemplo, Redux).
Polyfills (geralmente para navegadores modernos que não precisam deles).
Versões completas das bibliotecas, e não apenas as partes que são realmente usadas (por exemplo, a biblioteca Lodash inteira, Moment.js na versão com suporte para todos os padrões regionais).
Um conjunto de componentes da interface do usuário (botões, cabeçalhos, barras laterais etc.).

Tudo isso contribui para o tamanho geral do código que deve ser aceito e processado pelo navegador do usuário. Naturalmente, quanto mais código - mais tempo leva para o navegador levar a página à condição de funcionamento.

O processo de carregamento de uma página da web é semelhante ao filme em movimento no projetor, que captura três etapas principais que respondem às seguintes perguntas:

Isso está acontecendo? (Isso está acontecendo?).
Qual é a utilidade disso? (Isso é útil?).
Isso pode ser usado? (É utilizável?).

Aqui está como imaginar essas etapas, que, por sua vez, podem ser divididas em "quadros" menores, se continuarmos a analogia com o filme.

O carregamento da página é um processo. Recentemente, o foco do setor da web mudou para indicadores que refletem a experiência do usuário em trabalhar com páginas da web. Em vez de dar toda a nossa atenção aos domContentLoaded onload ou domContentLoaded , agora estamos nos perguntando se o usuário pode realmente trabalhar com a página. Se ele clicar em algo na página, haverá uma reação imediata?

Processo de carregamento de página da Web

Na etapa "Isso está acontecendo?" o site pode começar a transferir alguns dados para o navegador. Aqui, você pode fazer perguntas sobre se o acesso do navegador do usuário ao servidor foi corrigido (por exemplo, clicando em um determinado link) e se o servidor começou a gerar uma resposta.
Na etapa "Qual é a utilidade disso?" o site exibe algum texto ou outro conteúdo que permite ao usuário aprender algo útil e, em segundo lugar, é capaz de interessá-lo.
Na etapa "Isso pode ser usado?" o usuário pode iniciar uma interação completa com o site, o que pode levar a determinados eventos.

Páginas interativas e seus problemas

Acima, mencionamos um indicador como tempo para interatividade (tempo para interatividade, TTI). Vamos falar sobre isso em mais detalhes. Abaixo, no desenho animado preparado por Kevin Schaaf, você pode ver como a página, nem todos os materiais que foram baixados e processados, faz o usuário pensar que ele pode executar alguma ação, mas, de fato, devido ao fato de que o JS correspondente o código ainda não foi totalmente processado, esta ação não pode ser executada.

Usuários chateados por páginas que demoram muito para ficarem prontas

Para que uma página seja interativa, ela deve poder responder rapidamente às interações do usuário. As pequenas quantidades de código JS que alimentam as páginas ajudam a reduzir o tempo necessário para preparar as páginas para o trabalho.

Se o usuário clicar no link ou rolar a página, ele precisará ver que, em resposta a suas ações, algo acontece. Se a página não responder ao impacto dos usuários, eles não gostarão.

Aqui está um relatório gerado em um ambiente de teste usando as ferramentas Lighthouse, contendo um conjunto de indicadores (também há tempo para interatividade), focado em como os usuários percebem a página.

Relatório farol, que inclui indicadores que refletem a percepção do usuário sobre a página

Algo semelhante ao mostrado na figura anterior ocorre quando uma renderização do servidor é usada em um determinado projeto, e os resultados do que é gerado no servidor e o código JS usado para "revitalizar" a interface do usuário são transmitidos ao cliente (por exemplo, , pode conectar manipuladores de eventos e alguns mecanismos adicionais responsáveis pelo comportamento da página).

Quando o navegador estiver processando o código que conecta os eventos dos quais o usuário provavelmente precisará, provavelmente tudo isso será executado no mesmo encadeamento que processa a entrada do usuário. Este é o chamado fluxo principal.

Carregar muito código JavaScript usando o thread principal (por exemplo, isso acontece ao usar a <script> ) tem um efeito ruim no tempo de interatividade. O download do código JS que você planeja executar em trabalhadores da Web ou em cache com trabalhadores de serviço não tem um impacto negativo tão forte no TTI.

Aqui está um vídeo que mostra um exemplo de usuário que trabalha com um site com falha. Normalmente, o usuário pode marcar com segurança as caixas de seleção ou clicar nos links. No entanto, se você imitar o bloqueio do encadeamento principal, o usuário não poderá fazer nada - nem marque a caixa nem clique no link.

Tente minimizar as situações nas quais o encadeamento principal pode estar bloqueado. Aqui está o material onde você pode encontrar detalhes sobre isso.

Vemos como as equipes com as quais trabalhamos sofrem com o JavaScript que atua no TTI em muitos tipos de sites.

JavaScript é capaz de atrasar a saída de elementos visíveis no modo interativo

Essa situação pode ser um problema sério para muitas empresas. Acima estão alguns exemplos do mecanismo de pesquisa do Google. Os elementos aparecem na tela, eles parecem como se já fosse possível trabalhar com eles, mas se quantidades muito grandes de código JS são responsáveis pelo seu funcionamento, eles entram no modo de operação com algum atraso. Isso pode não agradar aos usuários. Idealmente, tudo com o qual o usuário possa interagir deve estar operacional o mais rápido possível.

TTI e dispositivos móveis

Aqui estão os TTIs do news.google.com ao usar uma conexão lenta à Internet 3G. Aqui você pode ver os dados com base nos quais este diagrama é construído. As medições são feitas por meio de WebPageTest e Lighthouse.

TTI para news.google.com

Depois de analisar esses dados, você pode ver que entre os dispositivos das categorias mais baixa e mais alta há uma lacuna grave. Portanto, o dispositivo mais poderoso no teste TTI é de cerca de 7 segundos. No mais simples - já são 55 segundos.

Aqui temos uma pergunta sobre qual deve ser o TTI. Acreditamos que você deve se esforçar para tornar as páginas mais interativas em dispositivos de médio alcance conectados a redes 3G lentas em menos de 5 segundos.

Vale a pena lutar por TTI em 5 segundos

Talvez aqui você diga que todos os seus usuários têm telefones de última geração e estão conectados a redes rápidas. No entanto, é realmente assim? Talvez alguém esteja conectado a uma rede Wi-Fi "rápida" em algum café, mas, de fato, apenas a característica de velocidade das conexões 2G ou 3G está disponível para ele. Avaliando as capacidades dos usuários, não se pode descontar a variedade de dispositivos e métodos de acesso à rede que eles usam.

Impacto do downsizing do código JS no TTI

Aqui estão alguns exemplos de como a redução do tamanho do código da página JS afetou a TTI.

O projeto Pinterest reduziu os pacotes JS de 2,5 MB para menos de 200 KB. O tempo para interatividade diminuiu de 23 segundos para 5,6 segundos. A receita da empresa cresceu 44%, o número de assinaturas aumentou 753%, o número de usuários semanais ativos da versão móvel do site cresceu 103%.
O AutoTrader reduziu o pacote JS em 56%, resultando em uma redução de TTI de cerca de 50%.
O recurso Nikkei.com reduziu o tamanho do pacote JS em 43%, o que permitiu à TTI melhorar em 14 segundos.

Esses resultados sugerem que os sites devem ser projetados para um ambiente móvel flexível e, ao mesmo tempo, tentar garantir que não estejam vinculados a grandes volumes de código JavaScript.

A criação de sites é baseada em um ambiente móvel flexível

TTI tem muito o que fazer. Por exemplo, o uso de um dispositivo móvel para visualizar um site cujas capacidades de rede são limitadas por um determinado plano tarifário pode afetar esse indicador, a TTI pode ser afetada pelo fato de o usuário trabalhar através de um ponto de acesso Wi-Fi público, não particularmente rápido, ou pelo fato de o usuário móvel está em constante movimento, perdendo periodicamente a rede.

Quando alguém está trabalhando com seu site em uma situação semelhante à que acabamos de descrever e, ao mesmo tempo, para garantir que o recurso esteja funcionando, é necessário baixar e processar uma grande quantidade de código JS. Para o usuário, a sessão de interação com o site pode ficar vazia tela. Ou, se o site ainda exibir pelo menos algo na tela, pode demorar muito tempo até que você possa trabalhar com ele. Idealmente, esses problemas podem ser atenuados simplesmente reduzindo o tamanho do código JS necessário para o funcionamento dos sites.

Por que o JavaScript é tão caro?

Para entender por que a preparação do código JavaScript para páginas pode criar uma enorme carga no sistema, vamos falar sobre o que acontece quando o servidor envia dados para o navegador.

Portanto, tudo começa com o fato de o usuário digitar a URL do site para o qual deseja acessar a barra de endereços do navegador.

Tudo começa com a inserção de um URL na barra de endereços do navegador.

A solicitação é então enviada ao servidor, que retorna a marcação HTML para o navegador. O navegador analisa essa marcação e encontra os recursos necessários para formar a página: CSS, JavaScript, imagens. Então o navegador precisa solicitar tudo isso ao servidor e processá-lo.
É nesse cenário que tudo acontece, por exemplo, ao trabalhar com o Google Chrome.

A dificuldade de todo esse processo é que o JavaScript acaba sendo o gargalo de todo o sistema. Idealmente, gostaríamos que o navegador exibisse rapidamente uma representação gráfica da página, após a qual seria possível interagir com ela. Mas, se o JavaScript é um gargalo, depois de exibir algo na tela, o usuário é forçado a examinar impotente com o que não pode trabalhar.

Nosso objetivo é garantir que o JavaScript deixe de ser um gargalo nos cenários modernos de interação do usuário com os recursos da Web.

Como acelerar o trabalho com JavaScript?

A tarefa de aceleração do JavaScript pode ser dividida em várias subtarefas. O tempo gasto em tudo relacionado ao JS é a soma do código de carga, análise, compilação e execução.

A velocidade do JavaScript consiste na velocidade de carregamento, análise, compilação e execução de código

Tudo isso significa que precisamos de velocidade, tanto na transferência de código quanto no seu processamento.
Se gastar muito tempo analisando e compilando o script no mecanismo JS, isso afetará a rapidez com que o usuário poderá interagir com a página.

Considere alguns dados nos processos acima. Veja mais sobre como o V8 , o mecanismo JavaScript usado no Chrome, passa o tempo processando páginas contendo scripts.

As etapas de análise e compilação levam de 10 a 30% do tempo na V8 ao carregar uma página

Os fragmentos que representam o tempo necessário para analisar o código de sites populares são destacados em laranja. Amarelo representa o tempo de compilação. Juntos, esses dois estágios levam cerca de 30% do tempo total necessário para processar o código JS da página. 30% é uma figura séria.

No Chrome 66, o V8 compila código no encadeamento em segundo plano, o que pode economizar até 20% do tempo de compilação. No entanto, a análise e a compilação ainda são operações extremamente caras, portanto você raramente vê um script grande que começa a ser executado em menos de 50 ms. após o carregamento, mesmo que seja compilado no encadeamento em segundo plano.

Qual a diferença do JavaScript para outros recursos?

Deve-se ter em mente que o tempo necessário, por exemplo, para processar um script com tamanho de 200 Kb e para processar uma imagem com o mesmo tamanho, varia significativamente. Neste exemplo, a quantidade de dados transmitidos pela rede pode ser a mesma, o tempo para a transferência também. Isso não pode ser dito sobre o custo dos recursos necessários para transformar os dados em algo com o qual você possa trabalhar.

200 KB de código JavaScript e um arquivo JPEG do mesmo tamanho são duas coisas diferentes.

A imagem JPEG precisa ser decodificada, rasterizada e exibida. E o pacote JS é necessário, se o considerarmos de maneira simplista, carregar, analisar, compilar, executar. De fato, o mecanismo precisa resolver outros problemas no processo de processamento do código JS. Em geral, deve-se ter em mente que muito mais recursos do sistema são gastos no processamento do código JavaScript, cujo tamanho, em bytes, é comparável ao tamanho de outros materiais.

Uma das razões que recentemente atraiu tanta atenção à questão da velocidade de processamento do código JavaScript pelos navegadores é a incrível expansão da tecnologia móvel.

Diversidade da Web e dispositivos móveis

Há uma grande variedade de dispositivos no mundo da web móvel. Se você tentar classificá-los de maneira simples, eles são telefones de nível básico, localizados na região de US $ 30, dispositivos de médio alcance, cujo custo não excede US $ 200, e dispositivos de ponta, cujo preço é de US $ 1000.

Vários dispositivos móveis

Se as circunstâncias derem certo, o site precisará trabalhar em dispositivos de nível médio e superior. No entanto, na realidade, nem todos os usuários possuem esses dispositivos.

Portanto, a maioria dos usuários pode trabalhar na Internet a partir de dispositivos dos níveis inicial e intermediário. Além disso, mesmo se nos restringirmos a esses dois níveis, a gama de recursos dos dispositivos incluídos neles pode ser muito grande. Por exemplo, os processadores de alguns deles funcionam a toda velocidade e, em alguns deles, sua frequência pode ser reduzida para economizar energia ou impedir o superaquecimento dos dispositivos.

Processadores comparáveis podem ter tamanhos de cache diferentes. No final, os dispositivos podem usar processadores completamente diferentes, sem mencionar outros componentes do sistema. Como resultado, o tempo necessário para processar recursos, como JavaScript, dependerá muito das características dos dispositivos usados para exibir sites. Além disso, telefones de nível básico são usados em todo o mundo, mesmo nos Estados Unidos .

Aqui estão os resultados de um estudo dos smartphones Android usados atualmente pelo newzoo . Como você pode ver, o sistema operacional Android está instalado em 75,9% dos telefones usados, enquanto espera-se que em 2018 outros 300 milhões de dispositivos sejam adicionados a eles. Muitos desses novos dispositivos serão econômicos.

Smartphones Android em 2018

Vamos ver quanto tempo leva para analisar e compilar o JavaScript em vários dispositivos modernos. Aqui estão os dados brutos.

O tempo necessário para processar (analisar e compilar) 1 Mb de código JS não compactado (por exemplo, pode ser de cerca de 200 Kb de código compactado compactado com gzip). As medições foram feitas manualmente em dispositivos reais.

No topo do diagrama estão os dispositivos de primeira classe, como o iPhone 8, que processam scripts de forma relativamente rápida. Se você descer mais, já existem dispositivos de gama média, como o Moto G4 e o muito simples Alcatel 1X. A diferença entre esses dispositivos é visível a olho nu.

Com o tempo, os telefones com Android se tornam mais baratos, mas não mais rápidos . Normalmente, os telefones baratos usam processadores fracos com um pequeno cache L2 / L3. Como resultado, se você se concentrar nos dispositivos de nível superior, poderá ignorar completamente as necessidades do usuário comum que não possui esse dispositivo.

Vamos voltar, por exemplo, com um site real, que já tocamos. As medições foram realizadas usando o WebPageTest, aqui estão os dados de origem.

O tempo necessário para processar o código JS do cnn.com para vários dispositivos

No iPhone 8 (usando o chip A11 ), o processamento leva 9 segundos mais rápido do que em um telefone de gama média. Estamos falando do fato de que no iPhone 8 o site será interativo 9 segundos antes.

Agora que, quando o WebPageTest oferece suporte ao Alcatel 1X (este telefone foi vendido nos EUA por cerca de US $ 100, foi vendido no início das vendas), podemos ver o " storyboard " do site do cnn.com carregando nos telefones de nível básico e intermediário. O Alcatel 1X carregou completamente o site usando a rede 3G em 65 segundos. Nem é "lento". Isso é simplesmente inaceitável.

Faça o download do cnn.com com Alcatel 1X, Moto G gen 1, Moto G4

Este estudo sugere que provavelmente devemos parar de pensar que todos os nossos usuários estão trabalhando em redes rápidas em dispositivos poderosos. Portanto, os aplicativos devem ser testados em redes reais e em dispositivos reais. A variedade de dispositivos móveis nos quais os sites precisam ser executados é um problema real.

Não suponha que todos os usuários usem redes rápidas e dispositivos poderosos.

Ilya Grigorik diz que a volatilidade é o que mata a experiência do usuário. Às vezes, até dispositivos rápidos podem funcionar lentamente. E redes rápidas podem ser lentas. A variabilidade pode retardar absolutamente qualquer coisa.

Embora a variabilidade possa prejudicar a experiência do usuário, o desenvolvimento de projetos da Web com base nos dispositivos não mais produtivos permite fazer com que os usuários "rápidos" e "lentos" se sintam confortáveis. Se sua equipe puder analisar as estatísticas e entender quais dispositivos são usados para trabalhar com seu site, isso lhe dará uma dica sobre qual dispositivo provavelmente vale a pena manter no escritório e usá-lo para testar o site.

Os sites de teste estão em dispositivos reais conectados a redes reais

Se a opção com seu próprio telefone de gama média não lhe agrada , o projeto WebPageTest oferece acesso a telefones Moto G4 personalizados ao escolher as configurações de teste móvel. Existem outras configurações lá.

Além disso, os testes devem ser realizados em redes nas quais usuários comuns trabalham. Anteriormente, falei sobre a importância de testar sites em telefones de nível básico e intermediário, e Brian Holt fez a seguinte excelente observação sobre esse assunto: é muito importante conhecer seu público. Ele diz que conhecer o público e otimizar o desempenho do aplicativo para as necessidades do público é crucial.

Conheça o seu público

Note-se que nem todo site deve funcionar bem em um dispositivo básico conectado a uma rede 2G.Assim, a orientação para dispositivos produtivos também é uma linha de comportamento completamente normal.

Aqui está o relatório que você pode obter seguindo o caminho Google Analytics → Público-alvo → Dispositivos móveis → Dispositivos. Ele mostra informações sobre os dispositivos e sistemas operacionais dos visitantes do site.

Relatório do Google Analytics

Muitos de seus usuários podem estar no topo do intervalo ou podem ser distribuídos por diferentes intervalos. O principal é saber quais dispositivos são usados para trabalhar com seus sites, o que permitirá que você tome decisões informadas sobre o que é importante e o que não é.

Otimização para redes lentas e dispositivos de baixa potência

JavaScript — . : , , ( gzip , Brotli , Zopfli ).

,

.

JavaScript — .

—

-, , , , .

, , JavaScript, , , , .

JavaScript-,

, JS-, , , . , — ( code splitting ).

, JS- , , , . , .

—

, , , JS-, . , .

webpack Parcel . React , Vue.js Angular .

React

React- React loadable — , API, React, .

.

 import OtherComponent from './OtherComponent'; const MyComponent = () => ( <OtherComponent/> );

 import Loadable from 'react-loadable'; const LoadableOtherComponent = Loadable({ loader: () => import('./OtherComponent'), loading: () => <div>Loading...</div>, }); const MyComponent = () => ( <LoadableOtherComponent/> );