Solucionar e Identificar Problemas de Largest Contentful Paint (LCP)

Esta guía forma parte de la sección de Largest Contentful Paint (LCP) de nuestro centro de recursos de Core Web Vitals. LCP mide el tiempo que tarda el elemento de contenido visible más grande en renderizarse en la pantalla, y Google considera que cualquier valor por debajo de 2,5 segundos es una puntuación "buena". A continuación, encontrarás la metodología de diagnóstico exacta utilizada en consultoría profesional de velocidad de página para identificar y solucionar problemas de LCP.

Guía de un Consultor para Diagnosticar y Solucionar LCP

Mi nombre es Arjen Karel, y soy consultor de velocidad de página. A lo largo de los años, he auditado cientos de sitios web, y uno de los desafíos más persistentes es Largest Contentful Paint (LCP). En esta guía, compartiré la metodología exacta que utilizo para diagnosticar y resolver problemas de LCP. Verás menciones de CoreDash, una herramienta de RUM que creé para obtener los datos precisos necesarios para este proceso. Los principios aquí son universales, pero creo en mostrar ejemplos reales de las herramientas que construyo y uso a diario.

Mejorar LCP es un proceso sistemático de eliminación. Siguiendo una metodología clara, puedes diagnosticar eficazmente los cuellos de botella en el proceso de carga de tu página y aplicar correcciones específicas para mejorar el rendimiento y la user experience de tu sitio.

La Metodología de Diagnóstico: Primero Datos de Campo, Después Datos de Laboratorio

Para optimizar eficazmente, debes adoptar un flujo de trabajo de diagnóstico en dos pasos. Esto asegura que estés resolviendo problemas que tus usuarios realmente enfrentan, no solo persiguiendo puntuaciones en un entorno de laboratorio.

1. Los Datos de Campo (RUM y CrUX) te muestran QUÉ está ocurriendo. Los datos de campo se recopilan de usuarios reales que visitan tu sitio [1]. Te indican si tienes un problema de LCP, qué páginas están afectadas y qué usuarios (móvil o escritorio) lo están experimentando. Siempre debes comenzar aquí para confirmar que existe un problema real.
2. Los Datos de Laboratorio (Lighthouse, DevTools) te ayudan a diagnosticar POR QUÉ está ocurriendo. Los datos de laboratorio se recopilan en un entorno controlado y simulado [2]. Una vez que tus datos de campo han confirmado un problema en una página específica, puedes usar herramientas de laboratorio para replicar el problema de forma consistente y analizar el proceso de carga para encontrar la causa raíz.

Comenzar con datos de campo asegura que tus esfuerzos de optimización se centren en cambios que tendrán un impacto medible en tus usuarios reales.

Paso 1: Identificar Problemas de LCP con Datos de Campo

Tu primera tarea es usar datos de usuarios reales para confirmar qué páginas, si las hay, tienen un LCP deficiente.

Un Punto de Partida Accesible: Google Search Console

Un lugar válido para comenzar es el informe de Core Web Vitals en Google Search Console. Inicia sesión, navega al informe y revisa los gráficos de móvil y escritorio. Si Google está marcando URLs con "Problema de LCP: superior a 2,5s", tienes confirmación del Chrome User Experience (CrUX) Report de que un porcentaje de tus usuarios está teniendo una experiencia deficiente.

Aunque Search Console es invaluable para confirmar un problema, se actualiza lentamente y agrupa datos por patrones de URL. Para obtener información más inmediata y granular, se necesita una herramienta de RUM dedicada.

Una Mirada más Profunda: Real User Monitoring (RUM)

Para obtener la verdad absoluta, puedes rastrear LCP para cada usuario en cada carga de página usando una solución de Real User Monitoring (RUM). Aunque puedes construir la tuya propia aprovechando la biblioteca web-vitals para enviar datos a tu backend de analítica, esto puede ser un esfuerzo de ingeniería significativo.

Alternativamente, las herramientas de RUM dedicadas están diseñadas para este propósito. Herramientas como CoreDash están construidas para proporcionar estos datos de forma inmediata. Configurarlo típicamente implica agregar un pequeño fragmento de JavaScript al encabezado de tu sitio. Una vez instalado, comienza a recopilar datos de rendimiento de cada visitante real.

Una buena herramienta de RUM te ayuda a ir más allá de los grupos de URLs para entender:

