Usei a Web por um dia com um orçamento de 50 MB

Este artigo faz parte de uma série em que tento usar a web sob várias restrições, representando um determinado demográfico de usuário. Espero aumentar o perfil das dificuldades enfrentadas por pessoas reais, que são evitáveis ​​se projetarmos e desenvolvermos de uma forma que seja simpática às suas necessidades.

Da última vez, naveguei na Web por um dia usando o Internet Explorer 8. Dessa vez, naveguei na Web por um dia com um orçamento de 50 MB.

Por que 50 MB?

Muitos de nós temos a sorte de estar em planos móveis que permitem vários gigabytes de transferência de dados por mês. Caso contrário, geralmente podemos nos conectar a redes WiFi domésticas ou públicas que estão em conexões de banda larga rápida e têm dados efetivamente ilimitados.

Mas há partes do mundo onde os dados móveis são proibitivamente caros e onde há pouca ou nenhuma infraestrutura de banda larga.

As pessoas geralmente compram pacotes de dados de apenas dezenas de megabytes por vez, tornando um gigabyte uma quantidade de dados relativamente grande e, portanto, cara para comprar.
— Dan Howdle, analista de telecomunicações de consumo da Cable.co.uk

Quão caro estamos falando?

O custo dos dados móveis

Um estudo de 2018 da cable.co.uk descobriu que o Zimbábue era o país mais caro do mundo para dados móveis, onde 1 GB custava em média US$ 75,20, variando de US$ 12,50 a US$ 138,46. A enorme faixa de preço se deve ao fato de que quantidades menores de dados são muito caras, ficando proporcionalmente mais baratas quanto maior o plano de dados com o qual você se compromete. Você pode ler a metodologia de estudo para obter mais informações.

O Zimbábue não é um caso isolado. Guiné Equatorial, Santa Helena e as Ilhas Malvinas são os próximos da fila, com 1 GB de dados custando US$ 65,83, US$ 55,47 e US$ 47,39, respectivamente. Esses países geralmente têm uma combinação de infraestrutura técnica ruim e baixa adoção, o que significa que os dados são caros para fornecer e não têm economia de escala para reduzir os custos.

Os dados também são caros em partes da Europa. Um gigabyte de dados na Grécia custará US$ 32,71; na Suíça, US$ 20,22. Para efeito de comparação, a mesma quantidade de dados custa US$ 6,66 no Reino Unido ou US$ 12,37 nos EUA. No outro extremo da escala, a Índia é o lugar mais barato do mundo para dados, a um custo médio de US$ 0,26. Quirguistão, Cazaquistão e Ucrânia seguem com US$ 0,27, US$ 0,49 e US$ 0,51 por GB, respectivamente.

A velocidade das redes móveis também varia consideravelmente entre os países. Talvez surpreendentemente, os usuários experimentam velocidades mais rápidas em uma rede móvel do que WiFi em pelo menos 30 países em todo o mundo, incluindo Austrália e França. A Coreia do Sul tem a velocidade de download móvel mais rápida, com média de 52,4 Mbps, mas o Iraque tem a mais lenta, com média de download de 1,6 Mbps e upload de 0,7 Mbps. Os EUA ocupam o 40º lugar no mundo em velocidades de download móvel, em torno de 34 Mbps, e correm o risco de ficar ainda mais para trás à medida que o mundo avança para o 5G.

Quanto ao tipo de conexão de rede móvel, 84,7% das conexões de usuários no Reino Unido são em 4G, em comparação com 93% nos EUA e 97,5% na Coreia do Sul. Isso se compara com menos de 50% no Uzbequistão e menos de 60% na Argélia, Equador, Nepal e Iraque.

O custo dos dados de banda larga

Enquanto isso, um estudo sobre o custo da banda larga em 2018 mostra que uma conexão de banda larga no Níger custa US$ 263 'por megabit por mês'. Esta métrica é um pouco difícil de compreender, então aqui está um exemplo: se o custo médio dos pacotes de banda larga em um país é de $ 22, e a velocidade média de download oferecida pelos pacotes é de 10 Mbps, então o custo 'por megabit por mês' seria ser $ 2,20.

É uma métrica interessante e que reconhece que a velocidade da banda larga é um fator tão importante quanto o limite de dados. Um custo de US$ 263 sugere uma combinação de banda larga extremamente lenta e extremamente cara. Para referência, a métrica é de US$ 1,19 no Reino Unido e US$ 1,26 nos EUA.

O que talvez seja mais fácil de compreender é o custo médio de um pacote de banda larga. Observe que este estudo estava procurando os pacotes de banda larga mais baratos oferecidos, ignorando se esses pacotes tinham ou não um limite de dados, portanto, fornece um valor aproximado útil em vez do custo dos dados em si.

