Carregamento rápido de páginas nos telefones baratos mais simples

Os telefones referidos no título, em inglês, são chamados de "telefone comum". Eles diferem em capacidades extremamente modestas. Além disso, eles são muito acessíveis, pois custam entre US $ 20 e 25. Eles podem ser comparados com versões lite de smartphones modernos. Esses telefones permitem que centenas de milhões de pessoas de países em desenvolvimento usem recursos da web.


Jio Phone

Se o site é baseado em tecnologias destinadas a garantir alta velocidade de seu trabalho, todos se beneficiarão dele - tanto os proprietários de telefones simples e baratos quanto aqueles que assistem a páginas da Web a partir de smartphones novos e poderosos.

Visão geral da situação

Os dispositivos de que estamos falando, recurso de telefone, são baratos. Portanto, eles têm recursos de hardware bastante fracos. Portanto, eles usam CPUs lentas (por exemplo, o processador de um telefone barato pode ser 6 vezes mais lento que o processador de um smartphone de ponta). Eles instalam muito pouca RAM (pode ser algo entre 256 e 512 MB, geralmente com menos de 4 GB). O mesmo se aplica à quantidade de memória interna para armazenamento de dados, que geralmente não excede 4 GB. Esses telefones geralmente não têm telas sensíveis ao toque. Em vez disso, eles têm teclados e joysticks simples usados ​​para fins de navegação. O cdpv mostra a aparência de um telefone semelhante.

Esses telefones não podem executar o código JavaScript tão rápido quanto os smartphones avançados. É difícil para eles exibir sites que contêm grandes quantidades de dados de mídia. Portanto, ao preparar páginas que funcionem bem nesses telefones, você precisa abordar com responsabilidade a questão de preencher essas páginas.


Os 10 melhores smartphones modernos: desempenho do processador (primeiro semestre de 2019)

Acima estão os resultados de um estudo de desempenho dos 10 smartphones mais vendidos em 2019. Este estudo foi realizado usando o benchmark Geekbench 4. Aqui, na parte superior, você pode ver os resultados dos testes do popular telefone barato - Nokia 3110.

O conteúdo JavaScript das páginas é executado principalmente no modo single-core (aqui é importante lembrar que o código JS, por sua natureza, é muito mais "single-threaded" do restante do conteúdo da web), portanto, o desempenho do JavaScript está atrelado aos recursos do processador. Isso sugere que, ao pensar em projetos da Web para países em desenvolvimento, é necessário lembrar as características dos dispositivos usados ​​lá.

Este material visa solucionar o problema de desenvolver sites para dispositivos lentos. A aplicação das técnicas descritas nele permite criar sites convenientes para o uso de todos - independentemente do desempenho do telefone.

Informação geral

Talvez você se lembre disso, talvez não, mas os telefones que chamamos de feature phone eram populares até meados dos anos 2000, antes do advento e do uso generalizado de smartphones. Estes eram dispositivos compactos com um teclado em vez de uma tela de toque. Eles possuíam apenas funcionalidades básicas: fazer chamadas, enviar SMS, navegar em sites, focados no conteúdo de texto das páginas. Desde o advento dos smartphones, o número de telefones celulares simples nos países desenvolvidos diminuiu.

Nos países em desenvolvimento, nem todos podem pagar um smartphone e uma tarifa 4G ilimitada. Esse mercado foi dominado por dispositivos chamados telefones inteligentes. Eles combinam o hardware e o preço de um telefone celular simples com alguns recursos específicos para smartphones.


Telefones baratos

O mercado de telefones baratos com recursos para smartphones cresceu significativamente desde 2017. Espera-se que em 2019 sejam vendidos em todo o mundo cerca de 400 milhões de dispositivos.

O crescimento do mercado de celulares de baixo custo foi facilitado pelo fato de a Nokia reviver seus antigos modelos populares, como o Nokia 3110 e 8110 ( aqui está um guia para depurar páginas da Web no Nokia 8110 com KaiOS). Na Índia, os telefones Reliance Jio oferecem a seus usuários um acesso móvel barato e moderno a recursos da web. Jio contribuiu para o desenvolvimento do KaiOS , um sistema operacional baseado em Linux projetado para telefones simples e acessíveis.

