La lista de verificación definitiva de Core Web Vitals (2026)

Table of Contents!

• El checklist definitivo de Core Web Vitals
• Checklist de optimización de Core Web Vitals
  • Optimiza imágenes
  • Optimiza las fuentes web
  • Optimiza los scripts
  • Optimiza los estilos
  • Optimiza los resource hints
  • Optimiza los iconos
  • Optimiza los tiempos de respuesta del servidor
  • Optimiza la interactividad
  • Monitoreo de Core Web Vitals
  • Optimiza la ruta crítica de renderizado
  • Optimiza el consentimiento de cookies
  • Optimiza las Single Page Applications
  • Evita un tamaño de DOM excesivo
  • Optimiza las peticiones a la API
  • Optimiza los widgets de chat
  • Optimiza el rendimiento del service worker
  • Optimiza el contenido de vídeo

Optimiza imágenes

Las imágenes grandes en el viewport visible se convertirán, la mayoría de las veces, en el elemento Largest Contentful Paint. Optimizar imágenes es una de las acciones de mayor impacto que puedes tomar para el LCP. Usa estos puntos del checklist de Core Web Vitals para mejorar la velocidad de las imágenes. Para la estrategia completa, lee nuestra guía sobre cómo optimizar la imagen LCP.

• Redimensiona las imágenes para que coincidan con las dimensiones máximas en pantalla: Esto asegura que nunca se desperdicien bytes descargando imágenes más grandes que su tamaño máximo en pantalla. Combina esta práctica con imágenes responsivas para tamaños de pantalla más pequeños. Servir imágenes del tamaño correcto puede reducir los tamaños de archivo de imagen en un 50% o más sin pérdida visible de calidad.
• Usa lazy loading para imágenes debajo del pliegue: El lazy loading retrasa la carga de imágenes fuera del viewport hasta que entran en la vista al hacer scroll, mejorando el First Contentful Paint (FCP) y la velocidad general de carga de la página. Nunca apliques lazy loading a la imagen LCP, ya que esto la retrasará significativamente.
• Precarga imágenes visualmente importantes como el elemento LCP: La precarga instruye al navegador a obtener imágenes críticas antes que el resto del contenido, priorizando el LCP. Usa <link rel="preload" as="image"> combinado con fetchpriority="high" para los mejores resultados. Esto es especialmente importante cuando la imagen LCP se referencia desde CSS o se carga mediante JavaScript.
• Establece width y height: Definir las dimensiones de la imagen por adelantado previene los layout shifts causados por el navegador esperando a que carguen las imágenes. Esto mejora el CLS. Los navegadores modernos usan los atributos width y height para calcular la relación de aspecto antes de que la imagen haya cargado, reservando la cantidad de espacio correcta.
• Usa formatos de imagen modernos como WebP o AVIF: Estos formatos ofrecen tamaños de archivo más pequeños en comparación con JPEG o PNG manteniendo una calidad similar, resultando en tiempos de carga más rápidos. WebP típicamente logra archivos un 25-34% más pequeños que JPEG, mientras que AVIF puede reducir el tamaño del archivo hasta en un 50%. Usa el elemento <picture> con fallbacks de formato para máxima compatibilidad del navegador.
• Usa lazy loading nativo y desactiva el lazy loading basado en JavaScript: El lazy loading retrasa la carga de imágenes fuera del viewport hasta que entran en la vista al hacer scroll. El lazy loading nativo ofrecido por los navegadores mediante el atributo loading="lazy" es generalmente más eficiente que depender de JavaScript para esta tarea, ya que no requiere parseo o ejecución de scripts adicionales.
• Usa imágenes responsivas con srcset: Este atributo especifica diferentes versiones de imagen para varios tamaños de pantalla, asegurando que el navegador entregue la imagen óptima para el dispositivo del usuario, reduciendo descargas grandes innecesarias. Combina srcset con el atributo sizes para un control preciso.
• Añade decoding="async": El atributo decoding="async" evita que el navegador bloquee otro contenido mientras decodifica una imagen. Esto permite al motor de renderizado seguir pintando otros elementos mientras la decodificación de la imagen ocurre en paralelo.
• Elimina los metadatos de las imágenes: Los metadatos como los datos EXIF incrustados en las imágenes pueden añadir bytes innecesarios. Eliminar esta información puede reducir el tamaño del archivo sin afectar la calidad de la imagen. Herramientas como ImageOptim, Squoosh o Sharp pueden automatizar la eliminación de metadatos como parte de tu proceso de build.
• Evita las imágenes de fondo en CSS para los elementos LCP: El navegador descubre las imágenes de fondo referenciadas en CSS más tarde que los elementos <img> en HTML. Si debes usar una imagen de fondo como el elemento LCP, precárgala con una etiqueta <link rel="preload"> para asegurar un descubrimiento temprano. Aprende más sobre el retraso de carga de recursos del LCP.

