WordPress 6.9 llega con una mejora técnica que, aunque no brilla tanto como un nuevo editor o un tema por defecto, puede notarse de forma muy clara en algo que obsesiona a cualquier administrador de sistemas y a muchos SEOs: el tiempo hasta el primer byte (TTFB). El proyecto ha decidido cambiar el momento en el que se lanza WP-Cron, el sistema de tareas programadas interno de WordPress, para evitar retrasos innecesarios en la carga de las páginas.

Hasta ahora, la llamada a WP-Cron se disparaba durante el hook init. A partir de WordPress 6.9, se mueve al hook shutdown. El objetivo es sencillo: evitar que el intento de ejecutar tareas cron añada hasta un segundo extra al TTFB cada vez que toca lanzar wp-cron.php.

Qué problema se ha detectado con WP-Cron

WP-Cron no es un cron del sistema como tal, sino un sistema de tareas programadas que WordPress activa cuando alguien visita la web. En lugar de depender de crontab a nivel de servidor, el núcleo intenta hacer una petición HTTP interna (loopback) hacia wp-cron.php para que se ejecuten las tareas pendientes: publicar entradas programadas, limpiar transitorios, lanzar tareas de plugins, etcétera.

En teoría, esa petición se realiza como una llamada “asíncrona y no bloqueante”, usando wp_remote_post() con el parámetro blocking => false. En la práctica, durante el ciclo de desarrollo de WordPress 6.9 se ha comprobado que, en muchos entornos, esta llamada sí introducía un retraso adicional antes de empezar a devolver contenido al navegador.

Eso se traducía en algo muy concreto: en el momento en que WordPress decidía “toca lanzar WP-Cron”, el usuario podía ver su TTFB incrementar alrededor de 1 segundo, incluso aunque el resto de la página estuviera optimizada.

Por qué mover WP-Cron de init a shutdown ayuda al rendimiento

El cambio introducido en WordPress 6.9 es simple pero efectivo: en lugar de intentar lanzar WP-Cron durante init —cuando aún se está preparando la respuesta—, el disparo de la llamada se retrasa hasta el hook shutdown, cuando WordPress ya ha enviado la salida principal al navegador.

La lógica detrás del cambio es clara:

• Antes:
  1. El usuario hace una petición.
  2. WordPress arranca, carga plugins y tema.
  3. Durante init, se comprueba si toca ejecutar cron y se intenta una llamada no bloqueante a wp-cron.php.
  4. Esa llamada, en algunos entornos, introduce hasta 1 segundo extra antes de que empiece a responder la página.
• Ahora (WordPress 6.9):
  1. El usuario hace una petición.
  2. WordPress procesa la solicitud y genera la respuesta.
  3. Se envía el contenido al navegador.
  4. Durante shutdown, se lanza la llamada para ejecutar WP-Cron, de forma que cualquier latencia afecta al servidor, pero no al TTFB ni a la percepción del usuario.

El impacto práctico, según la propia descripción del cambio, es un posible recorte de hasta 1 segundo de TTFB en las peticiones en las que se dispara WP-Cron.

Qué significa esto para administradores de sistemas y hosters

Aunque a primera vista pueda parecer un ajuste menor, este cambio encaja de lleno en el enfoque de rendimiento que WordPress lleva años impulsando desde el núcleo. Para administradores de sistemas, proveedores de hosting y responsables de sitios de alto tráfico, hay varios puntos clave:

1. Menos picos de latencia “inexplicables”
   Muchos equipos veían flujos de peticiones con TTFB razonable y, de repente, saltos de casi 1 segundo que no se justificaban ni por CPU, ni por I/O, ni por consultas SQL. En entornos donde el cron interno seguía activo, esas variaciones podían coincidir con ejecuciones de WP-Cron.
2. Mejor alineación con Core Web Vitals y SEO
   Aunque TTFB no es la única métrica que importa, una reducción de 500–1.000 milisegundos en determinadas peticiones puede ayudar a mejorar métricas relacionadas con la percepción de velocidad y, por extensión, a contribuir en los objetivos de rendimiento que marcan herramientas como PageSpeed Insights o Lighthouse.
