Velocidade não é um recurso, é o funil

Um milissegundo não é neutro. O relatório State of Online Retail Performance da Akamai —baseado em cerca de 10 bilhões de visitas de varejo— mostrou que um atraso de 100 milissegundos na carga reduz a conversão em 7%, e um atraso de dois segundos eleva a taxa de rejeição em 103%. A pesquisa móvel do Google é direta: 53% dos visitantes mobile deixam uma página que demora mais de três segundos. A análise da Portent sobre mais de 100 M de page views mostra que um site que carrega em 1 segundo converte 2,5x a 5x melhor que um lento, e Deloitte e Google mediram que uma melhoria de 0,1 segundo no mobile eleva as conversões de varejo em 8,4% e o valor médio do pedido em 9,2%. Na web aberta, o lento é um vazamento que se paga a cada visita.

H5 paga o imposto de latência a cada inicialização a frio

Uma página H5 dentro de um WebView se reconstrói do zero a cada inicialização a frio: o documento é buscado, o JavaScript é analisado e compilado, o framework sobe e só então ocorre a primeira interação significativa. O Web Almanac 2025 relata uma página móvel mediana de cerca de 2.164 KB e 646–697 KB de JavaScript em ~22 solicitações de script —todo esse trabalho está no caminho crítico antes do usuário poder agir. Não há ambiente pré-aquecido nem pacote pré-baixado, então o primeiro segundo é gasto negociando com a rede, não servindo o usuário. Em finanças, esse primeiro segundo é a diferença entre uma ordem executada e um checkout abandonado.

Um mini-programa gasta esse segundo antes do toque

Um runtime governado pré-aquece o contêiner: o motor lógico e a camada de render são inicializados e mantidos prontos, e o pacote é pré-baixado (pacote principal ≤ 2 MB, subpacotes em streaming ≤ 20 MB no total via preloadRule imposto pela plataforma). Quando o usuário toca, o runtime já está vivo e o código já está local, então o tempo até interagir é quase instantâneo —as partidas quentes são praticamente de graça. O custo que o H5 paga a cada visita é amortizado a quase zero porque foi gasto antes do usuário chegar. Essa é a razão estrutural pela qual os mini-programas parecem "instantâneos" enquanto o H5 segue pagando o imposto de latência.

Lado a lado

DimensãoH5 / WebView (a frio)Mini-Programa (runtime)
Custo de inicialização a frioBuscar + analisar + compilar JS a cada visitaContêiner pré-aquecido, pacote pré-baixado
Primeira interaçãoSegundos no caminho críticoQuase instantânea (quente)
Impacto de 100 ms−7% conversão (Akamai)Pré-aquecido; custo a frio quase nulo
Carga de 3 s53% abandonam no mobile (Google)Pacote em cache; TTI sub-segundo
Velocidade→receita0,1s mais rápido = +8,4% conv (Deloitte/Google)Delta quente desprezível
Resposta de entradaTarefas longas bloqueiam INPThread de render mantém INP baixo

O que isso significa para a conversão

Para superfícies transacionais —cadastro, KYC, checkout, entrada de ordens— a velocidade é o produto. Os dados da Portent apontam para uma meta de 1–2 segundos para páginas que cobram, porque a conversão cai em média 0,3% a cada segundo adicional. Um runtime que elimina o imposto de inicialização a frio não é um detalhe cosmético; protege diretamente o funil nos dispositivos Android de entrada que compõem a maior parte da base instalada global. O H5 segue sendo a ferramenta correta para a web aberta e o conteúdo, mas a superfície dentro do host onde o dinheiro circula não deveria sangrar conversão por uma primeira pintura lenta.

Onde o Cross Mini App se encaixa

Cross Mini App é o runtime e o catálogo aberto para esse modelo. Você constrói um mini-programa sobre uma superfície de API padrão e herda um caminho de inicialização pré-aquecido e pré-baixado em todo host que o incorpora —não uma página H5 que volta a pagar o imposto de latência a cada visita. O instantâneo é projetado, então o funil não vaza antes do primeiro toque. H5 conta a história; o mini-programa retém o usuário.

Fontes