Prefetching WordPress: qué cambia en el core y en el admin

En pocas palabras: El core de WordPress incorporó el prefetching en el changeset 64120, anunciado por Weston Ruter el 6 de octubre de 2026. El próximo paso, en el PR #13090, es desactivar por defecto la concatenación de scripts y estilos; después se planea eliminar load-scripts.php y load-styles.php.

El prefetching de WordPress ya está en el core: el equipo de Performance confirmó el 6 de octubre de 2026 que el changeset 64120 lo incorporó. El siguiente paso es apagar por defecto la concatenación de scripts y estilos para, más adelante, eliminar load-scripts.php y load-styles.php, según el resumen de la reunión de Performance.

El prefetching de WordPress es un mecanismo del core que imprime etiquetas <link rel="prefetch"> para que el navegador descargue, con la prioridad más baja, los scripts y estilos de la próxima pantalla del administrador mientras el usuario todavía está en la actual. Sirve para compensar el costo de no concatenar archivos y lo desarrolla el equipo de Performance de WordPress.

¿Qué son load-scripts.php y load-styles.php y para qué sirve la concatenación?

load-scripts.php y load-styles.php son los archivos del core que juntan varios scripts y hojas de estilo del administrador en una sola respuesta y la comprimen, para que el navegador haga menos pedidos. Esa técnica se llama concatenación, y durante años fue la «optimización» por defecto del wp-admin (con un historial de problemas que el propio equipo califica de «muchos años»).

Según la documentación de script_concat_settings(), la función existe desde WordPress 2.8.0 y lee tres constantes: CONCATENATE_SCRIPTS, COMPRESS_SCRIPTS y COMPRESS_CSS. Si CONCATENATE_SCRIPTS no está definida, asume true, salvo fuera del admin y del login, o con SCRIPT_DEBUG activo, donde queda en false.

Ojo con un detalle: el PR #13090 aclara que el cambio solo afecta wp-admin y la pantalla de login. El front no se toca. Además, en el merge de trunk que figura en ese PR, el default se movió a wp_should_concatenate_admin_scripts(), así que la documentación de arriba va a quedar desactualizada cuando el cambio aterrice.

¿Qué es el prefetching WordPress que se sumó al core y cómo funciona?

El prefetching funciona en dos lugares. En la pantalla de login, el core imprime etiquetas rel="prefetch" para los handles que load-scripts.php y load-styles.php agruparían, así el navegador los guarda en la caché HTTP mientras el formulario está a la vista y no después de la redirección. En el Dashboard y en los listados de entradas, precarga los estilos del editor de bloques.

Ponele que abrís wp-login.php desde el celular y tardás diez segundos en escribir la contraseña (ejemplo hipotético). Ese tiempo el navegador está ocioso. Eso es lo que aprovecha el cambio.

Según el PR #13084, el trabajo arrancó con rel="preload" y pasó a prefetch durante la revisión por tres razones: preload baja a la prioridad del documento actual, hace que la reutilización dependa de las cabeceras de caché de los archivos estáticos (que el core no controla) y genera advertencias del navegador por recursos que la página nunca usa. Después sacaron fetchpriority="low", porque, en palabras del mensaje de commit (traducción nuestra), «un prefetch ya se despacha con la prioridad más baja del navegador».

Sobre el editor, el PR mide que caer ahí desde el Dashboard trae 47 archivos que el Dashboard no tenía. Por eso el core prefetchea 18 hojas de estilo desde el Dashboard o un listado de entradas, y solo estilos: los scripts del editor pesan unos 1,26 MB comprimidos contra 98 KB de las hojas de estilo, demasiado para gastarlos a ciegas. Más contexto en seguir las novedades de WordPress Core.

Dos advertencias. El resumen de la reunión cita el changeset 64120 pero no nombra el PR; al 7 de octubre de 2026 el #13084 aparece cerrado y describe este trabajo, pero tomalo como el mejor indicio y no como confirmación. Y los nombres de funciones y filtros (wp_prefetch_admin_assets(), prefetch_admin_assets) salen de la conversación del PR, que cambió varias veces de nombre. Verificalos en trunk antes de depender de ellos desde un plugin.

¿Cuándo no se aplica el prefetching en WordPress?

