Hay una clase de decepción difícil de nombrar. Un usuario abre tu app, toca una entrada de «recarga», «viaje» o «seguro», y cae en una página que claramente no construyó tu equipo. La fuente no encaja. El scroll se traba. Un botón no hace nada un segundo y luego la página se recarga. Tiene que volver a iniciar sesión, en un servicio que no reconoce. Nada falla. Nada da error. Pero algo cercano a la confianza acaba de romperse, y nunca lo verás en los registros de errores.
Llevo casi una década viendo este patrón, en fintech, movilidad y apps de contenido. Los equipos pulen la cáscara nativa y luego entregan el servicio real — lo que genera dinero — a una página web embebida. El resultado se lee como «el producto de otro», y el usuario a menudo no distingue dónde termina tu app y dónde empieza la otra parte. El costo cae en conversión y retención, no en disponibilidad.
La grieta no es una. Son tres, y se apilan.
Dónde se ve la costura
Render. Una página H5 dentro de un webview se dibuja con su propio CSS, sus fuentes, su grilla — un segundo lenguaje de diseño viviendo dentro del primero. El usuario siente la costura aunque no la nombre. Un webview es un motor de navegador; no hereda tu sistema de componentes nativos, tu tipografía, ni tu movimiento. La página es correcta, y también es obviamente no tuya.
Carga. El primer render del H5 depende de la red. No hay precarga, no hay empaquetado y montaje de activos antes del toque como sí hace un runtime. Esto importa porque la velocidad no es una métrica de comodidad — es un embudo. El propio benchmark de Google encontró que el 53% de las visitas móviles se abandonan cuando una página tarda más de tres segundos, y las Core Web Vitals (LCP para pintado, INP para respuesta) se volvieron la definición compartida de «usable». Una página en webview suele medir peor que una pestaña real: sin caché de aislamiento de sitio, sin las optimizaciones que el host aplicó a su propio chrome, y un arranque en frío que es pura red.
Capacidad. Cuando el servicio necesita la cámara, la ubicación o un biométrico, el H5 cruza un puente JS hacia un modelo de seguridad de navegador que nunca se diseñó para eso. Algunas llamadas son poco fiables; muchas disparan un diálogo de permiso extra que se lee como advertencia. El flujo se rompe a sí mismo. Un runtime propio del host expone estas capacidades mediante APIs graduadas y auditadas, así que la misma acción es una llamada nativa, no una negociación.
Cara a cara
| Dimensión | H5 embebido (WebView) | Runtime de mini-programa (del host) |
|---|---|---|
| Consistencia de render | Sus propios estilos, visiblemente aparte | Componentes nativos, un lenguaje |
| Primer render | Atado a la red, gira seguido | Precargado, casi nativo |
| Capacidad nativa | Bridge limitado, diálogos extra | APIs auditadas, nativas |
| Inicio de sesión | Re-iniciar en tercero | Un inicio del host |
| Señal de confianza | Se lee como enlace externo | Sandbox, aval del host |
| Propiedad de marca | Se siente «de ellos» | Se siente «tuya» |
El daño es en parte reputacional. Cuando la página embebida se traba o pide re-iniciar sesión, el usuario rara vez culpa al tercero. Culpa a tu app. La reseña de una estrella dice «esta app es bugosa», no «este servicio embebido es bugoso». Cargas el riesgo de marca por una experiencia que no construiste y no puedes arreglar del todo.
Un runtime cierra la costura desde el otro lado. Los servicios se renderizan con componentes nativos y un lenguaje de diseño compartido, así se ven — y se comportan — como parte de tu producto. Los activos se montan antes del toque, así el primer render no espera a la red. Las capacidades las da el host, así la cámara abre como en el resto de tu app. Y como el runtime es sandbox y avalado por el host, el instinto del usuario es «esto es parte de la app», que es exactamente el instinto que quieres.
Agrego la salvedad honesta. Un runtime no es la cura milagro para un mal producto. Sus componentes nativos traen restricciones — no puedes soltar cualquier librería web arbitraria — y el sandbox que compra confianza es, por definición, un conjunto de límites. Lo que el runtime realmente hace es quitarte el impuesto de experiencia que pagabas en la puerta: evita que pierdas al usuario en el momento del toque, antes de que tu servicio tuviera la oportunidad de demostrarse.
Ese es el argumento más tranquilo a favor del runtime. No «construye un super-app». Solo: no dejes que la pantalla más importante de tu app parezca de otra persona.
