El Fetchpriority es una herramienta más para mejorar la velocidad de una web
El WPO, Web Performance Optimization, traducido del inglés “Optimización del rendimiento de una Web” consiste en buscar e implementar formas de hacer que una web vaya más rápida y fluida sin hacer un perjuicio en el contenido que acabará recibiendo el usuario.
Un aspecto que se suele pasar por alto a la hora de trabajar el WPO es el hecho de qué no todo consiste en mejorar cada uno de los elementos que se descarga el usuario. El orden en el que se descargan y ejecutan los elementos en el navegador también es una parte crucial a la hora de mejorar la experiencia del usuario y la sensación de velocidad y rapidez.
Es por ello que los SEOs técnicos solemos jugar mucho con las precargas y las cargas diferidas.
Normalmente, el orden por defecto viene dado por lo que va encontrando el navegador al descargar el HTML inicial, y a esos recursos les asigna una prioridad, dependiendo también del peso y el tipo de elemento. Los navegadores suelen hacer esto por defecto tratando de generar la mejor experiencia, pero no siempre lo hacen de la forma más óptima.
Además de otro tipo de precargas como el preload, prefetch y el preconnect, existe una precarga llamada FetchPriority que se inserta en las etiquetas HTML como atributo.
Sin embargo, este atributo es difícil de entender y de ejecutar de una forma correcta, así que lo voy a simplificar para que sea entendible.
El Fetch Priority altera la prioridad que se le da por defecto a un elemento marcado por HTML y se debe hacer dependiendo de lo relevante y prioritario que sea dicho elemento en la carga de recursos.
Un aspecto importante a destacar es que los navegadores a pesar de ser buenos estableciendo prioridades, a veces no son conscientes de la prioridad del elemento hasta que llegan a él y en ocasiones, sea en lo inicial o en el cambio, le asignan una prioridad incorrecta.
¿Quieres ver la prioridad que tienen los elementos en tu web?
Puedes utilizar la Chrome Devtools > red > Ruedita > Fila de solicitudes Grandes y si le das a mostrar la columna de prioridad te saldrá la diferencia entre la prioridad inicial y la final.
Si te preguntas para qué nos puede servir esta información es precisamente para tener idea de qué elementos pueden tener más necesidad de este cambio de prioridad, evidentemente sumándose a nuestros conocimientos para establecer un buen criterio.
Se debe entender la prioridad con las que carga por defecto un navegador los elementos, ya que antes de querer utilizar un modificador tan potente, debemos entender con qué prioridad suele cargar cada elemento.
La prioridad “superalta” y “alta” son las que se activan en la fase de “bloqueo de diseño”, LBP, por lo que debemos tener cuidado de no sobrecargarlo de recursos.
La Layout Blocking Phase o LBP (fase de bloqueo del diseño) en una web se refiere a la parte del proceso de renderizado en la que el navegador retrasa la presentación visual de la página debido a la carga y ejecución de ciertos recursos, especialmente CSS y scripts que afectan el diseño.
Sería simplemente un atributo de HTML para los elementos link, img o script, que además suelen ser los que traen los archivos multimedia más pesados.
Para la etiqueta Iframe no hay documentación al respecto. Mientras que el loading lazy si que funciona para iframe en la mayoría de navegadores, no parece tener el estándar para fetchpriority.
El atributo fetch priority solo tiene 3 valores posibles:
Ejemplos:
<img src="/images/logo.svg" fetchpriority="high"><link href="/css/estilos.css" fetchpriority="low"><script src="javascript.js" fetchpriority="high"></script>
Cabe destacar que el impacto de fetchPriority en esa prioridad dependen completamente del navegador utilizado.
Es decir es un estándar de HTML que cada navegador tomará en cuenta, ya que es una sugerencia, no una directiva. El navegador intenta respetar la preferencia del desarrollador, pero también puede aplicar sus preferencias de prioridad de recursos para resolver conflictos.
Estos elementos tienen su propia designación automática y por defecto su prioridad de carga. A continuación añado una tabla de cómo designa la prioridad chrome y cómo afectan estos atributos, pues si por ejemplo hay una etiqueta link con un CSS en el head por medio del atributo fetchpriority low no bajaremos su prioridad para que cargue después de la fase de bloqueo del diseño.
Para entender mejor la tabla que se verá a continuación para entender la prioridad que tiene cada elemento y cómo la podemos modificar, vamos a dividir estas 5 prioridades en dos fases, la que sucede en el LBP (Layout Blocking Phase) y la que sucede después del LBP.
Quiere decir que podemos cambiar la prioridad de elementos para que se carguen antes de que suceda la muestra visual para mejorar el CLS o después para posponer la carga del elemento y no afectar al LCP.
Como cada elemento tiene una prioridad por defecto distinta y no podemos cambiar la prioridad de cada elemento a voluntad, sino hacer una sugerencia y tenemos un rango de “movimiento de prioridad” dependiendo del elemento, veamos cómo podemos jugar con cada uno de ellos.
| Carga antes de la LBP | Carga después de la LBP | ||||
|---|---|---|---|---|---|
| Prioridad | Muy alta | Alta | Versión intermedia | Bajo | Muy baja |
| Recurso principal | ◉ | ||||
| CSS (early**) | ⬆◉ | ⬇ | |||
| CSS (late**) | ⬆ | ◉ | ⬇ | ||
| CSS (@media que no afecta***) | ⬆ | ◉⬇ | |||
| Script (early **) | ⬆◉ | ⬇ | |||
| Script (late**) | ⬆ | ◉ | ⬇ | ||
| Script (async/defer) | ⬆ | ◉⬇ | |||
| Fuente | ◉ | ||||
| Fuente (rel=preload) | ⬆◉ | ⬇ | |||
| @import | ◉ | ||||
| Imagen (viewport/above the fold. Que está en la pantalla sin hacer scroll.) | ⬆◉ | ⬇ | |||
| Imagen (las primeras 5 imágenes > 10,000 px2) | ⬆ | ◉ | ⬇ | ||
| Imagen | ⬆ | ◉⬇ | |||
| Contenido multimedia (video/audio) | ◉ | ||||
Aunque existen tantas opciones como web te muestro unas cuantas.
El preload permite informar la navegador de los recursos que quieres descargar y cargar antes de que el navegador llegue a ellos y los descubra de forma natural, muy útil por ejemplo para las fuentes que cargamos mediante un archivo de CSS externo, así podemos descargar y cargar las fuentes mientras se llega a ese proceso.
Sin embargo, no siempre es conveniente hacer esta precarga y lo único que queremos es indicar que cuando llegue el navegador a un recurso si tiene importancia inicialmente o no.
Es importante diferenciar la prioridad de carga con un preload, ya que:
La precarga no es opcional, es obligatoria.
La precarga adelanta la descarga, pero no cambia la prioridad.
Fetchpriority solo cambia la prioridad, pero no la visibilidad.
A veces convendrá más el fetch priority y otras el preload, dependerá de la situación.
Aunque en la documentación de Google dice que sí, no es una implementación del todo recomendable.
Un preload con un fetchpriority son contradictorios y se deben hacer con mucho cuidado y hacer una investigación en local del proyecto para ver si de verdad esa implementación es óptima y necesaria (en todos los navegadores que utilizan tus usuarios).
Al margen de que la implementación de script que hay debajo no debería unirse junto al atributo en la documentación ya que abarcan temas ligeramente distintos, lo que se indica en lo subrayado de la documentación es como un “quiero que descargue el recurso antes de que se necesite en el DOM” pero “quiero que la prioridad sea baja”. Es decir un “se prioritario pero no mucho”.
Si bien podría servir para desmarcar un poco de prioridad entre los recursos prioritarios no es la implementación más necesaria ni recomendable. Si algo es prioritario lo es, y si no, no debe serlo. Si le quieres bajar la prioridad a un elemento, deberías plantearte si necesita un preload.
Podemos decir que el atributo loading marca cuándo debe extraer el elemento, mientras que el fetch priority marca qué importancia tiene extraerlo.
Según CanIUse tiene compatibilidad con los navegadores más utilizados y modernos:
El Fecthpriority es una herramienta más para mejorar la velocidad y rendimiento de nuestras webs gracias a la estandarización de estos atributos por parte de los principales navegadores web.
No es un atributo que haya que implementar siempre, pero puede resultar de gran utilidad, por ejemplo para imágenes ocultas en una barra de navegación o sliders, o para Scripts que cargan después de un elemento para poder funcionar pero que su código afecta al diseño y no queremos una mala experiencia del usuario.
El mundo del WPO es largo y complejo y conocer todas estas herramientas que nos hacen ganar minipuntos en el rendimiento nos permiten tener flexibilidad en nuestras estrategias para optimizar webs y que sigan siendo rápidas sin perder funcionalidad.
Te falta mi máster. Accede a una formación avanzada que te permitirá aplicar e implementar SEO en cualquier tipo de WEB
¡Accede al Máster de SEO Técnico!Si te ha gustado esta publicación, siempre me lo puedes agradecer dándome like en esta publicación de LinkedIn sobre este mismo artículo.