3. Menos fricción para quienes aún no usan cron del sistema
   La recomendación tradicional en entornos profesionales ha sido desactivar el cron interno (DISABLE_WP_CRON) y programar un cron real del sistema que llame a wp-cron.php de forma periódica. Ese sigue siendo el enfoque más robusto, especialmente en sitios de alto tráfico o con muchas tareas programadas, pero el cambio de WordPress 6.9 reduce el impacto negativo para aquellos proyectos que todavía dependen del cron simulado.
4. Mejor comportamiento en entornos con loopbacks lentos
   En algunos hostings —sobre todo con restricciones de red internas, proxies o seguridad agresiva— las peticiones loopback a wp-cron.php pueden ser especialmente lentas o inestables. Al mover la ejecución a shutdown, esa lentitud deja de afectar al usuario final en primera instancia.

¿Sigue teniendo sentido usar un cron del sistema?

Sí. Este cambio mejora el comportamiento por defecto, pero no sustituye las buenas prácticas clásicas:

• En sitios de misión crítica, comercio electrónico, proyectos corporativos o medios de comunicación, lo ideal sigue siendo:
  • Desactivar WP-Cron interno (define('DISABLE_WP_CRON', true);).
  • Configurar un cron del sistema (cada 1–5 minutos) que llame a wp-cron.php vía CLI o HTTP.
• Esto garantiza:
  • Ejecución predecible de tareas programadas.
  • Menos acoplamiento entre tráfico real y ejecución de cron.
  • Mejor control sobre recursos y ventanas de mantenimiento.

WordPress 6.9 hace que el comportamiento por defecto sea menos perjudicial para el rendimiento, pero no convierte al cron interno en la opción óptima para cualquier escenario.

Qué pueden esperar los usuarios tras actualizar a WordPress 6.9

Para la mayoría de los usuarios finales y propietarios de sitios, el cambio será transparente. No hay que tocar ajustes ni añadir código: viene integrado en el núcleo.

Lo que sí pueden notar, especialmente en sitios con tráfico moderado y cron interno activo, es:

• Una sensación de página “más ágil” en determinadas cargas.
• Menos variación entre peticiones “rápidas” y peticiones “misteriosamente lentas” provocadas por el disparo de WP-Cron.
• Un pequeño empujón a la estabilidad de métricas de rendimiento, sin necesidad de instalar nuevos plugins.

Preguntas frecuentes sobre WordPress 6.9, WP-Cron y el TTFB

¿Este cambio en WordPress 6.9 elimina la necesidad de usar cron del sistema?
No. El nuevo comportamiento reduce el impacto del cron interno sobre el TTFB, pero en sitios serios sigue siendo recomendable desactivar WP-Cron por defecto y usar un cron real del sistema para ejecutar wp-cron.php de forma periódica y controlada.

¿Voy a notar siempre 1 segundo menos de TTFB tras la actualización?
No en todas las peticiones. La mejora potencial de hasta 1 segundo se aplica en aquellas solicitudes donde WordPress debía disparar WP-Cron y la llamada loopback introducía latencia. En otras peticiones, el TTFB dependerá de otros factores: PHP, base de datos, caché, red, etc.

¿Debo cambiar algo en mi configuración de plugins de caché o rendimiento?
En principio no. El cambio está en el núcleo y es transparente. Aun así, siempre es buena idea, después de una actualización mayor, vaciar cachés (de página, OPCache, CDN) y monitorizar métricas de TTFB y rendimiento durante unos días.

¿Cómo puedo saber si WP-Cron está afectando a mi tiempo de carga?
Se puede usar el registro de debug de WordPress y herramientas de profiling (plugins de monitorización, APM del proveedor de hosting, etc.) para comprobar cuándo se ejecuta WP-Cron y cruzarlo con los picos de TTFB. También es útil revisar los logs del servidor para ver cuánto tarda la llamada a wp-cron.php cuando se dispara.

vía: Cambios en WordPress 6.9 para WP Cron