O sinal nunca está garantido
A maior parte do tempo móvel é gasta em redes que vão bem até não irem: o metrô entre estações, um estádio na hora do jogo, uma estrada rural, uma fronteira em roaming. Para um bróker atualizando uma posição, um entregador aceitando um pedido ou um atendente escaneando um ticket, o momento em que o sinal cai é exatamente quando a tela precisa continuar funcionando. Dois modelos no mesmo telefone lidam com isso de forma muito diferente, e a diferença se mede em telas em branco.
O H5 pode esperar que a conexão segure. Um mini-programa é construído para que a conexão seja o opcional.
O H5 baixa o mundo de novo a cada abertura
Uma página H5 é um documento obtido de uma URL, e cada abertura é uma nova negociação com a rede. O navegador paga as negociações DNS, TCP e TLS para cada origem e então encadeia HTML, CSS, JavaScript e imagens onde cada passo espera o anterior. O custo não é teórico: o Web Almanac 2025 da HTTP Archive mediu a página móvel mediana em 2.164 KB de peso total com 22 solicitações de JavaScript somando 646 KB de script. Em um enlace instável, cada uma dessas solicitações é uma chance de travar, e uma única folha de estilo ou script bloqueante do primeiro paint a mantém refém.
O resultado aparece em campo. O mesmo relatório encontrou que o Time to First Byte móvel atingiu a barra "bom" em apenas 44% das páginas, e a Total Blocking Time móvel mediana chegou a 1.916 ms —subindo a 7.555 ms no percentil 90. Uma página pode parecer carregada enquanto o thread principal está ocupado demais para responder a um toque. Em redes móveis instáveis, a cauda é longa e errática, e a tela em branco é o modo de falha padrão quando o fio não coopera.
Um mini-programa só pede dados
Um mini-programa não baixa seu próprio corpo a cada abertura. O pacote —framework, camada e primeira tela— foi entregue e cacheado em uma abertura anterior, muitas vezes por previsão ou uma regla de pré-carga enquanto o sinal estava bom. Quando o usuário toca, a UI é pintada a partir de recursos locais e apenas pequenas solicitações de dados JSON cruzam a rede. Os pesados ativos propensos a falhar simplesmente não estão no caminho crítico.
O runtime também dá ao programa ferramentas explícitas que a página do navegador não tem. O WeChat documenta um tempo limite padrão de 60 segundos para solicitações de rede (configurável por chamada ou global), e a API onNetworkStatusChange permite ao app detectar uma queda e mudar de comportamento —mostrar dados em cache, enfileirar a ação, reintentar quando o enlace volta— em vez de deixar o usuário numa página em branco. As regras de pré-carga de subpacotes (preloadRule) obtêm a próxima tela enquanto a conexão está saudável, assim a navegação nunca espera por um enlace fraco.
De onde vem realmente a resiliência
- Pacote pré-carregado. A camada e a primeira tela estão locais; a UI visível abre sem uma ida à rede.
- Superfície de dados pequena. Só as solicitações vivas se exponham ao enlace instável —não folhas de estilo, não frameworks, não imagens.
- Consciência de rede. O runtime reporta mudanças de sinal para o app degradar com graça em vez de reintentar às cegas.
- Comportamento previsível em rede fraca. Como os ativos já estão no dispositivo, a experiência degrada por segundos de latência de dados, não por uma tela em branco total.
Lado a lado
| Dimensão | H5 / Web móvel | Mini-Programa |
|---|---|---|
| O que cruza a rede ao abrir | HTML + CSS + JS + imagens | Só dados vivos (JSON) |
| Peso móvel mediano | ~2.164 KB total, ~646 KB JS | Pacote em cache; pedidos escala-KB |
| Queda de sinal ao abrir | Tela em branco até carregar | UI do cache; dados reintentam |
| Exposição TBT (mediana móvel) | 1.916 ms; 7.555 ms no p90 | Lógica/rede isolada do paint |
| Consciência de rede | Feita à mão, se tanto | API de estado nativa + controle de timeout |
| Forma de degradação | Binária: carrega ou vazio | Gradual: vista em cache + chamadas na fila |
O que isso significa para o seu fluxo
Para qualquer fluxo que acontece no mundo real —uma validação no transporte, uma venda de campo, uma cotação num porão— a resiliência de rede é a diferença entre uma ação concluída e uma tela morta. O H5 pode chegar ao mesmo lugar, mas só construindo e mantendo à mão um service worker, uma estratégia de cache e uma camada de reintentos que a maioria das páginas nunca implementa. Um mini-programa obtém a forma resiliente por padrão, porque a parte que falha no móvel (o download de ativos) ele já terminou antes.
Onde o Cross Mini App se encaixa
O Cross Mini App é o runtime e o catálogo aberto do modelo resiliente-por-padrão. Você constrói um mini-programa uma vez contra uma superfície de API padrão e ele roda em qualquer host com seu pacote pré-carregado e sua camada de dados intacta, assim a tela abre e a vista em cache está lá mesmo com o sinal fraco. A rede vira a camada opcional, não a base. O H5 continua sendo a porta; o mini-programa é a sala que segue iluminada quando o sinal oscila.
