Contents
Introducción
Este tutorial explica en detalle cómo usar rel=preload para scripts críticos en un sitio WordPress desde PHP. Aprenderás por qué y cuándo usar preload, cómo integrarlo correctamente con el sistema de colas de scripts de WordPress (wp_enqueue_script), cómo manejar integridad y crossorigin, y distintos enfoques —desde el más simple al más robusto— con ejemplos prácticos listos para copiar.
Por qué usar rel=preload para scripts
- Reducción de la latencia de ejecución: rel=preload permite al navegador iniciar la descarga de un recurso crítico (por ejemplo, un script que necesita estar listo al mostrar la página) tan pronto como se parsea el head, aunque el ltscriptgt que lo ejecuta esté más abajo o en el footer.
- Mejoras medibles: en páginas donde un script bloqueante en el primer render es crucial, preload puede mejorar métricas como First Contentful Paint (FCP) o Largest Contentful Paint (LCP) al eliminar el tiempo de descarga adicional.
- Control fino: puedes decidir exactamente qué archivos merecen la prioridad de descarga temprana, evitando malgastar ancho de banda en recursos no críticos.
Conceptos clave y comportamientos importantes
- Preload no ejecuta: un ltlink rel=preload as=script href=…> sólo inicia la descarga anticipada. La ejecución se produce cuando el navegador encuentra el ltscript src=…> correspondiente.
- Coincidencia de URL: la URL del preload debe coincidir exactamente con la URL del script que finalmente se carga (incluyendo query string de versión) para que el navegador reutilice el recurso ya descargado.
- Crossorigin e integridad: si usas Subresource Integrity (SRI) o el archivo se sirve desde otro origen que exige CORS, debes añadir el atributo crossorigin apropiado al link de preload.
- No abuse: preloading indiscriminado puede empeorar la experiencia al saturar la conexión. Preload solo recursos realmente críticos.
- Compatibilidad: navegadores antiguos ignoran rel=preload sin romper nada. Para módulos JS hay rel=modulepreload.
Enfoque mínimo: añadir manualmente un link rel=preload en head
Este es el método más directo. Encola tu script con wp_enqueue_script y, en el head, imprime un tag ltlink rel=preload …gt apuntando a la misma URL.
Ejemplo básico
registered[ handle ] ) ) {
src = wp_scripts->registered[ handle ]->src
// Normalizar a URL absoluta si fuera relativa o protocol-relative
if ( strpos( src, // ) === 0 ) {
src = ( is_ssl() ? https: : http: ) . src
} elseif ( parse_url( src, PHP_URL_SCHEME ) === null ) {
src = site_url( src )
}
// Añadir la query de versión para asegurar coincidencia
ver = wp_scripts->registered[ handle ]->ver
if ( ver ) {
src = add_query_arg( ver, ver, src )
}
echo n
}
}
?>
Enfoque robusto: marcar scripts como preload usando wp_scripts()->add_data
En proyectos mayores es conveniente marcar scripts concretos como críticos, y luego generar automáticamente los link rel=preload para todos los marcados. Esto separa la lógica de encolado de la lógica de preloading y evita duplicaciones.
Pasos
- Encola los scripts como siempre.
- Marca con wp_scripts()->add_data(handle, preload, true) los que quieras preloading.
- En el head imprime los links para todos los scripts marcados.
Ejemplo completo
add_data(critico, preload, true)
// Si usas SRI o crossorigin, puedes añadir también esos datos:
// wp_scripts()->add_data(critico, integrity, sha384-AAA...)
// wp_scripts()->add_data(critico, crossorigin, anonymous)
}
add_action(wp_head, output_preload_links, 1)
function output_preload_links() {
if (is_admin()) {
return
}
wp_scripts = wp_scripts()
foreach (wp_scripts->registered as handle => script) {
should_preload = wp_scripts->get_data(handle, preload)
if ( ! should_preload ) {
continue
}
src = script->src
if ( strpos( src, // ) === 0 ) {
src = ( is_ssl() ? https: : http: ) . src
} elseif ( parse_url( src, PHP_URL_SCHEME ) === null ) {
src = site_url( src )
}
ver = script->ver ? add_query_arg( ver, script->ver, src ) : src
integrity = wp_scripts->get_data(handle, integrity)
cross = wp_scripts->get_data(handle, crossorigin)
attrs =
if ( integrity ) {
// Aunque integrity no es obligatorio en el de preload,
// si usas SRI, asegúrate de que el navegador pueda validar.
attrs .= integrity={integrity}
}
if ( cross ) {
attrs .= crossorigin={cross}
}
echo n
}
}
?>
Preload vía encabezado HTTP Link
Otra técnica es enviar un encabezado HTTP Link: es útil en sitios muy optimizados donde controlas la capa de salida de headers y quieres evitar imprimir markup extra. Si tu entrega pasa por cachés/CDNs, debes asegurarte de que éstos preserven y reenvíen el header.
Ejemplo de envío de header
rel=preload as=script, false) } ?>
Casos especiales: módulos ES (type=module)
Si tu script es un módulo ES (JS moderno con type=module), usa rel=modulepreload para aprovechar la precarga específica de módulos. El navegador gestionará mejor las dependencias entre módulos.
add_data(app-module, preload-module, true)
add_action(wp_head, function() {
handle = app-module
script = wp_scripts()->registered[handle] ?? null
if ( script wp_scripts()->get_data(handle, preload-module) ) {
src = script->src
if ( strpos( src, // ) === 0 ) {
src = ( is_ssl() ? https: : http: ) . src
} elseif ( parse_url( src, PHP_URL_SCHEME ) === null ) {
src = site_url( src )
}
src = add_query_arg(ver, script->ver, src)
echo n
}
}, 1)
?>
Consideraciones prácticas y errores comunes
- Coincidencia exacta de URL: si el script final se carga con ?ver=1.0.0 pero el link preload apunta sin query string, el navegador puede considerar recursos distintos y volver a descargar. Asegura añadir la versión o la URL exacta.
- Crossorigin y SRI: si utilizas SRI en el script, añade el mismo atributo integrity y crossorigin en el link de preload para evitar rechazos de CORS/SRI.
- Preload no sustituye ejecución anticipada: si necesitas que el código se ejecute cuanto antes, además del preload tendrás que colocar el script sin defer/async en el head (lo cual puede bloquear el render). Preload es ideal cuando quieres bajar la latencia de descarga pero mantener ejecución donde habitualmente sucede (footer o después del HTML crítico).
- CDNs y cachés: cuando uses headers Link, verifica que CDN y proxies no eliminen dichos headers. Muchas veces es más seguro imprimir el tag link en el head.
- Evita demasiados preloads: no conviertas rel=preload en la norma para todo. Preload demasiados recursos consume conexiones y puede empeorar el rendimiento.
Cómo probar y verificar
- Abre DevTools → Network y filtra por Preload o revisa la columna Initiator para confirmar que el recurso fue iniciado por un ltlink rel=preloadgt.
- Usa Lighthouse (Chrome) antes y después para medir LCP/FCP y verificar si el cambio beneficia realmente tu página.
- Revisa que no haya redescargas duplicadas del mismo archivo (signo de URL no coincidente).
- Usa la pestaña Coverage o Performance para ver si la precarga se reutiliza correctamente al momento de ejecución.
Resumen y recomendaciones
- Usa rel=preload para scripts que afecten directamente el render inicial o la interacción crítica.
- Marca los scripts críticos con wp_scripts()->add_data(handle,preload, true) para mantener un flujo organizado.
- Imprime los link rel=preload en el head (accion wp_head con prioridad alta) y asegúrate que la URL coincide exactamente con la del script final.
- Añade atributos crossorigin e integrity cuando proceda.
- Prueba con herramientas (Lighthouse, DevTools) y no abuses del preload.
Ejemplos rápidos de referencia
- Preload simple en head (ver ejemplo básico arriba).
- Pipeline organizado: encolar → marcar con add_data(preload, true) → imprimir preloads automáticamente (ver ejemplo robusto).
- Headers HTTP Link para casos extremos (ver ejemplo send_headers).
Notas finales
La técnica de rel=preload es potente cuando se usa de forma selectiva y técnica. En WordPress, aprovechar la API de encolado y los datos adicionales de wp_scripts() permite integrar preload de forma limpia y mantenible. Recuerda siempre medir y comparar antes y después para asegurarte de que el cambio tiene un impacto positivo real en la experiencia de usuario.
|
|
Acepto donaciones de BAT's mediante el navegador Brave 🙂 |