• Tu puntuación precisa de LCP para cualquier URL específica.
• Un desglose de cada elemento LCP (por ejemplo, una imagen, un titular) y cuáles son los más frecuentemente asociados con un LCP lento.
• El tiempo exacto de cada una de las cuatro fases de LCP para cada vista de página, identificando el cuello de botella.

Los casos del mundo real demuestran la importancia de mirar más allá de lo obvio. En un caso de estudio bien documentado, Vodafone mejoró su LCP en un 31%, lo que contribuyó directamente a un aumento del 8% en las ventas. Su optimización se centró en identificar y resolver el cuello de botella específico de LCP en páginas de destino clave usando una combinación de análisis de datos de campo y correcciones específicas. Esto demuestra que la optimización de LCP requiere mirar más allá del propio elemento LCP; exige comprender todo el proceso de carga, desde la respuesta del servidor hasta el pintado final.

Por ejemplo, en CoreDash, puedes navegar a la página de LCP y ver una tabla de datos que muestra tus elementos LCP más lentos. Al hacer clic en un elemento específico (como una clase CSS particular para una imagen hero), puedes filtrar todas las métricas para ver los datos de rendimiento solo de las páginas donde ese elemento fue el LCP.

Ya sea que uses una solución personalizada o una herramienta como CoreDash, el objetivo es el mismo: usar datos de campo para encontrar tu página más lenta e identificar su elemento LCP más común. Una vez que tengas ese objetivo, estás listo para diagnosticar.

Medir LCP con la Performance Observer API

Si quieres entender LCP a nivel técnico, la Performance Observer API proporciona acceso directo a las entradas de LCP en JavaScript. Esta es la misma API que las herramientas de RUM usan internamente para recopilar datos de campo. El siguiente fragmento registra cada candidato a LCP que el navegador identifica, incluyendo el elemento, su tamaño y el tiempo de renderizado.

const observer = new PerformanceObserver((list) => {
  const entries = list.getEntries();
  const lastEntry = entries[entries.length - 1];
  console.log('LCP element:', lastEntry.element);
  console.log('LCP time:', lastEntry.renderTime || lastEntry.loadTime);
  console.log('LCP size:', lastEntry.size);
});
observer.observe({ type: 'largest-contentful-paint', buffered: true });

Esto es útil para una validación rápida durante el desarrollo, pero para medición en producción deberías usar la biblioteca web-vitals, que maneja casos especiales como cambios de visibilidad de pestaña y restauraciones de caché de avance/retroceso.

Paso 2: Diagnosticar el Cuello de Botella con Herramientas de Laboratorio

Ahora que sabes qué página corregir, es hora de averiguar por qué es lenta. Aquí es donde una herramienta de laboratorio como PageSpeed Insights o el panel de Lighthouse en Chrome DevTools se vuelve esencial [3].

Ejecuta una prueba en tu URL objetivo. En el informe, desplázate hasta la sección "Diagnósticos" y encuentra la auditoría "Elemento Largest Contentful Paint". Este gráfico de cascada desglosa tu tiempo de LCP en sus cuatro sub-partes. Tu herramienta de RUM debería mostrar un desglose similar basado en tus datos de campo.

Tu objetivo es encontrar la fase más larga en este desglose. Ese es tu cuello de botella principal, y ahí es donde deberías centrar tus esfuerzos de optimización primero.

Paso 3: Comprender las Cuatro Fases de LCP

Cada puntuación de LCP es la suma de cuatro fases secuenciales. Comprender cada una es esencial para aplicar la corrección correcta. Cada fase tiene un artículo dedicado en profundidad en este sitio que cubre estrategias avanzadas de optimización.

• Time to First Byte (TTFB): Esta es la base ineludible. Una respuesta lenta del servidor es una adición directa, milisegundo por milisegundo, a tu LCP. Antes de optimizar una sola imagen, debes asegurarte de que tu servidor responda rápidamente. Aprende más sobre optimizar TTFB.
• Resource Load Delay: Este es el "problema de descubrimiento" y uno de los problemas más comunes. El navegador no puede descargar un recurso que no conoce. Si tu imagen LCP está oculta en un archivo CSS o JavaScript, o incluso si está en el HTML pero otros recursos se solicitan primero, el navegador la encuentra demasiado tarde, desperdiciando tiempo valioso. Lee la guía completa sobre Resource Load Delay.
• Resource Load Duration: Este es el tiempo de descarga del recurso LCP en sí. Imágenes grandes sin comprimir o condiciones de red lentas pueden hacer que esta fase sea un cuello de botella. Lee la guía completa sobre Resource Load Duration.
• Element Render Delay: Este es el problema de "demasiado ocupado para pintar". El archivo de imagen LCP podría estar completamente descargado, pero si el hilo principal del navegador está bloqueado por la ejecución pesada de JavaScript, simplemente no puede pintar la imagen en la pantalla. Lee la guía completa sobre Element Render Delay.

