Pourquoi WordPress ne peut pas garder un websocket ouvert, et que faire à la place

Tôt ou tard, un site WordPress a besoin que quelque chose se passe en direct : un nouveau message qui s’affiche sans recharger la page, une notification dès qu’une commande arrive, le nombre de personnes en ligne, un appel qui sonne. Sur le web, l’outil pour cela est le websocket, une connexion entre le navigateur et un serveur qui reste ouverte, pour que le serveur puisse envoyer ce qui se passe à l’instant même où cela se produit.

Vient alors la surprise : WordPress n’a pas de serveur websocket, et l’hébergement sur lequel il tourne ne peut pas en faire tourner un. Cet article explique pourquoi, ce que font d’habitude les sites pour s’en sortir, et ce qu’il en coûte de faire tourner votre propre serveur websocket.

WordPress répond à une requête puis s’arrête

Chaque page WordPress, chaque appel à l’API REST et chaque requête admin-ajax fonctionnent de la même façon. Le serveur web passe la requête à PHP, PHP charge WordPress avec ses extensions et son thème, calcule la réponse, l’envoie et s’arrête. La requête suivante repart de zéro.

C’est grâce à ce modèle que WordPress tourne presque partout. C’est aussi pour cela qu’il ne peut pas garder un websocket ouvert. Un websocket n’est pas une requête, mais une connexion qui reste ouverte aussi longtemps que la page, souvent pendant des heures. Pour la garder, il faudrait un processus PHP par page ouverte, qui ne ferait rien la plupart du temps, alors qu’un hébergeur n’accorde à un site qu’un petit nombre de processus PHP, assez pour des requêtes qui se terminent en une fraction de seconde. Une poignée de visiteurs avec une page ouverte suffirait à les occuper tous, et le site ne répondrait plus à personne d’autre.

Les hébergeurs s’en protègent. Ils interrompent les requêtes qui durent trop longtemps, souvent au bout de 30 à 60 secondes, et sur la plupart des offres, ils ne laissent pas un site lancer son propre processus en arrière-plan ni ouvrir un port pour lui. Même là où l’hébergeur le permet, le serveur placé devant PHP, et tout proxy placé devant ce serveur, doivent être configurés pour laisser passer un websocket.

Le polling : redemander encore et encore

Le contournement habituel est le polling. Toutes les quelques secondes, la page demande au serveur : « du nouveau ? » La plupart du temps, la réponse est non.

Chacune de ces questions est une requête WordPress complète : PHP démarre, charge WordPress et ses extensions, interroge la base de données et répond. Avec 50 visiteurs sur une page qui interroge le serveur toutes les 5 secondes, cela fait 10 requêtes WordPress complètes par seconde, chaque seconde, pour rien la plupart du temps. Demandez moins souvent, et le site semble lent, avec un message qui met une demi-minute à s’afficher. Demandez plus souvent, et l’hébergement commence à peiner, ou l’hébergeur vous avertit de votre consommation de ressources.

WordPress a sa propre version de ce mécanisme, l’API Heartbeat, qui interroge le serveur toutes les 15 à 60 secondes. Elle convient pour enregistrer les brouillons et montrer qui modifie un article. Elle est bien trop lente pour un chat ou un appel.

Le long polling et les server-sent events, où le serveur garde la requête ouverte jusqu’à ce qu’il se passe quelque chose, ressemblent à une solution. Sur WordPress, ils n’en sont pas une : chaque requête en attente occupe un processus PHP, et l’on se heurte tout droit à la même limite qu’avec un websocket.

Votre propre serveur websocket

La vraie solution, c’est un serveur conçu pour garder de nombreuses connexions ouvertes, à côté de WordPress plutôt qu’à l’intérieur. Beaucoup d’équipes en construisent un. Ce qu’il faut :

• Un serveur à part, en général un petit serveur virtuel qui fait tourner Node.js ou un autre runtime conçu pour les connexions longues, avec ses propres mises à jour et sa propre surveillance.
• Un certificat et un proxy, pour que le navigateur puisse se connecter en wss:// sur votre domaine.
• Connaître vos utilisateurs. Le serveur websocket ne sait pas qui est connecté à WordPress, si bien que votre site doit remettre à chaque page un jeton signé, que le serveur doit vérifier avant de décider qui peut rejoindre quel canal.
• Un moyen pour WordPress d’envoyer. Quand quelque chose se passe dans WordPress, un hook doit prévenir le serveur websocket, qui l’envoie ensuite aux bons navigateurs.
• Plusieurs serveurs, à mesure que vous grandissez. Avec un seul serveur, toutes les connexions peuvent tomber au même endroit. À partir de deux, il faut un moyen de partager les messages entre eux, et les pages doivent se reconnecter en douceur quand un serveur redémarre.

Rien de tout cela n’est exotique, mais c’est un second système à faire tourner à côté de WordPress, tant que le site a des fonctions en direct. Pour les appels, ce n’est qu’un début : un appel a aussi besoin de serveurs STUN et TURN, et les appels de groupe de serveurs multimédias, comme l’explique notre article sur le fonctionnement des appels vidéo de groupe.

Ou confier les connexions à un cloud temps réel

L’autre voie, c’est un service temps réel hébergé. Les navigateurs gardent leurs connexions ouvertes vers ce service, et non vers votre hébergement. Quand quelque chose se passe sur votre site, WordPress envoie une seule courte requête au service, et le service transmet l’événement à chaque page qui doit le recevoir. Votre hébergement ne répond qu’à des requêtes ordinaires, comme il l’a toujours fait.

Vos données continuent de vivre dans WordPress. Le service ne fait que transporter des événements du site vers les pages et d’une page à l’autre, et rien ne change dans la façon dont votre site enregistre ses articles, ses utilisateurs ou ses commandes.

Comment WordPlus Cloud s’en charge pour WordPress

WordPlus Cloud for WordPress est ce cloud, pour toutes les extensions d’un site WordPress :

• Rien à gérer. Les serveurs temps réel, les relais d’appel, les serveurs multimédias et l’IA tournent dans le cloud. Votre site n’a besoin que d’un abonnement, avec un prix par site, sans limite de membres ni de messages.
• Toutes les extensions du site peuvent l’utiliser. Better Messages et Live Stream l’utilisent d’emblée. Les extensions conçues pour le protocole Pusher se connectent avec nos hôtes et les clés de votre site, et toute autre extension, tout thème ou tout code sur mesure se connecte par notre API pour développeurs.
• Vos données restent dans WordPress. Conversations, membres et fichiers restent dans votre base de données. Les messages traversent le cloud scellés avec une clé que détient votre site, si bien que nous les relayons sans les lire.
• Plus que des websockets. Le même abonnement apporte des appels qui se connectent toujours, les appels de groupe, les notifications push sur navigateurs et téléphones, la diffusion en direct, vos propres applications mobiles et l’IA, sur la même connexion.

Une page garde une seule connexion, partagée par toutes les extensions du site, et cette connexion passe sur un autre serveur sans coupure quand l’un d’eux redémarre. Votre hébergement revient à ce qu’il fait bien : répondre aux requêtes.

Découvrez WordPlus Cloud for WordPress, ou consultez les tarifs pour votre nombre de sites.