O crescente mercado de telefones simples criou a necessidade de sites que possam funcionar efetivamente nesses dispositivos. Para desenvolver esses sites, você precisa considerar algumas restrições.


Vários projetos projetados para telefones de baixo custo

A imagem anterior mostra as telas dos projetos Google Images Lite e Facebook mBasic. Esses projetos são carregados rapidamente em telefones simples; eles dependem dos recursos de script do cliente ao mínimo. Outra captura de tela é o jogo Proxx , que, embora fortemente dependente de scripts, usa uma separação de código agressiva para acelerar o carregamento.

Limitações de telefones baratos

Os usuários de telefone low-end nos países em desenvolvimento são limitados por três fatores:

• Um pequeno número de dispositivos baratos de alta qualidade.
• Inacessibilidade de redes de comunicação de alta velocidade.
• Alto custo de transferência de dados.

Essas limitações devem ser lembradas para quem deseja sintonizar a percepção do desenvolvimento da web através do "prisma do telefone de recurso". Se falarmos com mais detalhes sobre as limitações desses telefones e o ambiente em que são usados, obteremos o seguinte:

1. Hardware Os telefones simples geralmente têm um processador de núcleo único ou dual mais lento (algo como 1,1 GHz) e menos de 512 MB de RAM. Para entender como isso limita os recursos dos dispositivos, compare isso com um processador de vários núcleos e um iPhone XS de 4 GB de RAM.
2. Transferência de dados. Os planos móveis estão ficando mais baratos, mas em regiões onde os telefones de baixo custo podem ser distribuídos, os planos ainda são severamente limitados. Isso significa que, ao desenvolver páginas projetadas para telefones comuns, você deve reduzir ao máximo a quantidade de dados em que essas páginas consistem. Isso permitirá que os sites carreguem mais rapidamente e, em segundo lugar, reduzam o custo de visitar esses sites para os usuários.
3. Tamanho de tela limitado. O tamanho da tela de um telefone barato geralmente é muito menor que o tamanho da tela de um smartphone. Estamos falando de uma tela com uma diagonal de cerca de 2,4 polegadas. Essas telas permitem exibir apenas um número muito limitado de elementos. Isso significa que o desenvolvedor do site deve se esforçar para baixar exatamente o que será exibido na tela o mais rápido possível.
4. A falta de uma tela de toque. Se o dispositivo não estiver equipado com uma tela sensível ao toque, isso significa que tudo com o qual o usuário pode interagir deve ser facilmente acessível ao trabalhar com a página usando o teclado. Você não deve exibir na página muitos elementos com os quais pode trabalhar.
5. Teclados Em telefones de baixo custo, são utilizados teclados de hardware completamente diferentes dos teclados QWERTY na tela, familiares aos proprietários de smartphones. O teclado do hardware possui aproximadamente 15 teclas, com várias teclas sendo usadas para inserir alguns caracteres. Como resultado, verifica-se que, em termos de UX, vale a pena se esforçar para minimizar a necessidade de entrada de texto.

Note-se que, mesmo no Japão, os planos tarifários limitados afetam a usabilidade dos usuários com recursos da web.


Tempo de carregamento da página para dispositivos 4G no Japão

Acima está uma imagem deste tweet, que diz que no Japão, no final do mês, as páginas carregam mais lentamente devido a restrições do plano tarifário.

Diretrizes de criação de sites

As diretrizes a seguir podem ajudá-lo a criar sites que funcionem rapidamente em telefones simples e baratos. Em geral, pode-se notar que não é recomendável que o usuário aguarde o download de algo que ele não solicitou explicitamente. Sempre que possível, você deve reduzir o tempo necessário para carregar e executar o código JavaScript.

▍ Defina limites para a quantidade de dados transferidos quando você carrega o site pela primeira vez

No caminho do servidor para o cliente, cada byte da sua página passa por muitos gargalos. São redes lentas e não confiáveis, processadores lentos. A única maneira garantida de aumentar o desempenho das páginas é planejar estritamente seu volume e cumprir (e até preencher demais) os planos.

