# Why Real-Time WordPress Is the Future > [!question] Lingering Questions > - Is the "90% of polling messages are empty" figure Rehtman's own testing or a published core benchmark? > - Is the "99% of hosts don't support WebSockets/SSE" figure sourced anywhere, or purely anecdotal? > - What does core's Real-Time Collaboration provider architecture actually expose as a documented extension point today? > [!tip] Article Ideas > - A sourced comparison of major WordPress hosts' WebSocket/SSE support, checked against Rehtman's unsourced "99% unsupported" claim. > - A sequence diagram contrasting HTTP polling (empty 90% of the time) against WebSocket push-on-change, for a DevRel talk or post. > [!link] Cross Reference > - [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] > [!quote] Vocabulary > - **Provider architecture** — the pluggable extension point in core's Real-Time Collaboration feature that lets an alternative transport (like a WebSocket relay) swap in for the current HTTP-polling implementation. ## Bib capsule Medeiros, Matt (host) and Jared Rehtman (guest). "Why Real-Time WordPress Is the Future." *The WP Minute*, YouTube, 2026. https://www.youtube.com/watch?v=qFTRZr2_s8k ## Author's thesis (Q1+Q2) Rehtman argues that WordPress's real gap around real-time behavior isn't a code problem — WP Signal's WebSocket relay is technically replicable by any competent team in a couple of months. The actual scarcity sits at the hosting layer: he estimates the vast majority of WordPress hosts don't support WebSockets or server-sent events, which is what pushes real-time capability out to a third-party relay. He extends this into core itself: core's own in-progress Real-Time Collaboration feature uses HTTP polling that wastes roughly 90% of its requests confirming nothing changed, and that design is reportedly the reason the feature slipped from a 7.0 target and is uncertain for 7.1 — but core built the feature on a provider architecture designed to be pluggable, so a WebSocket relay could swap in as an alternative transport without a core rewrite. ## Key arguments (≤3) 1. Core's current Real-Time Collaboration polling implementation is wasteful and likely load-bearing on its own delayed ship date — about 90% of its ~3-second polling requests return "nothing changed." 2. WP Signal's competitive moat isn't its code (easily replicated) but the hosting-support gap: most WordPress hosts allegedly don't support WebSockets/SSE at all. 3. Core didn't architect itself into a corner — the Real-Time Collaboration feature's provider architecture is a designed extension point, meaning a WebSocket relay is a plug-in transport swap, not a fork. ## Claim atoms ### Core's real-time polling wastes ~90% of requests > [!quote] ID:rw_qFTRZr2_s8k_1712 > So, 90% of those messages are empty because it's saying, "Has anything changed? Has anything changed?" Where/why: [28:32] — Rehtman explaining core's Real-Time Collaboration HTTP-polling transport; a specific, falsifiable performance claim tied to the feature's reported ship-date slip. ### WP Signal's real moat is hosting, not code > [!quote] ID:rw_qFTRZr2_s8k_481 > I would say the vast majority 99% of hosting companies don't support web sockets and service and events. Where/why: [08:01] — Rehtman's direct answer to "what's your moat," reframing the competitive question from code-replicability to hosting-layer scarcity. ### Core's provider architecture is built to be pluggable > [!quote] ID:rw_qFTRZr2_s8k_1681 > in using a provider architecture where you can as as a provider as a web socket um real-time collaboration I mean a real-time web socket relay, I can just plug into that provider architecture and instead of using the the polling mechanism that's that's kind currently implemented. Where/why: [28:01] — the polling-vs-WebSocket choice is a designed extension point in core, not a fork, which lowers the cost of eventually fixing the inefficiency named above. ## Permanent candidates - **New**: Real-time transport is a hosting-layer gap, not a WordPress-core gap — promoted below as [[3. Resources/Permanent Notes/Real-Time Transport Is a Hosting-Layer Gap Not a WordPress-Core Gap]] ## Processing checklist - [x] Checked for existing Literature Note — none found - [x] Checked for existing Permanent Notes covering this source's claims — grepped Permanent Notes and Literature Notes for "websocket," "real-time," "hosting infrastructure," "server-sent events." Found adjacent notes on collaborative editing generally (e.g. "Zet · Collaborative editing features mirror Google Docs patterns," "WordPress 7.1 Roadmap Focuses on Collaboration") but none capturing the hosting-layer-gap or polling-waste claims specifically — no duplicate. - [x] Connected into WordPress Hosting Security Stack MOC ## Links - [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] — the hosting-support gap for WebSockets/SSE is a hosting-infrastructure capability question, matching this MOC's scope.