WordPress 7.0 RC1 pasó del 19 al 24 de marzo por problemas de rendimiento de colaboración en tiempo real, optimización de medios en el cliente y tamaño del paquete. La colaboración muestra cómo una función visible puede forzar una decisión profunda de almacenamiento al final de una release.
La colaboración usa CRDT y HTTP polling. Los datos de sincronización estaban en post_meta, por lo que cada actualización invalidaba caches de consultas de posts. Un editor generaba un poll por segundo; dos producían cuatro. En un sitio con tráfico, activarla podía debilitar el cache persistente de posts.
La dirección propuesta era mover RTC a una tabla dedicada y separar escrituras volátiles de las consultas de contenido. Es un cambio arquitectónico grande entre beta y release candidate. El proyecto desactivó la colaboración por defecto en RC1, incluso donde se había activado en beta, y pospuso la decisión sobre el valor predeterminado.
Qué hace el poll con la cache de posts
Peter Wilson documentó en Trac que, con RTC encendido y el editor abierto, WordPress opera como si la cache persistente de queries de posts estuviera apagada. Presencia (wp_sync_awareness) y updates (wp_sync_update) viven en post_meta. Cualquier escritura ahí dispara invalidación amplia, incluso de queries que no tienen relación con el post abierto.
Un editor: un poll por segundo. Dos: cuatro por segundo. En un install fresco, Wilson midió 60 requests por minuto y 110 a 120 KB solo de abrir Hello World. Con dos colaboradores, del orden de 480 requests por minuto y unos 900 KB. Heartbeat, que el core ya usa para lock, dispara como máximo cada 10 segundos y desacelera con la pestaña en segundo plano. RTC, en la forma que encontró, seguía cada segundo con la pestaña abierta y nadie escribiendo.
En la reunión del equipo de hosting, GoDaddy describió requests cada 250 ms por editor, imposibles de cachear. WP Engine señaló contención de recurso y riesgo de race. En un sitio con object cache, la función encendida se vuelve un generador de invalidación mientras alguien deja Gutenberg abierto.
Criterio para activar colaboración donde ya hay tráfico
En RC1 la función viene apagada. Opt-in en Ajustes, Escritura. Quien la activó en beta la encuentra apagada después del update. En un sitio con object cache persistente y page cache delante, ese default es el único que tiene sentido hasta que la tabla nueva exista en el paquete que vas a correr de verdad.
Enciende RTC donde la coedición es rutina: redacción, agencia, equipo que trabaja el mismo post. Un sitio de un autor, una tienda, marketing con un editor por vez paga el poll y gana poco. Hay un caso estrecho, planteado en Trac, de quien abre el mismo post en varias pestañas o aparatos. Aun ahí, mide antes de convertirlo en política.
Con la función encendida y el editor abierto, compara tasa de invalidación, hit ratio del object cache, requests por minuto en el endpoint de sync, CPU e I/O de la base, y la misma URL de front con el editor cerrado. Si el listado de posts del sitio público se derrite porque alguien se fue a almorzar con Gutenberg abierto, el costo operativo ya apareció.
La tabla dedicada y lo que RC1 aún deja abierto
La dirección técnica es una tabla solo para el sync, discutida como wp_collaboration. Matt Mullenweg, en general contrario a tablas nuevas en core, aceptó esta como primitiva para colaboración y sync futuros. La última adición en ese espíritu fue wp_termmeta, en 4.4, en diciembre de 2015.
Sacar el sync de post_meta evita los hooks de invalidación, reduce la race de dos editores grabando en el mismo milisegundo y deja la compactación de datos viejos como operación atómica. Entre beta y RC, eso es un cambio pesado. Por eso el default quedó para RC2.
Multisite todavía tiene una arista: un administrador de subsitio puede encender RTC sin poder disparar el upgrade de base. También está la idea, en un ticket aparte, de marcar ciertas claves de post_meta como no consultables para no invalidar cache. Wilson prefirió no mezclar eso en la corrección actual. No lo actives en red hasta que el camino de schema esté claro en las release notes que vas a aplicar.
La fecha del 9 de abril en WordCamp Asia es calendario de lanzamiento. Default encendido o apagado es decisión de arquitectura. Las dos pueden divergir.
Prueba con el editor inactivo y la cache encendida
Make WordPress Test pidió ejercicio con contenido real, más de un colaborador, bloques custom y plugins. El polling HTTP tiene lag. El canal de la función y la tracking issue en GitHub existen para lo que traba y lo que fluye.
Para un sitio que ya sirve tráfico, el test útil empieza flaco: un editor, después dos, object cache encendido, plugin de page cache delante, Heartbeat en el comportamiento actual. Deja el editor abierto diez minutos sin escribir. Si el poll no amaina en el paquete candidato, enciende la función solo con horario marcado y rollback.
Un ajuste en el cliente ya reduce el poll con la pestaña inactiva, y la tasa debería quedar filtrable para hosts. Ninguno de los dos reemplaza salir de post_meta. Hasta que la tabla exista en el zip que vas a actualizar, trata la colaboración en tiempo real como opt-in, aunque la fase 3 de Gutenberg siga siendo el titular de 7.0.
Si tu empresa está evaluando algo parecido, escríbeme por LinkedIn o por WhatsApp.