As metas de desempenho da página são definidas pelas restrições que a equipe de desenvolvimento se esforça para fornecer um desempenho decente para seu projeto. Essas são as limitações das métricas além das quais foi decidido não ir além. Definir essas restrições em indicadores que podem ser medidos e definir restrições feitas antes do início do trabalho ajudam a equipe a garantir que o desempenho do projeto esteja dentro da estrutura especificada quando novos recursos forem adicionados a ele.

Exemplos de métricas de recursos que podem ser limitadas incluem o tamanho do pacote configurável JavaScript, o tamanho da imagem em bytes e o número de solicitações HTTP. Limitações nas métricas que afetam a maneira como os usuários percebem as páginas podem ser definidas para métricas como Primeira pintura com conteúdo , Maior pintura com conteúdo ou Atraso na primeira entrada . Eles permitem avaliar a rapidez com que o usuário vê a página e em quanto tempo ele pode interagir com ela. Você pode definir valores limite para esses indicadores, com base nas características do público-alvo do site.

Você pode desenvolver um sistema de restrições em relação ao seu próprio código de aplicativo, bem como sobre scripts de terceiros e outras coisas assim. As restrições podem ser verificadas durante a construção do projeto , usando o Lighthouse (LightWallet), em um sistema de integração contínua .

▍ Use o padrão PRPL

O PRPL é um padrão recomendado pela equipe de desenvolvimento do Chrome para o faseamento de downloads de código. Ele foi projetado para garantir que os aplicativos que o utilizam sejam interativos o mais rápido possível em dispositivos de baixo custo e redes lentas. O padrão PRPL incentiva o pré-carregamento da quantidade mínima de código JS necessária para fazer a página funcionar. Os recursos são carregados usando técnicas de carregamento lento. Se necessário, você pode usar o responsável pelo serviço para armazenar em cache previamente os recursos JavaScript necessários para futuras interações com o site.

O padrão PRPL-50 define um limite para a quantidade de recursos inicialmente carregados igual a 50 Kb. Como os telefones de baixo custo possuem recursos de hardware muito modestos, é necessário definir restrições ainda mais rigorosas. Aqui eu aconselho você a considerar o padrão PRPL-30. 30 é 30 Kb de recursos de origem; esse é o tamanho do pacote compactado e compactado carregado no carregamento da primeira página.


Exemplo de alocação de espaço em um pacote configurável JS de 30 Kb. Isso inclui lógica do aplicativo, código da estrutura, utilitários auxiliares e dependências de terceiros

Com essa abordagem, o primeiro byte de materiais do site de um bom servidor de cache de borda, após a conclusão do procedimento de conexão SSL, chegará ao dispositivo em cerca de 2 segundos. Isso nos dá 3 segundos para baixar os materiais da rota original, exibi-los e preparar a página para a interação do usuário. Para projetos baseados em JavaScript, isso significa que o tamanho total do pacote compactado compactado e compactado carregado na saída da primeira página não deve exceder 30 Kb.


O uso do padrão PRPL-30 permite que o desenvolvedor leve a página para o modo interativo em um telefone barato em cerca de 5 segundos

Talvez isso surpreenda alguém: “Do que estamos falando? Tamanho do pacote original de 30 Kb? Isso é estranho Afinal, nem vou ajustar o React e o código do aplicativo neste volume! ”Deve-se notar que, ao desenvolver sites projetados para dispositivos realmente fracos, o criador do projeto, por conveniência do usuário, terá que fazer compromissos difíceis. Por exemplo, o React pode ser usado para sites de telefone de recursos se o uso do React estiver limitado à renderização do servidor (1), o que parece bastante sensato, ou se (2) os fragmentos de código que contêm a lógica do aplicativo forem muito, muito pequenos e isto se em sua preparação aplicar as regras mais severas de carregamento lento. Existe uma terceira opção - escolha um análogo leve do React como o Preact (3). Falaremos mais sobre esses compromissos abaixo.

Um exemplo de aplicativo criado usando o limite de 30 Kb é o Proxx . O conjunto de dados inicial do projeto tem um tamanho de 25 Kb, difere pelo indicador TTI (Time To Interactive), que é inferior a 5 segundos. Aqui está uma calculadora que você pode usar para encontrar destinos para projetos da web e selecionar suas próprias limitações.

