fetchpriority: qué hace y cómo usarlo para el LCP

La imagen que más pesa en tu LCP suele pedirse con prioridad baja. Los navegadores empiezan por tratar casi todas las imágenes como poco urgentes y solo suben la prioridad de las que están en pantalla cuando ya han calculado el diseño. Ese retraso es el que corrige fetchpriority, y por eso aparece en casi todas las auditorías de Lighthouse que miran el LCP.

Aquí explico qué hace el atributo y en qué elementos funciona, con la lista de lo que no está documentado, cómo se combina con preload y con loading="lazy", los errores que anulan su efecto y una prueba propia en Chrome con prioridades medidas, además de lo que hay en cristofercruz.net.

Qué es fetchpriority y qué no es

MDN define el atributo como una señal para indicar que descargar un recurso pronto tiene más o menos impacto en la experiencia del usuario que lo que el navegador puede deducir por sí mismo. Con ello el navegador puede subir o bajar la prioridad y cargarlo antes o después. Los valores son tres:

• high: pide el recurso con prioridad alta en relación con otros recursos.
• low: lo pide con prioridad baja en relación con otros.
• auto: no expresa preferencia. Es el valor por defecto y también el que se usa si el valor escrito no es válido.

Hay dos matices que cambian cómo se usa. El primero es que la prioridad es relativa: high no coloca un recurso en la cima de todo, lo coloca por encima de recursos parecidos. web.dev lo resume con que el atributo establece una prioridad relativa y por eso a menudo, pero no siempre, acaba en High o Low en DevTools. El segundo es que es una pista. La guía de web.dev dice textualmente que es «a hint, not a directive», y MDN añade que tanto la prioridad interna de cada petición como el efecto del atributo dependen del navegador.

En qué elementos funciona

La página de MDN sobre el atributo HTML lista tres elementos: img, link y script, más su equivalente en SVG. Para fetch() existe la opción priority en el objeto de opciones. web.dev ofrece ejemplos de las cuatro formas:

<img src="lcp.webp" fetchpriority="high" alt="…">
<link rel="preload" href="/js/app.js" as="script" fetchpriority="low">
<script src="importante.js" async fetchpriority="high"></script>
fetch('https://example.com/', { priority: 'low' });

El soporte lo recoge web.dev como Chrome 102, Edge 102, Firefox 132 y Safari 17.2, y MDN lo etiqueta como Baseline 2024: desde octubre de 2024 funciona en los navegadores actuales. En los antiguos no hace nada y tampoco rompe nada, así que se puede añadir sin condiciones.

El caso del iframe merece una frase aparte, porque hay artículos que lo incluyen. En mi prueba, un iframe con fetchpriority="low" y otro con high se pidieron igual que uno sin atributo, como documento VeryHigh. Mi lectura es que no hay nada que ajustar ahí; para diferir iframes lo que cuenta es loading="lazy", que trato en el artículo sobre lazy loading en iframes. Tampoco he probado la cabecera HTTP Link con este atributo, aunque MDN la menciona, así que no la recomiendo sin verla funcionar en tu servidor.

Qué prioridad tiene cada recurso sin tocar nada

Para saber cuándo hace falta el atributo hay que conocer el punto de partida. La tabla de web.dev recoge las prioridades de Chrome, que son las que aparecen en la columna Priority de DevTools:

Dos detalles de esa tabla explican la mayoría de los problemas reales. Una imagen empieza en Low y solo sube a High cuando el navegador confirma tras el diseño que está en el viewport. Y las cinco primeras imágenes grandes reciben Medium, así que una imagen principal que llega la sexta en el HTML parte en Low. Eso lo vi tal cual en mi laboratorio, que cuento más abajo. El CSS bloqueante ya sale con prioridad máxima, y web.dev avisa de que fetchpriority="high" no lo sube más ni low lo baja de High; cómo tratarlo está en el artículo sobre CSS y SEO.

El caso principal: la imagen LCP

Si el elemento LCP de la página es una imagen que está en el HTML, la combinación correcta son dos cosas a la vez: fetchpriority="high" y ninguna marca de carga diferida.

<img src="/img/hero-1200.webp"
     srcset="/img/hero-600.webp 600w, /img/hero-1200.webp 1200w"
     sizes="(max-width: 900px) 100vw, 50vw"
     width="1200" height="800"
     fetchpriority="high" alt="…">