Apenas no custo do pacote, a Mauritânia tem a banda larga mais cara do mundo, com uma média de US$ 768,16 (uma faixa de US$ 307,26 a US$ 1.368,72). Este enorme custo inclui a construção de linhas físicas para a propriedade, pois poucas já existem na Mauritânia. Com 0,7 Mbps, a Mauritânia também possui uma das redes de banda larga mais lentas do mundo.

Taiwan tem a banda larga mais rápida do mundo, com velocidade média de 85 Mbps. O Iêmen tem o mais lento, com 0,38 Mbps. Mas mesmo países com boa infraestrutura de banda larga estabelecida têm os chamados 'não-spots'. O Reino Unido está classificado em 34º entre 207 países em velocidade de banda larga, mas em julho de 2019 ainda havia uma escola no Reino Unido sem banda larga.

O custo médio de um pacote de banda larga no Reino Unido é de US$ 39,58 e nos EUA é de US$ 67,69. A média mais barata do mundo é a da Ucrânia, com apenas US$ 5, embora a oferta de banda larga mais barata de todas tenha sido encontrada no Quirguistão (US$ 1,27 – contra a média do país de US$ 108,22).

O Zimbábue foi o país mais caro para dados móveis, e as estatísticas não são muito melhores para sua banda larga, com um custo médio de US$ 128,71 e um custo 'por megabit por mês' de US$ 6,89.

Custo absoluto vs custo em termos reais

Todos os custos descritos até agora são os custos absolutos em dólares, com base nas taxas de câmbio no momento do estudo. Esses custos não foram contabilizados no custo de vida, o que significa que, para muitos países, o custo é realmente muito mais alto em termos reais.

Vou limitar minha navegação hoje a 50 MB, o que no Zimbábue custaria cerca de US$ 3,67 em uma tarifa de dados móveis. Isso pode não parecer muito, mas os professores no Zimbábue entraram em greve este ano porque seus salários caíram para apenas US$ 2,50 por dia.

Para efeito de comparação, US$ 3,67 é cerca de metade do salário mínimo de US$ 7,25 nos EUA. Como zimbabuense, eu teria que trabalhar cerca de um dia e meio para ganhar dinheiro para comprar esses 50 MB de dados, em comparação com apenas meia hora nos EUA. Não é fácil comparar o custo de vida entre os países, mas apenas com os salários, o custo de US$ 3,67 de 50 MB de dados no Zimbábue pareceria US$ 52 para um americano no salário mínimo.

Configurando o experimento

Iniciei o Chrome e abri as ferramentas de desenvolvimento, onde limitei a rede para uma conexão 3G lenta. Eu queria simular uma conexão lenta como as experimentadas pelos usuários no Uzbequistão, para ver que tipo de experiência os sites me dariam. Eu também estrangulei minha CPU para simular estar em um dispositivo de extremidade inferior.

Instalei o ModHeader e configurei o cabeçalho 'Save-Data' para que os sites saibam que quero minimizar meu uso de dados. Este também é o cabeçalho definido pelo Chrome para o 'modo Lite' do Android, que abordarei com mais detalhes posteriormente.

Baixei o TripMode; um aplicativo para Mac que lhe dá controle sobre quais aplicativos no seu Mac podem acessar a Internet. O acesso à Internet de qualquer outro aplicativo é bloqueado automaticamente.

Até onde posso prever que meu orçamento de 50 MB me levará? Com o peso médio de uma página da web sendo quase 1,7 MB, isso sugere que tenho cerca de 29 páginas no meu orçamento, embora provavelmente um pouco mais do que isso, se eu puder permanecer nos mesmos sites e aproveitar o cache do navegador.

Ao longo do experimento, vou sugerir dicas de desempenho para acelerar a primeira pintura de conteúdo e o tempo de carregamento percebido da página. Algumas dessas dicas podem não afetar a quantidade de dados transferidos diretamente , mas geralmente envolvem adiar o download de recursos menos importantes, o que em conexões lentas pode significar que os recursos nunca são baixados e os dados são salvos.

O experimento

Sem mais delongas, carreguei o google.com, usando 402 KB do meu orçamento e gastando US$ 0,03 (cerca de 1% do meu orçamento do Zimbábue).

Em suma, não é um tamanho de página ruim, mas eu me perguntava de onde vinham essas 24 solicitações de rede e se a página poderia ou não ser mais leve.

Página inicial do Google — DOM

Observando a marcação da página, não há folhas de estilo externas — todo o CSS é embutido.

Dica de desempenho nº 1: CSS crítico embutido

Isso é bom para o desempenho, pois evita que o navegador precise fazer uma solicitação de rede adicional para buscar uma folha de estilo externa, para que os estilos possam ser analisados ​​e aplicados imediatamente para a primeira pintura de conteúdo. Há uma troca a ser feita aqui, pois folhas de estilo externas podem ser armazenadas em cache, mas as inline não (a menos que você seja esperto com JavaScript).