O tamanho recomendado para rotas carregadas no modo lento não excede 35 Kb. Mas os "fragmentos", cujo tamanho está na faixa de 30 a 35 Kb, também são grandes o suficiente para falar sobre o processamento paralelo usando os recursos do V8 para fluxo de trabalho com scripts.

▍ Salvar recursos JavaScript

Se falamos em economia de recursos JavaScript em poucas palavras, é possível usar renderização estática ou renderização de servidor com o mínimo envolvimento dos scripts do cliente. Se for completamente impossível sem a renderização híbrida ou do cliente, somente os scripts necessários para uma rota específica devem ser enviados ao cliente, e é melhor fazer isso no menor número possível de sessões de transferência de dados. Aqui você pode considerar técnicas como a preparação progressiva da página para trabalhar no navegador .


Renderização estática

JavaScript é o principal gargalo de telefones simples

Ao desenvolver projetos interativos para telefones baratos, lembre-se de que o JavaScript geralmente é o principal obstáculo ao alto desempenho da página. Isso é importante, pois o tempo em que o usuário pode usá-los depende de como é decidido renderizar as páginas . Mesmo que ele trabalhe com eles usando um joystick para telefone. Se você decidir usar a renderização estática ou do lado do servidor, tente que a quantidade de código JS necessária para organizar o trabalho interativo da página seja a menor possível.

Entrada de URL; carregando resultados de renderização do servidor; carregando o código JavaScript necessário para trazer a página para o modo interativo; página pronta para interação do usuário

O preço do JavaScript consiste em dois indicadores: o tempo de carregamento e o tempo de execução do código. Uma rede lenta (por exemplo, uma conexão 3G estável) pode aumentar o tempo de inicialização do JS. Um processador lento aumentará o tempo necessário para executar o script. A figura a seguir mostra o tempo necessário para vários dispositivos processarem o código JavaScript do recurso popular reddit.com. É fácil ver que um dispositivo lento (Alcatel 1X 5059D) leva 6 vezes mais tempo que um rápido (Pixel 3).


O tempo necessário para diferentes dispositivos processarem o código JS de um site popular

Se a renderização da página ou o processo de trazê-la para o modo interativo depender muito do JavaScript, isso pode levar ao fato de que o usuário de um telefone barato precisará esperar 30 a 60 segundos para ter a oportunidade de trabalhar com a interface do usuário. Como resultado, para minimizar o tempo necessário para carregar e processar o JavaScript, o desenvolvedor deve usar os scripts com moderação e fazer o download do código apenas para as rotas e componentes que o usuário possa precisar. Você precisa fazer isso quando houver a necessidade do código apropriado.

Esforce-se para minimizar a quantidade de código necessária para trazer a página interativamente

Aqui estão algumas dicas para ajudar a minimizar a quantidade de código necessário para fornecer os recursos interativos de suas páginas:

1. Use mecanismos de carregamento lento o mais amplamente possível. Estamos falando de rotas, componentes, recursos que estão fora da área visível da tela, sobre o que não pode ser chamado de extremamente importante para garantir a integridade da página.
2. Use mecanismos de divisão de código para dividir o código JavaScript em partes e fazer o download apenas do que o usuário precisa ao trabalhar com a rota inicial. Isso levará a um carregamento mais rápido da página, reduzindo a quantidade de scripts carregados e processados.
3. Remova o código não utilizado dos pacotes configuráveis ​​do JavaScript para reduzir o tamanho possível. Para fazer isso, você precisará analisar o pacote e identificar as bibliotecas que não são usadas, e aquelas que podem ser substituídas por algo mais compacto, adaptado às necessidades do seu projeto. Bibliotecas que não são usadas quando a página é carregada pela primeira vez podem ser carregadas no modo lento.
4. Considere usar mecanismos de carregamento de código diferencial . Isso permitirá que você forneça o código JavaScript moderno para navegadores modernos, se livrando do uso excessivo do código transpilado e evitando polyfills. Reduzir o código para navegadores mais antigos pode melhorar o desempenho do código em navegadores modernos.
5. Se o código JS for absolutamente necessário para renderizar a página e exibir sua interface no modo interativo, organize um carregamento preliminar dos scripts necessários. O atributo correspondente, como mostrado abaixo, informa ao navegador que o script é importante e que precisa ser baixado o mais rápido possível.