Optimiza las fuentes web

Las fuentes web pueden retrasar el First Contentful Paint, causar layout shifts y competir por los recursos tempranos de ancho de banda. Usa este checklist para asegurar una experiencia fluida con las fuentes web. Para mejores prácticas de alojamiento de fuentes, lee nuestra guía sobre cómo autohospedar Google Fonts.

• Usa font-display: swap para un primer pintado más rápido: Establece la propiedad font-display en swap en tus declaraciones @font-face. Esto asegura que el navegador muestre una fuente fallback inmediatamente mientras carga la fuente web en segundo plano. Una vez que la fuente está lista, la intercambia sin problemas. Lee más sobre cómo asegurar que el texto permanezca visible durante la carga de la fuente web.
• Usa font-display: optional combinado con precarga para eliminar el layout shift causado por las fuentes: Combinar font-display: optional con precarga ofrece un equilibrio entre velocidad y posibles layout shifts. El valor optional oculta el texto brevemente (unos 100ms) antes de usar una fuente fallback. La precarga instruye al navegador a obtener la fuente web temprano, minimizando el tiempo que se pasa en fuentes fallback y reduciendo los layout shifts.
• Usa descriptores de font-face para hacer que la fuente fallback coincida con las dimensiones de la fuente web: Esto asegura un CLS mínimo cuando entra la fuente web. Al especificar métricas similares usando size-adjust, ascent-override, descent-override y line-gap-override para la fuente fallback, puedes evitar que el contenido salte mientras la fuente carga.
• Haz subset de las fuentes para incluir solo los caracteres necesarios: Reduce el tamaño del archivo de la fuente haciendo subset para incluir solo los caracteres necesarios para tu contenido. Herramientas como Font Squirrel, pyftsubset o glyphhanger pueden ayudar a generar subsets. Una fuente con el set completo de caracteres latinos a menudo se puede reducir de más de 100KB a menos de 20KB con un subsetting adecuado.
• Limita el número de pesos y estilos de fuente: Evita cargar variaciones excesivas de fuentes. Limítate a un máximo de 2 fuentes críticas (usualmente precargadas) y 2 fuentes de carga tardía (cargadas después del renderizado inicial). Cada peso de fuente adicional añade de 15 a 50KB de tamaño de descarga.

Optimiza los scripts

Los scripts pueden causar problemas de Interaction to Next Paint, desencadenar Cumulative Layout Shifts o retrasar el Largest Contentful Paint. Incluso los scripts tempranos optimizados y relativamente inofensivos pueden competir por recursos y retrasar las métricas de pintado (LCP y FCP). Para una guía completa, lee 14 métodos para diferir JavaScript.

• Elimina el JavaScript innecesario: Identifica y elimina el código JavaScript no usado para minimizar la cantidad de código que necesita descargarse y ejecutarse. Usa la pestaña Coverage en Chrome DevTools para encontrar código no usado. Eliminar código muerto reduce tanto el tiempo de descarga como el procesamiento del main thread.
• Prioriza los scripts según su función e importancia: Los scripts que hacen cambios grandes en el viewport visible deben ser render blocking. Los scripts importantes deben ser diferidos o cargados asíncronamente. Los scripts secundarios deben cargar cuando el navegador esté inactivo (idle). Lee nuestra guía de priorización de recursos para una estrategia detallada.
• Code splitting y lazy loading: Divide los bundles grandes de JavaScript en chunks más pequeños y cárgalos solo cuando se necesiten. Esto reduce el tiempo de carga inicial. Los bundlers modernos como webpack, Rollup y esbuild soportan code splitting automático basado en imports dinámicos.
• Minifica y recompila los archivos JavaScript: Siempre minifica y recompila tus archivos JavaScript con una herramienta de minificación como SWC, Terser o esbuild. La minificación típicamente reduce el tamaño del archivo JavaScript entre un 30% y un 50%.
• Limita los scripts de terceros: Los scripts de terceros pueden introducir una sobrecarga de rendimiento significativa. Evalúa su necesidad y explora alternativas si es posible. Cada script de terceros añade búsquedas DNS, sobrecarga de conexión y tiempo de procesamiento en el main thread. Audita los scripts de terceros regularmente usando el panel Network de Chrome DevTools.
• Carga los scripts de terceros asíncronamente: Debido a la naturaleza impredecible de los scripts de terceros, nunca permitas que un tercero bloquee el renderizado. Usa el atributo async o defer en todas las etiquetas de scripts de terceros.
• Monitorea el rendimiento de los scripts de terceros: Usa la API Long Animation Frames (LoAF) o CoreDash para rastrear el impacto en el mundo real de los scripts de terceros sobre el INP y el LCP. Establece presupuestos de rendimiento (performance budgets) para el JavaScript de terceros y revísalos regularmente.

