La velocidad no es una función, es el embudo

Un milisegundo no es neutral. El informe State of Online Retail Performance de Akamai —basado en unas 10 mil millones de visitas minoristas— encontró que un retraso de 100 milisegundos en la carga reduce la conversión un 7%, y un retraso de dos segundos sube la tasa de rebote un 103%. La investigación móvil de Google es contundente: el 53% de los visitantes móviles deja una página que tarda más de tres segundos. El análisis de Portent sobre más de 100 M de impresiones muestra que un sitio que carga en 1 segundo convierte 2.5x a 5x mejor que uno lento, y Deloitte y Google midieron que una mejora de 0.1 segundo en móvil eleva las conversiones minoristas un 8.4% y el valor promedio de pedido un 9.2%. En la web abierta, lo lento es una fuga que pagas en cada visita.

H5 paga el impuesto de latencia en cada arranque en frío

Una página H5 dentro de un WebView se reconstruye desde cero en cada arranque en frío: se obtiene el documento, se analiza y compila el JavaScript, arranca el framework y solo entonces ocurre la primera interacción significativa. El Web Almanac 2025 reporta una página móvil mediana de unos 2,164 KB y 646–697 KB de JavaScript en ~22 solicitudes de script —todo ese trabajo está en la ruta crítica antes de que el usuario pueda actuar. No hay entorno precalentado ni paquete predescargado, así que el primer segundo se gasta negociando con la red, no sirviendo al usuario. En finanzas, ese primer segundo es la diferencia entre una orden ejecutada y un checkout abandonado.

Un mini-programa gasta ese segundo antes del toque

Un runtime gobernado precalienta el contenedor: el motor lógico y la capa de render se inicializan y se mantienen listos, y el paquete se predescarga (paquete principal ≤ 2 MB, subpaquetes en streaming ≤ 20 MB total vía preloadRule impuesto por la plataforma). Cuando el usuario toca, el runtime ya está vivo y el código ya está local, así que el tiempo hasta interactuar es casi instantáneo —los arranques en caliente son prácticamente gratis. El costo que H5 paga en cada visita se amortiza a casi cero porque se gastó antes de que el usuario llegara. Esa es la razón estructural por la que los mini-programas se sienten "instantáneos" mientras H5 sigue pagando el impuesto de latencia.

Cara a cara

DimensiónH5 / WebView (en frío)Mini-Programa (runtime)
Costo de arranque en fríoObtener + analizar + compilar JS en cada visitaContenedor precalentado, paquete predescargado
Primera interacciónSegundos en la ruta críticaCasi instantánea (en caliente)
Impacto de 100 ms−7% conversión (Akamai)Precalentado; costo en frío casi nulo
Carga de 3 s53% abandona en móvil (Google)Paquete en caché; TTI sub-segundo
Velocidad→ingreso0.1s más rápido = +8.4% conv (Deloitte/Google)Delta en caliente despreciable
Respuesta de entradaTareas largas bloquean INPHilo de render mantiene INP bajo

Qué significa para la conversión

Para superficies transaccionales —registro, KYC, checkout, entrada de órdenes— la velocidad es el producto. Los datos de Portent apuntan a un objetivo de 1–2 segundos para páginas que cobran, porque la conversión cae un promedio de 0.3% por cada segundo adicional. Un runtime que elimina el impuesto de arranque en frío no es un detalle cosmético; protege directamente el embudo en los dispositivos Android de gama baja que constituyen la mayor parte de la base instalada global. H5 sigue siendo la herramienta correcta para la web abierta y el contenido, pero la superficie dentro del host donde circula el dinero no debería sangrar conversiones por un primer pintado lento.

Dónde encaja Cross Mini App

Cross Mini App es el runtime y el catálogo abierto para este modelo. Construyes un mini-programa sobre una superficie de API estándar y hereda una ruta de arranque precalentada y predescargada en cada host que lo embebe —no una página H5 que vuelve a pagar el impuesto de latencia en cada visita. Lo instantáneo se diseña, así el embudo no gotea antes del primer toque. H5 cuenta la historia; el mini-programa retiene al usuario.

Fuentes