WordPress 6.9 llega con una mejora silenciosa pero de gran impacto para muchos sitios: la corrección de un fallo en la caché de fuentes RSS que se introdujo en WordPress 6.7 tras la actualización de la librería SimplePie. El problema pasaba desapercibido a simple vista, pero tenía consecuencias claras en el rendimiento de cualquier instalación que utilizara widgets o bloques basados en feeds externos.

Durante varias versiones, las llamadas a fetch_feed() —la función estándar de WordPress para consumir fuentes RSS o Atom— no reutilizaban correctamente la respuesta almacenada en transients, a pesar de que, por diseño, estos datos deberían cachearse durante 12 horas. El resultado: cada carga de página volvía a descargar y procesar el feed, como si no existiera caché.

Con WordPress 6.9 este comportamiento se corrige y la caché vuelve a funcionar como estaba previsto, con un impacto medible en tiempos de respuesta y consumo de recursos.

Qué se rompió en WordPress 6.7 y por qué importa

En WordPress 6.7 se actualizó SimplePie, la librería encargada de parsear RSS, Atom y otros formatos de sindicación. Esa actualización introdujo un efecto colateral: el sistema de caché basado en transients dejó de reutilizar los datos ya almacenados.

En la práctica, esto significaba que:

• Cada llamada a fetch_feed() suponía una nueva petición HTTP al origen del feed.
• El contenido se volvía a procesar en cada carga de página.
• El tiempo de generación de la página aumentaba, especialmente si había varios feeds o si el servidor remoto respondía lento.

El problema afectaba especialmente a:

• Sitios que utilizaban el widget o bloque de “Feed” en barras laterales y pies de página.
• Portales que agregan noticias, podcasts o contenidos externos en portada.
• Temas y plugins que usan fetch_feed() de forma programática.

En muchos casos, los administradores veían un aumento del tiempo de respuesta sin cambiar nada en su configuración de plugins, temas o hosting, lo que complicaba el diagnóstico.

Qué cambia con WordPress 6.9: caché de RSS de nuevo bajo control

WordPress 6.9 corrige el fallo en la integración con SimplePie y restablece el comportamiento esperado de la caché de RSS:

• La primera llamada a fetch_feed() descarga y procesa el feed.
• El resultado se almacena en un transient con una vida útil por defecto de 12 horas.
• Las llamadas posteriores reutilizan esos datos sin volver a consultar al servidor remoto, salvo que haya expirado el tiempo de caché.

Esto reduce de forma directa:

• El número de peticiones HTTP salientes.
• El trabajo de CPU al parsear y procesar el feed.
• El tiempo total de generación de la página, sobre todo en vistas con widgets de feeds.

El impacto en números: hasta un 87 % menos de tiempo de respuesta

Las propias pruebas de rendimiento con WordPress 6.9 muestran diferencias muy claras al comparar una página con el widget de feed antes y después de la corrección.

Tomando como referencia 100 peticiones a una misma URL, las métricas medianas pasan de:

• Tiempo de respuesta total (Response Time):
  • De 266,57 ms en WordPress 6.8
  • A 34,74 ms en WordPress 6.9
  • Es decir, unos 231,83 ms menos, una reducción aproximada del 87 %.
• Tiempo total de WordPress (wp-total) —el tiempo interno de ejecución del CMS—:
  • De 264,56 ms
  • A 33,40 ms
  • También con una caída de alrededor del 87,4 %.
• Fase wp-template (carga de la plantilla):
  • De 252,55 ms
  • A 25,56 ms
  • Una mejora cercana al 90 %.
• Filtro the_content (procesado del contenido del post):
  • De 224,50 ms
  • A 9,35 ms
  • Una reducción de alrededor del 95,8 %.

Los números dejan claro que, en páginas donde se mostraba un feed remoto mediante el widget correspondiente, el simple hecho de arreglar la caché devuelve el coste de esa operación a niveles casi anecdóticos.

Quién se beneficia más de esta mejora

No todos los sitios notarán el cambio con la misma intensidad. Los que más se benefician son:

• Blogs y medios online que muestran titulares de otras webs mediante RSS.
• Sitios corporativos con bloques de “Últimas noticias del sector” obtenidas de fuentes externas.
• Portales de comunidad o agregadores que combinan contenido propio y ajeno.
• Cualquier instalación con el widget de feeds activo en barras laterales, footers o secciones de contenido.

En sitios sin uso de feeds externos, el impacto de esta mejora concreta será nulo o muy pequeño. En cambio, en entornos donde se abusa de fetch_feed() —por ejemplo, consultando varios feeds en una misma página— la diferencia puede ser dramática.

Qué deberían hacer administradores y desarrolladores

Para los administradores de sistemas y responsables técnicos de sitios WordPress, los pasos recomendables son claros:

1. Actualizar a WordPress 6.9
   Especialmente si el sitio usa feeds externos. La corrección del bug de caché viene integrada en el núcleo y no requiere cambios en plugins o temas.
2. Revisar el uso de widgets y bloques de RSS
   Conviene identificar dónde se están cargando feeds, cuántos por página y de qué orígenes. Esto ayuda a entender por qué ciertas URLs eran más lentas en versiones anteriores.
3. Medir antes y después
   Usar herramientas como las cabeceras de Server-Timing, Query Monitor o el propio panel de rendimiento del proveedor de hosting permite confirmar la mejora en tiempos de generación.
4. Ajustar la duración de la caché si es necesario
   Para sitios que necesitan actualizaciones de feeds más frecuentes o, al contrario, pueden vivir con datos menos recientes, es posible ajustar la vida útil de los transients mediante filtros como wp_feed_cache_transient_lifetime.

A nivel de desarrollo, los autores de temas y plugins que usan fetch_feed() no tienen que hacer cambios específicos por esta corrección, pero sí se recomienda:

• Evitar llamadas redundantes al mismo feed dentro de una misma petición.
• Documentar qué feeds se consumen y con qué frecuencia.
• Supervisar posibles errores cuando el origen del RSS no responde o lo hace con lentitud.

WordPress 6.9, una versión claramente orientada al rendimiento

La mejora de la caché de RSS no llega sola. WordPress 6.9 incorpora otros ajustes pensados para reducir la latencia en el lado del servidor, como el cambio del disparo de WP-Cron desde el hook init al hook shutdown para evitar añadir hasta 1 segundo de TTFB cuando se lanza el proceso de cron.

En conjunto, este tipo de cambios demuestran que el núcleo de WordPress sigue prestando atención no solo a nuevas funcionalidades visibles, sino también a detalles de rendimiento que, sumados, marcan la diferencia en sitios con mucho tráfico.

Preguntas frecuentes sobre la caché de RSS en WordPress 6.9

¿Cómo sé si mi sitio se veía afectado por el fallo de caché de RSS?
Si usabas WordPress 6.7 u otra versión posterior a la actualización de SimplePie y tenías widgets o bloques de feeds activos, es muy probable que cada carga de página volviera a consultar el feed remoto. Un indicio claro son tiempos de respuesta elevados en páginas con feeds frente a otras sin ellos.

¿Cuánto tiempo se cachean ahora las fuentes RSS en WordPress 6.9?
Por defecto, el resultado de fetch_feed() se almacena en un transient durante unas 12 horas. Dentro de ese intervalo, las siguientes llamadas reutilizan los datos ya almacenados en lugar de volver a descargar el feed.

¿Se puede cambiar la duración de la caché de RSS en WordPress?
Sí. Los desarrolladores pueden modificar el tiempo de vida de la caché usando filtros específicos del sistema de feeds, ajustándolo a las necesidades del proyecto (por ejemplo, reduciéndolo para noticias muy dinámicas o ampliándolo para contenidos más estáticos).

¿Esta mejora de rendimiento afecta a todos los sitios WordPress por igual?
No. Solo tendrá un impacto significativo en sitios que consumen RSS externos mediante el widget de feeds, bloques similares o llamadas a fetch_feed(). En instalaciones que no utilizan fuentes RSS, la mejora será irrelevante, aunque sigue siendo recomendable actualizar a WordPress 6.9 por el conjunto de correcciones y optimizaciones que incluye.