Aplicación web progresiva - cuando no hace falta una app y basta el sitio como aplicación
Una aplicación web progresiva (PWA) es un sitio que se instala en la pantalla de inicio, se abre casi como una app nativa y puede funcionar sin conexión o con red débil. Para muchos negocios un lanzamiento completo en App Store y Google Play son meses y presupuesto de más: catálogos, áreas de cliente, reservas, menús y portales B2B suelen resolverse con una PWA sobre HTML, CSS y JavaScript habituales. Abajo - cuándo basta el «sitio como app», qué tecnologías son obligatorias y dónde sigue haciendo falta lo nativo.
- PWA - sitio + manifiesto + service worker: icono, pantalla completa, caché, a veces push
- No sustituye cualquier app - gráficos pesados, acceso profundo al dispositivo y SLAs duros de App Store siguen siendo nativos
- Una base de código - una versión web en lugar de equipos iOS/Android separados al inicio
- Actualizaciones sin tiendas - publicas en el servidor: el usuario recibe la nueva versión en la siguiente visita
- El SEO se mantiene - siguen siendo páginas en búsqueda, no un binario cerrado
- Checklist inicial - HTTPS,
manifest.webmanifest, service worker, responsive y First Contentful Paint rápido
Qué es una PWA en palabras simples
PWA (Progressive Web App) es un conjunto de prácticas y APIs web con las que el sitio se comporta como una aplicación instalada:
- Se instala en el teléfono o el escritorio desde el navegador (icono, ventana aparte sin la barra de direcciones habitual).
- Abre rápido gracias a la caché del shell (la carcasa de la interfaz).
- Aguanta mala red - muestra pantallas cacheadas o encola acciones para «enviar después».
- Se ve nativa - splash, theme-color,
display: standalone.
No es otro lenguaje ni «otro framework». Es tu sitio actual, llevado a criterios de installability y entrega fiable de contenido. En Chrome, Edge, Safari y Firefox el escenario básico ya es maduro; quedan matices en push, sincronización en segundo plano y parte de las APIs del dispositivo.
Cuándo basta el sitio como aplicación
La PWA compensa cuando el producto es, en esencia, una interfaz de datos en el navegador, no un juego ni una herramienta de sistema.
Buenos candidatos:
| Escenario | Por qué suele bastar una PWA |
|---|---|
| Catálogo, menú, precios, reserva | Contenido + formularios; las tiendas aportan poco |
| Área de cliente / portal B2B | Login, tablas, documentos, estados de pedido |
| Herramienta interna de empleados | Instalación en móviles de trabajo sin publicar en tiendas |
| Medios y feeds (noticias, blog, docs) | Importan el SEO y compartir enlaces |
| MVP antes de vender la «app de verdad» | Validar demanda sin el coste de dos equipos nativos |
Si el usuario vuelve varias veces por semana, quiere un icono «como el del banco» y un UX estable en el metro sin red - la PWA cubre la expectativa sin revisión de App Store.
Cuándo conviene una app nativa
Una respuesta honesta vale más que el marketing de «la PWA lo reemplaza todo»:
- hacen falta tareas en segundo plano estrictas, Bluetooth / NFC complejo o sensores a bajo nivel;
- son críticos el rendimiento 3D/AR, cámara pesada y juegos offline;
- el producto debe vivir solo en tiendas (vitrinas de partners, MDM corporativo que exige nativo);
- necesitas pagos y suscripciones estrictamente vía IAP de Apple/Google como canal principal;
- el equipo ya mantiene plantillas fuertes de iOS/Android y la web es secundaria.
Compromiso habitual en 2026: PWA o sitio responsive para todos + app nativa solo donde las métricas demuestren demanda (retención, cuota de tráfico móvil, visitas repetidas).
De qué se compone una PWA
El mínimo sin el cual no hay «progresividad»:
1. HTTPS
El service worker y la installability exigen un origen seguro. El localhost local es excepción para desarrollo.
2. Web App Manifest
El archivo manifest.webmanifest (o JSON) describe nombre, iconos (suele 192 y 512), start_url, display, colores de tema. Sin él el navegador no ofrecerá «Instalar aplicación».
3. Service Worker
Script en segundo plano: cachea el shell y lo estático, sirve un fallback offline, a veces encola POST si cae la red. Estrategias típicas: cache-first para CSS/JS/iconos, network-first para API y precios.
4. UI responsive y rápida
La PWA no salva un sitio lento. Hace falta responsive, compresión de imágenes y un bundle razonable de JavaScript. Si no, instalan la «app» una vez y la borran.
5. Opcional: push, Share Target, shortcuts
Push y badge mejoran retención, pero complican el consentimiento y la política de notificaciones. Los shortcuts del manifiesto dan acciones rápidas con pulsación larga del icono.
Efecto de negocio: cifras sin ilusiones
Compara presupuesto y ciclo de release, no «está de moda / no».
| Parámetro | PWA / sitio | App nativa |
|---|---|---|
| Plazo de MVP | semanas | a menudo meses en ambas plataformas |
| Actualización | deploy al servidor | revisión de tiendas + esperar que el usuario actualice |
| Distribución | URL + «añadir a pantalla» | tiendas, ASO, moderación |
| Búsqueda y enlaces | SEO completo | limitado; el tráfico viene a menudo de la tienda y de anuncios |
| Coste de mantenimiento | un frontend | dos bases de código o multiplataforma + web igual |
El ahorro es real al validar hipótesis y en servicios donde el contenido y los formularios importan más que el acceso al hardware. El ahorro desaparece si prometes «sensación bancaria nativa con biometría compleja y geo-triggers en segundo plano» - ahí encaja mejor lo nativo.
Checklist de implantación en un sitio existente
- Cerrar velocidad y responsive básicos - si no, la PWA solo fija un mal UX.
- Publicar el manifiesto y el set de iconos (tema claro/oscuro si hace falta).
- Registrar el service worker con política de caché clara; no cachear datos personales sin caducidad.
- Comprobar installability en Chrome DevTools / Lighthouse (categoría PWA).
- Probar Safari (iOS) - instalación vía «Añadir a pantalla de inicio»; push y parte de las APIs difieren de Android.
- Medir instalaciones y rutas «abierto desde el icono» vs «llegó por enlace».
- No romper la indexación - el contenido debe seguir en URLs normales; la PWA es capa, no un callejón SPA sin SSR/prerender.
- Describir el offline con honestidad - qué hay sin red y qué no.
En constructores de sitios depende de la plataforma: a veces PWA se activa con un interruptor, a veces hace falta hosting propio y código a medida. El principio es el mismo - manifiesto + worker + HTTPS.
Errores frecuentes
- Llamar PWA a cualquier sitio responsive sin service worker ni manifiesto.
- Cachear API de precios y stock «para siempre» - el usuario ve el tarifario de ayer.
- Prometer «como en la App Store» y a la vez recortar presupuesto de UX y rendimiento.
- Ignorar iOS: probar solo Android Chrome.
- Montar un SPA pesado sin indexación y perder tráfico de búsqueda.
- Activar push agresivo en la primera visita - bloquean notificaciones y la marca.
Conclusión
Una aplicación web progresiva es el camino pragmático cuando necesitas «icono en pantalla + visitas repetidas rápidas», no un producto nativo completo para ambas plataformas. Para catálogos, portales, reservas y herramientas internas, el sitio como aplicación a menudo basta. Para juegos, hardware profundo y monetización centrada en tiendas - planifica nativo. Empieza por HTTPS, manifiesto, service worker y velocidad; el resto son iteraciones sobre retención, no sobre el hype.
Preguntas frecuentes
¿En qué se diferencia una PWA de un sitio móvil normal?
Un sitio responsive normal se abre en una pestaña del navegador. Una PWA añade installability (icono, ventana standalone), service worker para caché y offline, y un manifiesto con metadatos de app. Visualmente puede ser el mismo diseño, pero el modelo de entrega y de retornos se acerca a una aplicación.
¿Se puede publicar una PWA en App Store y Google Play?
Google Play es relativamente amable con Trusted Web Activity / envoltorios de PWA. La App Store es más dura: un simple «sitio en una cáscara» suele rechazarse sin valor nativo claro. Para la mayoría el canal principal de PWA es el navegador y «Añadir a pantalla»; las tiendas son otro producto con otros requisitos.
¿Funciona una PWA totalmente offline?
Rara vez al completo. Suelen estar offline el shell, páginas ya abiertas y la estática. Precios en vivo, cuenta e pagos requieren red. Una buena PWA muestra con honestidad lo no disponible y, si hace falta, encola acciones hasta que vuelva internet.
¿Hace falta un dominio o subdominio aparte para la PWA?
Un dominio aparte no es obligatorio. Importa más un origin estable (esquema + host + puerto), un start_url correcto y que las actualizaciones del service worker no choquen con la caché antigua. A veces se saca la app a app.example.com, pero es decisión organizativa, no exigencia de la especificación.
¿Por dónde empezar si el sitio ya está en WordPress, Tilda o stack propio?
Comprueba si la plataforma ofrece manifiesto y service worker de serie. Si no - añade el manifiesto estático, un worker mínimo del shell e iconos; en stack propio suele ser un sprint. Luego mide Core Web Vitals, prueba instalación en Android e iOS y define la política de caché de API. No empieces por push: primero logra instalación rápida y reapertura estable.