La guía de optimización del LCP de web.dev es clara en los dos frentes. Pide que nunca se aplique lazy loading a la imagen LCP, porque el recurso no se carga hasta que el diseño confirma que la imagen está en el viewport. Y pide fetchpriority="high" en esa imagen, con una advertencia: poner prioridad alta en más de una o dos imágenes deja de servir para reducir el LCP. Para que el hint llegue a servir, la imagen debe poder descubrirse en el HTML inicial. Si la inserta JavaScript o es un fondo CSS, el navegador no la ve hasta mucho después y el atributo llega tarde.

web.dev cuenta que en Google Flights el LCP bajó de 2,6 s a 1,9 s al aplicar Fetch Priority a la imagen LCP (0,7 s menos), un caso concreto de una prueba con Cloudflare Workers reescribiendo la página. Hay guías que publican rangos de mejora sin citar origen y esos no los repito.

El Web Almanac 2024 mide cuánto se usa: el 15 % de los sitios móviles priorizaban su imagen LCP en 2024, frente al 0,03 % de 2022, con WordPress como motor de buena parte del salto. WordPress añade fetchpriority="high" a la imagen que considera candidata a LCP y nunca la combina con loading="lazy". Los detalles del resto de la optimización de la imagen (formato, tamaño, srcset) están en el artículo sobre optimización de imágenes para SEO.

Bajar la prioridad: carruseles y contenido fuera de pantalla

La otra mitad del atributo es low. web.dev lo recomienda para imágenes que no se ven al empezar, como las diapositivas siguientes de un carrusel, y explica por qué no basta con loading="lazy": las imágenes fuera de pantalla pueden considerarse «suficientemente cerca» como para subirlas a High. En el caso de Oodle que cuenta la guía, bajar la prioridad de las imágenes que no aparecen al cargar redujo el tiempo de carga de la página en 2 segundos, sin más detalle de la medición, así que tómalo como el resultado de un caso y no como una promesa.

<ul class="carrusel">
  <li><img src="s1.webp" width="1200" height="600" fetchpriority="high" alt="…"></li>
  <li><img src="s2.webp" width="1200" height="600" fetchpriority="low" alt="…"></li>
  <li><img src="s3.webp" width="1200" height="600" fetchpriority="low" alt="…"></li>
</ul>

En mi prueba, una imagen con fetchpriority="low" pasó de Medium a Low. Es el mismo mecanismo en sentido contrario. Las otras formas de bajar prioridad con este atributo son scripts no críticos y peticiones fetch() que no afectan a lo primero que ve el usuario, como analítica o precargas de datos.

Scripts, terceros y fetch()

En scripts, el atributo sirve para dos cosas. Un script async parte en Low, y si es importante para la primera pantalla (un componente del que depende lo visible), fetchpriority="high" lo sube; así lo vi: async a secas salió Low y con high salió High. En sentido contrario, un script no crítico que precargas puede bajar con low, algo que web.dev propone para que no compita con recursos críticos.

Con terceros tienes menos margen de lo que parece: si los inyecta un gestor de etiquetas, no controlas su HTML y no puedes poner el atributo. Además, un script síncrono en el head ya sale con prioridad alta (lo confirmé en mi prueba), así que low no es el arreglo para un script bloqueante; lo es async o defer.

Para fetch(), el valor por defecto es High en Chrome. Una petición de fondo, como enviar métricas o cargar un listado que se muestra más abajo, puede ir con { priority: 'low' } para no competir con las que mantienen la interfaz viva. MDN define la opción con los mismos tres valores y con auto por defecto.

fetchpriority y preload: qué hace cada uno

Son piezas distintas y se usan juntas con frecuencia. preload resuelve el descubrimiento: dice al navegador que un recurso existe antes de que el parser lo encuentre. fetchpriority resuelve la prioridad: cuánto de urgente es. web.dev lo advierte, y lo cito también en el artículo de precarga de recursos con preload: una imagen precargada, sin fetchpriority, se sigue pidiendo con la prioridad por defecto, que para una imagen es baja. En mi prueba, un preload de imagen sin atributo salió Low y con fetchpriority="high" salió High.

