Por qué WordPress no puede mantener abierto un websocket y qué hacer en su lugar

Tarde o temprano, un sitio WordPress necesita que algo pase en directo: un mensaje nuevo que aparece sin recargar, un aviso en cuanto entra un pedido, un contador de quién está en línea, una llamada que suena. La herramienta para eso en la web es el websocket, una conexión entre el navegador y un servidor que se mantiene abierta, para que el servidor pueda enviar algo en el momento en que ocurre.

Y entonces llega la sorpresa: WordPress no tiene servidor websocket, y el hosting en el que funciona no puede alojar uno. Este artículo explica por qué, qué suelen hacer los sitios al respecto y lo que cuesta mantener tu propio servidor websocket.

WordPress responde a una petición y se detiene

Cada página de WordPress, cada llamada a la REST API y cada petición a admin-ajax funcionan igual. El servidor web pasa la petición a PHP, PHP carga WordPress con sus plugins y su tema, calcula la respuesta, la envía y se detiene. La siguiente petición vuelve a empezar desde cero.

Gracias a ese modelo, WordPress funciona casi en cualquier parte. Y por ese mismo modelo no puede mantener un websocket. Un websocket no es una petición, sino una conexión que sigue abierta mientras lo esté la página, a menudo durante horas. Mantenerla exigiría un proceso de PHP por cada página abierta, sin hacer nada la mayor parte del tiempo, y un hosting solo da a cada sitio unos pocos procesos de PHP, suficientes para peticiones que terminan en una fracción de segundo. Un puñado de visitantes con una página abierta los ocuparía todos, y el sitio dejaría de responder a todos los demás.

Los proveedores de hosting se protegen de eso. Cortan las peticiones que duran demasiado, a menudo al cabo de entre 30 y 60 segundos, y en la mayoría de los planes no dejan que un sitio arranque un proceso propio en segundo plano ni que abra un puerto para él. Incluso donde el hosting lo permite, el servidor que está delante de PHP, y cualquier proxy que haya delante de ese servidor, tienen que estar configurados para dejar pasar un websocket.

Polling: preguntar una y otra vez

La forma habitual de esquivarlo es el polling. La página pregunta al servidor cada pocos segundos: “¿hay algo nuevo?”. Casi siempre la respuesta es que no.

Cada una de esas preguntas es una petición completa a WordPress: PHP arranca, carga WordPress y sus plugins, consulta la base de datos y responde. Con 50 visitantes en una página que pregunta cada 5 segundos, son 10 peticiones completas a WordPress por segundo, cada segundo, casi siempre para nada. Si preguntas con menos frecuencia, el sitio parece lento, con mensajes que tardan medio minuto en aparecer. Si preguntas más a menudo, el hosting empieza a sufrir, o te envía un aviso por uso de recursos.

WordPress tiene su propia versión de esto, la Heartbeat API, que pregunta cada 15 a 60 segundos. Sirve para guardar borradores y mostrar quién está editando una entrada. Para un chat o una llamada, es demasiado lenta.

El long polling y los server-sent events, en los que el servidor mantiene abierta la petición hasta que pasa algo, parecen una solución. En WordPress no lo son: cada petición en espera ocupa un proceso de PHP, y eso choca de lleno con el mismo límite que un websocket.

Un servidor websocket propio

La solución de verdad es un servidor hecho para mantener muchas conexiones abiertas, junto a WordPress y no dentro de él. Muchos equipos montan uno. Esto es lo que hace falta:

• Un servidor propio, normalmente un pequeño servidor virtual con Node.js u otro entorno de ejecución pensado para conexiones largas, con sus propias actualizaciones y su propia monitorización.
• Un certificado y un proxy, para que el navegador pueda conectarse por wss:// en tu dominio.
• Conocer a tus usuarios. El servidor websocket no ve el inicio de sesión de WordPress, así que tu sitio tiene que dar a cada página un token firmado, y el servidor tiene que comprobarlo y decidir quién puede entrar en cada canal.
• Una forma de que WordPress envíe. Cuando pasa algo en WordPress, un hook tiene que avisar al servidor websocket, que luego lo envía a los navegadores que corresponda.
• Más de uno, a medida que creces. Un solo servidor es un único punto en el que pueden caerse todas las conexiones. Con dos o más hace falta una forma de compartir los mensajes entre ellos, y las páginas tienen que reconectarse sin problemas cuando un servidor se reinicia.

Nada de esto es exótico, pero es un segundo sistema que hay que mantener en marcha junto a WordPress mientras el sitio tenga funciones en directo. Para las llamadas, es solo el principio: una llamada también necesita servidores STUN y TURN, y las llamadas en grupo necesitan servidores multimedia, como explica nuestro artículo sobre cómo funcionan las videollamadas en grupo.

O deja que una nube en tiempo real mantenga las conexiones

La otra vía es un servicio en tiempo real alojado. Los navegadores mantienen sus conexiones abiertas con el servicio, no con tu hosting. Cuando pasa algo en tu sitio, WordPress envía una petición corta al servicio, y el servicio la entrega a cada página que deba recibirla. Tu hosting solo responde a peticiones normales, como siempre ha hecho.

WordPress sigue siendo el lugar donde viven tus datos. El servicio solo lleva eventos del sitio a las páginas y entre páginas, así que no cambia nada en cómo tu sitio guarda entradas, usuarios o pedidos.

Cómo lo hace WordPlus Cloud para WordPress

WordPlus Cloud for WordPress es esa nube, para todos los plugins de un sitio WordPress:

• Nada que mantener. Los servidores en tiempo real, los relés de las llamadas, los servidores multimedia y la IA funcionan en la nube. Tu sitio solo necesita una suscripción, con un precio por sitio y sin límites de miembros ni mensajes.
• Todos los plugins del sitio pueden usarla. Better Messages y Live Stream la usan desde el primer momento. Los plugins creados para el protocolo Pusher se conectan con nuestros hosts y las claves de tu sitio, y cualquier otro plugin, tema o código personalizado se conecta mediante nuestra API para desarrolladores.
• Tus datos se quedan en WordPress. Las conversaciones, los miembros y los archivos se quedan en tu base de datos. Los mensajes cruzan la nube sellados con una clave que guarda tu sitio, así que los transportamos sin leerlos.
• Más que websockets. La misma suscripción trae llamadas que siempre se conectan, llamadas en grupo, notificaciones push en navegadores y teléfonos, transmisión en directo, tus propias apps móviles e IA, sobre la misma conexión.

Cada página mantiene una sola conexión, compartida por todos los plugins del sitio, que pasa a otro servidor sin cortes cuando uno se reinicia. Tu hosting vuelve a hacer lo que hace bien: responder a peticiones.

Descubre WordPlus Cloud for WordPress, o consulta los precios para tu número de sitios.