- Desde 2017, o aumento de largura de banda superou até certo ponto o crescimento do tamanho de transferência de sites comuns, mas as exigências de CPU dos web apps cresceram mais rápido que o desempenho de dispositivos baratos, piorando a acessibilidade da web mesmo com internet rápida
- Mesmo em conexão de
1Gbps, oTecno Spark 8Csofre travamentos do navegador em fóruns Discourse, e noItel P32sites como Discourse, Reddit, Shopify, Substack, Wix, Mastodon e Bluesky ficam em estado de FAIL ou praticamente inutilizáveis - As medições compararam
LCP*e tempo de CPU da main thread emM3 Max,M1 Pro, Chrome com throttling de CPU em10x,Tecno Spark 8CeItel P32; a pontuação do PageSpeed Insights teve pouca correlação com a velocidade percebida no uso real - Sites simples ou antigos como MyBB, phpBB, WordPress antigo, HN e danluu.com funcionaram relativamente bem mesmo em celulares de baixo custo, enquanto sites com muito carregamento dinâmico como Discourse, Medium, Reddit e Substack mostraram forte atraso em rolagem, busca e toques
- Usuários de dispositivos baratos em regiões como Nigéria, Índia e América Latina são usuários reais da web; construir a web tomando apenas iOS e internet rápida como referência exclui tanto usuários menos ricos quanto usuários de desktops de baixa especificação
A web em que a CPU virou gargalo mais do que a largura de banda
- Em 2017, o inchaço da web prejudicava fortemente a usabilidade em conexões lentas, e desde então a largura de banda de conexões avançadas cresceu rapidamente, em torno de
50%ao ano segundo o critério de Nielsen - Ainda há muitos usuários com internet lenta, e boa parte da web moderna continua difícil de usar nessas conexões, mas em sites comuns o aumento de largura de banda superou até certo ponto o aumento do tamanho transferido
- Em contrapartida, as exigências de desempenho de CPU dos web apps não melhoraram tão rápido quanto a largura de banda, então mesmo com boa conexão à internet a web fica difícil de usar em dispositivos fracos
- Fóruns “modernos” baseados em Discourse chegam a causar travamentos do navegador no
Tecno Spark 8C, e a responsividade entre um travamento e outro foi medida como pior do que usar um BBS com8 MHz 286e modem1200 baud - No Discourse, o payload comprimido para carregar títulos de mensagens é de
2.6 MB, um nível de transferência cerca de1000xmaior do que no passado, mas relativamente leve em conexão de1Gbps - Do lado da CPU, até o
Tecno Spark 8Ccom8-core (2 1.6 GHz Cortex-A75 / 6 1.6 GHz Cortex-A55)não consegue dar conta do Discourse, embora essa CPU seja cerca de100000xmais rápida que um286
Dispositivos e métricas da medição
- Os dispositivos de teste foram
M3 Max Macbook (14-core),M1 Pro Macbook (8-core),M3 Maxcom throttling de10xno Chrome DevTools,Tecno Spark 8CeItel P32 - A rede foi configurada para favorecer os dispositivos, usando internet de
1Gbpse um roteador Wi‑Fi com baixa latência sob carga em benchmarks - Os alvos de comparação incluíram blogs e microblogs, fóruns e plataformas para pequenos negócios
- Blogs e microblogs: danluu.com, Substack, Medium, Ghost, Hugo, Tumblr, Mastodon, Twitter, Threads, Bluesky, Patreon
- Fóruns: Discourse, Reddit, Quora, vBulletin, XenForo, phpBB, MyBB
- Plataformas para pequenos negócios: Wix, Squarespace, Shopify, WordPress
- As principais métricas foram tamanho comprimido transferido (
wire), tamanho descomprimido (raw),LCP*e tempo de CPU da main thread LCP*não é o Largest Contentful Paint medido pelo Chrome, mas um critério baseado no momento em que o conteúdo realmente útil passa a estar visível para o usuário, quando grandes atualizações de tela não são úteis- Tempo de CPU não é uma Core Web Vital, mas foi usado como métrica simples por se alinhar fortemente com a usabilidade percebida por usuários em dispositivos lentos
A lacuna de usabilidade revelada na tabela
- danluu.com e HN rodaram rápido em todos os dispositivos testados
- danluu.com:
6kB wire / 18kB raw,0.4s LCP* / 0.3s CPUnoTecno Spark 8C - HN:
11kB wire / 50kB raw,0.5s LCP* / 0.5s CPUnoTecno Spark 8C
- danluu.com:
- Fóruns antigos baseados em PHP se saíram muito melhor que fóruns modernos em dispositivos lentos
- MyBB:
0.8s LCP* / 0.8s CPUnoTecno Spark 8C - phpBB:
1.7s LCP* / 1.5s CPU - vBulletin:
4.4s LCP* / 4.8s CPU - Discourse:
15s LCP* / 26s CPUeFAILnoItel P32
- MyBB:
- Também nas plataformas de blog, temas antigos de WordPress foram muito mais rápidos em dispositivos fracos do que Medium e Substack
- WordPress(old):
0.7s LCP* / 1.7s CPUnoTecno Spark 8C - Medium:
2.8s LCP* / 33s CPU - Substack:
14s LCP* / 14s CPU
- WordPress(old):
- Vários sites modernos falharam no
Itel P32ou eram praticamente inutilizáveis- XenForo, Mastodon, Bluesky, Wix, Substack, Shopify, Discourse e Reddit:
FAIL - Threads:
28s LCP* / 66s CPU, Twitter:24s LCP* / 43s CPU, Medium:3.2s LCP* / 63s CPU
- XenForo, Mastodon, Bluesky, Wix, Substack, Shopify, Discourse e Reddit:
- Páginas que consomem
10s+ CPUcontinuam oferecendo uma experiência ruim mesmo depois do carregamento- A rolagem cai para poucos FPS e o atraso no toque é tão grande que o usuário não sabe se o toque foi registrado
- Ao tocar de novo, o primeiro toque pode acabar sendo registrado tarde, e o segundo pode disparar uma ação inesperada
Diferenças entre dispositivos reais e throttling de CPU
- O throttling de CPU do Chrome DevTools é prático, mas não aproxima de forma consistente o resultado de dispositivos lentos reais
- Na comparação entre
M3/10eTecno Spark 8C, a diferença variou muito conforme o site- danluu.com e Ghost tiveram aproximação razoável
- Medium, Substack e Twitter foram cerca de
3xmais lentos em tempo de CPU noTecno Spark 8C - Reddit e Discourse foram cerca de
4xmais lentos - Shopify apresentou resultado em que o
Tecno Spark 8Cfoi mais de uma ordem de grandeza mais rápido queM3/10
- Em páginas lentas, o desempenho pode piorar superlinearmente à medida que o dispositivo fica mais lento, e a lentidão de uma página não prevê bem a de outra
- Discourse, Medium e Reddit parecem não usar tanta CPU em
M3eM1, mas entram entre os mais lentos noTecno Spark 8C - No Reddit, mesmo sem interação e só esperando, o uso fica em
~90% CPU, então a CPU aparece como∞
A força de sites antigos e páginas simples
- Em geral, sites antigos foram mais rápidos que os modernos, e os que quase não mudaram visualmente em 10 a 20 anos ficaram entre os mais rápidos
- MyBB foi
3.6x / 5xmais rápido que Discourse noM3e19x / 33xmais rápido noTecno Spark 8C - WordPress(old) foi medido como
17.5x / 10xmais rápido que Medium noM3 Maxe4x / 19xmais rápido noTecno Spark 8C - Ghost, embora seja uma plataforma moderna lançada um ano depois do Medium, é uma exceção que mostra desempenho capaz de competir com plataformas antigas
- NodeBB também ficou próximo de uma exceção entre fóruns modernos nos testes do apêndice
0.3s / 0.4snoM13.4s / 7.2snoTecno Spark 8C- Muito mais rápido que Discourse, com rolagem e toques funcionando de forma básica após o carregamento
As armadilhas do carregamento dinâmico e da otimização para métricas
- Sites como Discourse, Reddit e Substack, que carregam primeiro só parte da página e depois buscam o resto dinamicamente, têm usabilidade real pior do que a sugerida pelos números da tabela
- Em dispositivos lentos, é difícil prever a distância de rolagem, e rolar longe demais pode disparar carregamento extra e travar a página
- Páginas que removem conteúdo já rolado ficam praticamente inutilizáveis em dispositivos lentos
- Páginas com carregamento dinâmico dificultam usar a busca rápida do navegador com
Ctrl/Command+Fe acabam precisando implementar uma busca própria- A busca no Google Docs tem carregado tão tarde nos últimos meses ou cerca de um ano que não dá para usar logo após abrir o documento
- A busca do Discourse nunca funcionou bem em dispositivos lentos ou mesmo em dispositivos não tão rápidos
- Em teoria, mais trabalho de CPU no início poderia acelerar interações posteriores, mas nas páginas testadas o carregamento inicial, os carregamentos seguintes e a interação após carregar foram todos lentos
A gamificação do LCP
- O
LCPfoi criado para estimar quando o conteúdo principal da página aparece para o usuário, mas a medição do Chrome fica mais próxima de detectar quando ocorreu uma grande pintura na tela - Alguns sites reduzem o
LCPexibindo rapidamente uma tela de carregamento grande que não ajuda o usuário, e depois dividem o conteúdo real em pequenas atualizações para que ele não entre noLCP - O Discourse introduziu publicamente o Discourse Splash e informou que uma grande tela de splash em carregamentos lentos reduzia bastante o
LCP - A resposta oficial do Discourse foi, em essência, que se o banner com o conteúdo real fosse maior que o splash isso pioraria o
LCP - Os casos com maior diferença entre o
LCP*baseado em conteúdo útil e oLCPmedido pelo Chrome foram Wix e Discourse- Wix:
6xnoM3,12xnoM1,3xnoTecno Spark 8C - Discourse:
10xnoM3,12xnoM1,4xnoTecno Spark 8C
- Wix:
O impacto da otimização de desempenho nos negócios
- Em grandes empresas, melhorar o desempenho de sites e apps tinha valor financeiro grande o bastante para ser medido em testes A/B
- Mesmo em holdbacks de longo prazo, melhorias de desempenho apareceram como intervenções com impacto relativamente grande em crescimento e retenção
- No Twitter, a latência p99 observada pelos usuários era de cerca de
60snão só na Índia e em vários países africanos, mas também nos Estados Unidos - Em cada país havia usuários suficientes com dispositivos ou conexões lentas, então o fator limitante estava mais próximo da paciência do usuário do que da distribuição média de dispositivos e conexões da população como um todo
- Reduzir de
60spara50sem dispositivos lentos pode corresponder, para usuários de aparelhos avançados, a algo como cair de5spara4.5s, com efeitos sobre receita, crescimento e retenção
Projetando com dispositivos de baixa especificação em mente
- Em dispositivos lentos ou em conexões de baixa largura de banda e instáveis, a melhor experiência em geral vem de carregar bastante conteúdo de uma vez em uma página estática
- Ter atributos adequados de
width,heightealtnas imagens ajuda, mas JPEG progressivo não trouxe benefício especialmente grande - Em dispositivos lentos com conexão rápida, páginas estáticas leves funcionam bem, e páginas dinâmicas leves com cuidado de desempenho também podem funcionar
- Em páginas pesadas, carregamento extra durante a rolagem e interceptação da busca quebram modelos de interação utilizáveis
- No Substack, um texto pode ter
LCPrápido em um iPhone 8, mas para rolar abaixo do cabeçalho pode ser preciso esperar6spelo carregamento da próxima parte da página e depois ainda esperar1s~2s - No caso oposto, páginas grandes em HTML puro funcionam relativamente bem mesmo em dispositivos fracos
https://danluu.com/diseconomies-scale/tem0.1 MB wire / 0.4 MB rawhttps://danluu.com/threads-faq/tem0.4 MB wire / 1.1 MB raw- Uma página de texto de
1.1 MBfunciona melhor em dispositivos lentos do que a maioria dos sites modernos
- A documentação da biblioteca padrão de Zig baixa todo o código-fonte no início e renderiza localmente, mas depois de
4.7sde CPU noTecno Spark 8Cmantém responsividade relativamente boa
Usuários de baixa renda e acessibilidade
- O
Tecno Spark 8Cpode ser encontrado por cerca deUSD 50-60na Nigéria eUSD 100-110na Índia, mas essa faixa representa uma parcela da renda familiar mediana muito maior do que um iPhone atual nos EUA - Em escala global, o
Tecno Spark 8Cnão está nem perto de ser o aparelho mais barato, e oItel P32também fica acima de muitos dispositivos de menor especificação realmente usados - Segundo Alex Russell, a participação do iOS é de
7%na Índia e6%na América Latina - Pela telemetria do Windows, a maioria dos usuários de notebooks e desktops usa dispositivos de baixa especificação que provavelmente são mais lentos que um iPhone recente
- Entre os aparelhos “lifeline” fornecidos a pessoas elegíveis, há iPhone 6 e iPhone 8, mas também muitos aparelhos piores que o
Itel P32; além disso, o limite de dados é pequeno, e depois que acaba pode ficar difícil procurar emprego, preencher formulários de benefícios ou usar o Maps - Apps móveis podem ser baixados antecipadamente quando há boa conexão, mas web apps que exigem baixar vários MB de JavaScript comprimido a cada acesso se tornam inviáveis em conexões limitadas
Condições e limitações do experimento
- Cada site foi medido tentando encontrar a experiência “mais básica” possível
- WordPress usou a demo do tema padrão atual
twentytwentyfour - Shopify usou o primeiro tema exibido na lista de temas
- Discourse, vBulletin, XenForo, phpBB e MyBB usaram páginas encontradas em fóruns oficiais
- WordPress usou a demo do tema padrão atual
- O trabalho foi um projeto curto, com coleta e análise dos dados em um único dia, portanto não reflete necessariamente os temas mais comuns nem a distribuição real de customizações feitas pelos usuários
- Os notebooks foram testados com cerca de
60%de bateria, fora da tomada, em ambiente de20°C, após ficarem próximos do equilíbrio térmico - Os celulares foram testados com cerca de
100%de carga, conectados à energia e sem outros apps ou abas abertos - No uso real, a maioria das pessoas provavelmente verá desempenho ainda pior no mesmo aparelho por causa de mais apps e tarefas em segundo plano
- Os tamanhos foram medidos no mobile, então quando mobile e desktop recebiam assets diferentes os números refletem os assets mobile
CPUfoi medida como tempo de CPU da main thread; o tempo de outras threads foi registrado, mas não usado na métrica
Casos de destaque por site
- Wix não estabiliza corretamente a rolagem no
Tecno Spark 8Ce falha de forma não determinística noItel P32 - Patreon tem desempenho de rolagem pior do que os números de carregamento inicial sugerem; a experiência é tão ruim para encontrar posts antigos que foi preciso manter um índice separado de posts do Patreon
- O Discourse tem
LCPfortemente gamificado; mesmo em1GbpsnoM3 Max, oLCPmedido pelo Chrome foi de115ms, mas o conteúdo real só carregou em1.1s - Bluesky mostra tela em branco no
Itel P32 - Os dois primeiros casos reais de Shopify vistos foram ambos bem mais lentos do que a página de demo testada
- Tumblr gera erro de JavaScript no
Itel P32, mas isso acabou fazendo a página carregar mais rápido, e rolagem e cliques em links funcionaram - MyBB não oferece versão mobile, o que pode prejudicá-lo no Google, mas em celulares lentos a rolagem e os toques realmente funcionam bem
- Woo Commerce é difícil de comparar com Shopify apenas pela performance de carregamento inicial; seria preciso uma comparação separada incluindo fluxos reais como carrinho e checkout, por isso ficou fora da tabela
1 comentários
Comentários do Hacker News
Recentemente, ao usar um celular Android relativamente lento, ficou claro que até páginas da web que parecem ter apenas texto e imagens podem ser realmente penosas para carregar.
O gargalo real parece estar menos na rede e mais em rastreadores, anúncios e no inchaço do JavaScript.
Em celulares antigos e lentos, até um navegador completo como o Firefox para mobile é pesado demais, então a pessoa acaba usando um navegador mais leve, como o Firefox Focus; mas, sem extensões, também não dá para usar o uBlock Origin, e a experiência na web piora ainda mais.
Alguns sites reclamam quando não se usa um navegador “padrão” e ficam unusable, enquanto as empresas forçam a instalação de apps no lugar.
Antigamente havia versões simplificadas para dispositivos e conexões lentas, mas elas estão desaparecendo cada vez mais, provavelmente porque é difícil manter redes de anúncios e rastreamento sem o inchaço do JavaScript.
Isso é ainda pior quando anúncios aleatórios são enfiados em páginas com rolagem infinita.
Um exemplo recente: a loja online da Nike exibiu um erro inútil durante o checkout, e o suporte apenas disse para “tentar usar o app”.
Sites de reserva de companhias aéreas europeias também são exemplos clássicos de sites de grandes empresas que quebram com frequência.
É estranho achar que, em 2024, não conseguir fazer um site funcional mesmo com recursos praticamente ilimitados não afeta negativamente a marca.
Ele precisava funcionar em todos os países, e muitos dos celulares mais lentos eram produtos da própria empresa.
Ele não é rápido, mas não tenho dificuldade para usar sites; só não é tão instantâneo quanto hardware novo, mas ainda é perfeitamente utilizável.
Porém, uso o uBlock Origin.
Fico curioso se esses dispositivos Android são, na prática, realmente mais fracos do que um MacBook de configuração básica com 11 anos de idade.
Concordo fortemente com o ponto do Dan de que precisamos estar cientes do nível de desigualdade no mundo, mas isso também deveria incluir países de renda média, como os da América Latina e do Sudeste Asiático.
Por exemplo, há usuários com franquias mensais de dados de um dígito em GB e RAM/CPU no nível dos flagships dos EUA de 10 anos atrás.
Não chega a ser o caso de não conseguir usar o Discourse, mas a experiência provavelmente será desagradavelmente lenta.
Acho que, quando Dan vê melhorias incrementais de CPU/RAM/disco aumentando a participação de forma mensurável, é principalmente por causa desse grupo de usuários.
Os gráficos do Dan mostram que usuários de dispositivos ultrabaratos, como o Itel P32, não ganham muita coisa com otimizações incrementais.
O que poderia ajudar seria uma estrutura de cliente completamente diferente, que sacrificasse recursos e refinamento para entregar o código mais enxuto possível — algo como um modo lite/básico alternativo.
Só que essa abordagem raramente dá certo, porque o problema de empatia volta a aparecer: desenvolvedores americanos tendem a julgar mal o que manter e o que descartar em nome da performance.
Fico me perguntando o que o Discourse atual oferece a mais do que o PhpBB ou fóruns em DLang.
Tirando o design amigável para mobile, em um mundo normal algumas linhas de CSS responsivo deveriam bastar.
Um plano mensal de 30 GB custa US$ 3,64, cerca de 4 a 6 horas de trabalho pelo salário mínimo.
O ponto mais importante é que as pessoas não gastam dados indiscriminadamente como no Ocidente.
Há Wi-Fi grátis em cafés, restaurantes, supermercados e shoppings, e a maioria das pessoas pergunta a senha do Wi-Fi antes mesmo de perguntar pelo cardápio.
Nunca vi nem ouvi alguém dizer que sites gastam dados rápido demais.
Isso soa como uma preocupação inventada por pessoas que nunca moraram de fato em um país em desenvolvimento.
Aqui, quando os dados acabam, é por assistir vídeos no TikTok, Instagram e Facebook, não por causa do inchaço dos sites.
O mesmo vale para o bloatware que vem instalado junto com o computador.
Comprei um notebook novo recentemente e me ofereceram uma “otimização” de US$ 50.
É estranho se você imaginar uma concessionária oferecendo algo assim em um carro novo.
Em um lugar com sinal ruim, o problema fica 10 vezes pior.
Não estou falando de UIs complexas em que cabeçalhos fixos e anúncios deixam só um terço da tela visível, mas do tamanho dos próprios sites, montados de qualquer jeito até parecerem um documento de design.
Um site que já seria inchado mesmo se fosse bem feito se torna inutilizável em uma conexão lenta, sem falar em hardware lento.
É difícil imaginar como deve ser usar a internet no ambiente descrito, e só espero que essas pessoas usem sites locais ajustados à sua largura de banda e aos seus dispositivos, em vez de lidar com o lixo inchado que nós enfrentamos.
A maioria dos sites é quase uma tortura.
É interessante que a maioria só culpe o chefe ou as grandes corporações assustadoras
Desenvolvedores não admitem que também existe um grande grupo de programadores web sem competência suficiente que não entende bem eficiência e nem parece querer entender
Tanto quanto os chefes ou a elite corporativa que os obrigou a criar software ruim, eles também são responsáveis por este triste mundo do software web
Quando eu perguntava sobre detalhes concretos do “resultado final”, ou seja, HTML, CSS, JS, olhavam para mim como se eu estivesse falando outra língua
Elas vinham do mundo dos frameworks JavaScript e não pensavam muito no resultado gerado por baixo
Minha filosofia é praticamente o oposto: perguntar qual é o mínimo de código manutenível que produz um resultado equivalente a um site em HTML+CSS+JS bem escrito à mão
Normalmente, o resultado fica algumas ordens de grandeza menor
Quando perguntaram como eu tinha feito uma tabela com 1000 linhas carregar rápido e funcionar bem no celular, com filtragem em tempo real, eu disse que apenas enviava todos os dados na primeira requisição e ocultava dinamicamente os dados que não correspondiam ao filtro
O servidor web só precisava entregar os mesmos dados em cache para todo mundo, e esse era também todo o JavaScript executado no site, então, para eles, parecia estranhamente rápido
Quando se olhava o HTML de linhas de tabela semelhantes na solução baseada em framework deles, 80% era boilerplate que nem era usado
O desenvolvimento web ficou engessado demais, e muita gente se afastou demais da essência das tecnologias web
Se o público principal fossem usuários dos EUA ou da UE, até poderia fazer sentido não otimizar demais para hardware fraco e conexões instáveis, de baixa largura de banda e alta latência
Mas, se o alvo era a África rural, uma otimização agressiva parecia óbvia
Só que a homepage carregava uma imagem gigantesca de 2 MB reduzida por CSS para 500×1000 pixels, e o que vinha depois era ainda pior
Não lembro o tamanho exato do payload de JS, mas era de vários MB, e o front-end era extremamente pesado, embora a maior parte parecesse uma aplicação backend tradicional baseada em templates
Candidatei-me porque o conceito era bom, mas a tecnologia era horrível
Como nem cheguei à primeira etapa da entrevista, não sei por que era assim, mas é difícil imaginar outra coisa além de desenvolvedores da Europa Ocidental não perceberem direito o que estavam fazendo nesse aspecto
O ponto de partida não é o desenvolvedor, é o orçamento
Se a alta liderança não entende de tecnologia ou não tem formação em engenharia, normalmente aloca orçamento para novos recursos, mas subestima ou simplesmente não aloca nada para manutenção e eliminação de dívida técnica
Mesmo quando há orçamento de manutenção, ele quase sempre fica a cargo de uma equipe de manutenção offshore mais barata
Uma equipe de funcionalidades passa 6 meses criando um recurso, faz uma “sessão de KT” de 1 hora com a equipe de manutenção offshore e depois entrega o código
A equipe offshore tem alguma informação sobre a funcionalidade, mas não o suficiente para lidar com a dívida técnica existente; ela apenas mantém as luzes acesas
Quando esse ciclo se repete de 100 a 1000 vezes dentro da organização, rapidamente se chega a um front-end com 2 milhões de linhas que originalmente poderia ter, no máximo, 250 mil
Mesmo que os melhores engenheiros entrem em uma nova equipe de funcionalidades, precisam trabalhar dentro da caixa que já foi criada
Se o mockup e os elementos não batem, pode ser que o mockup esteja errado, que o kit de UI tenha sido atualizado ou que o kit de UI existente precise de refatoração, mas não há orçamento para isso
Então a equipe recebe a instrução de copiar o componente e modificá-lo para a sua funcionalidade
Na hora de entregar para a equipe de manutenção, a nova equipe também não quer mexer no trabalho de funcionalidades existente, então deixa como está
A gestão não técnica não sabe a diferença e, depois de anos de equipes copiando/colando para encaixar novos recursos, a base de código acaba com mais de 50 componentes chamados “Button”
Se a equipe tiver desenvolvedores experientes que valorizem eficiência, e eles insistirem em um site mais eficiente ou o criarem de forma mais eficiente desde o começo, a página pode melhorar
Mas, na maior parte dos casos, é um problema de incentivos
Se a gestão não se importa, é provável que o programador prefira fazer algo funcionar em metade do tempo e avançar o backlog, em vez de gastar tempo melhorando a eficiência
Por isso, dispositivos lentos são um ótimo filtro para evitar lixo
Só recentemente troquei meu flagship da LG de 6 anos por um Galaxy novo, e a diferença de desempenho foi enorme
Isso não deveria acontecer
Na época do lançamento, era um aparelho muito premium, não é tão antigo assim e ainda funciona como novo
Como os Galaxy S9 que usamos para testes passam pelas mesmas dificuldades, não é um problema só do meu celular
Eu gostaria que a Amazon tivesse entrado nos testes
Pela minha experiência, o site da Amazon está entre os piores dos piores em dispositivos móveis com mais de 4 anos
Mesmo em hardware móvel premium relativamente recente, era praticamente o único site que eu acessava regularmente que chegava a ser quase inutilizável
Uso no dia a dia um OnePlus 5 com Android 14 via LineageOS, e a experiência de usuário em tarefas que não são jogos é boa o bastante
Esse celular tem 6 GB de RAM, algo comparável até a intermediários atuais
Minha única reclamação é que precisei trocar a bateria e desmontar o celular é chato
Por outro lado, um Galaxy S8 com o mesmo SoC, 4 GB de memória e Android 9 de fábrica com modificações da Samsung engasga sem parar
A diferença de 2 GB de memória pode influenciar, mas a diferença entre os dois celulares é da noite para o dia
Não sei se o gerenciamento de memória do Android 14 é muito melhor que o do Android 9 ou se o software lento e inchado da Samsung está segurando o aparelho
De qualquer forma, é irritante que muitas empresas não testem em dispositivos antigos e de baixo custo
Se o público é global, é preciso considerar que a maior parte do mundo não usa o flagship mais recente
Na prática, ela não funciona tão mal assim
Claro, concordo que isso não deveria ser necessário
Mas uso o Firefox com todos os bloqueadores de anúncios, então isso parece ajudar
A tecnologia de hoje é indiferente demais até com pessoas que não estão familiarizadas com tecnologia
Vejo os smartphones como o principal exemplo
Já vi muita gente que mal consegue usar o próprio aparelho, ou não o entende de jeito nenhum, e para elas tudo parece magia negra
O maior problema é a dependência excessiva da navegação por gestos, que, por não ser visível, é como se não existisse
Até dá para descobrir de algum jeito a barra de gestos do iPhone, mas não há noção alguma de Central de Notificações ou Central de Controle
Essas pessoas não são burras; em outras áreas, podem ser muito melhores do que eu
Em tecnologia, o problema não é falta de esforço, e sim falta de interfaces intuitivas
Para ver a documentação de fato, é preciso chegar até a página de documentos no site da Apple e, fuçando um pouco mais, aparece uma página que mostra por alto alguns gestos possíveis
Sobre quando usar qual gesto, não há mais do que um exemplo em uma frase
E isso é só sobre o sistema operacional
Fico me perguntando quantos apps fornecem junto uma documentação explicando como os recursos por gestos são usados no próprio app
https://support.apple.com/guide/iphone/learn-basic-gestures-...
Elas certamente cresceram cercadas por esses aparelhos
Então não acho que seja uma falha exclusiva da tecnologia moderna
Em vez de permitir que o usuário escolha o design e a interação que combinam com ele, o designer ou responsável pelo produto age como se soubesse o que é melhor para todos os usuários
Foi uma das minhas maiores reclamações depois de vir do Android
Onde está o botão de voltar, onde está o botão home, e onde estão os próprios botões?
Detesto de verdade a obsessão da Apple por minimalismo e, quando este celular morrer, vou voltar para o Android
Este texto é basicamente difícil de ler para mim, que tenho 48 anos, no desktop
Ao adicionar o seguinte ao
bodynas ferramentas de desenvolvedor, ele ficou legívelfont-size: 18px;line-height: 1.5em;max-width: 38rem;Dá para ver como isso fica mais fácil de ler e bonito
Leio muitos textos do Dan Luu, mas preciso mudar assim toda vez
Falando sério, pessoal de tecnologia: tornar uma página mais legível custa só 64 bytes a mais
Aquela página estava quase boa; bastava ampliar com CTRL +
A página é praticamente texto puro e quase não tem interação
Você tem uma solução adequada ao seu caso de uso, e eu tenho a minha
Leitores com deficiência visual também conseguem acessá-la com a própria solução
Como o código-fonte é simples, as soluções de acessibilidade também ficam razoavelmente simples
Acho que Dan sabe como se comunicar de forma eficaz
É manter simples e não presumir que será necessariamente lido com os olhos
A pessoa consegue mudar facilmente a apresentação de acordo com seu objetivo
Se não gostar desse modo de exibição, pode reformatar por conta própria antes de ler
É como se Dan entregasse a mensagem em um fluxo simples de texto, fácil de manipular
O público do Luu, no geral, provavelmente prefere uma abordagem relativamente sem estilo
O usuário pode alterar o tamanho da janela, o tamanho da fonte, as cores etc. conforme suas preferências
Não deveria ser necessário mudar isso arquivo por arquivo toda vez; deveria ser permitido adicionar e usar um arquivo CSS de usuário aplicável a vários arquivos
Isso fica na página de configurações padrão do Firefox
Se um site força
font-size: 18px;, para usuários que escolheram uma fonte maior no navegador o texto pode acabar ficando menorMas também dá para usar o modo de leitura do navegador, e isso é um clique só, em vez de passar por várias etapas nas ferramentas de desenvolvedor
Para constar, no Raspberry Pi 3 não dá para usar o YouTube
Isso ficou assim ao longo do último ano; antes disso, ainda era possível “assistir” a vídeos a uns 10–15 FPS, o que era suficiente para ver vídeos de reparo na oficina
Quando o Raspberry Pi Model B, ou seja, o primeiro modelo, foi lançado, dava para reproduzir vídeos em 1080p do repositório, assistir ao YouTube e até jogar
Não sei o que o YouTube está fazendo, nem o que outros serviços estão fazendo
Se levamos a crise e as mudanças climáticas a sério, essas artimanhas do Google e da Meta deveriam ser examinadas com muito rigor
Queimar ciclos de CPU em nome do lucro — chutando de improviso, por causa de ad tech — a ponto de quebrar o YouTube em dispositivos de baixa potência deveria ser duramente criticado pela imprensa, e deveríamos usar serviços mais eficientes mesmo que a experiência geral de usuário fosse pior
O Pi3 tem aceleração por hardware para x264, mas há algum tempo o YouTube começou a usar outros codecs
Mesmo em um MacBook Air Intel do começo de 2021, os vídeos travam aleatoriamente sob carga moderada, algo que antes não acontecia
Atacar isso para resolver as mudanças climáticas faz tão pouco sentido quanto proibir canudos de plástico ou sacolas plásticas
Como outro ponto de referência, o YouTube de 10 anos atrás teria funcionado perfeitamente nesse hardware
O culpado é o inchaço geral da web e, mais especificamente, os monstros de abstração que se tornaram comuns em JS
Mesmo para alguém que não acredita nem um pouco na “crise climática”, dá para dizer que, com o tempo, o artesanato e a qualidade desapareceram e geraram essa bagunça
Por isso acho que é um tema com o qual todos, em todo o espectro político, podem concordar
Poderia ser no estilo Consumer Reports, ou um add-on que funcione como a audiência Nielsen
Aquele pessoal do Discourse é um exemplo típico de quem projeta produtos com base não no mundo real em que vivemos, mas no mundo em que gostaria de existir
Existem bilhões de dispositivos com SoC Qualcomm, eles continuarão existindo e continuarão sendo fabricados e vendidos
Reclamar, por mais que seja, não vai mudar isso
É preciso aceitar e otimizar para esses dispositivos
Os usuários desses aparelhos não se importam com as reclamações dos desenvolvedores; se o software trava, eles simplesmente vão achar que são desenvolvedores de software incompetentes
Normalmente gosto dos textos do Dan Luu, mas achei que este errou o alvo
A tabela de LCP/CPU era boa, mas depois disso o texto descambou para psicologia de poltrona
Com base em alguns comentários aleatórios do fundador do Discourse, ele pede ao leitor que imagine as atitudes dos engenheiros de software
Até arrastou Knuth para baixo com base em declarações sobre desempenho single-core versus multi-core e sobre o Itanium, mas esses são pontos antigos de debate acadêmico
Achei o texto fraco demais e dependente demais de brigas de internet para se sustentar direito
As falas do fundador do Discourse são apenas muito explicativas
Se você usou a web recentemente, ela ficou tão inchada, a um ponto além da imaginação, que o Google agora chama Largest Contentful Paint de 2,4 segundos de rápido: https://blog.chromium.org/2020/05/the-science-behind-web-vit...
Isso é de 4 anos atrás, então é bem possível que hoje esteja ainda pior
Não é preciso ir longe: do YouTube carregando 2,5 MB de CSS no desktop até o fundador da Vercel se gabando de um site supostamente muito rápido que, com uma limitação pequena, leva 20 segundos para carregar: https://x.com/dmitriid/status/1735338533303259571
Se o tempo de resposta de um simples serviço de API para o frontend é de 500 ms, ninguém dá risada
Também me pergunto quantos engenheiros sabem quanto gastam com cloud e realmente se importam com isso
A paralelização de hoje não é usada em 90% dos softwares, exceto em casos de uso especializados ou quando se executa o mesmo programa single-thread em vários itens de dados
Tanto as linguagens de programação quanto o hardware não oferecem bom suporte à paralelização de granularidade fina, e tornar software clássico rápido com uma abordagem paralela é muito difícil
Luu, na verdade, escreveu de forma bem generosa
Knuth estava mais perto de reclamar que o almoço grátis que durou décadas estava acabando
Jeff Atwood foi apenas o exemplo escolhido
Pensadores famosos de desenvolvimento web com muitos seguidores continuam despejando pontos de vista parecidos, e muitos seguidores simplesmente aceitam o que eles dizem
Todas as empresas pararam de se importar, especialmente aquelas que antes estavam na linha de frente dos padrões e das boas práticas de design para a Web, como Google e Apple.
Recentemente, o Google encerrou o HTML Gmail, que rodava rápido e bem até em um celular Android de 2008 com 256 MB de RAM e em versões antigas do Firefox.
Naturalmente, a nova versão inchada em JavaScript simplesmente mata o navegador.
É um exemplo extremo, mas celulares de baixo custo têm 2 GB de RAM, e hoje é difícil esperar um desempenho razoável ao navegar na Web com esses aparelhos.
A Web móvel é horrível, e isso é intencional para empurrar os usuários para apps “nativos”.
Porque assim fica mais fácil para empresas como Apple e Google coletarem dados e exibirem anúncios.
Os sites delas são péssimos no celular, e o da Decathlon é péssimo até em desktops que não são de alto desempenho.
Mas elas nem recomendam o app de forma muito destacada, então acho que é simplesmente incompetência.
Parece que os desenvolvedores testam tudo apenas em aparelhos topo de linha conectados ao backbone.
RIP Google
O Reddit novo é inutilizável, e o old Reddit é velho demais.
A Twitch é quase utilizável por causa dos problemas de chat e de stream de vídeo.
A lista é longa.
Quando você já tem a fórmula final, toda mudança vira uma mudança ruim para garantir emprego.
Um dia, os macacos neste pedaço de terra vão perceber que empregos e dinheiro não existem, mas aí já será tarde demais.
Não, isso é agora.
RIP Humans