A rede é o elo mais fraco
A maior parte do tempo móvel é gasta em redes que funcionam até não funcionarem — um vagão de metrô, um estádio, uma estrada rural, uma fronteira com roaming. Para um corretor conferindo uma posição, um entregador aceitando um pedido ou um funcionário escaneando um ingresso, o momento em que o sinal cai é exatamente quando a tela precisa continuar funcionando. Dois modelos no mesmo telefone lidam com esse momento de forma muito diferente.
O H5 pode esperar sobreviver offline. Um mini-programa foi feito para isso.
O offline do H5 é negociar com o navegador
Uma página H5 depende da rede por padrão. Para funcionar offline, precisa registrar um service worker —e é aí que está a armadilha—. Os service workers só rodam sobre HTTPS (ou localhost), têm um ciclo de vida de várias etapas (registrar, instalar, ativar, buscar) e exigem que o desenvolvedor escreva à mão a estratégia de cache com a Cache API e os dados persistentes com IndexedDB. Se o registro falha, o escopo está errado, a atualização trava ou o navegador não suporta, a página simplesmente morre quando a conexão cai. Muitas páginas H5 nunca o implementam, então ficam offline-mortas por omissão.
Mesmo quando há um service worker, ele é um thread de fundo separado com seu próprio estado e modos de falha. Uma ativação travada ou um cache que nunca atualiza é invisível até o usuário já estar olhando para uma tela em branco.
Os mini-programas tratam o offline como um primitivo
Um mini-programa não acrescenta offline como uma ocorrência tardia. O pacote do programa —framework, shell e primeira tela— já está no dispositivo desde uma execução anterior, e o armazenamento local dá ao programa um lugar durável e quase síncrono para guardar dados do usuário e conteúdo frequente. Quando o sinal cai, o shell do app renderiza a partir do cache, os dados em cache aparecem na hora, e só as requisições ao vivo esperam e tentam de novo. O fluxo degrada com graça em vez de colapsar.
É por isso que o mesmo fluxo transacional se comporta tão diferentemente: o H5 busca a rede primeiro e o cache depois (se se deu ao trabalho de criá-lo); um mini-programa pinta com o que já está no dispositivo e trata a rede como a parte opcional.
De onde vem de fato a resiliência
- Pacote pré-carregado. O shell e a primeira tela são locais; a UI abre sem uma ida e volta à rede.
- Armazenamento local de dados. O estado do usuário, cotações recentes e rascunhos de formulário sobrevivem à queda e reaparecem ao reabrir.
- Degradação integrada. O runtime pinta a vista em cache e coloca as chamadas ao vivo na fila; o H5 tem que codificar tudo isso à mão em um thread de fundo frágil.
- Previsível em redes fracas. Como os ativos pesados já são locais, só pequenas requisições de dados ficam expostas ao enlace instável.
Lado a lado
| Dimensão | H5 / PWA | Mini-Programa |
|---|---|---|
| Mecanismo offline | Service worker + Cache API + IndexedDB | Pacote pré-carregado + armazenamento local |
| Ativação | Thread separado, ciclo de vida multi-etapas, pode falhar em silêncio | Integrado ao runtime, ativado por padrão |
| Funciona sem HTTPS? | Não — o SW exige HTTPS | Sim — ativos locais não precisam de transporte |
| Comportamento ao cair | Em branco se o SW falta/quebra; em cache se presente | Shell + dados em cache renderizam; chamadas ao vivo tentam de novo |
| Carga do desenvolvedor | Estratégia de cache à mão + tratamento de atualização | Pacote declarativo + APIs de armazenamento |
| Exposição em rede fraca | Página inteira reobtida | Só pequenas requisições de dados ao vivo |
O que isso significa para o seu fluxo
Para qualquer fluxo que acontece no mundo real —não apenas ao lado do Wi-Fi de uma mesa— a resiliência offline é uma função, não um bônus. Uma cotação que abre a partir do cache, um formulário que mantém o rascunho, um ingresso que continua escaneando, são 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 worker de fundo com estado que a maioria das páginas nunca entrega.
Onde o Cross Mini App se encaixa
O Cross Mini App é o runtime e o catálogo aberto do modelo offline-por-design. Um mini-programa construído uma vez contra a superfície de API padrão roda dentro de qualquer host com seu pacote pré-carregado e seu armazenamento local intacto, então a tela abre e os dados estão lá mesmo quando o enlace não está. A rede se torna a camada opcional, não a fundação. O H5 continua sendo a porta; o mini-programa é a sala que não apaga quando a luz oscila.