Optimiza los estilos

Los estilos son render blocking por defecto. Optimizar los estilos resultará en métricas de pintado optimizadas. Sigue el checklist para mejorar el rendimiento de los estilos de tu página web. El CSS render blocking impacta directamente tanto en el First Contentful Paint como en el retraso de renderizado del elemento LCP. Para consejos sobre cómo limpiar estilos no usados, lee cómo eliminar CSS no usado.

• Minifica los archivos CSS: Elimina los caracteres innecesarios como espacios en blanco, comentarios y formato de los archivos CSS. Los archivos minificados tienen un tamaño menor, lo que resulta en tiempos de carga más rápidos. Herramientas como cssnano, PostCSS o la compresión integrada de tu preprocesador CSS pueden automatizar esto.
• Elimina el CSS no usado: Identifica y elimina el código CSS que no se usa en tus páginas web. Esto reduce la cantidad de datos que el navegador necesita descargar y parsear, mejorando el rendimiento. Herramientas como PurgeCSS o la pestaña Coverage de Chrome DevTools ayudan a identificar el CSS no usado.
• Incluye el CSS crítico inline: Sirve los estilos esenciales para renderizar el contenido inicial de la página directamente en el HTML para mejorar las métricas de pintado. Considera servir CSS crítico solo a los nuevos visitantes y usar hojas de estilo externas cacheadas para los visitantes recurrentes. Esta técnica puede reducir el FCP eliminando el round trip necesario para obtener una hoja de estilo externa.
• Distribuye equitativamente el tamaño de los archivos CSS: Aunque pueda parecer eficiente combinar todo el CSS en un solo archivo, los archivos excesivamente grandes pueden ralentizar los tiempos de descarga. Considera dividir el CSS en archivos más pequeños con una distribución de tamaño más uniforme (10 a 15KB cada uno) para optimizar la carga y permitir al navegador procesar los estilos incrementalmente.
• Carga asíncronamente los estilos fuera de pantalla: Para los estilos que se aplican a elementos fuera del viewport inicial, considera usar la carga asíncrona mediante el patrón media="print" onload="this.media='all'". Esto permite al navegador obtener estos estilos en paralelo con otros recursos sin bloquear el renderizado inicial de la página.

Optimiza los resource hints

Los resource hints ayudan a priorizar las descargas de recursos críticos. Los recursos precargados suelen ponerse en cola para su descarga y estar disponibles para el navegador mucho antes de lo que estarían sin precarga. El uso efectivo de los resource hints puede reducir significativamente el retraso de carga de recursos del LCP. Para una implementación avanzada, lee sobre 103 Early Hints.

• Elimina los resource hints no críticos: Elimina los hints de precarga para los recursos que no son esenciales para la carga inicial de la página. Esto previene descargas o conexiones de red innecesarias que compiten por esos recursos tempranos y limitados en ancho de banda. Cada precarga innecesaria consume ancho de banda que podría usarse para recursos críticos.
• Preconecta a los dominios críticos: Establece conexiones con dominios importantes (como CDNs o proveedores de fuentes) de forma temprana. Esto acelera la descarga de recursos críticos desde esos dominios completando los handshakes de DNS, TCP y TLS por adelantado. Usa <link rel="preconnect" href="https://example.com"> para orígenes de terceros críticos.
• Considera DNS prefetch como alternativa a preconnect: Similar a preconnect, DNS prefetch da un hint al navegador sobre posibles conexiones. Sin embargo, preconnect prioriza establecer la conexión completa, mientras que DNS prefetch solo le dice al navegador que resuelva el nombre de dominio por adelantado. Usa <link rel="dns-prefetch"> cuando la sobrecarga de la conexión completa de preconnect no se justifique.
• Precarga el elemento LCP: El LCP mide cuánto tarda en cargar el contenido principal. Precargar el elemento LCP instruye al navegador a priorizar la descarga de este recurso crítico, acelerando el tiempo que tardan los usuarios en ver el contenido principal. Esto es especialmente importante para imágenes referenciadas en CSS o cargadas mediante JavaScript.
• Precarga las fuentes críticas: Precargar las fuentes críticas asegura que el navegador las obtenga temprano, previniendo retrasos al mostrar texto y mejorando los cumulative layout shifts causados por el intercambio de fuentes. Usa <link rel="preload" as="font" type="font/woff2" crossorigin> para tus tipografías más importantes.
• Prefiere 103 Early Hints para los resource hints: El código de estado HTTP 103 Early Hints permite al servidor enviar resource hints antes de que la respuesta completa esté lista. Si tu servidor no soporta 103, usa encabezados de respuesta Link en su lugar. Si los encabezados no están disponibles, añade elementos <link> al <head> de la página como fallback. Una entrega más temprana de los hints significa un descubrimiento de recursos más rápido.
• Precarga las fuentes antes de que los archivos CSS las descubran: Las fuentes referenciadas en CSS solo se descubren después de que el archivo CSS se ha descargado y parseado. Al precargar fuentes directamente en el <head> del HTML, eliminas la dependencia del parseo de CSS y permites que las fuentes carguen en paralelo, reduciendo tanto el FCP como el riesgo de layout shift.

