Resource hints: preload, preconnect, prefetch y fetchpriority
Tabla de contenidos
Tu web no siempre es lenta: muchas veces el navegador descubre el recurso importante demasiado tarde. Los resource hints son directivas que le dicen qué conectar o descargar antes de que lo necesite, y se declaran en una sola línea de HTML.
No son un factor de ranking: son una palanca sobre las métricas de carga que Google sí usa, y mal usados empeoran la carga. Aquí verás cuál usar, cuándo evitarlos y cómo verificar.
Qué son los resource hints y por qué afectan a la carga
Según web.dev, los resource hints indican al navegador que realice ciertas acciones por adelantado para mejorar la velocidad de carga: adelantan la resolución de un dominio, la apertura de una conexión o la descarga de un recurso. Se declaran en el <head> o en una cabecera HTTP.
| Hint | Qué adelanta | Coste |
|---|---|---|
dns-prefetch | Solo la resolución DNS | Mínimo |
preconnect | DNS + TCP + TLS | Bajo, pero real |
preload | La descarga del recurso | Ancho de banda |
prefetch | Una navegación futura | Se desperdicia si no se navega |
fetchpriority | Nada: cambia la prioridad | Ninguno por sí solo |
El problema que resuelven: el preload scanner solo ve el HTML inicial. Lo que se descubre por CSS (un @import, un background-image), por JavaScript o por otro origen se pide tarde, y cuanto más tarde llega el recurso crítico, peor acaba el LCP.
El encuadre honesto es el de Google Search Central: los Core Web Vitals se usan en sus sistemas de ranking, pero no existe una única señal de page experience y las métricas no garantizan posiciones.
preconnect: adelanta la conexión con el origen
preconnect negocia DNS, TCP y TLS con otro origen antes de que el parser lo pida. Es el más caro de los hints baratos porque abrir una conexión consume recursos: resérvalo para los dos a cuatro orígenes críticos, como la CDN de imágenes o las fuentes.
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>El error del crossorigin
Son dos dominios: el CSS sale de fonts.googleapis.com y los archivos de fonts.gstatic.com. Las fuentes viajan por CORS, así que sin crossorigin el navegador abre otra conexión al descargarlas y pagas el coste sin beneficio. En Lighthouse 13, la auditoría de preconnect vive en el insight Network dependency tree.
dns-prefetch: el hint más barato (y el más olvidado)
dns-prefetch solo resuelve el dominio a una IP y no abre conexión: encaja donde preconnect no escala, en los orígenes secundarios.
<link rel="dns-prefetch" href="https://cdn.ejemplo.com">Caso subestimado: inyectar el hint cuando un enlace saliente entra en el viewport. Regla: preconnect para los orígenes críticos y dns-prefetch para el resto de terceros relevantes.
preload: lo crítico que el navegador descubre tarde
El caso de uso es estrecho a propósito: fuentes, CSS traído por @import, un background-image que puede ser la imagen LCP o un recurso que carga JavaScript. No se usa para lo que el preload scanner ya ve. Convive con el lazy loading: primero lo crítico, después lo que no se ve.
as obligatorio y crossorigin para fuentes
as declara el tipo de recurso (style, image, font, fetch) y no es opcional: sin él el recurso se descarga dos veces. Las fuentes necesitan crossorigin siempre, aunque el archivo esté en tu dominio.
<link rel="preload" href="/fuentes/inter.woff2" as="font" type="font/woff2" crossorigin>Imagen LCP y preload responsive
Para la imagen de la primera pantalla, la guía de optimización de LCP recomienda este patrón:
<link rel="preload" fetchpriority="high" as="image" href="/hero.webp" type="image/webp">Si la imagen es responsive, añade imagesrcset e imagesizes y excluye src. Ojo con el exceso: los preload se descargan en alta prioridad y abusar de ellos crea contención; preloadeando todo, el LCP sube, no baja.
fetchpriority: la palanca más rentable sobre la imagen LCP
La Fetch Priority API se expone como fetchpriority con valores high, low y auto, y funciona en <link>, <img> y <script>.
Las imágenes se piden con prioridad baja y solo tras el layout, si están en el viewport inicial, el navegador la sube a alta: high te salta esa espera. La carga ocurre en dos fases y la primera se cierra cuando terminan los scripts bloqueantes, así que high mete el recurso en la primera fase.
<img src="/hero.webp" width="1200" height="675" alt="Descripción de la imagen principal" fetchpriority="high">El uso honesto es simétrico: high en la imagen que crees que será el LCP y low en las que quedan fuera de pantalla, como las miniaturas de un carrusel. Subir la prioridad de muchos recursos crea contención, y ninguna fuente oficial publica un porcentaje fijo de mejora.
prefetch y Speculation Rules: adelantar la siguiente navegación
<link rel="prefetch"> lanza una petición de baja prioridad para un recurso de una navegación futura. Es especulativo: si el usuario no navega, el ancho de banda se desperdicia. Mídelo con datos reales y respeta Save-Data.
La Speculation Rules API usa reglas JSON en <script type="speculationrules"> o en la cabecera Speculation-Rules. Apunta a URLs de documento, sirve en sitios multipágina y sustituye al obsoleto rel="prerender". Su prefetch baja solo el HTML destino; el prerender lo renderiza en una pestaña invisible, con un coste similar al de un iframe.
eagerness: cuándo especular
immediate actúa al observar las reglas, moderate espera 200 ms de hover o un pointerdown en móvil y conservative espera al clic. Por defecto, las list rules son immediate y las document rules conservative. Chrome limita a 50 prefetch y 10 prerender con immediate o eager, y a 2 y 2 con cola FIFO en el resto.
Novedad 2026: prerender_until_script
Chrome publicó en enero de 2026 un punto medio: prerender_until_script, en origin trial desde Chrome 144. Descarga el HTML y renderiza con subrecursos, pero no ejecuta scripts: al topar con uno bloqueante pausa el parser y espera la navegación. Se usa con fallback a prefetch. El API no es Baseline, así que detéctalo con HTMLScriptElement.supports("speculationrules"); el servidor ve una prerender por Sec-Purpose e inicializa la analítica al activar, no al renderizar.
Cuándo NO usar resource hints
Las URLs con efectos secundarios nunca se prefetchean ni se prerenderizan: logout, cambio de idioma, carrito, logins con código por SMS y URLs que consumen cupo, como los artículos gratis del mes. El caso extremo son las que disparan conversiones de anuncios en el servidor: una especulación puede registrar una conversión que nunca ocurrió. Mitigación: leer Sec-Purpose en el servidor y aplazar lo que no debe ejecutarse.
Chrome cachea las páginas prefetcheadas unos cinco minutos, y los Disallow del robots.txt sirven como lista de URLs sospechosas de efectos secundarios. Si el efecto ocurre solo en JavaScript, el prefetch es seguro porque el script no corre hasta la activación. Los otros errores son de exceso: demasiados preload en alta prioridad generan contención, y especular sin datos de uso gasta ancho de banda y CPU.
Cómo verificar que funcionan
En DevTools, la pestaña Network con su columna Priority muestra si el hint aparece antes del recurso y si la fuente se descarga dos veces, la señal habitual de un as o un crossorigin mal puestos.
El informe Core Web Vitals de Search Console, con los umbrales de LCP bajo 2,5 s, INP bajo 200 ms y CLS bajo 0,1, confirma si la mejora se ve en usuarios reales. El método: medir, aplicar un hint, medir de nuevo.
Checklist: los resource hints que valen la pena hoy
preconnect, concrossoriginsi son fuentes, a los orígenes críticos; el resto,dns-prefetch.preloadsolo de lo crítico tardío: fuente principal, CSS por@importo imagen LCP por CSS/JS.assiempre en el preload ycrossoriginen fuentes; comprueba que no hay doble descarga.fetchpriority="high"en la imagen LCP (conimagesrcseteimagesizessi es responsive) ylowen las de fuera de pantalla.- Navegación multipágina predecible:
prefetchy, si el sitio es liviano, Speculation Rules coneagerness: moderate. - Excluir de toda especulación el logout, el idioma, el carrito y las URLs que consumen cupo.
- Medir en Core Web Vitals después del cambio, de a un hint por vez.
Los resource hints son la optimización más barata de un plan de SEO técnico: unas líneas de HTML y ninguna dependencia nueva. La diferencia entre que ayuden o estorben es una sola: aplicarlos sobre lo crítico y medir.