O conselho geral é que seus estilos críticos (qualquer coisa acima da dobra) sejam inline e que o restante de seu estilo seja externo e carregado de forma assíncrona. O carregamento assíncrono de CSS pode ser alcançado em uma linha de HTML notavelmente inteligente:

 <link rel="stylesheet" href="/path/to/my.css" media="print" onload="this.media='all'">

Os devtools mostram uma versão embelezada do DOM. Se você quiser ver o que foi realmente baixado para o navegador, vá para a guia Fontes e encontre o documento.

Você pode ver que há MUITO JavaScript embutido aqui. Vale a pena notar que ele foi feiurado em vez de meramente minificado.

Dica de desempenho nº 2: reduza e enfeite seus ativos

A minificação remove espaços e caracteres desnecessários, mas a uglificação na verdade 'mangle' o código para ser mais curto. O sinal revelador é que o código contém nomes de variáveis ​​curtos, gerados por máquina, em vez de código-fonte intocado. Isso é bom, pois significa que o script é menor e mais rápido para baixar.

Mesmo assim, os scripts inline parecem ter aproximadamente 120 KB do recurso de página de 210 KB (cerca de metade do tamanho gzip de 60 KB). Além disso, existem cinco arquivos JavaScript externos no valor de 291 KB dos 402 KB baixados:

Isso significa que o JavaScript é responsável por cerca de 80% do peso geral da página.

Isso não é JavaScript inútil; O Google precisa ter alguns para exibir sugestões enquanto você digita. Mas suspeito que muito disso seja código de rastreamento e configuração de publicidade.

Para comparação, desativei o JavaScript e recarreguei a página:

A versão desabilitada para JS da pesquisa do Google tem apenas 102 KB, em oposição a 402 KB. Embora o Google não possa fornecer sugestões automáticas nessas condições, o site ainda funciona e acabei de reduzir o uso de dados para um quarto do que era. Se eu realmente tivesse que limitar meu uso de dados a longo prazo, uma das primeiras coisas que faria seria desabilitar o JavaScript. Não é tão ruim quanto parece.

Dica de desempenho nº 3: menos é mais

Inlining, uglifying e minifying assets são muito bons, mas o melhor desempenho vem de não enviar os assets em primeiro lugar.

• Antes de adicionar novos recursos, você tem um orçamento de desempenho?
• Antes de adicionar JavaScript ao seu site, seu recurso pode ser realizado usando HTML simples? (Por exemplo, validação de formulário HTML5).
• Antes de colocar uma grande biblioteca JavaScript ou CSS em seu aplicativo, use algo como bundlephobia.com para medir o tamanho dela. A conveniência vale o peso? Você pode fazer a mesma coisa usando código vanilla em um tamanho de dados muito menor?

Analisando as informações do recurso

Há muito para desempacotar aqui, então vamos começar. Eu só tenho 50 MB para jogar, então vou aproveitar cada pedacinho do carregamento desta página. Acomode-se para um breve tutorial do Chrome Devtools.

402 KB transferidos, mas 1,1 MB de recursos: o que isso realmente significa?

Isso significa que 402 KB de conteúdo foram realmente baixados, mas em sua forma compactada (usando um algoritmo de compactação como gzip ou brotli). O navegador então teve que fazer algum trabalho para descompactá-lo em algo significativo. O tamanho total dos dados descompactados é de 1,1 MB.

Essa descompactação não é gratuita — há alguns milissegundos de sobrecarga na descompactação dos recursos. Mas isso é uma sobrecarga insignificante em comparação com o envio de 1,1 MB pelo fio.

Dica de desempenho nº 4: compactar ativos baseados em texto

Como regra geral, sempre compacte seus ativos, usando algo como gzip. Mas não use compactação em suas imagens e outros arquivos binários — você deve otimizá-los antecipadamente na fonte. A compressão pode realmente acabar tornando-os maiores.

E, se puder, evite compactar arquivos com 1500 bytes ou menores. O menor tamanho de pacote TCP é de 1500 bytes, portanto, compactando para, digamos, 800 bytes, você não economiza nada, pois ainda é transmitido no mesmo pacote de bytes. Novamente, o custo é insignificante, mas desperdiça algum tempo de CPU de compactação no servidor e tempo de CPU de descompactação no cliente.

Agora, de volta à guia Rede no Chrome: vamos nos aprofundar nessas prioridades. Observe que os recursos têm prioridade “Mais alta” para “Mais baixa” — esses são os melhores palpites do navegador sobre quais são os recursos mais importantes para download. Quanto maior a prioridade, mais cedo o navegador tentará baixar o ativo.

Dica de desempenho nº 5: dê dicas de recursos ao navegador

