Qué es Web Push y cómo funciona

Web Push es el estándar que permite a una web enviar notificaciones al navegador de un usuario aunque no tenga ninguna página abierta, sin app nativa ni tienda de aplicaciones. El usuario da permiso una vez, su navegador crea una suscripción y, cuando pasa algo relevante, tu producto le avisa con una notificación del sistema que lo devuelve a tu web con un toque.

En resumen:

• Intervienen cuatro actores: tu web, el navegador del usuario, el servicio push del fabricante del navegador y quien envía (un proveedor o tu propio servidor).
• El flujo siempre es el mismo: permiso, suscripción, envío, notificación y clic.
• Necesitas HTTPS, un service worker y un permiso que el usuario concede a partir de un gesto suyo.
• Funciona en escritorio y en Android; en iPhone y iPad, desde iOS 16.4 y solo si la web está añadida a la pantalla de inicio.
• Sirve para avisos breves, oportunos y personales, no para sincronizar datos ni para mensajes largos.

Los cuatro actores de Web Push

Son cuatro piezas y cada una tiene un papel claro:

El servicio push no lo eliges: viene con el navegador. Chrome usa el de Google, Firefox el de Mozilla, Safari el de Apple y Edge el de Microsoft. Todos siguen el mismo estándar, así que para tu producto es transparente. Lo que sí decides es quién hace de remitente: montarlo tú o delegarlo en un servicio.

El flujo completo, de permiso a clic

Todo aviso recorre cinco pasos. Pongamos una tienda online que quiere avisar cuando un pedido sale del almacén:

1. Permiso. En la página del pedido, un botón dice «Avísame cuando se envíe». El usuario lo pulsa y el navegador muestra su diálogo de permiso.
2. Suscripción. Si acepta, el navegador se registra en su servicio push y devuelve una suscripción: una dirección única para ese navegador en esa web. El remitente la guarda asociada al usuario.
3. Envío. Días después, tu backend detecta que el pedido ha salido y pide el envío: «a este usuario, con este título y este enlace».
4. Notificación. El servicio push entrega el mensaje al dispositivo. El navegador despierta al service worker de tu web, aunque no haya ninguna pestaña abierta, y este muestra la notificación.
5. Clic. El usuario la toca y el service worker abre la página de seguimiento, o enfoca la pestaña si ya la tenía abierta.

Por el camino, los mensajes viajan cifrados de extremo a extremo y el remitente se identifica con un par de claves VAPID, así que el servicio push transporta el aviso sin poder leerlo y nadie más puede escribir a tus suscriptores. Por qué esas claves importan tanto lo contamos en claves VAPID explicadas.

Qué necesita tu web

• HTTPS. Los service workers y la Push API solo existen en contextos seguros. Para desarrollar, localhost cuenta como seguro; una IP de tu red local por HTTP, no.
• Un service worker. Es un archivo JavaScript de tu dominio que el navegador ejecuta en segundo plano: recibe los push, muestra la notificación y gestiona el clic. Te explicamos su papel en el service worker en las notificaciones push.
• Un permiso pedido a partir de un gesto. Safari y Firefox solo muestran el diálogo si lo pides como respuesta a un clic o un toque, y Chrome muestra una versión discreta del diálogo en las webs cuyas peticiones suelen rechazarse.
• Una notificación visible por cada push. Los navegadores no permiten pushes silenciosos: cada mensaje tiene que terminar en algo que el usuario ve.

El permiso es el recurso más delicado. Si el usuario pulsa «Bloquear», solo él puede deshacerlo desde los ajustes del sitio, y casi nadie lo hace. Por eso conviene mostrar antes un aviso propio («¿Te avisamos cuando se envíe tu pedido?») y abrir el diálogo del navegador solo cuando el usuario ya ha dicho que sí.

Dónde funciona