El prefetching se omite cuando la próxima pantalla no es el admin o cuando el navegador ya tiene los archivos. La lista sale de los commits del PR #13084:

• Flujos de login que no llevan al admin. Recuperación de contraseña, registro, confirmación de cierre de sesión y «revisá tu correo» no prefetchean nada.
• Login interino. Reautentica en un modal sobre una página que ya tiene los assets.
• Redirecciones fuera del admin. Si redirect_to apunta a otro lado dentro del sitio, no hay prefetch. Si apunta a otro host, sí lo hay, porque wp_safe_redirect() cae al admin.
• Editor de bloques sin permisos o sin uso. Se saltan los estilos del editor para quien no puede crear el tipo de contenido y para tipos que usan el editor clásico.
• Concatenación activa (inferencia nuestra). El PR habla de assets «sin concatenar», así que con concatenación activa no hay archivos sueltos que precargar.

¿Por qué WordPress quiere desactivar la concatenación por defecto?

Porque el equipo considera que la lógica de concatenación y compresión dio problemas durante años y porque, con el prefetching, el costo de no concatenar baja. El PR #13090, de haqadn, cambia el fallback de script_concat_settings(): una CONCATENATE_SCRIPTS sin definir pasa a resolverse como false y load-scripts.php y load-styles.php se vuelven opt-in. Quien quiera el comportamiento anterior define la constante en true.

Lo que no queda claro: cuáles son los bugs concretos. Las fuentes que pude leer dicen «problemática» y nada más, y el ticket histórico #57548 es el que referencia el PR, pero no pude leerlo y no voy a inventarle contenido.

Otra cosa que no cierra del todo: el resumen habla de apagar la concatenación «fuera de entornos de desarrollo», mientras que el PR cambia el valor cuando la constante no está definida (con SCRIPT_DEBUG ya se apaga hoy). Son formulaciones distintas del mismo plan, y habría que ver cómo queda el texto final. Al 7 de octubre de 2026, el PR #13090 no muestra merge.

¿Cuánto mejora el rendimiento del admin con el prefetching?

Las fuentes no traen una cifra de mejora medida para el prefetching terminado, solo el costo que viene a compensar. Según el autor del PR #13084, medido en Fast 4G con caché frío, cargar el primer admin sin concatenar cuesta unos 600 ms de First Contentful Paint frente a la versión concatenada, por 28 pedidos extra que HTTP/1.1 serializa detrás de su tope de seis conexiones. Tema relacionado: cómo actualizar WordPress sin sorpresas.

Es una medición del propio autor, no un benchmark independiente. Y está hecha sobre HTTP/1.1: si tu servidor sirve HTTP/2 o HTTP/3, el costo podría ser menor, pero ninguna fuente lo mide.

De yapa, en la misma reunión Weston Ruter contó que PHPStan 2.3.0 bajó el análisis completo sin caché del core de 60 a 8 segundos. No tiene que ver con el admin, pero le ahorra tiempo a quien contribuye.

¿Cómo mantengo o desactivo la concatenación de scripts en WordPress?

Con la constante CONCATENATE_SCRIPTS en wp-config.php. Definirla en false desactiva la concatenación hoy; en true la conserva aunque el default cambie. Ponela antes de la línea que dice «That’s all, stop editing».

// Desactivar concatenación (load-scripts.php y load-styles.php)
define( 'CONCATENATE_SCRIPTS', false );

// Mantener el comportamiento anterior si el default cambia
// define( 'CONCATENATE_SCRIPTS', true );

Si querés decidir con datos y no por intuición, esta es una propuesta editorial (no la probamos): en Chrome DevTools, con red en Fast 4G y la caché deshabilitada, logueate y compará cantidad de pedidos y FCP de la primera pantalla del admin con la constante en true y en false, tres veces cada una. Después mirá en la pestaña Network de wp-login.php si aparecen pedidos de tipo prefetch. Ojo con SCRIPT_DEBUG: si está activo, la concatenación ya está apagada y la comparación no te dice nada.

Hacé las pruebas en un entorno de staging antes de tocar producción.

¿El prefetching del core es lo mismo que la carga especulativa de WordPress 6.8?

No. La carga especulativa de WordPress 6.8, explicada en el post oficial, trabaja sobre el front-end con Speculation Rules. El prefetching de este changeset precarga assets del administrador con etiquetas link. Comparten idea (adelantarse a la próxima navegación) y nada más.