O navegador adivinhará quais são os ativos de prioridade mais alta, mas você pode fornecer uma dica de recurso usando a tag <link rel="preload"> , instruindo o navegador a baixar o ativo o mais rápido possível. É uma boa ideia pré-carregar fontes, logotipos e qualquer outra coisa que apareça acima da dobra.

Vamos falar sobre cache. Vou segurar ALT e clicar com o botão direito do mouse para alterar os cabeçalhos das minhas colunas para desbloquear algumas informações mais interessantes. Vamos verificar o Cache-Control.

Cache-Control indica se um recurso pode ou não ser armazenado em cache, por quanto tempo ele pode ser armazenado em cache e quais regras ele deve seguir para revalidar. Definir valores de cache adequados é crucial para manter baixo o custo de dados de visitas repetidas.

Dica de desempenho nº 6: defina cabeçalhos de controle de cache em todos os ativos que podem ser armazenados em cache

Observe que o valor de controle de cache começa com uma diretiva de public ou private , seguida por um valor de expiração (por exemplo max-age=31536000 ). O que a diretiva significa e por que o valor max-age estranhamente específico?

O valor 31536000 é o número de segundos que há em um ano e é o valor máximo teórico permitido pela especificação de controle de cache. É comum ver este valor aplicado a todos os ativos estáticos e efetivamente significa “esse recurso não vai mudar”. Na prática, nenhum navegador armazenará em cache por um ano inteiro, mas armazenará o recurso em cache pelo tempo que fizer sentido.

Para explicar a diretiva public/private, devemos explicar os dois caches principais que existem fora do servidor. Primeiro, há o tradicional cache do navegador, onde o recurso é armazenado na máquina do usuário (o 'cliente'). E depois há o cache CDN, que fica entre o cliente e o servidor; os recursos são armazenados em cache no nível da CDN para evitar que a CDN solicite o recurso do servidor de origem repetidamente.

Uma diretiva Cache-Control de public permite que o recurso seja armazenado em cache no cliente e na CDN. Um valor de private significa que apenas o cliente pode armazená-lo em cache; o CDN não é suposto. Este último valor é normalmente usado para páginas ou ativos que existem por trás da autenticação, onde não há problema em ser armazenado em cache no cliente, mas não queremos vazar informações privadas armazenando-as em cache na CDN e entregando-as a outros usuários.

Uma coisa que me chamou a atenção foi que o logotipo do Google tem um controle de cache de “privado”. Outras imagens na página têm um cache público e não sei por que o logotipo seria tratado de maneira diferente. Se você tiver alguma ideia, deixe nos comentários!

Atualizei a página e a maioria dos recursos foram servidos do cache, além da própria página, que como você viu já é private, max-age=0 , o que significa que não pode ser armazenada em cache. Isso é normal para páginas da Web dinâmicas em que é importante que o usuário sempre obtenha a página mais recente ao atualizar.

Foi nesse ponto que acidentalmente cliquei em um URL de 'Explicação' nas devtools, o que me levou à referência de análise de rede, custando cerca de 5 MB do meu orçamento. Ops.

Documentos de desenvolvimento do Google

4,2 MB dessa nova página de 5 MB eram imagens; especificamente SVGs. O mais pesado deles era de 186 KB, o que não é particularmente grande - havia tantos deles, e todos baixados de uma só vez.

Esse carregamento de página de 5 MB foi 10% do meu orçamento para hoje. Até agora, usei 5,5 MB, incluindo o recarregamento sem JavaScript da página inicial do Google, e gastei US$ 0,40. Eu nem queria abrir esta página.

O que teria sido uma melhor experiência de usuário aqui?

Dica de desempenho nº 7: carregue lentamente suas imagens

Normalmente, se eu clicasse acidentalmente em um link, eu apertaria o botão voltar no meu navegador. Eu não teria recebido nenhum benefício ao baixar essas imagens - que desperdício de 4,2 MB!

Além do vídeo, onde você geralmente sabe no que está se metendo, as imagens são de longe o maior culpado pelo uso de dados na web. Um estudo dos 500 maiores sites do mundo descobriu que as imagens ocupam até 53% do peso médio da página. “Isso significa que eles têm um grande impacto nos tempos de carregamento da página e, posteriormente, no desempenho geral”.

Em vez de baixar todas as imagens no carregamento da página, é uma boa prática fazer o carregamento lento das imagens para que apenas os usuários envolvidos com a página paguem o custo de baixá-las. Os usuários que optam por não rolar abaixo da dobra, portanto, não desperdiçam nenhuma largura de banda desnecessária baixando imagens que nunca verão.

Há um ótimo guia css-tricks.com para lançar o carregamento lento para imagens que oferece um bom equilíbrio entre aquelas com boas conexões, aquelas com conexões ruins e aquelas com JavaScript desabilitado.

Se esta página tivesse implementado o carregamento lento conforme o guia acima, cada um dos 38 SVGs teria sido representado por uma imagem de espaço reservado de 1 KB por padrão e carregado apenas na visualização na rolagem.

