Prefetch de recursos: preload, preconnect y más

¿Qué es el prefetch de recursos?

El prefetch de recursos es una familia de indicaciones (hints) para el navegador, escritas como etiquetas <link rel="..."> o cabeceras Link, que le piden descargar un recurso o abrir una conexión antes de lo que haría por sí solo. Así la página actual carga más rápido o la siguiente navegación parece instantánea. Es una sugerencia: el navegador puede ignorarla.

Las indicaciones de un vistazo

Cómo funciona cada una

preload hace que el navegador descubra y descargue un recurso pronto y lo conserve para reutilizarlo. El atributo as (image, font, script, style, fetch, track) indica el tipo, para que aplique la prioridad y las cabeceras correctas. Los preloads de fuentes y de fetch deben llevar crossorigin, incluso si el archivo es del mismo origen; si no, el navegador lo descarga dos veces.

preconnect paga el coste de la conexión antes de la primera petición. No aporta nada para tu propio origen, que ya está conectado. Los navegadores cierran las conexiones sin usar a los 10 segundos aproximadamente, así que solo conviene para orígenes que vas a usar enseguida. Para fuentes y otras peticiones CORS necesita crossorigin; sin él, el navegador solo hace la resolución DNS.

dns-prefetch es la versión barata: resuelve el nombre de host y no hace más. Una resolución DNS suele tardar decenas de milisegundos, por lo que solo suma cuando la página habla con muchos orígenes.

prefetch descarga un recurso a la caché HTTP con prioridad baja, para una navegación que aún no ha ocurrido. Cache-Control: no-store y no-cache lo bloquean, y la petición lleva la cabecera Sec-Purpose: prefetch, visible para tu servidor. Para documentos completos, MDN recomienda la Speculation Rules API donde esté disponible; consulta carga especulativa y prerenderizado.

fetchpriority es un atributo aparte (high, low, auto) para img, script y link. Sube o baja la prioridad, pero no ayuda a que el navegador encuentre antes el recurso; por eso se combina con preload cuando la imagen se define en CSS.

Ejemplo: imagen principal y fuente

Una landing tiene una imagen principal como fondo CSS y una fuente web. El navegador solo las descubre tras analizar el CSS, lo que retrasa el Largest Contentful Paint. Dos indicaciones en el head resuelven el descubrimiento:

<link rel="preload" href="/hero.webp" as="image" fetchpriority="high">
<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>

Las fuentes y otros archivos de terceros en una CDN se benefician de una conexión temprana:

<link rel="preconnect" href="https://cdn.example.com" crossorigin>
<link rel="dns-prefetch" href="https://cdn.example.com">

Para una página siguiente probable, un prefetch de prioridad baja o una regla de especulación calienta la caché:

<link rel="prefetch" href="/pricing">

<script type="speculationrules">
{
  "prefetch": [{ "urls": ["/pricing", "/signup"] }]
}
</script>

Speculation Rules sigue siendo experimental y no está en todos los navegadores: úsala como mejora y comprueba la compatibilidad antes de depender de ella.

Errores frecuentes

• Precargar demasiado. Los preloads compiten entre sí y con lo que el navegador habría descargado de todos modos. Limítalos a uno o dos que condicionen el LCP.
• Olvidar crossorigin. Sin él, el preload de una fuente no se reutiliza y el archivo se descarga dos veces.
• Valor de as incorrecto. El preload no se asocia entonces con la petición posterior.
• Preconectar con todos los terceros. Cada conexión cuesta ancho de banda y CPU por el TLS, y las inactivas se cierran a los 10 segundos aproximadamente. Usa dns-prefetch para el resto.
• Hacer prefetch de páginas que nadie visita. Gasta datos del visitante sin beneficio, sobre todo en móvil. Basa la lista en recorridos reales.
• Hacer prefetch de URL con efectos secundarios. Una URL de cierre de sesión o de añadir al carrito sigue llegando a tu servidor.

Relación con las pruebas y la monitorización de rendimiento

Las indicaciones cambian lo que hace el navegador, así que mide antes y después en lugar de fiarte de la teoría. Compara la cascada de carga y el LCP con cada hint y sin él. El verificador gratuito de Core Web Vitals muestra si los usuarios reales ya superan LCP, INP y CLS, y la monitorización de velocidad de página de LoadFocus ejecuta auditorías Lighthouse programadas desde 25 regiones en la nube para comprobar si un cambio ayudó en todas partes o solo cerca de tu servidor. Para el resto de mejoras de frontend, consulta la guía de 10 pasos para mejorar la velocidad de tu web. Relacionado: conexiones de red y velocidad de página y precarga de recursos.

Preguntas frecuentes: prefetch de recursos

¿Cuál es la diferencia entre preload y prefetch?

Preload es para algo que la página actual necesitará pronto y se descarga con prioridad alta. Prefetch es para algo que una navegación posterior podría necesitar y se descarga con prioridad baja.

¿Debo precargar la imagen principal?

Si es el elemento LCP y el navegador la encontraría tarde, por ejemplo por ser un fondo CSS, sí. Combínala con fetchpriority="high" y comprueba en una cascada que el LCP mejora.

¿Cuántos preconnect son demasiados?

No hay un número fijo. MDN y web.dev aconsejan preconectar solo con los orígenes más críticos, porque cada conexión tiene un coste y las que no se usan se cierran a los 10 segundos aproximadamente. Usa dns-prefetch para el resto.

¿Qué diferencia hay entre preconnect y dns-prefetch?

dns-prefetch solo resuelve el nombre de host. Preconnect además abre la conexión TCP y, en HTTPS, completa el handshake TLS.

¿Prefetch es lo mismo que prerender?

No. Prefetch descarga un recurso sin ejecutarlo. Prerender carga y renderiza una página completa de forma oculta, lo que cuesta mucho más, así que resérvalo para navegaciones muy probables.

¿El prefetch gasta datos móviles?

Puede, si el usuario nunca visita la página precargada. Haz prefetch solo de los siguientes pasos muy probables y evita la carga especulativa para usuarios que han pedido ahorrar datos.