---
title: "WordPress 6.9 recorta el TTFB moviendo WP-Cron al apagado: pequeño cambio, gran impacto"
description: "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 s..."
url: https://wpdirecto.com/wordpress-6-9-recorta-el-ttfb-moviendo-wp-cron-al-apagado-pequeno-cambio-gran-impacto/
date: 2025-12-09
modified: 2025-12-07
author: "Editor WPDirecto"
image: https://wpdirecto.com/wp-content/uploads/2025/12/wp-cron-mejoras.jpg
categories: ["Actualidad"]
tags: ["wp cron"]
type: post
lang: es
---

# WordPress 6.9 recorta el TTFB moviendo WP-Cron al apagado: pequeño cambio, gran impacto

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](https://wpdirecto.com/tag/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](https://make.wordpress.org/core/2025/11/18/wordpress-6-9-frontend-performance-field-guide/#spawn-wp-cron-at-shutdown-instead-of-init)