Dica de desempenho nº 8: use o formato certo para suas imagens

Achei que o Google tinha perdido um truque ao não usar o WebP, que é um formato de imagem 26% menor em tamanho comparado aos PNGs (sem perda de qualidade) e 25-34% menor em tamanho comparado aos JPEGs (e de um tamanho qualidade comparável). Eu pensei em converter SVG para WebP.

A conversão para WebP reduziu um dos SVGs de 186 KB para apenas 65 KB, mas, na verdade, olhando as imagens lado a lado, o WebP ficou granulado:

Tentei então converter um dos PNGs para WebP, que deveria ser sem perdas e deveria sair menor. No entanto, a saída WebP foi *mais pesada* (127 KB, de 109 KB)!

Isso me surpreendeu. O WebP não é necessariamente a bala de prata que pensamos que é, e até o Google deixou de usá-lo nesta página.

Portanto, meu conselho seria: sempre que possível, experimente diferentes formatos de imagem por imagem. O formato que mantém a melhor qualidade para o menor tamanho pode não ser o que você espera.

Agora de volta ao DOM. me deparei com isso:

Observe a palavra-chave async no script do Google Analytics?

Apesar de ser uma das primeiras coisas no início do documento, isso recebeu uma prioridade baixa, pois optamos explicitamente por não ser uma solicitação de bloqueio usando a palavra-chave async .

Uma solicitação de bloqueio é aquela que interrompe a renderização da página. Uma chamada <script> está bloqueando por padrão, interrompendo a análise do HTML até que o script seja baixado, compilado e executado. É por isso que tradicionalmente colocamos chamadas <script> no final do documento.

Dica de desempenho nº 9: evite escrever chamadas de script de bloqueio

Ao adicionar o atributo async à nossa tag <script> , estamos dizendo ao navegador para não parar de renderizar a página, mas para baixar o script em segundo plano. Se o HTML ainda estiver sendo analisado no momento em que o script for baixado, a análise será pausada enquanto o script é executado e, em seguida, retomada. Isso é significativamente melhor do que bloquear a renderização assim que <script> for encontrado.

Há também um atributo defer , que é sutilmente diferente. <script defer> diz ao navegador para renderizar a página enquanto o script é carregado em segundo plano, e mesmo que o HTML ainda esteja sendo analisado no momento em que o script é baixado, o script deve esperar até que a página seja renderizada antes de poder ser executado . Isso torna o script completamente não bloqueante. Leia “Carregar JavaScript de forma eficiente com adiamento e assíncrono” para obter mais informações.

De qualquer forma, chega de dissecação do Google. É hora de experimentar outro site. Eu ainda tenho quase 45 MB do meu orçamento sobrando!

Amazonas

A página inicial da Amazon carregou com um peso total de cerca de 6 MB. Uma delas era uma imagem de 587 KB que eu nem consegui encontrar na página. Este era um PNG, presumivelmente para ter texto nítido, mas em um fundo fotográfico - uma combinação clássica que é terrível para o desempenho.

Na verdade, havia algumas imagens de várias centenas de kilobytes na minha guia de rede que eu não conseguia ver na página. Suspeito de uma configuração incorreta em algum lugar da Amazon, mas essas imagens invisíveis combinadas mastigaram pelo menos 1 MB dos meus dados.

Como sobre a imagem do herói? É a imagem principal da página e são apenas 94 KB transferidos - mas poderia ser reduzido em tamanho em cerca de 15% se fosse cortado diretamente ao redor do texto e dos jogadores de futebol. Poderíamos então aplicar a mesma cor de fundo em CSS que está na imagem. Isso tem a vantagem adicional de ser redimensionável para telas menores, mantendo a legibilidade do texto.

Eu já disse isso uma vez, e vou dizer de novo: otimizar e carregar lentamente suas imagens é o maior benefício que você pode fazer para o peso da página do seu site .

A otimização de imagens proporcionou, de longe, a redução de dados mais significativa. Você pode argumentar que o JavaScript é um negócio maior para o desempenho geral, mas não para a redução de dados. Otimizar ou remover imagens é a maneira mais segura de garantir uma experiência muito mais leve e essa é a principal otimização da qual o Data Saver depende.
— Tim Kadlec, Entendendo as páginas do Chrome Lite

Para ser justo com a Amazon, se eu redimensionar o navegador para um tamanho móvel e atualizar a página, o site será otimizado para celular e o peso total da página será de apenas 2,1 MB.

Mas isso me leva ao meu próximo ponto…

Dica de desempenho nº 10: não faça suposições sobre conexões de dados

