Todo el peso aparece en la primera apertura
Un sitio de marketing, un flujo de pago, un panel — ábrelo en el móvil y el navegador empieza a descargar. La página web móvil mediana transfiere hoy cerca de 2,2 MB (2.164 KB) de recursos en la primera vista (HTTP Archive Web Almanac 2025, rastreo de julio de 2025), con JavaScript en una mediana de 646–697 KB comprimidos y 22 solicitudes de script en una página típica. Una parte — unos 251 KB sin comprimir, mediana — es JavaScript que nunca se ejecuta. El modelo es "descarga el documento, luego lo que necesita", y en la primera apertura el usuario paga por todo.
H5 envía el peso por adelantado
Los navegadores pueden dividir código, cargar perezosamente y separar por ruta. Pero el patrón dominante sigue siendo un paquete de entrada que arrastra el framework, la ruta y la UI compartida. Incluso con disciplina, el peso de la página es un número único que el usuario descarga antes de que algo sea útil. JavaScript es el recurso más caro byte a byte (web.dev / Google): tras descargarse debe analizarse, compilarse y ejecutarse en el hilo principal, así que un paquete pesado retrasa la interactividad directamente. En un dispositivo de gama media, un paquete de 1 MB+ puede empujar el tiempo hasta interactivo más allá del punto donde los usuarios abandonan.
El problema más profundo es estructural: el navegador no tiene noción de "solo la carcasa, el resto después". Todo es una descarga por URL, y la primera descarga es toda la experiencia.
Los mini-programas solo descargan el paquete principal
Un mini-programa se entrega como paquetes, no como página. Los límites documentados de WeChat son un paquete principal no mayor a 2 MB y un programa total no mayor a 20 MB (Tencent Cloud / docs oficiales). Al iniciar solo se descarga el paquete principal — la página de lanzamiento, la TabBar y los recursos comunes que comparte cada subpaquete. Los subpaquetes (cada uno ≤2 MB) se obtienen solo cuando el usuario navega a ellos. Un subpaquete independiente puede incluso cargar sin el paquete principal, por eso las páginas de campaña arrancan rápido sin arrastrar toda la app.
La clave es que la división la impone la plataforma, no la disciplina del desarrollador. La primera descarga está acotada y es pequeña por construcción.
Las reglas de precarga esconden la espera
Incluso la descarga bajo demanda es invisible en buenas implementaciones. Con preloadRule en app.json, el host precarga el subpaquete que una página probablemente necesite antes de que el usuario navegue — al entrar al inicio puede bajar en segundo plano el subpaquete "important". Para cuando ocurre el toque, la siguiente pantalla ya está en el dispositivo. La plataforma equilibra contra tráfico y almacenamiento, limitando la precarga a 2 MB por página para no consumir datos silenciosamente.
Así la experiencia es: descarga inicial mínima, resto transmitido y a menudo ya presente. El equivalente H5 — carga perezosa por ruta — sigue pagando una descarga en cada primera navegación a un nuevo fragmento.
Cara a cara
| Dimensión | H5 / Web móvil | Mini-Programa |
|---|---|---|
| Tamaño de primera descarga | ~2,2 MB mediana (peso completo) | Solo paquete principal (≤2 MB) al inicio |
| División de paquete | División manual / lazy import | Subpaquetes por plataforma (cada ≤2 MB, total ≤20 MB) |
| Al navegar | Descarga el nuevo fragmento en la primera visita | Subpaquete ya precargado o bajo demanda |
| Código no usado | ~251 KB JS no usado mediana | Solo lo que el paquete referencia |
| Control de precarga | Service worker / heurísticas de app shell | preloadRule declarativo, tope 2 MB/página |
| Aislamiento de pantalla grande | N/A | Subpaquetes independientes sin paquete principal |
Qué significa para tu build
Si tu flujo es algunas pantallas pesadas detrás de una entrada ligera, un mini-programa mantiene la puerta ligera y transmite las habitaciones. Esto importa más en la pantalla de adquisición y en Android de gama baja, donde un paquete principal de 2 MB gana a un bundle único de 2 MB+ porque solo la carcasa está en la ruta crítica. H5 sigue ganando en la web abierta — el enlace, la landing, el SEO — pero la experiencia dentro del host no debería enviar todo su peso en la primera apertura cuando no es necesario.
Dónde encaja Cross Mini App
Cross Mini App da a tu mini-programa un runtime y un catálogo abierto que heredan este modelo de entrega dividida. Construye una vez contra una superficie de API estándar; cada host que lo incrusta descarga solo lo que la entrada necesita y transmite el resto por reglas de plataforma, en lugar de volver a buscar un bundle monolítico. La primera descarga está acotada a propósito. H5 trae al visitante; el mini-programa lo retiene sin el impuesto del peso.
