O primeiro segundo é a conversão
Abrir uma cotação, tocar em um botão de compra, escanear um QR para entrar em uma loja. Em um fluxo transacional, o primeiro segundo não é estética: é quando o usuário decide se isso parece um produto real ou uma página web que pode não funcionar. Duas tecnologias no mesmo telefone geram dois primeiros segundos bem diferentes: uma página H5 obtida pela rede e um mini-programa que já estava esperando no dispositivo.
A diferença não é "a web é lenta e o nativo é rápido". É onde a espera acontece. O H5 gasta seu primeiro segundo negociando com a rede; um runtime governado o gasta antes do usuário tocar.
O H5 paga o imposto da rede toda vez
Uma página H5 é um documento obtido de uma URL. Em uma inicialização a frio sem cache, o navegador precisa inicializar o WebView, solicitar o HTML, analisar o DOM, buscar e analisar CSS e JavaScript, executar os scripts e só então pintar. Em um Android de médio porte, essa cadeia leva 1,5–3 segundos até a primeira pintura quando nada está em cache, com first contentful paint perto de 1,2s e time-to-interactive perto de 2,2s. Cada passo espera a conexão, e em redes móveis instáveis a cauda é longa e instável.
Os service workers podem reduzir visitas repetidas, mas o modelo continua sendo "obtenha a página e tente lembrar dela". A primeira abertura —a que mais importa para aquisição— sempre depende da rede.
Os mini-programas chegam pré-carregados
Um mini-programa não se obtém quando o usuário toca. O host já inicializou o runtime, e o framework, o shell do app e frequentemente a primeira tela já estão empacotados e em cache no dispositivo. O WeChat documenta limites rígidos de pacote —um pacote principal não maior que 2MB e um programa total não maior que 20MB (30MB para mini-games)— justamente para que o download a frio seja pequeno e previsível. Os subpacotes são baixados sob demanda e as regras de pré-carga permitem ao host obter o próximo subpacote antes do usuário navegar para ele.
Medido de ponta a ponta, uma inicialização a frio de mini-programa fica em 800–1200ms, cerca da metade do H5, e as inicializações quentes são quase instantâneas porque o ambiente foi aquecido em segundo plano (a inicialização do contêiner costuma levar 10–20ms uma vez que o runtime está residente). Nenhuma dessas esperas é paga na rota crítica de tocar a pintar.
Como o runtime antecipa a espera
Os ganhos vêm de três escolhas estruturais que um runtime governado faz e uma página de navegador pura não pode:
- Aquecimento do ambiente. O host pré-inicializa o motor de JavaScript e a biblioteca base ao abrir o app, assim o mini-programa herda um runtime em execução em vez de iniciar um.
- Pré-download de pacotes. O shell, o framework e a primeira tela chegam ao dispositivo antes da intenção —por previsão, por regras de pré-carga ou por uma chamada explícita—, não depois que o usuário pede.
- Entrega limitada e dividida. Subpacotes e limites de tamanho mantêm o download pequeno, enquanto o modelo de dois threads (lógica e render separados) evita que scripts pesados bloqueiem a primeira pintura.
O modelo mental: o H5 é obtenha e execute; um mini-programa é já está aqui, execute.
Lado a lado
| Dimensão | H5 / Web móvel | Mini-Programa |
|---|---|---|
| Inicialização a frio (sem cache) | ~1,5–3,0s até a pintura | ~0,8–1,2s incluindo download |
| Inicialização quente | Busca recursos de novo | Quase instantâneo (runtime residente) |
| Motor da primeira pintura | Rede + parse + execução | Pacote local + runtime aquecido |
| Unidade de entrega | Documento URL sob demanda | Pacote pré-carregado (principal ≤2MB, total ≤20MB) |
| Carga dividida | Divisão manual | Subpacotes + regras de pré-carga nativas |
| Custo de init do runtime | Na primeira abertura | Uma vez ao abrir o host |
O que isso significa para o seu fluxo
Para um login, um checkout, uma cotação ou um escaneamento de entrada, a lacuna de inicialização a frio é a diferença entre "isto funciona" e "isto é uma página web". Times que movem o núcleo transacional para um mini-programa costumam ver a mudança refletida diretamente na conclusão e na retenção, porque o momento da intenção encontra uma tela que já está lá. O H5 ainda é a superfície da web aberta —o link compartilhado, a campanha, o SEO—, mas o núcleo transacional dentro do host não deveria esperar pela rede quando não precisa.
Onde o Cross Mini App se encaixa
O Cross Mini App é o runtime e o catálogo aberto do modelo pré-carregado. Você constrói um mini-programa uma vez contra uma superfície de API padrão e ele herda um runtime aquecido e pré-carregado em todo host que o incorpora —mensageria, carteira ou super-app— em vez de ser obtido de novo a cada entrada. O primeiro segundo é projetado, não negociado com a rede. O H5 continua sendo a porta; o mini-programa é a sala que já está iluminada.