É difícil detectar se alguém em um desktop está em uma conexão de banda larga ou está conectando por meio de um dongle ou celular com limitação de dados. Muitas pessoas trabalham no trem assim, ou moram em uma área onde a infraestrutura de banda larga é ruim, mas o sinal móvel é forte. No caso da Amazon, há espaço para fazer algumas economias de big data no site para desktop e não devemos ficar complacentes apenas porque o tamanho da tela sugere que não estou em um dispositivo móvel.

Sim, devemos esperar um carregamento de página maior se nossa janela de visualização for do tamanho de uma área de trabalho, pois as imagens serão maiores e melhor otimizadas para a tela do que uma tela móvel mais granulada. Mas a página não deve ser muito maior.

Além disso, eu estava enviando o cabeçalho Save-Data com minha solicitação. Este cabeçalho indica explicitamente uma preferência pelo uso reduzido de dados, e espero que mais sites comecem a notar isso no futuro.

A carga inicial do 'desktop' pode ter sido de 6 MB, mas depois de ficar sentado e assisti-lo por um minuto, subiu para 8,6 MB quando os recursos de prioridade mais baixa e o rastreamento de eventos entraram em ação. Esse peso de página inclui quase 1,7 MB de JavaScript reduzido. Eu nem quero começar a olhar para isso.

Dica de desempenho nº 11: use Web Workers para seu JavaScript

O que seria pior — 1,7 MB de JavaScript ou 1,7 MB de imagens? A resposta é JavaScript: os dois ativos não são equivalentes quando se trata de desempenho.

Uma imagem JPEG precisa ser decodificada, rasterizada e pintada na tela. Um pacote JavaScript precisa ser baixado e então analisado, compilado, executado — e há várias outras etapas que um mecanismo precisa concluir. Esteja ciente de que esses custos não são totalmente equivalentes.
— Addy Osmani, O custo do JavaScript em 2018

Se você precisar enviar tanto JavaScript, tente colocá-lo em um web worker. Isso mantém a maior parte do JavaScript fora do encadeamento principal, que agora está liberado para repintar a interface do usuário, ajudando sua página da Web a permanecer responsiva em dispositivos de baixa potência.

Estou agora com cerca de 15,5 MB no meu orçamento e gastei $ 1,14 do meu orçamento de dados do Zimbábue. Eu teria que ter trabalhado meio dia como professor para ganhar o dinheiro para chegar até aqui.

Pinterest

Já ouvi falar bem do desempenho do Pinterest, então resolvi testá-lo.

Talvez este não seja o teste mais justo; Fui levado para a página de login, na qual um processo assíncrono descobriu que eu estava conectado ao Facebook e automaticamente. A página foi carregada com relativa rapidez, mas as solicitações aumentaram à medida que mais e mais conteúdo era pré-carregado.

No entanto, vi que em carregamentos de página subsequentes, o service worker exibia grande parte do conteúdo – economizando cerca de metade do peso da página:

O site Pinterest é um aplicativo da web progressivo; ele instalou um service worker para manipular manualmente o cache de CSS e JS. Agora eu poderia desligar meu WiFi e continuar usando o site (embora não muito útil):

Dica de desempenho nº 12: use Service Workers para fornecer suporte offline

Não seria ótimo se eu tivesse que carregar um site apenas uma vez pela rede e agora obter todas as informações de que preciso mesmo estando offline?

Um ótimo exemplo seria um site que mostra a previsão do tempo para a semana. Eu só precisaria baixar essa página uma vez. Se eu desligar meus dados móveis e, posteriormente, voltar para a página em algum momento, ela poderá fornecer o último conteúdo conhecido para mim. Se eu me conectar à Internet novamente e carregar a página, obterei uma previsão mais atualizada, mas os ativos estáticos, como CSS e imagens, ainda devem ser servidos localmente pelo service worker.

Isso é possível configurando um service worker com uma boa estratégia de armazenamento em cache para que as páginas armazenadas em cache possam ser acessadas novamente offline. O site de documentação do lodash é um bom exemplo de um service worker à solta:

O conteúdo que raramente é atualizado e provavelmente será usado com bastante regularidade é um candidato perfeito para o tratamento do service worker. Sites dinâmicos com feeds de notícias em constante mudança não são tão adequados para experiências offline, mas ainda podem se beneficiar.

Os service workers podem realmente salvar o dia quando você está com um orçamento de dados apertado. Não estou convencido de que a experiência do Pinterest tenha sido a melhor em termos de uso de dados - as páginas subsequentes estavam em torno da marca de 0,5 MB, mesmo em páginas com poucas imagens - mas deixando seu JavaScript lidar com solicitações de página para você e mantendo os mesmos elementos de navegação no lugar pode ser muito performático. A BBC gerencia um tamanho de transferência de apenas 3,1 KB para visitas de retorno a artigos que podem ser renderizados por meio do aplicativo de página única.

Até agora, o Pinterest sozinho consumiu 14 MB, o que significa que estourei cerca de 30 MB do meu orçamento, ou US $ 2,20 (quase um dia de salário) do meu orçamento do Zimbábue.