web.dev matiza el beneficio: si el preload ya está arriba del todo en el head, la ganancia de añadirle prioridad puede ser pequeña, y si llega tarde, la ganancia es mayor. Además, la documentación de Chrome sobre el descubrimiento del LCP pide que, si precargas la imagen, el fetchpriority="high" esté en el preload y también en la imagen. Cuáles son los demás tipos de pista y cuándo usarlos no lo repito: está en el artículo de preload.

fetchpriority y lazy loading

Los dos atributos se contradicen si van en la misma imagen. loading="lazy" retrasa la petición hasta que el diseño confirma que la imagen se verá; fetchpriority="high" pide lo contrario. El resultado es una imagen que se descarga tarde con una prioridad que no sirve de nada, y es uno de los errores que marca Lighthouse. Lo vi en el laboratorio: la imagen principal con loading="lazy" empezó a pedirse a los 205 ms, frente a los 97 ms de las otras variantes, y su LCP no mejoró. Shopify recomienda en su documentación el mismo emparejamiento: fetchpriority="high" con loading="eager" o sin atributo loading.

La regla práctica es repartir los papeles. Lo que está en la primera pantalla va sin loading y, si es el LCP, con high. Lo que queda por debajo lleva loading="lazy" y no necesita fetchpriority. La técnica de carga diferida completa, con sus umbrales y su efecto en el rastreo, tiene su propio artículo sobre carga diferida con loading="lazy".

Qué impacto tiene en SEO

No hay un factor «fetchpriority» en el posicionamiento, y Google no lo documenta como tal. La relación es indirecta y pasa por el LCP. Google dice en su documentación que recomienda tener buenos Core Web Vitals para tener éxito en Search y que esas señales se alinean con lo que sus sistemas de ranking buscan premiar; no dice cuánto pesan frente a la relevancia. El umbral de un LCP bueno que fija web.dev es 2,5 segundos o menos, evaluado en el percentil 75 de las cargas. Cómo se miden y qué otras causas tiene un LCP malo está en el artículo de Core Web Vitals.

Lo que sí puedo decir con seguridad es dónde actúa el atributo. web.dev divide el LCP en cuatro partes: tiempo hasta el primer byte, retraso de carga del recurso, duración de la carga y retraso de renderizado. El ideal que propone es aproximadamente 40 % para el primer byte, menos del 10 % para el retraso de carga, 40 % para la duración y menos del 10 % para el renderizado, aclarando que son guías y no objetivos absolutos. fetchpriority reduce la segunda parte, el retraso de carga, y en parte la tercera, porque con más prioridad la imagen compite mejor por el ancho de banda. Si tu LCP es lento por un servidor lento o por una imagen de 2 MB, el atributo no lo arregla.

Límites y errores típicos

• High en todo. web.dev avisa de que priorizar más de una o dos imágenes deja de ayudar, y MDN pide un uso moderado porque una prioridad excesiva o incorrecta puede empeorar el rendimiento.
• Poner el atributo en la imagen equivocada. La imagen del header o un logo no son el LCP. Mira primero qué elemento lo es, porque puede cambiar entre escritorio y móvil.
• Combinarlo con loading="lazy". Se anulan entre sí, como expliqué arriba.
• Esperar que descubra el recurso. Si la imagen la inserta JavaScript, el atributo no sirve hasta que el script corre. Eso lo resuelve el HTML o un preload.
• Pensar que es una orden. El navegador puede ignorarla, y los servidores y CDN no aplican las prioridades de HTTP/2 y HTTP/3 de forma uniforme, según web.dev, lo que dificulta reproducir resultados.
• Usarlo para compensar un recurso pesado. Sigue valiendo lo básico: formato, dimensiones y compresión, y una caché bien configurada, que tratan los artículos sobre imágenes y caché para SEO.

Mi prueba: qué cambia el atributo en Chrome

Monté una página de prueba con seis imágenes pequeñas, un script y una imagen grande al final del HTML como elemento LCP, todas de unos 150 KB, servidas desde un servidor local HTTP/1.1. Lancé Chromium 141 con Playwright, caché desactivada y la red limitada a 2 Mbps con 80 ms de latencia, y repetí tres veces cada variante. Registré la prioridad inicial con el evento Network.requestWillBeSent del protocolo de Chrome y el LCP con PerformanceObserver.

La imagen sin atributo salió en Low porque era la séptima imagen grande del HTML y, según las reglas que recoge web.dev, solo las cinco primeras reciben Medium. Con high, el LCP bajó unos 0,7 s (un 15 %), con una dispersión entre repeticiones inferior a 40 ms. Una tanda previa a 1,5 Mbps con cinco repeticiones fue en la misma dirección: 10,5 s sin atributo y 9,0 s con él. Bajar además las otras imágenes a low no añadió nada medible en este montaje.