Optimiza los iconos

Los iconos pueden añadir un peso significativo a tu página si no están optimizados. Los iconos SVG grandes en línea inflan tu HTML, mientras que las fuentes de iconos a menudo incluyen miles de glifos no usados. Optimizar los iconos impacta tanto al LCP (peso reducido de HTML/CSS) como al CLS (reserva adecuada de dimensiones).

• Evita los iconos SVG en línea en el HTML: Incluir en línea iconos SVG grandes puede aumentar el tamaño de tu código HTML y ralentizar la carga de la página. Considera métodos alternativos como servirlos como archivos separados o usar fuentes de iconos (con precaución) para minimizar el tamaño del HTML y permitir el almacenamiento en caché del navegador para los iconos. Un sprite sheet SVG externo es a menudo el mejor equilibrio entre rendimiento y flexibilidad.
• Evita las fuentes de iconos grandes: Nunca uses sets de iconos grandes como Font Awesome en su totalidad. Haz subsetting para crear fuentes de iconos optimizadas o SVGs individuales para reducir el tamaño general de la página web y mejorar la velocidad de carga. Un set completo de Font Awesome puede superar los 100KB, mientras que un subset con 20 iconos puede pesar menos de 5KB.
• Reserva el width y height para los iconos: De manera similar a las imágenes, especificar el width y height para los iconos ayuda al navegador a reservar espacio y previene los layout shifts mientras cargan. Usa los atributos width y height en los elementos SVG o establece dimensiones explícitas en CSS.
• Desprioriza los sets de iconos no críticos: Si los iconos no son críticos para el renderizado inicial de tu página, considera cargarlos con menor prioridad. Esto asegura que el contenido esencial cargue primero y minimiza el impacto en las métricas de Core Web Vitals. Usa lazy loading o carga asíncronamente las hojas de estilo de los iconos después del primer pintado.

Optimiza los tiempos de respuesta del servidor

Los tiempos de respuesta del servidor, medidos por el Time to First Byte (TTFB), tienen una relación directa con todas las métricas de pintado. Una respuesta lenta del servidor retrasa todo lo que le sigue. Para estrategias de optimización detalladas, explora nuestras guías sobre cómo diagnosticar problemas de TTFB y cómo configurar Cloudflare para el rendimiento.