La siguiente guía está estructurada para abordar estas fases en un orden lógico. Siempre comienza asegurándote de que tu TTFB sea rápido y tu recurso LCP sea descubrible antes de pasar a las optimizaciones de tamaño de archivo y renderizado.

Paso 4: Ejecutar la Corrección

Con el cuello de botella identificado, puedes aplicar optimizaciones específicas. La forma en que implementes estas correcciones dependerá en gran medida de la arquitectura de tu sitio. Primero cubriremos los principios universales para cada fase, y luego proporcionaremos consejos específicos para WordPress y frameworks modernos de JavaScript.

1. Optimizar Time to First Byte (TTFB)

Si tu TTFB es lento (un buen objetivo es menos de 800ms [4]), establece un piso alto para tu LCP. Mejorar TTFB mejorará todas las demás métricas de carga. Este es el tiempo que tarda el navegador en recibir el primer byte de HTML de tu servidor.

Soluciones Universales para TTFB

• Habilitar Caché: Esta es una de las formas más efectivas de mejorar TTFB. El almacenamiento en caché genera y almacena una copia de la página para que pueda servirse instantáneamente sin esperar a que el servidor la construya desde cero en cada visita.
• Usar un CDN: Una Red de Distribución de Contenidos sirve tu contenido desde un servidor físicamente cercano a tu usuario, lo que reduce la latencia de red [5]. Almacenar en caché tus páginas HTML completas en el borde del CDN es una estrategia poderosa para un TTFB rápido y global. Para consejos detallados de configuración de CDN, consulta nuestra guía sobre cómo configurar Cloudflare para un rendimiento óptimo.
• Usar Compresión Brotli o Gzip: Asegúrate de que tu servidor esté comprimiendo los activos basados en texto como HTML, CSS y JavaScript. Brotli ofrece mejor compresión que Gzip y debería ser la opción preferida.
• Usar HTTP/3 con 0-RTT: Asegúrate de que tu servidor esté configurado para usar HTTP/3. Ofrece ventajas significativas de rendimiento, incluyendo mejor multiplexación. Soporta 0-RTT (Zero Round Trip Time Resumption), que elimina el tiempo de establecimiento de conexión para visitantes recurrentes, proporcionando un impulso instantáneo al TTFB [6].
• Usar 103 Early Hints: Para un impulso avanzado, usa el código de estado 103 Early Hints. Esto permite que tu servidor o CDN envíe indicaciones sobre archivos críticos de CSS y JS al navegador mientras aún está preparando el documento HTML completo, permitiendo que las descargas comiencen incluso antes [7]. Para una guía de implementación completa, consulta nuestro artículo sobre 103 Early Hints.

Correcciones de TTFB Específicas por Plataforma

En WordPress:

• Invertir en Hosting de Calidad: En WordPress, un TTFB lento a menudo está relacionado con el entorno de hosting. El hosting compartido barato puede ser un cuello de botella. Considera un host de WordPress gestionado que esté optimizado para rendimiento.
• Usar un Plugin de Caché: Un plugin de caché de alta calidad (por ejemplo, WP Rocket, W3 Total Cache) es innegociable. Se encarga de la generación de archivos HTML estáticos por ti, que es el núcleo del almacenamiento en caché efectivo en esta plataforma.

En un Framework de JS:

• Elegir la Plataforma de Hosting Correcta: Para aplicaciones Node.js, plataformas como Vercel o Netlify están altamente optimizadas para frameworks SSR/SSG y ofrecen almacenamiento en caché inteligente y ejecución de funciones serverless listas para usar.
• Implementar Caché SSR: Si estás usando Server-Side Rendering, almacena en caché las páginas renderizadas en el servidor (por ejemplo, usando Redis o una caché en memoria) para evitar el re-renderizado en cada solicitud.
• Cuidado con los Cold Starts de Serverless: Si usas funciones serverless para el renderizado, ten en cuenta que un "cold start" (la primera solicitud después de un período de inactividad) puede tener un TTFB alto. Usa concurrencia provisionada o estrategias de keep-alive para mitigar esto.

