Há um número que deveria temperar qualquer plano de crescimento voltado aos próximos bilhões de usuários. Google e SOASTA, medindo sessões móveis reais, descobriram que 53% das visitas móveis são abandonadas quando a página leva mais de três segundos para carregar, e que a probabilidade de rejeição sobe 90% quando o carregamento passa de um segundo para cinco. Agora cruze esse número com o lugar onde esses próximos bilhões realmente estão. Na África Subsaariana, mais da metade dos usuários móveis ainda está no 3G; em 2024, um terço de todas as conexões eram 3G, e dois terços dos internautas dependem de celulares 3G ou básicos. Eles pagam, em média, 2,4% da renda mensal por um único gigabyte de dados, acima do limite de acessibilidade da ONU. O público que você cruzou o oceano para captar é, precisamente, o que uma página dependente da rede tem mais chances de perder no spinner de carregamento.
E, ainda assim, a forma padrão como um app de tráfego «entrega uma experiência» nesses mercados é entregar ao usuário um WebView, apontá-lo para um documento remoto e recarregar o mundo a cada toque. Ela não sobrevive à rede em que vive.
A armadilha é estrutural, não cosmética
Uma experiência H5 ou WebView é construída sobre uma suposição: a rede está presente, é rápida e barata. Em um 4G de mercado maduro, essa suposição em geral se sustenta. Em um 3G em Lagos, em um distrito rural nos arredores de São Paulo, em um trem de periferia fora de Jacarta, ela falha com relógio. Cada navegação é uma nova requisição. Cada imagem, cada script, cada rota é uma ida e volta que a rede pode cortar. Quando o sinal pisca —e nessas redes pisca sem parar— a página vira um documento em branco sem memória local de si mesma. O spinner gira, a estatística de rejeição se cumpre sozinha, e o usuário que você adquiriu a custo real se vai antes de sua primeira tela pintar.
Isso não é um problema de latência que você resolve com um servidor mais rápido. A dependência é arquitetural. O documento que é seu produto vive em outro lugar, e a única coisa entre o usuário e seu conteúdo é uma conexão que, para as pessoas que você mais quer, é a parte menos confiável do dia.
Cada condição é diferente, e você não controla nenhuma
O segundo problema é que «rede fraca» não é uma condição. É 3G em um mercado, 4G congestionado em outro, um túnel de trem, uma borda rural, um celular com orçamento de dados que o usuário desliga entre toques. Cada um se comporta diferente, e cada um está fora do seu runtime quando sua experiência é uma página web remota. A lógica de retry, o timeout, o modo de falha —todos decididos pelo navegador e pela rede, não por você—. Quando a conexão degrada, seu app degrada justo onde você tem menos voz, frente aos usuarios exatos cuja paciência e orçamento de dados são mais escassos.
Lado a lado
| Dimensão | H5 / WebView (rede primeiro) | Runtime do host + catálogo empacotado |
|---|---|---|
| Primeira pintura em rede fraca | Espera fetch remoto, gira | Recursos locais, pinta na hora |
| Navegação | Cada toque é uma nova ida e volta | Roteamento local, sem refetch |
| Uso offline | Documento em branco, morto | Conteúdo em cache, usável |
| Custo de dados por sessão | Recarrega recursos repetidas vezes | Recursos empacotados uma vez |
| Posse do host | Navegador e rede donos da UX | O host é dono da experiência |
| Mantenibilidade | Documento remoto deriva por mercado | Uma entrada de catálogo por superfície |
O que um runtime muda de verdade
Um runtime próprio do host não inventa largura de banda. Elimina a parte que sempre foi sua para consertar: a dependência. Em vez de entregar ao usuário um documento remoto e rezar para a rede se comportar, o host empacota o mini-programa uma vez e o executa a partir de recursos locais que o runtime já armazenou em cache. O usuário abre o conteúdo, o sinal cai, e a tela continua viva —a navegação é local, o conteúdo já visto está presente, e a sessão sobrevive ao piscar que teria matado uma página web—.
O host também preserva o que importa: a experiência, a resiliência e o relacionamento. Este é o mesmo argumento de posse das peças anteriores sobre controle de ativos e controlabilidade de plataforma —mas aqui trata-se de uptime onde é mais difícil garanti-lo—. A rede continua sendo a rede; o controle da experiência fica nas mãos do host.
O aviso honesto
Um runtime não é um amplificador de sinal. O empacotamento e o cache eliminam a dependência do seu app em relação à rede para recursos, navegação e conteúdo já obtido, mas não podem criar largura de banda onde ela não existe. Você ainda precisa de uma CDN, degradação elegante e um tratamento honesto das requisições que de fato precisam ir ao servidor. O que o runtime elimina é o imposto de rede que você mesmo se impõe —as sessões que você perde toda vez que recarrega seu próprio produto a partir de um documento que vive a três mil milhas de distância—. Ele não remove a física do último trecho. Quem lhe disser «bota um runtime e você fica rápido em todo lugar» está vendendo algo.
Se seu plano de crescimento depende dos próximos bilhões de usuários, a pergunta não é se eles estão em redes fracas. Estão. A pergunta é se sua arquitetura consegue manter suas próprias luzes acesas quando o sinal pisca, ou se você ainda está recarregando seu produto a partir de uma conexão que seus usuários mais valiosos menos podem se dar ao luxo de confiar.