Esto es un laboratorio artificial, con imágenes de ruido y un servidor HTTP/1.1 que no se parece al tuyo. No lo uses como estimación de lo que ganarás: sirve para ver el mecanismo (la prioridad inicial cambia y el orden de peticiones con ella) y para tener un método. Con HTTP/2 o HTTP/3 el reparto es otro y no lo he medido.

Cómo lo tengo en mi web

Lo leí del código y lo medí con Playwright sobre la copia local del sitio, con el protocolo de Chrome registrando la prioridad inicial de cada petición.

• Portada de cada artículo. La plantilla article-page.php pinta la imagen de portada con fetchpriority="high", sin loading y con width y height. Va dentro de un picture cuyo source para pantallas de hasta 900 px apunta a un GIF de un píxel. Es una decisión de diseño, no un fallo: en ese ancho el CSS oculta el contenedor (.post-hero-media{display:none}), así que la portada no se muestra y no hace falta descargarla. En el artículo de caché, a 1.440 px la portada salió High y fue el elemento LCP; a 390 px no se pidió y el LCP fue el H1.
• Home, landings y páginas de ciudad. El retrato de la home lleva fetchpriority="high" y además un preload con imagesrcset en el head. Las 12 landings de servicio, «Sobre mí» y las páginas de ciudad llevan la imagen principal con loading="eager" y fetchpriority="high". Antes, tres landings (formación SEO, marketing de contenidos y SEO para LLMs) solo llevaban fetchpriority; las he alineado con las demás. eager es el valor por defecto, así que no cambia el comportamiento: lo explicito para que el HTML diga lo mismo en todas.
• El resto. Las figuras de los artículos llevan loading="lazy" y salen en Low; las tarjetas y el pie también van diferidos. No uso fetchpriority="low" en ningún sitio, y tampoco priority en fetch().

Hay un hallazgo que no esperaba. En móvil, tanto en la home como en las landings de servicio que medí (auditoría, formación SEO, marketing de contenidos y SEO para LLMs), el elemento LCP es un párrafo y no la imagen, pero la imagen con fetchpriority="high" se descarga igualmente con prioridad alta. Pesan poco (la de la landing, unos 32 KB; el retrato de la home en móvil, unos 12 KB), así que el daño probable es pequeño, pero es un caso en el que el atributo prioriza algo que no es el LCP. Tengo pendiente revisarlo y no he medido si afecta al LCP real en móvil. Todas estas pruebas son locales y sin limitación de red, así que no te doy tiempos de LCP del sitio, solo prioridades.

Cómo auditarlo

1. Identifica el elemento LCP. Graba la carga en la pestaña Performance de DevTools; el LCP aparece marcado y el panel dice qué elemento es. Hazlo en móvil y en escritorio.
2. Mira su prioridad. En la pestaña Network, activa la columna Priority. Chrome indica que es la misma información que ofrece el panel Performance, con «Big request rows» activado; ahí también se ve la prioridad inicial y la final de cada petición, por si cambió.
3. Revisa las comprobaciones de Lighthouse. Su información sobre el descubrimiento de la petición LCP comprueba tres cosas si el LCP es una imagen: que lleve fetchpriority=high (o su preload), que se pueda descubrir en el documento principal y que no tenga loading=lazy. Recuerda que, si hay preload, el atributo debe estar en el preload y en la imagen.
4. Mide antes y después. Una sola carga no vale. Repite varias veces con red limitada y compara la mediana, como en mi laboratorio, y valida en datos de campo cuando haya tráfico suficiente.

Preguntas frecuentes

Referencias

1. Optimize resource loading with the Fetch Priority API web.dev
2. Optimize Largest Contentful Paint web.dev
3. HTML attribute: fetchpriority MDN Web Docs
4. RequestInit (opción priority de fetch) MDN Web Docs
5. LCP request discovery Chrome for Developers
6. Web Almanac 2024: Performance HTTP Archive
7. Image performance enhancements in WordPress 6.3 Make WordPress Core
8. Set fetchpriority high on the LCP image Shopify Developer Docs
9. Understanding Core Web Vitals and Google search results Google Search Central