• Usa un proveedor de alojamiento rápido y fiable: Un proveedor de alojamiento rápido con una infraestructura sólida puede mejorar significativamente los tiempos de respuesta del servidor y el rendimiento general del sitio web. Compara proveedores de alojamiento usando mediciones de TTFB del mundo real, no afirmaciones de marketing sintéticas.
• Optimiza el código del lado del servidor y las consultas a la base de datos: Registra frecuentemente la ejecución del código y el tiempo de las consultas a la base de datos para encontrar cuellos de botella y mejorar la velocidad general. Usa herramientas de perfilado de consultas y monitoreo de rendimiento de aplicaciones (APM) para identificar endpoints lentos.
• Implementa estrategias de caché: Utiliza la caché del navegador y la caché del lado del servidor para almacenar datos accedidos frecuentemente, reduciendo la necesidad de obtener datos repetidamente y mejorando los tiempos de carga. La caché de página completa puede reducir el TTFB de segundos a menos de 100ms. Aprende más sobre la optimización de la duración de la caché.
• Renderizado en el cliente o en el edge para personalización: Considera el renderizado en el cliente o en el edge de pequeñas personalizaciones como el conteo del carrito, el estado de sesión o cambios menores en el menú para mantener la funcionalidad de la caché de página completa. Esto evita invalidar la caché (cache busting) de toda la página por elementos dinámicos menores.
• Optimiza las configuraciones del servidor: Revisa y ajusta la configuración de tu servidor web para el rendimiento. Esto incluye la configuración de keep-alive de la conexión, el recuento de procesos worker, la asignación de memoria y los valores de timeout. Los servidores mal configurados pueden desperdiciar recursos y aumentar los tiempos de respuesta.
• Usa una Content Delivery Network (CDN): Una CDN distribuye el contenido estático de tu sitio web a través de múltiples nodos edge (servidores). Esto reduce la distancia física que los usuarios necesitan para acceder a tu contenido, llevando a tiempos de carga más rápidos para audiencias globales. Además, las CDNs suelen estar mejor configuradas que tu propio servidor. Lee nuestra guía sobre cómo configurar Cloudflare para un recorrido de configuración práctico.
• Reduce el procesamiento del lado del servidor: Minimiza la cantidad de trabajo que hace tu servidor por cada petición. Precalcula operaciones costosas, usa algoritmos eficientes y mueve el procesamiento no esencial a tareas en segundo plano. Analiza el ciclo de vida de las peticiones de tu aplicación para encontrar y eliminar pasos de procesamiento innecesarios.
• Usa HTTP/3: HTTP/3 es la última versión del Hypertext Transfer Protocol. HTTP/3 es más rápido y más eficiente que HTTP/2 y significativamente más rápido que HTTP/1.1. Actualizar a HTTP/3 puede mejorar los tiempos de carga generales de la página y potencialmente las tres métricas de Core Web Vitals (LCP, INP, CLS). Aprende más sobre la optimización de la duración de la conexión.
• Configura los encabezados Server-Timing: Estos encabezados proporcionan información detallada sobre cuánto tardan en procesarse diferentes partes de tu página en el servidor. Con estos datos, puedes identificar cuellos de botella y áreas de mejora, centrándote específicamente en mejorar el Largest Contentful Paint (LCP). Los encabezados Server-Timing son visibles en el panel Network de Chrome DevTools y pueden ser capturados por herramientas RUM como CoreDash.
• Registra las consultas lentas a la base de datos y optimízalas regularmente: Activa el registro de consultas lentas en tu base de datos (MySQL, PostgreSQL, MongoDB) y revisa los registros semanalmente. La optimización de índices, la reestructuración de consultas y la adición de capas de caché para consultas frecuentes pueden reducir drásticamente el TTFB.
• Usa compresión GZIP o Brotli: GZIP, o el más reciente Brotli, ofrece compresión al vuelo de recursos basados en texto (HTML, CSS, JavaScript) antes de la transmisión, resultando en tamaños de archivo aproximadamente un 70% más pequeños. Brotli típicamente logra una compresión de un 15 a un 20% mejor que GZIP. Tamaños de archivo más pequeños se traducen en tiempos de carga más rápidos.

Optimiza la interactividad

El Interaction to Next Paint (INP) mide qué tan rápido responde tu sitio a las interacciones del usuario. La mala interactividad a menudo es causada por tareas largas de JavaScript que bloquean el main thread. Para un desglose completo de las tres fases del INP, lee nuestras guías sobre retraso de entrada, tiempo de procesamiento y retraso de presentación.

• Implementa un patrón idle-until-urgent para scripts costosos: Este enfoque implica priorizar tareas críticas y diferir la ejecución de JavaScript no esencial hasta que el main thread del navegador esté inactivo. Esto asegura que tareas críticas como el renderizado y las interacciones del usuario no se vean bloqueadas por scripts de larga duración. Usa requestIdleCallback para programar trabajo no urgente. Aprende más sobre la optimización del tiempo de procesamiento.
• Divide los long tasks haciendo yielding al main thread: Las tareas complejas de JavaScript pueden bloquear el main thread, retrasando la capacidad de respuesta. Dividir estas tareas en chunks más pequeños y hacer yielding al main thread entre chunks permite al navegador manejar interacciones del usuario y mantener una experiencia de usuario fluida. Usa scheduler.yield() (donde sea soportado) o setTimeout(0) para dividir un long task. Lee nuestra guía sobre cómo mejorar el INP abandonando el scroll por JavaScript.
• Proporciona feedback inmediato después de la entrada (input): Los usuarios esperan una respuesta inmediata tras interactuar con tu sitio web. Proporciona señales visuales o reconoce la entrada del usuario rápidamente, incluso mientras un long task se procesa en segundo plano. Usa transiciones CSS y la pseudo-clase :active para feedback visual instantáneo. Esto ayuda a mantener una sensación de interactividad y evita que los usuarios sientan que el sitio web está congelado.
• Usa event listeners pasivos para scroll y touch: Añade { passive: true } a los event listeners de scroll y touch. Los listeners pasivos le dicen al navegador que el handler nunca llamará a preventDefault(), permitiéndole empezar a hacer scroll inmediatamente sin esperar a JavaScript. Esto es especialmente impactante en dispositivos móviles y mejora directamente el INP para interacciones adyacentes al scroll.

Monitoreo de Core Web Vitals

Monitorear tus Core Web Vitals continuamente es esencial para detectar regresiones a tiempo y validar que las optimizaciones tienen el impacto esperado. Usa una combinación de herramientas de laboratorio, field data y monitoreo de usuarios reales para obtener una imagen completa.

