Preload, prefetch y preconnect: cuándo ayuda realmente cada uno
Las pistas de recursos son útiles cuando coinciden con cuellos de botella reales del navegador. Usadas a ciegas, añaden ruido de prioridad y a veces hacen que las páginas sean más lentas.
Tabla de contenido
- Las pistas de recursos no son magia
- Lo que el navegador ya hace bien
- Preload: para recursos de la página actual descubiertos demasiado tarde
- Preload e imágenes LCP
- Prefetch: para la siguiente página, no para esta
- Preconnect: para conexiones costosas a orígenes importantes
- DNS-prefetch: el primo más ligero
- Cómo decidir: un flujo de trabajo práctico
- 1. Identifica el cuello de botella
- 2. Añade una pista cada vez
- 3. Comprueba los efectos secundarios de prioridad
- 4. Verifica cabeceras y caché
- Errores comunes
- Hacer preload de demasiado
- Usar prefetch para recursos obligatorios
- Hacer preconnect a todos los terceros
- Olvidar las condiciones móviles
- Una tabla de decisión simple
- La regla tranquila
Las pistas de recursos no son magia
preload, prefetch y preconnect suelen tratarse como una lista de comprobación de rendimiento. Añades unas cuantas etiquetas al <head>, vuelves a ejecutar Lighthouse y te quedas más tranquilo. No funcionan así.
Estas pistas son instrucciones para la canalización de carga del navegador. Pueden ayudar cuando sabes algo que el navegador no puede descubrir lo bastante pronto. Pueden perjudicar cuando haces suposiciones, das demasiada prioridad a trabajo no crítico o preparas conexiones que los usuarios nunca necesitan.
La versión breve:
- Usa
preloadpara recursos necesarios en la página actual, pero descubiertos demasiado tarde. - Usa
prefetchpara recursos de navegaciones futuras probables, no para elementos esenciales de la página actual. - Usa
preconnectpara orígenes importantes de terceros cuando el establecimiento de la conexión sea un retraso real.
La pregunta práctica no es “¿qué pista es más rápida?”. Es “¿qué está esperando el navegador, y puede esta pista eliminar esa espera?”.
Lo que el navegador ya hace bien
Los navegadores modernos no son descargadores pasivos de archivos. Analizan HTML, escanean por adelantado en busca de recursos, asignan prioridades, reutilizan conexiones, retrasan trabajo que no es visible y se adaptan a las condiciones de red.
Eso significa que las pistas de recursos deben usarse de forma selectiva. Si una hoja de estilos, script, imagen o fuente ya se descubre pronto y recibe la prioridad adecuada, añadir una pista puede no hacer nada. Peor aún, puede competir con recursos que importan más.
Antes de añadir pistas, mira una traza de cascada en DevTools o un informe de laboratorio. Si usas Lighthouse, empieza por los diagnósticos en lugar de la puntuación; tenemos una guía aparte sobre cómo leer un informe de Lighthouse sin entrar en pánico, pero ten en cuenta que la URL correcta distingue entre mayúsculas y minúsculas, así que usa el artículo enlazado desde la navegación de tu sitio si hace falta.
La evidencia real suele verse en tres lugares:
- Un recurso crítico empieza tarde porque el navegador lo descubre tarde.
- Una conexión a un origen importante tarda un tiempo apreciable antes de la primera solicitud.
- Un recurso de la siguiente página es muy predecible y barato de obtener en tiempo inactivo.
Si ninguna de esas cosas es cierta, probablemente la pista sea decoración.
Preload: para recursos de la página actual descubiertos demasiado tarde
preload le dice al navegador: “Obtén este recurso ahora porque la página actual lo va a necesitar”.
Un ejemplo típico es una fuente web referenciada dentro del CSS. El navegador debe descargar el HTML, descubrir el CSS, descargar el CSS, analizarlo, descubrir la fuente y luego solicitarla. Si esa fuente es importante para el texto visible en la parte inicial de la página, el descubrimiento puede ser lo bastante tardío como para causar cambios de diseño o retrasar la renderización del texto.
Un preload puede adelantar esa solicitud:
<link rel='preload' href='/fonts/inter-var.woff2' as='font' type='font/woff2' crossorigin>El atributo as importa. Le indica al navegador qué tipo de recurso es, lo que afecta a la prioridad, la caché, la política de seguridad de contenido y las cabeceras de la solicitud. Las fuentes también suelen necesitar crossorigin, incluso cuando se sirven desde el mismo sitio, porque la obtención de fuentes usa modo CORS.
Buenos candidatos para preload incluyen:
- La fuente web principal usada para el texto visible.
- Una imagen hero que es el elemento Largest Contentful Paint y no se puede descubrir pronto.
- Un archivo CSS crítico cargado indirectamente.
- Un módulo o script necesario muy pronto, pero oculto detrás de otro script.
Malos candidatos para preload incluyen:
- Todos los pesos de fuente del sistema de diseño.
- Imágenes por debajo de la parte visible inicial.
- Scripts que no son necesarios para la renderización inicial.
- Recursos que el navegador ya descubre en el primer fragmento de HTML.
Preload es potente porque afecta a la prioridad de la página actual. Por eso mismo también es fácil usarlo mal. Si haces preload de cinco recursos grandes, ya no estás ayudando al navegador. Estás discutiendo con él.
Las fuentes son el caso clásico. Hacer preload de un archivo de fuente principal puede ayudar. Hacer preload de seis pesos y cursivas suele empeorar las cosas. Si las fuentes son tu cuello de botella, arregla primero el conjunto de fuentes; nuestra guía sobre por qué las fuentes web siguen siendo la mejora de rendimiento más fácil en la mayoría de los sitios cubre esa limpieza con más detalle.
Preload e imágenes LCP
Hacer preload de una imagen LCP puede ser útil cuando la imagen no es visible en el HTML inicial. Entre las causas habituales están las imágenes de fondo en CSS, los componentes renderizados en el cliente o la lógica de imágenes responsivas que aparece tarde.
Pero si tu imagen hero ya está en el HTML como un <img> con srcset, sizes, dimensiones sensatas y sin carga diferida, probablemente el navegador pueda encontrarla rápido. En ese caso, añadir fetchpriority='high' puede ser más apropiado que preload, según la página.
Una buena prueba: si la solicitud de la imagen empieza tarde en la cascada y se convierte en el elemento LCP, considera preload. Si empieza pronto pero se descarga despacio, el problema es el tamaño, el formato, el comportamiento del CDN o la latencia del servidor, no el descubrimiento. Para decisiones sobre formatos de imagen, consulta cuándo AVIF supera a WebP y cuándo no.
Prefetch: para la siguiente página, no para esta
prefetch le dice al navegador: “Este recurso puede ser necesario pronto, pero no es obligatorio ahora mismo”.
Esa distinción es importante. Prefetch tiene prioridad baja de forma intencionada. El navegador puede obtenerlo durante tiempo inactivo y guardarlo para usarlo más tarde. También puede omitirlo en conexiones malas, modos de ahorro de datos o bajo presión de memoria.
Usa prefetch cuando la intención del usuario sea lo bastante fuerte como para que el siguiente recurso sea probable.
Buenos candidatos para prefetch incluyen:
- El siguiente paso en un proceso de compra de varias páginas.
- Resultados de búsqueda después de que un usuario empieza a escribir una consulta, si la siguiente ruta es predecible.
- Páginas de documentación enlazadas desde una tabla de contenido cuando el usuario está leyendo activamente contenido cercano.
- Fragmentos de ruta en una aplicación de una sola página después de que un usuario pasa el cursor o enfoca un elemento de navegación.
Malos candidatos para prefetch incluyen:
- Todo tu árbol de navegación.
- Vídeos grandes o galerías de imágenes.
- Scripts de terceros “por si acaso”.
- Páginas que los usuarios rara vez visitan a continuación.
Prefetch es donde la moderación compensa. Un recurso obtenido y nunca usado no es gratis. Consume ancho de banda, capacidad del servidor, energía y posiblemente datos del usuario. En redes móviles, la obtención especulativa puede ser activamente poco amable.
Para muchos sitios, la mejor estrategia de prefetch se basa en la intención. No hagas prefetch de la página de precios en cuanto se carga la página de inicio. Hazlo cuando el usuario abre el menú de precios, pasa el cursor sobre el enlace de precios o se desplaza cerca de una llamada a la acción que predice con fuerza la navegación.
Recuerda también que el comportamiento del navegador varía. Algunos navegadores son conservadores con prefetch; algunos ajustes de privacidad reducen o desactivan la carga especulativa. Trata prefetch como una mejora oportunista, no como un mecanismo de corrección.
Preconnect: para conexiones costosas a orígenes importantes
preconnect le dice al navegador: “Empieza a establecer una conexión con este origen ahora”.
Eso puede incluir la resolución DNS, la conexión TCP y la negociación TLS. Para orígenes de terceros, esta preparación puede tardar cientos de milisegundos, especialmente en redes de alta latencia. Si la página pronto necesita una solicitud crítica desde ese origen, preconnect puede hacer que la solicitud posterior sea más rápida.
Ejemplo:
<link rel='preconnect' href='https://fonts.gstatic.com' crossorigin>Buenos candidatos para preconnect incluyen:
- Un origen de fuentes usado para texto que bloquea la renderización.
- Un origen de API crítico necesario durante la interacción inicial.
- Un origen de CDN que sirve recursos visibles en la parte inicial.
- Un proveedor de pagos o identidad necesario inmediatamente después de una acción del usuario.
Malos candidatos para preconnect incluyen:
- Endpoints de analítica y publicidad que no son críticos para el usuario.
- Orígenes usados solo en algunas sesiones.
- Largas listas de terceros.
- Recursos del mismo origen, donde el navegador ya tiene o pronto abrirá la conexión.
Preconnect tiene un coste de mantenimiento. Los sockets abiertos consumen memoria y recursos de red. Los navegadores cerrarán conexiones no utilizadas, pero eso no hace que los preconnect innecesarios sean inofensivos.
Una regla útil: haz preconnect como máximo a uno o dos orígenes de terceros de alta confianza en una página. Si tienes la tentación de añadir más, probablemente tu arquitectura de terceros necesite una revisión más que tus pistas una ampliación.
DNS-prefetch: el primo más ligero
También puedes ver dns-prefetch:
<link rel='dns-prefetch' href='https://example-cdn.com'>Esto solo resuelve el nombre de dominio. No abre una conexión TCP ni TLS. Es más barato que preconnect, pero también ayuda menos.
DNS-prefetch puede ser razonable para orígenes de terceros de menor confianza cuando un preconnect completo parece demasiado agresivo. En la práctica, si un origen es crítico y se usará pronto con seguridad, prefiere preconnect. Si es solo posible, usa DNS-prefetch o no hagas nada.
Cómo decidir: un flujo de trabajo práctico
Empieza con medición, no con etiquetas.
1. Identifica el cuello de botella
Abre una traza de rendimiento y busca descubrimientos tardíos. ¿La solicitud de la fuente, imagen hero o script empieza solo después de que otro archivo se haya descargado y analizado? Ese es un candidato para preload.
Si una solicitud empieza solo después de una larga preparación DNS/TCP/TLS hacia un origen de terceros, ese es un candidato para preconnect.
Si la página actual está bien pero la siguiente navegación es predeciblemente lenta, prefetch puede ayudar.
2. Añade una pista cada vez
Las pistas de recursos interactúan entre sí. Añade una, pruébala y mantenla solo si la cascada mejora y las métricas orientadas al usuario no empeoran.
Para preload, observa si el recurso indicado se usa realmente pronto. Chrome puede advertir cuando un recurso precargado no se usa poco después de la carga. Tómate esa advertencia en serio.
3. Comprueba los efectos secundarios de prioridad
Un preload puede quitar ancho de banda a CSS, JavaScript o imágenes que importan más. Un preconnect puede ocupar un espacio de conexión. Un prefetch puede añadir tráfico en segundo plano.
El resultado correcto no es “el archivo indicado empieza antes”. El resultado correcto es “la página mejora de forma significativa para los usuarios”. Observa LCP, INP, CLS y, cuando sea posible, monitorización de usuarios reales.
4. Verifica cabeceras y caché
Las pistas pueden enviarse en HTML o en cabeceras HTTP Link. Las cabeceras son útiles cuando el servidor sabe pronto lo que la página necesitará, pero son más difíciles de inspeccionar de forma casual. Si estás depurando si una pista está realmente presente en producción, las cabeceras sin procesar importan; este es exactamente el tipo de situación cubierta en nuestra guía para depurar redirecciones y cabeceras HTTP.
La caché también importa. Hacer preload de un recurso con credenciales no coincidentes, un as incorrecto o parámetros de URL distintos puede causar descargas duplicadas. Esa es una de las formas más comunes en que un preload bien intencionado se convierte en un error de rendimiento.
Errores comunes
Hacer preload de demasiado
Si todo es crítico, nada lo es. Limita preload a recursos necesarios para la renderización inicial o la interactividad inmediata. Una página típica debería tener de cero a tres preloads, no veinte.
Usar prefetch para recursos obligatorios
Prefetch es de baja prioridad y opcional. No lo uses para recursos requeridos por la página actual. Si la página lo necesita ahora, considera preload o el descubrimiento HTML normal.
Hacer preconnect a todos los terceros
Las páginas con muchos terceros suelen tener diez o más orígenes externos. Hacer preconnect a todos crea ruido. Elige el uno o dos que sean críticos y se usen de forma predecible.
Olvidar las condiciones móviles
Las pistas de recursos son más valiosas en conexiones lentas, pero también más peligrosas ahí. Un prefetch desperdiciado en una conexión rápida de escritorio es un error de redondeo. En un plan móvil limitado, es un mal intercambio.
Una tabla de decisión simple
| Situación | Mejor pista | Por qué | |---|---:|---| | Fuente crítica descubierta mediante CSS | preload | La página actual la necesita, el descubrimiento es tardío | | Imagen hero oculta detrás de CSS o renderización en cliente | preload | Puede mejorar LCP si la imagen empieza tarde | | Ruta siguiente probable tras intención del usuario | prefetch | Ayuda a la navegación futura sin bloquear la página actual | | Origen crítico de fuente/API de terceros | preconnect | Elimina la preparación de conexión de la ruta crítica | | Origen de terceros posible pero incierto | dns-prefetch o ninguno | Menor coste, menor confianza | | Imagen por debajo de la parte visible inicial | ninguno | Deja que funcionen la carga diferida y la prioridad del navegador |
La regla tranquila
Las pistas de recursos funcionan mejor cuando son aburridas y específicas. Una fuente. Una imagen LCP. Un origen importante de terceros. Una siguiente ruta probable tras la intención.
Funcionan mal cuando se usan como optimismo: quizá el usuario necesite esto, quizá el navegador debería obtener aquello, quizá más pistas signifiquen más velocidad.
Los navegadores ya optimizan de forma agresiva. Tu trabajo no es microgestionar cada solicitud. Tu trabajo es corregir los pocos casos en los que al navegador le falta información en el momento adecuado.
Preguntas frecuentes
¿Debería hacer preload de todas mis fuentes?
¿Es seguro usar prefetch para todos los enlaces internos?
¿Cuál es la diferencia entre preconnect y dns-prefetch?
¿Pueden las pistas de recursos mejorar Core Web Vitals?
¿Deberían añadirse las pistas de recursos en HTML o en cabeceras HTTP?
Fuentes y lecturas adicionales
