Todo o peso aparece na primeira abertura
Um site de marketing, um fluxo de checkout, um painel — abra no celular e o navegador começa a baixar. A página web móvel mediana transfere hoje cerca de 2,2 MB (2.164 KB) de recursos na primeira visualização (HTTP Archive Web Almanac 2025, rastreamento de julho de 2025), com JavaScript numa mediana de 646–697 KB comprimidos e 22 solicitações de script numa página típica. Uma parte — cerca de 251 KB descomprimidos, mediana — é JavaScript que nunca executa. O modelo é "baixe o documento, depois o que ele precisa", e na primeira abertura o usuário paga por tudo.
H5 entrega o peso por antecipação
Navegadores podem dividir código, carregar preguiçosamente e separar por rota. Mas o padrão dominante ainda é um pacote de entrada que arrasta o framework, a rota e a UI compartilhada. Mesmo com disciplina, o peso da página é um número único que o usuário baixa antes de algo ser útil. JavaScript é o recurso mais caro byte a byte (web.dev / Google): após baixar, precisa ser analisado, compilado e executado no thread principal, então um pacote pesado atrasa a interatividade diretamente. Num dispositivo de médio porte, um pacote de 1 MB+ pode empurrar o tempo até interativo além do ponto em que os usuários saem.
O problema mais profundo é estrutural: o navegador não tem noção de "só o shell, o resto depois". Tudo é um fetch por URL, e o primeiro fetch é toda a experiência.
Mini-programas baixam apenas o pacote principal
Um mini-programa é entregue como pacotes, não como página. Os limites documentados da WeChat são um pacote principal não maior que 2 MB e um programa total não maior que 20 MB (Tencent Cloud / docs oficiais). No lançamento só o pacote principal é baixado — a página inicial, a TabBar e os recursos comuns que todo subpacote compartilha. Os subpacotes (cada um ≤2 MB) são obtidos só quando o usuário navega para eles. Um subpacote independente pode até carregar sem o pacote principal, por isso páginas de campanha abrem rápido sem arrastar o app todo.
A chave é que a divisão é imposta pela plataforma, não pela disciplina do desenvolvedor. O primeiro download é limitado e pequeno por construção.
Regras de pré-carga escondem a espera
Mesmo o download sob demanda é invisível em boas implementações. Com preloadRule no app.json, o host pré-carrega o subpacote que uma página provavelmente precisará antes de o usuário navegar — ao entrar no início ele pode baixar em segundo plano o subpacote "important". Quando o toque acontece, a próxima tela já está no dispositivo. A plataforma equilibra contra tráfego e armazenamento, limitando a pré-carga a 2 MB por página para não consumir dados silenciosamente.
Assim a experiência é: download inicial mínimo, resto transmitido e frequentemente já presente. O equivalente H5 — lazy loading por rota — ainda paga um fetch em cada primeira navegação a um novo fragmento.
Lado a lado
| Dimensão | H5 / Web móvel | Mini-Programa |
|---|---|---|
| Tamanho do primeiro download | ~2,2 MB mediana (peso completo) | Só pacote principal (≤2 MB) no lançamento |
| Divisão de pacote | Divisão manual / lazy import | Subpacotes por plataforma (cada ≤2 MB, total ≤20 MB) |
| Ao navegar | Baixa o novo fragmento na primeira visita | Subpacote já pré-carregado ou sob demanda |
| Código não usado | ~251 KB JS não usado mediana | Só o que o pacote referencia |
| Controle de pré-carga | Service worker / heurísticas de app shell | preloadRule declarativo, teto 2 MB/página |
| Isolamento de tela grande | N/A | Subpacotes independentes sem pacote principal |
O que isso significa para o seu build
Se o seu fluxo tem algumas telas pesadas atrás de uma entrada leve, um mini-programa mantém a porta leve e transmite as salas. Isso importa mais na tela de aquisição e em Android de entrada, onde um pacote principal de 2 MB ganha de um bundle único de 2 MB+ porque só o shell está no caminho crítico. H5 ainda vence na web aberta — o link, a landing, o SEO — mas a experiência dentro do host não deveria entregar todo o seu peso na primeira abertura quando não precisa.
Onde o Cross Mini App se encaixa
O Cross Mini App dá ao seu mini-programa um runtime e um catálogo aberto que herdam esse modelo de entrega dividida. Construa uma vez contra uma superfície de API padrão; cada host que o incorpora baixa só o que a entrada precisa e transmite o resto por regras de plataforma, em vez de buscar novamente um bundle monolítico. O primeiro download é limitado de propósito. H5 traz o visitante; o mini-programa o retém sem o imposto do peso.