É melhor eu ter cuidado com meus 20 MB finais… mas onde está a graça nisso?

Local de jogos

Eu escolhi este porque parecia visivelmente lento no meu celular no passado e eu queria investigar os motivos. Com certeza, carregar a página inicial consome 8,5 MB de dados.

6,5 MB disso foi para um vídeo de reprodução automática no meio da página, que - para ser justo - não parecia ser baixado até que eu começasse a rolar. No entanto…

Eu só conseguia ver metade do vídeo na minha janela de visualização - o lado direito estava cortado. Também teve 30 segundos de duração, e eu apostaria que a maioria das pessoas não vai sentar e assistir a coisa toda. Esse único recurso mais que triplicou o tamanho da página.

Dica de desempenho nº 13: não pré-carregue o vídeo

Como regra, a menos que o principal modo de comunicação do seu site seja o vídeo, não o pré-carregue.

Se você for YouTube ou Netflix, é razoável supor que alguém que acessa sua página deseja que o vídeo seja carregado e reproduzido automaticamente. Há uma expectativa de que o vídeo vá mastigar alguns dados, mas que seja uma troca justa pelo conteúdo. Mas se você é um site cujo meio principal é texto e imagem – e você oferece conteúdo de vídeo adicional – então não pré-carregue o vídeo.

Pense em artigos de notícias com vídeos incorporados. Muitos usuários querem apenas dar uma olhada no título do artigo antes de passar para o próximo. Outros lerão o artigo, mas ignorarão qualquer incorporação. E outros clicarão diligentemente e assistirão a cada vídeo incorporado. Não devemos monopolizar a largura de banda de todos os usuários supondo que eles vão querer assistir a esses vídeos.

Para reiterar: os usuários não gostam de reprodução automática de vídeo. Como desenvolvedores, só fazemos isso porque nossos gerentes nos mandam, e eles só nos dizem para fazer porque todos os aplicativos mais legais estão fazendo isso, e os aplicativos mais legais só estão fazendo isso porque os anúncios em vídeo geram 20 a 50 vezes mais receita do que os tradicionais Publicidades. O Google Chrome começou a bloquear vídeos de reprodução automática para alguns sites, com base em preferências pessoais, portanto, mesmo que você desenvolva seu site para reproduzir vídeos automaticamente, não há garantia de que essa seja a experiência que seus usuários estão obtendo.

Se concordarmos que é uma boa ideia tornar o vídeo uma experiência opcional (clique para reproduzir), podemos dar um passo adiante e fazê-lo clicar para carregar também. Isso significa zombar de uma imagem de espaço reservado de vídeo com um botão de reprodução sobre ela e baixar o vídeo apenas quando você clicar no botão de reprodução. People on fast connections should notice no difference in buffer speed, and people on slow connections will appreciate how fast the rest of your site loaded because it didn't have to preload a large video file.

Anyway, back to Gamespot, where I was indeed forced to preload a large video file I ended up not watching. I then clicked through to a game review page that weighed another 8.5 MB, this time with 5.4 MB of video, before I even started scrolling down the page.

What was really galling was when I looked at what the video actually was. It was an advert for a Samsung TV! This advert cost me $0.40 of my Zimbabwe wages. Not only was it pre-loaded, but it also didn't end up playing anywhere as far as I'm aware, so I never actually saw it.

The 'real' video — the gameplay footage (in other words, the content) — wasn't actually loaded until I clicked on it. And that ploughed through my remaining data in seconds.

É isso. That's my 50 MB gone. I'll need to work another 1.5 days as a Zimbabwean schoolteacher to repeat the experience.

Performance Tip #14: Optimize For First Page Load

What's striking is that I used 50 MB of data and in most cases, I only visited one or two pages on any given site. If you think about it, this is true of most user journeys today.

Think about the last time you Googled something. You no doubt clicked on the first search result. If you got your answer, you closed the tab, or else you hit the back button and moved onto the next search result.

With the exception of a few so-called 'destination sites' such as Facebook or YouTube, where users habitually go as a starting point for other activities, the majority of user journeys are ephemeral. We stumble across random sites to get the answers to our questions, never to return to those sites again.

Web development practices are heavily skewed towards optimising for repeat visitors. “Cache these assets — they'll come in handy later”. “Pre-load this onward journey, in case the user clicks to read more”. “Subscribe to our mailing list”.

Instead, I believe we should optimize heavily for one-off visitors. Call it a controversial opinion, but maybe caching isn't really all that important. How important can a cached resource that never gets surfaced again be ? And perhaps users aren't actually going to subscribe to your mailing list after reading just the one article, so downloading the JavaScript and CSS for the mail subscription modal is both a waste of data and an annoying user experience.

The Decline Of Proxy Browsers