El caso del iPhone es el que más sorprende. En una pestaña normal de Safari no hay push: el usuario tiene que usar Compartir y «Añadir a pantalla de inicio», abrir la web desde ese icono y conceder el permiso ahí. Apple lo detalla en el anuncio de WebKit, y nosotros en web push en iPhone.

¿Y si el dispositivo está apagado? El servicio push guarda el mensaje durante el tiempo de vida (TTL) que indique quien envía y lo entrega al reconectarse. «Tu pedido ha salido» puede esperar un día; «tu taxi está en la puerta» no sirve pasados unos minutos.

Para qué sirve y cuáles son sus límites

Web Push brilla cuando el aviso es breve, oportuno y personal:

• Transaccionales: pago recibido, pedido enviado, cita confirmada.
• Alertas que el usuario pidió: bajada de precio, vuelta de stock, respuesta a su comentario.
• Recordatorios con fecha: tu reserva es mañana, tu prueba gratuita termina en tres días.

Y tiene límites que conviene conocer antes de diseñar el producto:

• Poco espacio: el mensaje cifrado no puede pasar de 4096 bytes. Da para un título, un texto corto, un enlace y algunos datos; si necesitas más, envía un identificador y que la página cargue el resto.
• Entregado no es leído: un modo concentración o un navegador cerrado en el escritorio retrasan o esconden el aviso aunque haya llegado.
• Suscripciones que caducan: si el usuario revoca el permiso o borra los datos del navegador, su suscripción deja de existir y hay que retirarla de la lista.
• Atención limitada: cada aviso irrelevante acerca al usuario a desactivarlos.

Cómo encaja castly

La parte del remitente (guardar suscripciones, cifrar, identificarse ante cada servicio push, entregar, retirar las suscripciones caducadas y saber qué llegó) es la que más trabajo da y la que menos diferencia tu producto. castly la resuelve con tres piezas. En tu web, el SDK y un botón:

<script src="https://castly.sh/sdk/v1/castly.js"></script>
<script>
  Castly.init({ publicKey: 'pk_live_…' });
  document.querySelector('#avisame').addEventListener('click', () =>
    Castly.subscribe({ userId: 'user_123' })
  );
</script>

En la raíz de tu web, un archivo /castly-sw.js de una sola línea:

importScripts('https://castly.sh/sdk/v1/sw.js');

Y en tu backend, una llamada cuando el pedido sale del almacén:

curl https://castly.sh/v1/notifications \
  -H "Authorization: Bearer $CASTLY_SECRET_KEY" \
  -H "Content-Type: application/json" \
  -d '{"to":{"type":"users","userIds":["user_123"]},"title":"Tu pedido va en camino","url":"https://tienda.example/pedidos/8421"}'

La API responde 202 al momento, la entrega a cada dispositivo ocurre en segundo plano y en el panel ves cada aviso pasar de enviado a entregado y clicado. Tienes el paso a paso en la guía de inicio rápido.

Preguntas frecuentes

¿Web Push necesita Firebase?

No. Chrome usa la infraestructura de Google como servicio push, pero no necesitas cuenta, proyecto ni SDK de Firebase. El estándar funciona igual en todos los navegadores compatibles.

¿Llegan las notificaciones con la web cerrada?

Sí, porque el navegador despierta al service worker cuando llega el mensaje. En Android basta con que el dispositivo esté encendido y conectado. En escritorio, el navegador tiene que estar en ejecución; si no lo está, el aviso espera en el servicio push hasta que se abra, mientras no venza su TTL.

¿Puedo enviar un push sin mostrar ninguna notificación?

No. Los navegadores esperan una notificación visible por cada mensaje y penalizan a las webs que no la muestran. Si lo que quieres es sincronizar datos en segundo plano, Web Push no es la herramienta adecuada.

¿Necesito una PWA para usar Web Push?

En escritorio y Android, no: basta una web servida por HTTPS con un service worker. En iPhone y iPad, en la práctica sí, porque el push solo funciona cuando la web está añadida a la pantalla de inicio, y para eso conviene que tenga un manifiesto web.