La señal nunca está garantizada
La mayor parte del tiempo móvil se pasa en redes que están bien hasta que no lo están: el metro entre estaciones, un estadio al comenzar el partido, una carretera rural, una frontera en roaming. Para un bróker que actualiza una posición, un repartidor que acepta un pedido o un empleado que escanea un ticket, el momento en que baja la señal es exactamente cuando la pantalla debe seguir funcionando. Dos modelos en el mismo teléfono lo manejan de forma muy distinta, y la diferencia se mide en pantallas en blanco.
El H5 puede esperar que la conexión aguante. Un mini-programa se construye para que la conexión sea lo opcional.
El H5 vuelve a descargar el mundo en cada apertura
Una página H5 es un documento obtenido desde una URL, y cada apertura es una nueva negociación con la red. El navegador paga las negociaciones DNS, TCP y TLS por cada origen, y luego encadena HTML, CSS, JavaScript e imágenes donde cada paso espera al anterior. El costo no es teórico: el Web Almanac 2025 de HTTP Archive midió la página móvil mediana en 2.164 KB de peso total con 22 solicitudes de JavaScript que suman 646 KB de script. En un enlace inestable, cada una de esas solicitudes es una oportunidad de fallar, y una sola hoja de estilos o script bloqueante del primer paint lo toma de rehén.
El resultado se ve en campo. El mismo informe encontró que el Time to First Byte móvil cumplió la barra "buena" en solo 44% de las páginas, y la Total Blocking Time móvil mediana llegó a 1.916 ms —subiendo a 7.555 ms en el percentil 90. Una página puede verse cargada mientras el hilo principal está demasiado ocupado para responder a un toque. En redes móviles inestables, la cola es larga y errática, y la pantalla en blanco es el modo de fallo por defecto cuando el cable no coopera.
Un mini-programa solo pide datos
Un mini-programa no vuelve a descargar su propio cuerpo en cada apertura. El paquete —framework, capa y primera pantalla— se entregó y guardó en caché en un lanzamiento anterior, a menudo por predicción o una regla de precarga mientras la señal estaba buena. Cuando el usuario toca, la UI se pinta desde recursos locales y solo pequeñas solicitudes de datos JSON cruzan la red. Los pesados activos propensos a fallar simplemente no están en la ruta crítica.
El runtime también da al programa herramientas explícitas que la página del navegador no tiene. WeChat documenta un tiempo de espera predeterminado de 60 segundos para solicitudes de red (configurable por llamada o global), y la API onNetworkStatusChange permite a la app detectar una caída y cambiar de comportamiento —mostrar datos en caché, encolar la acción, reintentar cuando vuelve el enlace— en lugar de dejar al usuario en una página en blanco. Las reglas de precarga de subpaquetes (preloadRule) obtienen la siguiente pantalla mientras la conexión está sana, así la navegación nunca espera a un enlace débil.
De dónde viene realmente la resiliencia
- Paquete precargado. La capa y la primera pantalla están locales; la UI visible se abre sin un viaje de red.
- Superficie de datos pequeña. Solo las solicitudes en vivo se exponen al enlace inestable —no hojas de estilo, no frameworks, no imágenes.
- Conciencia de red. El runtime reporta cambios de señal para que la app degrade con gracia en lugar de reintentar a ciegas.
- Comportamiento predecible en red débil. Como los activos ya están en el dispositivo, la experiencia degrada por segundos de latencia de datos, no por una pantalla en blanco total.
Cara a cara
| Dimensión | H5 / Web móvil | Mini-Programa |
|---|---|---|
| Qué cruza la red al abrir | HTML + CSS + JS + imágenes | Solo datos en vivo (JSON) |
| Peso móvil mediano | ~2.164 KB total, ~646 KB JS | Paquete en caché; peticiones escala-KB |
| Caída de señal al abrir | Pantalla en blanco hasta cargar | UI desde caché; datos reintentan |
| Exposición TBT (mediana móvil) | 1.916 ms; 7.555 ms en p90 | Lógica/red aislada del paint |
| Conciencia de red | Hecha a mano, si acaso | API de estado nativa + control de timeout |
| Forma de degradación | Binaria: carga o vacío | Gradual: vista en caché + llamadas en cola |
Qué significa para tu flujo
Para cualquier flujo que ocurre en el mundo real —un chequeo en tránsito, una venta de campo, una cotización en un sótano— la resiliencia de red es la diferencia entre una acción completada y una pantalla muerta. El H5 puede llegar al mismo lugar, pero solo construyendo y manteniendo a mano un service worker, una estrategia de caché y una capa de reintentos que la mayoría de las páginas nunca implementa. Un mini-programa obtiene la forma resiliente por defecto, porque la parte que falla en móvil (la descarga de activos) ya la terminó antes.
Dónde encaja Cross Mini App
Cross Mini App es el runtime y el catálogo abierto del modelo resiliente-por-defecto. Construyes un mini-programa una vez contra una superficie de API estándar y corre en cualquier host con su paquete precargado y su capa de datos intacta, así la pantalla se abre y la vista en caché está ahí aunque la señal sea débil. La red se vuelve la capa opcional, no la base. El H5 sigue siendo la puerta; el mini-programa es la habitación que sigue iluminada cuando la señal parpadea.