2. Reducir el Resource Load Delay

Este es frecuentemente el mayor cuello de botella. Significa que el navegador estaba listo para trabajar, pero no pudo encontrar tu imagen principal o archivo de fuente de inmediato. Este retraso es típicamente causado por uno de dos problemas: el recurso se descubre tarde, o se le da una prioridad de descarga baja. Para la guía completa en profundidad sobre este tema, lee nuestra guía dedicada sobre Resource Load Delay.

Soluciones Universales para Load Delay

La solución universal para Resource Load Delay es asegurar que tu recurso LCP sea tanto descubrible en el marcado HTML inicial como que reciba una alta prioridad por parte del navegador. Así es como lograrlo:

• Hacer el Recurso LCP Descubrible: El paso más importante es asegurar que tu elemento LCP esté presente en el HTML que el servidor envía. Los navegadores usan un "escáner de precarga" de alta velocidad para buscar anticipadamente en el HTML sin procesar recursos como imágenes y scripts para descargar. Si tu imagen LCP se carga mediante un background-image de CSS o se inyecta con JavaScript, es invisible para este escáner, causando un retraso importante. La solución más robusta es siempre usar una etiqueta <img> estándar con un atributo src en tu HTML renderizado por el servidor.
• Controlar el Orden de Carga con preload: Si no puedes hacer que el recurso LCP sea directamente descubrible (un problema común con fuentes o imágenes de fondo CSS), la siguiente mejor solución es usar <link rel="preload">. Esta etiqueta actúa como una instrucción explícita en tu <head> de HTML, indicando al navegador que comience a descargar un recurso crítico mucho antes de lo que lo habría encontrado de forma natural. Para detalles de implementación y ejemplos, consulta nuestra guía sobre cómo precargar la imagen LCP.
• Asegurar Alta Prioridad con fetchpriority: Incluso cuando un recurso es descubrible, el navegador podría no darle la mayor prioridad de descarga. Agregar fetchpriority="high" a tu etiqueta <img> o tu etiqueta <link rel="preload"> es una indicación poderosa al navegador de que este recurso específico es el más importante para la user experience, ayudándolo a ganar la carrera por el ancho de banda frente a otros recursos [8].

Correcciones de Load Delay Específicas por Plataforma

En WordPress:

• Evitar Imágenes de Fondo de Page Builders: Muchos page builders facilitan establecer una imagen hero como un background-image de CSS en un div. Esto la hace invisible para el escáner de precarga del navegador. Si es posible, usa un bloque <img> estándar en su lugar. Si no, puede que necesites un plugin o código personalizado para precargar esa imagen específica.
• Desactivar Lazy-Loading para la Imagen LCP: Muchos plugins de optimización aplicarán automáticamente lazy-load a todas las imágenes. Debes encontrar la configuración en tu plugin para excluir la imagen LCP (y a menudo las primeras imágenes de la página) del lazy-loading. Este es un error tan común que tenemos un artículo dedicado sobre cómo corregir imágenes LCP con carga diferida.

En un Framework de JS:

• Usar Server-Side Rendering (SSR): Esta es a menudo la corrección de mayor impacto. Una aplicación React con Client-Side Rendering (CSR) por defecto envía un HTML mínimo, y el elemento LCP solo existe después de que se descarga y ejecuta un gran bundle de JS. Los frameworks SSR como Next.js o Remix entregan el HTML completo, incluyendo la etiqueta <img>, para que el navegador pueda descubrirla inmediatamente.
• Usar Componentes de Imagen Específicos del Framework: Frameworks como Next.js ofrecen un componente de imagen con una propiedad priority. Usar la propiedad priority aplica automáticamente fetchpriority="high" y otras optimizaciones a tu imagen LCP.

3. Disminuir la Resource Load Duration

Asegurar que tu recurso LCP sea lo más pequeño posible sigue siendo una parte esencial del proceso. Esta fase trata sobre cuánto tiempo tarda en descargarse el archivo del recurso LCP a través de la red. Para una guía completa sobre técnicas de optimización de imágenes, consulta nuestro artículo sobre optimizar la imagen LCP, y para más información sobre Resource Load Duration específicamente.