• Revisa Lighthouse regularmente: Lighthouse es una herramienta de auditoría de código abierto y gratuita de Google que te ayuda a identificar problemas de rendimiento en tus páginas web. Aunque Lighthouse no mide los Core Web Vitals directamente en un contexto de usuario real, es una excelente herramienta para probar y comparar periódicamente tu sitio web bajo condiciones reguladas y estandarizadas. Ejecuta Lighthouse en pipelines de CI/CD para detectar regresiones antes del despliegue.
• Revisa los datos históricos de CrUX regularmente: CrUX (Chrome User Experience Report) es un dataset público de Google que proporciona datos de rendimiento del mundo real. CrUX es la fuente de datos usada por Google para determinar si superas o no los Core Web Vitals. Usa los datos históricos para detectar regresiones rápidamente. Puedes acceder a los datos de CrUX mediante PageSpeed Insights, el Dashboard de CrUX o la API de CrUX.
• Configura el tracking RUM: RUM (Real User Monitoring) implica rastrear las experiencias de usuarios reales en tu sitio web. Las herramientas RUM recogen datos sobre cuánto tardan realmente las páginas en cargar para tus visitantes en diferentes ubicaciones y en varios dispositivos. Esto proporciona valiosos insights sobre el rendimiento en el mundo real, complementando los datos simulados de Lighthouse y CrUX. Recomendamos CoreDash como tu herramienta de tracking RUM para obtener datos detallados de atribución de Core Web Vitals.
• Establece presupuestos de rendimiento: Los presupuestos de rendimiento (performance budgets) establecen objetivos de rendimiento específicos (por ejemplo, LCP por debajo de 2,5 segundos, INP por debajo de 200ms, CLS por debajo de 0,1) para diferentes métricas. Estos actúan como benchmarks para guiar tus esfuerzos de optimización. Revisar regularmente tu rendimiento frente a estos presupuestos te ayuda a identificar áreas que necesitan atención inmediata y a priorizar optimizaciones.
• Usa segmentación: Usa la segmentación para rastrear tus tipos de visitantes más valiosos y diferentes tipos de páginas. Grandes cantidades de tráfico podrían de otra manera enmascarar problemas de rendimiento que impactan específicamente a estos grupos vitales. Segmenta por tipo de dispositivo, velocidad de conexión, geografía y plantilla de página para descubrir problemas ocultos.

Optimiza la ruta crítica de renderizado

La ruta crítica de renderizado es la secuencia de pasos que el navegador toma para convertir HTML, CSS y JavaScript en píxeles visibles. Optimizar esta ruta mejora directamente el First Contentful Paint y el retraso de renderizado del elemento LCP. Lee también cómo evitar un tamaño de DOM excesivo.

• Minimiza el número de recursos críticos: Cada recurso render blocking (CSS y JavaScript síncrono) debe descargarse y procesarse antes de que el navegador pueda pintar. Reduce el número de recursos críticos difiriendo scripts no esenciales y cargando de forma asíncrona las hojas de estilo no críticas.
• Optimiza el orden de carga de recursos: Asegura que el CSS crítico y las fuentes carguen primero, seguidos por imágenes arriba del pliegue (above-the-fold), y luego los scripts diferidos. Usa el atributo fetchpriority y los hints de priorización de recursos para comunicar la importancia al navegador.
• Reduce la profundidad del árbol DOM: Los árboles DOM profundamente anidados aumentan el tiempo de cálculo de estilos y el trabajo de layout. Apunta a una profundidad máxima de 32 niveles y a menos de 1.500 elementos DOM totales donde sea posible. Una estructura DOM más plana mejora tanto el rendimiento de pintado como el retraso de presentación del INP.
• Prefiere clases e IDs sobre etiquetas de elementos y atributos: En lugar de p.important, usa .important. Esto reduce la necesidad del navegador de buscar a través de todos los elementos de ese tipo para emparejar estilos, resultando en un recálculo de estilos más rápido.
• Evita anidar selectores profundamente: Cuanto más profundo anidas los selectores CSS, más cálculos necesita realizar el navegador. Intenta reestructurar tu HTML para reducir el anidamiento o usa clases más específicas cerca del elemento. Limita la profundidad del selector a un máximo de 3 niveles.
• Minimiza los selectores descendientes: Selectores como .container > .content obligan al navegador a comprobar cada elemento dentro del contenedor. Si es posible, usa una clase más directa en el elemento contenido para un emparejamiento de selectores más rápido.
• Consolida selectores con los mismos estilos: Si múltiples elementos comparten los mismos estilos, agrúpalos en una sola clase o usa una convención de nomenclatura BEM (Block Element Modifier) para un mejor mantenimiento y una salida CSS más pequeña.

Optimiza el consentimiento de cookies

