El primer segundo es la conversión
Abrir una cotización, tocar un botón de compra, escanear un QR para entrar a una tienda. En un flujo transaccional, el primer segundo no es estética: es cuando el usuario decide si esto parece un producto real o una página web que podría no funcionar. Dos tecnologías en el mismo teléfono dan dos primeros segundos muy distintos: una página H5 obtenida por la red y un mini-programa que ya estaba esperando en el dispositivo.
La diferencia no es "la web es lenta y el nativo rápido". Es dónde ocurre la espera. H5 gasta su primer segundo negociando con la red; un runtime gobernado lo gasta antes de que el usuario toque.
H5 paga el impuesto de la red cada vez
Una página H5 es un documento obtenido desde una URL. En un arranque en frío sin caché, el navegador debe inicializar el WebView, solicitar el HTML, analizar el DOM, obtener y analizar CSS y JavaScript, ejecutar los scripts y luego pintar. En un Android de gama media, esa cadena tarda 1.5–3 segundos hasta el primer paint cuando nada está en caché, con un first contentful paint cercano a 1.2s y un time-to-interactive cercano a 2.2s. Cada paso espera la conexión, y en redes móviles inestables la cola es larga y errática.
Los service workers pueden recortar las visitas repetidas, pero el modelo sigue siendo "obtén la página y luego intenta recordarla". La primera apertura —la que más importa para la adquisición— siempre depende de la red.
Los mini-programas llegan precargados
Un mini-programa no se obtiene cuando el usuario toca. El host ya inicializó el runtime, y el framework, la carcasa de la app y a menudo la primera pantalla ya están empaquetados y en caché en el dispositivo. WeChat documenta límites estrictos de paquete —un paquete principal no mayor a 2MB y un programa total no mayor a 20MB (30MB para mini-juegos)— precisamente para que la descarga en frío sea pequeña y predecible. Los subpaquetes se descargan bajo demanda y las reglas de precarga permiten al host obtener el siguiente subpaquete antes de que el usuario navegue a él.
Medido de extremo a extremo, un arranque en frío de mini-programa queda en 800–1200ms, aproximadamente la mitad de H5, y los arranques en caliente son casi instantáneos porque el entorno se calentó en segundo plano (la inicialización del contenedor suele ser 10–20ms una vez que el runtime está residente). Ninguna de esas esperas se paga en la ruta crítica de tocar a pintar.
Cómo el runtime adelanta la espera
Las mejoras vienen de tres decisiones estructurales que un runtime gobernado toma y una página de navegador simple no puede:
- Calentamiento del entorno. El host preinicializa el motor de JavaScript y la librería base al abrir la app, así el mini-programa hereda un runtime en ejecución en lugar de arrancar uno.
- Precarga de paquetes. La carcasa, el framework y la primera pantalla llegan al dispositivo antes de la intención —por predicción, por reglas de precarga o por una llamada explícita—, no después de que el usuario lo pide.
- Entrega acotada y dividida. Los subpaquetes y los límites de tamaño mantienen la descarga pequeña, mientras el modelo de doble hilo (lógica y render separados) evita que los scripts pesados bloqueen el primer paint.
El modelo mental: H5 es obtén y luego ejecuta; un mini-programa es ya está aquí, ejecuta.
Cara a cara
| Dimensión | H5 / Web móvil | Mini-Programa |
|---|---|---|
| Arranque en frío (sin caché) | ~1.5–3.0s al primer paint | ~0.8–1.2s incluyendo descarga |
| Arranque en caliente | Vuelve a obtener recursos | Casi instantáneo (runtime residente) |
| Motor del primer paint | Red + parseo + ejecución | Paquete local + runtime caliente |
| Unidad de entrega | Documento URL bajo demanda | Paquete precargado (principal ≤2MB, total ≤20MB) |
| Carga dividida | División manual | Subpaquetes + reglas de precarga nativas |
| Costo de init del runtime | En la primera apertura | Una vez al abrir el host |
Qué significa para tu flujo
Para un login, un checkout, una cotización o un escaneo de entrada, la brecha de arranque en frío es la diferencia entre "esto funciona" y "esto es una página web". Los equipos que mueven el núcleo transaccional a un mini-programa suelen ver el cambio reflejado directamente en la finalización y la retención, porque el momento de la intención se encuentra con una pantalla que ya está ahí. H5 sigue siendo la superficie de la web abierta —el enlace compartido, la campaña, el SEO—, pero el núcleo transaccional dentro del host no debería esperar a la red cuando no tiene que hacerlo.
Dónde encaja Cross Mini App
Cross Mini App es el runtime y el catálogo abierto del modelo precargado. Construyes un mini-programa una vez contra una superficie de API estándar y hereda un runtime caliente y precargado en cada host que lo incrusta —mensajería, billetera o super-app— en lugar de volver a obtenerse en cada entrada. El primer segundo se diseña, no se negocia con la red. H5 sigue siendo la puerta; el mini-programa es la habitación que ya está iluminada.