I had hoped to try out Opera Mini as part of this experiment. Opera Mini is a mobile web browser which proxies web pages through Opera's compression servers. It accounts for 1.42% of global traffic as of June 2019, according to caniuse.com.

Opera Mini claims to save up to 90% of data by doing some pretty intensive transcoding. HTML is parsed, images are compressed, styling is applied, and a certain amount of JavaScript is executed on Opera's servers. The server doesn't respond with HTML as you might expect — it actually transcodes the data into Opera Binary Markup Language (OBML), which is progressively loaded by Opera Mini on the device. It renders what is essentially an interactive 'snapshot' of the web page — think of it as a PDF with hyperlinks inside it. Read Tiffany Brown's excellent article, “Opera Mini and JavaScript” for a technical deep-dive.

It would have been a perfect way to eek my 50 MB budget as far as possible. Unfortunately, Opera Mini is no longer available on iOS in the UK. Attempting to visit it in the app store throws an error:

It's still available “in some markets” but reading between the lines, Opera will be phasing out Opera Mini for its new app — Opera Touch — which doesn't have any data-saving functionality apart from the ability to natively block ads.

Opera desktop used to have a 'Turbo mode', acting as a traditional proxy server (returning a HTML document instead of OBML), applying data-saving techniques but less intensively than Opera Mini. According to Opera, JavaScript continues to work and “you get all the videos, photos and text that you normally would, but you eat up less data and load pages faster”. However, Opera quietly removed Turbo mode in v60 earlier this year, and Opera Touch doesn't have a Turbo mode either. Turbo mode is currently only available on Opera for Android.

Android is where all the action is in terms of data-saving technology. Chrome offers a 'Lite mode' on its mobile browser for Android, which is not available for iPhones or iPads because of “platform constraints“. Outside of mobile, Google used to provide a 'Data Saver' extension for Chrome desktop, but this was canned in April.

Lite mode for Chrome Android can be forcibly enabled, or automatically kicks in when the network's effective connection type is 2G or worse, or when Chrome estimates the page will take more than 5 seconds to reach first contentful paint. Under these conditions, Chrome will request the lite version of the HTTPS URL as cached by Google's servers, and display this stripped-down version inside the user's browser, alongside a “Lite” marker in the address bar.

I'd love to try it out — apparently it disables scripts, replaces images with placeholders, prevents loading of non-critical resources and shows offline copies of pages if one is available on the device. This saves up to 60% of data. However, it isn't available in private (Incognito) mode, which hints at some of the privacy concerns surrounding proxy browsers.

O modo Lite compartilha o URL HTTPS com o Google, portanto, faz sentido que esse modo não esteja disponível no modo de navegação anônima. No entanto, outras informações, como cookies, informações de login e conteúdo de página personalizada, não são compartilhadas com o Google – de acordo com ghacks.net – e “nunca quebra as conexões seguras entre o Chrome e um site”. Alguém se pergunta por que aparentemente nenhum desses serviços de economia de dados é permitido no iOS (e não há notícias sobre se o modo Lite estará disponível no iOS).

Os proxies de economia de dados exigem muita confiança; sua atividade de navegação, cookies e outras informações confidenciais são confiadas a algum servidor, geralmente em outro país. Muitos proxies simplesmente não funcionam mais porque muitos sites mudaram para HTTPS, o que significa que iniciativas como o modo Turbo se tornaram um “recurso inútil”. O HTTPS evita esse tipo de comportamento man-in-the-middle, o que é bom, embora tenha significado o fim de alguns desses serviços de proxy e tenha tornado os sites menos acessíveis para aqueles com conexões ruins.

Não consegui encontrar nenhuma ferramenta de economia de dados compatível com OSX ou iOS, exceto Bandwidth Hero para Firefox (que requer a configuração de seu próprio serviço de compactação de dados - muito além dos recursos técnicos da maioria dos usuários!) 2017 e cheio de erros de digitação, eu simplesmente não conseguia confiar).

Conclusão

Reduzir a pegada de dados do seu site anda de mãos dadas com a melhoria do desempenho do front-end. É a coisa mais confiável que você pode fazer para acelerar seu site.

Além do custo dos dados, há muitos bons motivos para focar no desempenho, conforme descrito em uma postagem no blog do GOV.UK sobre o assunto:

• 53% dos usuários abandonarão um site mobile se ele demorar mais de 3 segundos para carregar.
• As pessoas precisam se concentrar 50% a mais ao tentar concluir uma tarefa simples em um site usando uma conexão lenta.
• Páginas da Web com melhor desempenho são melhores para a vida útil da bateria do dispositivo do usuário e normalmente exigem menos energia do servidor para fornecer. Um site de alto desempenho é bom para o meio ambiente.

Não temos o poder de mudar o custo global da desigualdade de dados. Mas temos o poder de diminuir seu impacto, melhorando a experiência de todos no processo.