<link rel="preload" as="script" href="critical.js"> 

Choose Escolha cuidadosamente a pilha de tecnologias usadas

Estrutura e Utilitários

Embora o uso de bibliotecas de terceiros possa acelerar o desenvolvimento e simplificar a solução de problemas complexos, as bibliotecas podem ter um tamanho considerável. Eles devem ser usados ​​com cautela ao desenvolver projetos projetados para dispositivos fracos. Aqui estão algumas diretrizes para o uso de dependências externas:

1. Telefones baratos são muito limitados em recursos. Portanto, se possível, evite usar estruturas JS ou limite seu uso. O objetivo desta dica é deixar o máximo de espaço possível para a lógica do aplicativo. Em uma situação em que um desenvolvedor procura limitar o uso de JavaScript para reduzir o tamanho da página e aumentar seu desempenho, as estruturas JS podem sobrecarregar a página excessivamente. Se o projeto for baseado no React, considere limitar o uso desta biblioteca à renderização do servidor, ou considere alternar para Preact e usar o preact-compat durante a compilação para reduzir o tamanho do pacote em cerca de 30 Kb. Para criar pacotes leves, faz sentido olhar para tecnologias como Svelte , lit-html e JavaScript simples.
2. Tente garantir que as dependências de terceiros ocupem o mínimo de espaço possível. Isso garantirá que os tamanhos dos pacotes configuráveis ​​usados ​​durante o carregamento inicial da página se ajustem aos limites especificados. Para analisar a contribuição para o tamanho dos pacotes configuráveis criados por bibliotecas de terceiros, você pode usar o bundlephobia.com . Analise criticamente a composição de seus pacotes configuráveis ​​para determinar se o espaço deles está sendo usado com eficiência. Por exemplo, em vez da biblioteca Moment.js, que contém, em um formulário padrão, grandes quantidades de dados relacionados aos padrões nacionais, você pode usar date-fns ou luxon .
3. Tenha muito cuidado ao usar o Redux e os repositórios internos do Redux usados ​​para gerenciar a integridade do aplicativo. Os dados do repositório Redux geralmente são incorporados ao HTML para que possam ser usados ​​para tornar as páginas operacionais. Isso pode facilmente levar a um aumento excessivo no tamanho dos dados enviados pelo servidor em resposta às solicitações do cliente.

AptAdaptem materiais do site para não carregar recursos volumosos em conexões lentas

Imediatamente, quero aconselhá-lo a dar uma olhada neste material sobre a adaptação de recursos com base em dispositivos fracos.


Carregamento adaptável de recursos, dependendo da velocidade da conexão de rede

O carregamento adaptável de recursos é uma técnica de "adaptação" de materiais enviados ao usuário com base em informações sobre o tipo de conexão efetivo (ECT) disponível para o navegador por meio da API de informações de rede . Veja como é o trabalho com esta API:

 console.log(navigator.connection.effectiveType); // 3G 

O carregamento adaptável permite que os sites garantam que os usuários que trabalham em conexões lentas possam ter quase a mesma experiência de interagir com recursos que os usuários que têm acesso a redes mais rápidas. Talvez na versão “lenta” do site tudo não seja tão bonito quanto na versão “rápida”, mas esse é um pagamento aceitável por um bom desempenho.

Observe que, mesmo em uma conexão 4G "rápida", os usuários podem encontrar baixas velocidades de transferência de dados. Talvez você tenha se encontrado com algo assim, usando a Internet Wi-Fi em um restaurante ou em alguma conferência.

Considere um exemplo específico de uso de carregamento de material adaptável. Será sobre o componente que representa um determinado produto no site. Um usuário que trabalha em uma conexão lenta verá uma versão compactada da imagem do produto. E qualquer pessoa que acesse a Internet em alta velocidade verá uma imagem de alta qualidade e, além disso, poderá usar recursos adicionais que exigem muito código JavaScript para implementar. Por exemplo - essa é a capacidade de aumentar a imagem do produto ou exibir, no "carrossel", várias fotos do produto.