Soluciones Universales para Load Time

• Reducir el Tamaño del Archivo con Formatos Modernos e Imágenes Responsivas: La forma más directa de acortar el tiempo de descarga es hacer el archivo más pequeño. Para imágenes, esto significa usar formatos modernos y altamente eficientes como AVIF o WebP [9]. También debes servir imágenes responsivas usando el elemento <picture> o los atributos srcset y sizes. Esto asegura que un usuario en un dispositivo móvil reciba una imagen del tamaño apropiado para su pantalla más pequeña, en lugar de verse obligado a descargar una imagen masiva del tamaño de escritorio. Una pantalla móvil de 400 píxeles de ancho simplemente no necesita un archivo de imagen de 2000 píxeles de ancho. Para LCPs basados en texto, asegúrate de que tus fuentes estén en el formato eficiente WOFF2 y estén subconjuntadas para eliminar caracteres no utilizados.
• Reducir la Contención de Red: El recurso LCP tiene que competir por el ancho de banda de red limitado del usuario. Diferir recursos no críticos, como scripts de analítica o CSS para contenido debajo del pliegue, libera ancho de banda para que el navegador pueda centrarse en descargar el recurso LCP más rápido.
• Alojar Recursos Críticos en tu Dominio Principal: Evita cargar tu recurso LCP desde un dominio diferente si es posible. Establecer una nueva conexión a otro servidor añade búsquedas DNS y handshakes que consumen tiempo.

Correcciones de Load Time Específicas por Plataforma

En WordPress:

• Usar un Plugin de Optimización de Imágenes: Herramientas como ShortPixel o Smush pueden comprimir automáticamente las imágenes al subirlas, convertirlas a formatos modernos como WebP/AVIF y generar tamaños srcset responsivos.
• Redimensionar Imágenes Manualmente: Antes de subir, redimensiona tus imágenes para que no sean más grandes de lo necesario. No subas una imagen de 4000px de ancho para un espacio que solo tiene 1200px de ancho en las pantallas más grandes.

En un Framework de JS:

• Usar un CDN de Imágenes: Esta es una solución poderosa. Servicios como Cloudinary, Imgix o Image & Video Manager de Akamai pueden automatizar todo el proceso de optimización. Subes una imagen de alta calidad, y ellos entregan una versión perfectamente dimensionada, comprimida y formateada a cada usuario a través de un CDN rápido.
• Aprovechar las Herramientas de Build: Cuando importas una imagen en un componente en un framework moderno, la herramienta de build (como Webpack o Vite) puede automáticamente hashear y optimizar el archivo como parte del proceso de build.

4. Acortar el Element Render Delay

El recurso ha terminado de descargarse, pero aún no está en la pantalla. Esto significa que el hilo principal del navegador está ocupado con otras tareas y no puede pintar el elemento. Este es otro cuello de botella muy común y significativo. Para la guía completa en profundidad, lee nuestra guía sobre Element Render Delay.

Soluciones Universales para Render Delay

• Diferir o Eliminar JavaScript No Utilizado: Cualquier JS que no sea esencial para renderizar la parte inicial visible de la página debería diferirse usando los atributos defer o async.
• Usar CSS Crítico: Una hoja de estilos grande que bloquea el renderizado puede retrasar la representación. La técnica de CSS crítico implica extraer el CSS mínimo necesario para dar estilo al contenido visible inicialmente, incrustarlo en el <head>, y cargar el resto de los estilos de forma asíncrona [10].
• Dividir Tareas Largas: Un script de larga ejecución puede bloquear el hilo principal durante un período prolongado, impidiendo el renderizado. Esta es también una causa principal de un Interaction to Next Paint (INP) deficiente. Divide tu código en fragmentos más pequeños y asíncronos que cedan el control al hilo principal.

Correcciones de Render Delay Específicas por Plataforma

En WordPress:

• Auditar tus Plugins: Demasiados plugins, especialmente los pesados como sliders o page builders complejos, pueden añadir CSS y JS significativos que bloquean el hilo principal. Desactiva los plugins uno por uno para identificar los que consumen más rendimiento.
• Usar un Tema Ligero: Un tema sobrecargado con docenas de funciones que no usas puede ser una fuente importante de código que bloquea el renderizado. Elige un tema enfocado en el rendimiento.
• Usar Gestores de Activos de Plugins: Herramientas como Asset CleanUp o Perfmatters te permiten desactivar condicionalmente CSS y JS de plugins específicos en páginas donde no son necesarios.

En un Framework de JS:

• La División de Código es Clave: No envíes todo el JavaScript de tu aplicación en un solo bundle gigante. Divide tu código por ruta (para que los usuarios solo descarguen el código de la página que están visitando) y por componente.
• Cargar Componentes de Forma Diferida: Usa React.lazy y Suspense para cargar de forma diferida componentes que no son inmediatamente visibles (por ejemplo, componentes debajo del pliegue o en modales). Esto los mantiene fuera del bundle inicial.

Avanzado: Optimizar LCP para Navegaciones Posteriores

Corregir el LCP inicial es importante, pero puedes crear una experiencia dramáticamente más rápida para los usuarios mientras navegan por tu sitio optimizando las cargas de páginas posteriores.

Asegurar que las Páginas sean Elegibles para el Back/Forward Cache (bfcache)

El bfcache es una optimización del navegador que almacena una instantánea completa de una página en memoria cuando un usuario navega fuera de ella. Si hacen clic en el botón de retroceso, la página puede restaurarse instantáneamente, resultando en un LCP cercano a cero. Muchas páginas no son elegibles para esta caché debido a cosas como los event listeners de unload. Usa la auditoría "bfcache" de Lighthouse para probar tus páginas y eliminar cualquier característica que lo bloquee [11].

Usar la Speculation Rules API para Prerenderizado

La Speculation Rules API es una herramienta poderosa que te permite indicar declarativamente al navegador qué páginas es probable que el usuario visite a continuación. El navegador puede entonces obtener y prerenderizar estas páginas en segundo plano. Cuando el usuario hace clic en un enlace a una página prerenderizada, la navegación es instantánea, lo que lleva a una user experience fenomenal y un LCP cercano a cero [12]. Puedes definir estas reglas en una etiqueta <script type="speculationrules"> en tu HTML.

<script type="speculationrules">
 {
  "prerender": [{
   "source": "document",
   "where": {
    "href_matches": "/products/*"
   },
   "eagerness": "moderate"
  }]
 }
 </script>  

Este ejemplo indica al navegador que busque enlaces en la página actual que vayan a páginas de productos y que comience a prerenderizarlas cuando un usuario pase el cursor sobre el enlace.

Trabajando metódicamente a través de estas cuatro fases y considerando las optimizaciones avanzadas de navegación, puedes identificar la causa exacta de tus problemas de LCP y aplicar la corrección correcta y de alto impacto.

Próximos Pasos: Profundiza en Cada Fase de LCP

Ahora que entiendes la metodología de diagnóstico, explora cada fase de LCP en detalle con nuestras guías dedicadas:

• Optimizar la Imagen LCP: Una guía completa sobre selección de formato de imagen, imágenes responsivas, precarga y errores comunes de optimización de imágenes.
• Resource Load Delay: Cómo asegurar que el navegador descubra tu recurso LCP lo antes posible usando preload, fetchpriority y una estructura HTML adecuada.
• Resource Load Duration: Cómo reducir el tiempo de descarga de tu recurso LCP mediante compresión de archivos, formatos modernos, configuración de CDN y optimización de red.
• Element Render Delay: Cómo liberar el hilo principal del navegador para que pueda pintar el elemento LCP inmediatamente después de la descarga, cubriendo CSS crítico, diferimiento de JavaScript y content-visibility.

Referencias

1. web.dev: Datos de laboratorio y de campo
2. Chrome for Developers: Depurar Web Vitals en el campo
3. web.dev: Optimizar Largest Contentful Paint
4. web.dev: Optimizar para un buen TTFB
5. Cloudflare: ¿Qué es un CDN?
6. web.dev: HTTP/3
7. web.dev: ¿Más lento es más rápido? Enviar una respuesta HTTP 103 para acelerar tu sitio
8. web.dev: Optimizar LCP con fetchpriority
9. web.dev: Usar formatos de imagen modernos
10. web.dev: Extraer CSS crítico
11. web.dev: Caché de avance/retroceso
12. web.dev: Speculation Rules API