Aspecto	Carga especulativa (6.8)	Prefetching del changeset 64120
Dónde actúa	Front-end del sitio	Login, Dashboard y listados del wp-admin
Qué adelanta	Navegaciones entre páginas	Scripts y estilos del admin y estilos del editor
Mecanismo	Speculation Rules	rel="prefetch"

¿Qué está confirmado y qué falta para eliminar load-scripts.php y load-styles.php?

Confirmado hay una sola cosa: el prefetching está commiteado. Lo demás son pasos planeados, con distinto grado de avance. Esto se conecta con lo que analizamos en probar estos cambios en un staging.

Paso	Estado según las fuentes
Prefetching en el core	Commiteado (changeset 64120)
Concatenación apagada por defecto	PR #13090, sin merge visible en las fuentes al 7 de octubre de 2026
Eliminar load-scripts.php, load-styles.php y su lógica de concatenación y compresión	Plan a futuro, sin fecha ni versión
Próxima reunión de Performance	Martes 20 de octubre de 2026, 16:00 UTC, #core-performance

Lo que no podés concluir de esto: que el cambio llegue en la próxima versión de WordPress. Ninguna fuente lo dice.

Errores comunes

• Medir con SCRIPT_DEBUG activo. Los propios tests del PR #13090 pasaban desde src/ justamente porque SCRIPT_DEBUG apaga la concatenación. Corrección: comprobá que esté en false antes de comparar.
• Medir con caché caliente. El costo de los 28 pedidos aparece con caché frío. Corrección: desactivá la caché en DevTools.
• Esperar mejoras en el front. Este prefetching es del admin; para el sitio público existe la carga especulativa de 6.8. Corrección: no los mezcles al evaluar resultados.
• Dejar reglas de servidor atadas a los archivos. Si tenés reglas de caché o de firewall que mencionan load-scripts.php o load-styles.php, vale la pena revisarlas antes de que desaparezcan (recomendación nuestra, no de las fuentes).

Preguntas Frecuentes

¿Qué es el prefetching en WordPress y cómo funciona?

Es un mecanismo del core que imprime etiquetas rel="prefetch" para que el navegador descargue los assets de la próxima pantalla del admin con la prioridad más baja. Ocurre en el login, en el Dashboard y en los listados de entradas.

¿Para qué sirve load-scripts.php en WordPress?

Sirve para entregar varios scripts del admin concatenados y comprimidos en una sola respuesta. Su par, load-styles.php, hace lo mismo con las hojas de estilo.

¿Cómo desactivo la concatenación de scripts en WordPress con CONCATENATE_SCRIPTS?

Agregá define( 'CONCATENATE_SCRIPTS', false ); en wp-config.php. Con SCRIPT_DEBUG en true la concatenación también queda apagada.

¿WordPress va a eliminar load-scripts.php y load-styles.php?

Es el plan que el equipo de Performance describió el 6 de octubre de 2026, después de apagar la concatenación por defecto. No hay fecha ni versión de WordPress confirmadas.

¿El prefetching del core es lo mismo que la carga especulativa de WordPress 6.8?

No: la carga especulativa de 6.8 actúa sobre el front-end con Speculation Rules, y este prefetching precarga assets del wp-admin.

Conclusión

El prefetching de WordPress ya está en el core y prepara el terreno para apagar la concatenación por defecto y, más adelante, retirar load-scripts.php y load-styles.php. Mi lectura: es una jugada razonable (se saca código viejo y se compensa el costo con precarga), pero la compensación todavía no tiene una medición publicada en lo que leí.

Qué hacer: no hay nada urgente. Si administrás sitios, definí CONCATENATE_SCRIPTS de forma explícita para que ningún cambio de default te sorprenda, probá en staging con el criterio de arriba y seguí el PR #13090 y la reunión del 20 de octubre de 2026.

Fuentes

• Make WordPress Core – Resumen de la reunión de Performance del 6 de octubre de 2026
• GitHub – PR #13084, prefetch de assets para la próxima pantalla del admin
• GitHub – PR #13090, concatenación de scripts y estilos desactivada por defecto
• Developer WordPress – Referencia de script_concat_settings()
• Make WordPress Core – Speculative Loading in 6.8