Los banners de consentimiento de cookies son requeridos por el GDPR y regulaciones similares, pero pueden impactar significativamente en los Core Web Vitals si no se implementan con cuidado. Un banner de consentimiento mal cargado puede retrasar el LCP, causar CLS y aumentar el INP. Para más detalles, lee sobre cómo optimizar widgets de terceros para Core Web Vitals.

• Considera el consentimiento de cookies del lado del servidor para páginas dinámicas: Para páginas renderizadas dinámicamente en el servidor, implementar una solución del lado del servidor que renderice el banner de consentimiento en la respuesta HTML inicial suele ser más rápido que cargar una solución separada basada en JavaScript. Esto elimina la petición de red adicional y la sobrecarga de evaluación del script.
• Carga de forma asíncrona los scripts de consentimiento de cookies en páginas cacheadas: Para páginas cacheadas, carga asíncronamente tu script de consentimiento de cookies y considera añadir fetchpriority="high" al script para asegurar que cargue lo suficientemente temprano como para mostrarse antes de la interacción del usuario.
• Mantén el texto de consentimiento corto para evitar interferencias con el LCP: Los textos largos de aviso de cookies pueden apropiarse del elemento LCP porque el navegador considera el bloque de texto visible más grande como un posible candidato a LCP. Considera escribir textos más cortos o dividir los textos en múltiples párrafos con un área visible menor.
• Autohospeda los scripts de notificación de cookies: Almacena en caché y autohospeda los scripts y las hojas de estilo de notificación de cookies siempre que sea posible. Esto elimina las búsquedas DNS y la sobrecarga de conexión a plataformas de gestión de consentimiento de terceros y te da control total sobre el comportamiento de carga.

Optimiza las Single Page Applications

Las Single Page Applications (SPAs) construidas con React, Vue, Angular o frameworks similares enfrentan desafíos únicos de Core Web Vitals. El renderizado en el cliente puede retrasar tanto el FCP como el LCP, mientras que la hidratación puede bloquear el INP.

• Siempre usa server-side rendering o prerenderizado: Las SPAs que dependen únicamente del renderizado en el cliente obligan al navegador a descargar, parsear y ejecutar JavaScript antes de que cualquier contenido sea visible. Usa SSR (Next.js, Nuxt, SvelteKit) o prerenderizado estático para servir HTML inicial que el navegador pueda pintar inmediatamente.
• Prefiere los prerenderizados estáticos sobre la generación dinámica: Los prerenderizados estáticos (generados en tiempo de build) son mucho más rápidos que los prerenderizados generados dinámicamente porque pueden servirse directamente desde una CDN sin ningún procesamiento del lado del servidor. Usa generación estática para páginas que no requieren datos por petición.
• Carga los scripts de terceros después de la hidratación: Durante la hidratación, el framework ya está consumiendo un tiempo significativo en el main thread para hacer que la página sea interactiva. Cargar scripts de terceros simultáneamente agrava el problema y empeora el retraso de entrada. Difiere todos los scripts no esenciales hasta que termine el proceso de hidratación.

Evita un tamaño de DOM excesivo

Un DOM grande (más de 1.500 elementos o una profundidad que exceda los 32 niveles) aumenta el uso de memoria, ralentiza los cálculos de estilos y causa reflows de layout costosos. Esto impacta directamente tanto en el retraso de presentación del INP como en las métricas de pintado. Lee cómo arreglar un tamaño de DOM excesivo.

• Reduce los elementos DOM innecesarios: Audita tu HTML en busca de elementos envoltorios (wrappers) que no tengan ningún propósito estructural o de estilo. Reemplaza las estructuras <div> profundamente anidadas con elementos HTML semánticos. Considera virtualizar listas largas con librerías como react-window o virtual-scroller para mantener pequeño el DOM activo.
• Usa selectores de JavaScript y CSS eficientes: Los selectores CSS complejos y las consultas DOM de JavaScript (como querySelectorAll con patrones amplios) se vuelven exponencialmente más lentos a medida que crece el tamaño del DOM. Usa selectores de clases específicos y limita el alcance de las consultas DOM a subárboles siempre que sea posible.
• Usa content-visibility: auto para contenido fuera de pantalla: La propiedad CSS content-visibility: auto le dice al navegador que omita el renderizado de elementos fuera de pantalla hasta que entren en la vista al hacer scroll. Esto puede reducir drásticamente el trabajo de renderizado inicial para páginas con secciones de contenido largas.

Optimiza las peticiones a la API

Las peticiones a la API que bloquean el renderizado o retrasan el contenido pueden impactar negativamente en el LCP y el TTFB. La obtención de datos en el lado del cliente es una fuente común de LCP lento en single page applications.