No caso de telefones baratos, uma rede lenta não é necessariamente o principal obstáculo ao envio de recursos em massa para eles. As impressões do usuário de trabalhar com o site provavelmente serão afetadas pelo processador lento e pela baixa capacidade de memória - mesmo se o dispositivo estiver conectado a uma rede 4G bastante rápida. Embora os desenvolvedores da web ainda não tenham acesso a informações detalhadas sobre o processador, as dicas do cliente fornecem informações aproximadas sobre a memória do dispositivo, sobre a largura e a densidade de pixels da tela, sobre a rede e outras coisas. Essas informações podem ser usadas para desenvolver uma estratégia mais precisa para fornecer dados otimizados ao cliente.

▍ Respeite o plano tarifário do usuário, considerando o conteúdo do cabeçalho Save-Data

O navegador Chrome para Android tem uma opção especial que inclui salvar dados. Ele permite que os usuários interessados ​​em economizar tráfego trabalhem em um modo no qual o navegador otimiza automaticamente os recursos, tentando acelerar o carregamento da página. A otimização inclui compactação de imagens mais do que o habitual, atrasando o carregamento de recursos que não são críticos, gerando nas imagens do servidor a visualização de páginas. Aqui está o material onde você pode encontrar detalhes sobre isso.

Quando os usuários ativam o modo de economia de dados em navegadores compatíveis com esse modo, os navegadores anexam o cabeçalho Save-Data a solicitações HTTP e HTTPS. O desenvolvedor do projeto da web pode, usando JavaScript, verificar se a solicitação possui esse título e, se houver, pode fornecer ao usuário uma versão otimizada dos materiais do site. Como resultado, acontece que o usuário abandona intencionalmente as oportunidades "difíceis" e o desenvolvedor simplesmente cumpre seu desejo. Para verificar o cabeçalho Save-Data na solicitação, você pode usar algo como este código:

 if ("connection" in navigator) {  if (navigator.connection.saveData === true) {    //  ,    .  } } 

Aqui está a aparência do trabalho com a versão lite da página.


Versão leve da página preparada pelo Google

Observe que, embora um telefone simples e barato possa suportar o Chrome, isso não garante a disponibilidade do modo de economia de dados no navegador. É melhor considerar esse recurso como algo como a funcionalidade opcional opcional de alguns navegadores.

▍ Coloque mecanismos lógicos e de gerenciamento de estado de aplicativo com uso intensivo de recursos nos trabalhadores da Web

Aqui está um bom material para encontrar dicas sobre como acelerar o carregamento de aplicativos da Web em telefones fracos.

O segmento principal do navegador, além de executar o JavaScript, está ocupado com outras coisas importantes. Esta é a formação do layout da página, a exibição de pixels na tela, garantindo a interação do usuário com a página. Operações JavaScript longas e complexas podem bloquear o encadeamento principal, o que significa interferir na página.

Os trabalhadores da Web permitem executar o código JavaScript em segundo plano e não bloquear o encadeamento principal. Eles devem ser usados ​​para remover a carga criada por operações JavaScript "pesadas" do encadeamento principal. Entre eles está a lógica complexa dos aplicativos da Web e seu gerenciamento de estado. O thread principal e o thread de trabalho trocam informações usando a função postMessage () e o manipulador de eventos onmessage . A função postMessage() permite que o remetente envie um valor ao destinatário, que pode ser, por exemplo, um objeto JavaScript. Existem bibliotecas como o Comlink que facilitam o uso de web workers.

Aqui está o material em que o trabalho do projeto Proxx é estudado com o uso de fluxos de trabalho e sem eles. Durante o estudo, verificou-se que, sem o uso de trabalhadores, um aplicativo que realiza uma certa operação “congela” no telefone Nokia 2 (1 GB de memória, um processador quad-core com uma frequência de 1,3 GHz) por 6,6 segundos. Nas mesmas condições, mas com o uso de um trabalhador, o tempo de reação do sistema é de apenas 48 ms. Como resultado, se você tiver um código que exija recursos sérios do processador, considere se transportá-lo para um trabalhador da Web melhorará a situação.

▍ Otimizar imagens

As imagens geralmente têm uma quantidade muito grande de dados relacionados a páginas da web. Ao mesmo tempo, as imagens não precisam apenas ser carregadas. Eles ainda precisam ser decodificados, preparados para a saída, e isso pode carregar muito um dispositivo de baixa energia. Como resultado, para o desenvolvimento de sites projetados para telefones fracos, é importante garantir que as imagens usadas nesses sites sejam de tamanho adequado e sejam adequadamente compactadas. Aqui estão algumas sugestões para otimização de imagem:

1. Comprima imagens usando ferramentas como Imagemin. Eles permitem obter uma redução no tamanho da imagem sem uma diminuição perceptível na qualidade.
2. Substitua GIFs animados por arquivos de vídeo que são carregados muito mais rapidamente. Mas, quando se trata de vídeo, vale a pena considerar se é necessária mídia pesada em um site projetado para um telefone simples e barato.
3. Use sempre que possível mecanismos de carregamento lento de imagens. Como esses mecanismos são baseados em JavaScript, tente garantir que a implementação do software não seja muito "pesada". Aqui você pode encontrar o novo atributo de carregamento padrão útil.
4. Envie imagens responsivas do tamanho certo para o cliente. Isso pode ser feito criando várias versões de imagens e dando ao cliente as que melhor se adequam à sua tela.
5. Use imagens que se ajustem à tela. A saída de imagens pequenas compactadas o suficiente para um usuário que trabalha com um telefone fraco levará ao fato de que essas imagens serão mais rápidas de decodificar.

▍ Forneça ao cliente recursos que correspondam ao tamanho da tela do dispositivo

Muitos dispositivos modernos que podem ser classificados como "smart feature phone" possuem telas QVGA com uma resolução de 320x240 pixels, respectivamente, horizontal e verticalmente. Se você precisar descobrir o tamanho da tela do dispositivo ao carregar a página (por exemplo, para usar certas otimizações), poderá usar algo como este fragmento de código:

 const isFeaturePhone = Math.min(screen.width, screen.height) <= 240; 

Uma abordagem semelhante é usada no projeto Proxx.

Sites de teste em dispositivos reais ou no emulador

Se você estiver desenvolvendo sites projetados para telefones simples e baratos, é recomendável testá-los nesses telefones. Eles são baratos. Por exemplo, um tweet que diz que os desenvolvedores que vivem nos EUA e desejam testar seus sites em dispositivos KaiOS devem ir ao BestBuy e obter um telefone por US $ 15.


Telefone barato para testar sites no KaiOS

Se você deseja emular um telefone semelhante (por exemplo, algo como um telefone Jio executando no KaiOS), use as ferramentas de desenvolvedor do Chrome para isso:

• Abra as Ferramentas do desenvolvedor do Chrome.
• Abra a barra de ferramentas do Device .
• Na barra de ferramentas Device , abra o menu do dispositivo e selecione Edit . Na janela que aparece, clique no botão Add custom device .
• Nomeie o novo dispositivo KaiOS (ou o que você quiser).
• Defina o tamanho da tela para 240x320 .
• No campo User agent string do User agent string , digite o seguinte: Mozilla/5.0 (Mobile; LYF/F90M/LYF-F90M-000-02-23-181217; Android; rv:48.0) Gecko/48.0 Firefox/48.0 KAIOS/2.5 YouTube/1.66.51.J .
• Salve o dispositivo clicando no botão Add .
• Se necessário, ative a desaceleração do processador, mas lembre-se de que, com a ajuda de um emulador, você não poderá verificar um site tão bem quanto isso pode ser feito usando um dispositivo real.

Configurar um novo dispositivo nas Ferramentas do desenvolvedor do Chrome

Sumário

Você pode criar sites que sejam convenientes para absolutamente todos os usuários móveis, independentemente de onde eles morem. Mas, para isso, o desenvolvedor precisa fazer alguns esforços, pois os dispositivos móveis de diferentes categorias de preços são muito diferentes um do outro.

Quanto mais acessível o telefone, maior a probabilidade de ele poder usar um processador lento. O desempenho dos sites JavaScript depende da velocidade de carregamento do código e da velocidade de sua execução. Isso deve ser considerado para quem deseja criar sites que funcionem bem em qualquer dispositivo e em qualquer rede.

Tudo o que falamos acima é importante para smartphones, mas é ainda mais importante para telefones simples e baratos, para dispositivos da classe “feature phone”, que são muito populares nos países em desenvolvimento.

Caros leitores! Você otimiza seus projetos da web para dispositivos móveis fracos?