• Minimiza el número de peticiones a la API: Cada petición a la API se suma al tiempo de carga general de la página. Evalúa la funcionalidad de tu sitio web e identifica oportunidades para reducir el número de peticiones a la API necesarias para renderizar el contenido inicial. Técnicas como data batching (combinar múltiples peticiones en una) y GraphQL pueden reducir los round trips.
• Usa APIs eficientes y optimizadas: El diseño y la implementación de las APIs pueden impactar en el rendimiento. Asegúrate de que usas APIs bien diseñadas que están optimizadas para la velocidad y la eficiencia. Implementa mecanismos de caché en el lado de la API para reducir los tiempos de respuesta para datos solicitados frecuentemente.
• Precarga las peticiones a la API críticas: De manera similar a la precarga de recursos críticos como imágenes, precargar peticiones a la API esenciales puede mejorar significativamente el rendimiento percibido. Usa <link rel="preload" as="fetch"> para instruir al navegador a obtener las APIs críticas temprano, minimizando retrasos cuando se necesitan para renderizar el contenido inicial. Lee nuestra guía de priorización de recursos para más técnicas.

Optimiza los widgets de chat

Los widgets de chat son una causa común de layout shifts y pueden incluso causar problemas con el LCP si se cargan temprano. Para un enfoque paso a paso, lee cómo implementar un widget de chat con Core Web Vitals perfectos.

• Carga los widgets de chat después de que el contenido principal haya cargado: Nadie en la historia de Internet ha necesitado nunca chatear antes de que el contenido principal de la página haya cargado. Difiere la inicialización del widget de chat hasta que la página haya terminado su renderizado inicial, usando requestIdleCallback o un trigger basado en el scroll.
• Previene los layout shifts de los widgets de chat: Si los widgets de chat causan un layout shift, usualmente es buena idea ocultarlos con opacity: 0 hasta que se hayan renderizado completamente en la página. Esto permite que el widget haga su layout en segundo plano sin causar que el contenido visible salte. Usa una transición CSS para mostrar el widget suavemente.
• Elige proveedores de widgets de chat ligeros: Compara opciones. Algunos widgets de chat son mucho más ligeros y causan menos problemas de Core Web Vitals que otros. Compara el tamaño del bundle de JavaScript, el número de peticiones de red y el impacto en el INP de diferentes proveedores antes de comprometerte.

Optimiza el rendimiento del service worker

Los service workers pueden mejorar significativamente el rendimiento de las visitas recurrentes almacenando assets e incluso respuestas completas de páginas en caché, reduciendo el TTFB para los visitantes que regresan. Sin embargo, un service worker mal implementado puede de hecho ralentizar la navegación. Aprende más sobre la optimización de la duración de la caché.

• Almacena en caché los assets críticos en el service worker: Usa una estrategia cache-first para assets estáticos como CSS, JavaScript, fuentes e imágenes. Esto permite a los visitantes recurrentes cargar tu sitio casi instantáneamente desde la caché local. Precarga los recursos más importantes durante el evento install del service worker.
• Optimiza el código del service worker: Mantén tu service worker ligero y eficiente. Evita la lógica de enrutamiento compleja, el uso excesivo de event.waitUntil() y los grandes manifiestos de precarga que ralentizan la instalación. Usa el patrón stale-while-revalidate para recursos que cambian frecuentemente pero que no requieren frescura inmediata.

Optimiza el contenido de vídeo

Los elementos de vídeo pueden convertirse en el elemento LCP si son el contenido visible más grande en el viewport. Los vídeos grandes y no optimizados también compiten por ancho de banda con otros recursos críticos.

• Comprime y optimiza los vídeos: Usa códecs modernos como H.264, VP9 o AV1 con configuraciones de calidad adecuadas. Reduce la resolución del vídeo para que coincida con el tamaño máximo de visualización. Un vídeo que aparece con 400px de ancho no necesita estar codificado a 1920px. Usa la codificación en dos pasadas para obtener la mejor relación entre calidad y tamaño de archivo.
• Usa lazy loading para vídeos: Para vídeos debajo del pliegue, usa el atributo loading="lazy" en los elementos <iframe> o retrasa la carga del vídeo con la Intersection Observer API. Reemplaza los vídeos de fondo en reproducción automática con imágenes poster y carga el vídeo solo cuando el usuario hace scroll cerca de él.
• Aloja los vídeos en una CDN rápida: Los archivos de vídeo son grandes y se benefician enormemente de la distribución en CDN. Usa una CDN dedicada de vídeo o un servicio de alojamiento (como Cloudflare Stream, Mux o Bunny.net) que proporcione streaming con bitrate adaptativo, distribución geográfica y entrega optimizada.
• Usa imágenes poster para los elementos de vídeo: Siempre establece un atributo poster en los elementos <video>. La imagen poster le da al navegador algo que pintar inmediatamente mientras carga el vídeo, lo que puede servir como el elemento LCP. Optimiza la imagen poster como cualquier otra imagen LCP.