La Lista de Verificación Definitiva de Core Web Vitals (2026)

Table of Contents!

• La Lista de Verificación Definitiva de Core Web Vitals
• Lista de Verificación para la Optimización de Core Web Vitals
  • Optimizar Imágenes
  • Optimizar Fuentes Web
  • Optimizar Scripts
  • Optimizar Estilos
  • Optimizar Resource Hints
  • Optimizar Iconos
  • Optimizar los Tiempos de Respuesta del Servidor
  • Optimizar la Interactividad
  • Monitoreo de Core Web Vitals
  • Optimizar la Ruta Crítica de Renderizado
  • Optimizar el Consentimiento de Cookies
  • Optimizar Aplicaciones de Página Única
  • Evitar un Tamaño Excesivo del DOM
  • Optimizar Solicitudes API
  • Optimizar Widgets de Chat
  • Optimizar el Rendimiento del Service Worker
  • Optimizar Contenido de Video

Optimizar 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 las imágenes es una de las acciones de mayor impacto que puedes tomar para mejorar LCP. Usa estos elementos de la lista de verificación 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.

• Redimensionar 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 responsive para pantallas más pequeñas. Servir imágenes correctamente dimensionadas puede reducir el tamaño de los archivos de imagen en un 50% o más sin pérdida visible de calidad.
• Usar lazy loading para las imágenes debajo del pliegue: El lazy loading retrasa la carga de imágenes fuera del viewport hasta que se desplazan a la vista, mejorando 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.
• Precargar imágenes visualmente importantes como el elemento LCP: La precarga indica al navegador que descargue recursos críticos antes del resto del contenido, priorizando LCP. Usa <link rel="preload" as="image"> combinado con fetchpriority="high" para obtener los mejores resultados. Esto es especialmente importante cuando la imagen LCP está referenciada desde CSS o cargada mediante JavaScript.
• Establecer ancho y alto: Definir las dimensiones de las imágenes de antemano previene los cambios de diseño causados por la espera del navegador a que las imágenes se carguen. Esto mejora CLS. Los navegadores modernos usan los atributos de ancho y alto para calcular la relación de aspecto antes de que la imagen se haya cargado, reservando la cantidad correcta de espacio.
• Usar formatos de imagen modernos como WebP o AVIF: Estos formatos ofrecen tamaños de archivo más pequeños comparados con JPEG o PNG mientras mantienen una calidad similar, lo que resulta en tiempos de carga más rápidos. WebP normalmente logra archivos entre un 25-34% más pequeños que JPEG, mientras que AVIF puede reducir el tamaño del archivo hasta un 50%. Usa el elemento <picture> con fallbacks de formato para máxima compatibilidad con navegadores.
• Usar lazy loading nativo y desactivar el lazy loading basado en JavaScript: El lazy loading retrasa la carga de imágenes fuera del viewport hasta que se desplazan a la vista. 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 análisis o ejecución adicional de scripts.
• Usar imágenes responsive 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 innecesarias de gran tamaño. Combina srcset con el atributo sizes para un control preciso.
• Agregar decoding="async": El atributo decoding="async" evita que el navegador bloquee otro contenido mientras decodifica una imagen. Esto permite que el motor de renderizado continúe pintando otros elementos mientras la decodificación de la imagen ocurre en paralelo.
• Eliminar metadatos de las imágenes: Los metadatos como los datos EXIF incrustados en las imágenes pueden agregar 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 compilación.
• Evitar imágenes de fondo CSS para elementos LCP: Las imágenes de fondo referenciadas en CSS son descubiertas más tarde por el navegador que los elementos <img> en HTML. Si debes usar una imagen de fondo como elemento LCP, precárgala con una etiqueta <link rel="preload"> para asegurar su descubrimiento temprano. Aprende más sobre el retraso en la carga de recursos LCP.

Optimizar Fuentes Web

Las fuentes web pueden retrasar el First Contentful Paint, causar cambios de diseño y competir por recursos de ancho de banda tempranos. Usa esta lista de verificación para asegurar una experiencia fluida con las fuentes web. Para las mejores prácticas de alojamiento de fuentes, consulta nuestra guía sobre auto-alojar Google Fonts.

• Usar 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 de 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 fuentes web.
• Usar font-display: optional combinado con precarga para eliminar los cambios de diseño causados por las fuentes: Combinar font-display: optional con la precarga ofrece un equilibrio entre velocidad y posibles cambios de diseño. El valor optional oculta el texto brevemente (alrededor de 100ms) antes de usar una fuente de fallback. La precarga indica al navegador que descargue la fuente web tempranamente, minimizando el tiempo con fuentes de fallback y reduciendo los cambios de diseño.
• Usar descriptores de font-face para hacer que la fuente de fallback coincida con las dimensiones de la fuente web: Esto asegura un mínimo de CLS cuando la fuente web se intercambia. Al especificar métricas similares usando size-adjust, ascent-override, descent-override y line-gap-override para la fuente de fallback, puedes evitar que el contenido salte cuando la fuente se carga.
• Hacer subset de fuentes para incluir solo los caracteres necesarios: Reduce el tamaño del archivo de fuentes mediante subset para incluir solo los caracteres necesarios para tu contenido. Herramientas como Font Squirrel, pyftsubset o glyphhanger pueden ayudar a generar subsets. Un conjunto completo de caracteres latinos puede reducirse de más de 100KB a menos de 20KB con un subset adecuado.
• Limitar el número de pesos y estilos de fuentes: Evita cargar variaciones excesivas de fuentes. Limítate a un máximo de 2 fuentes críticas (generalmente precargadas) y 2 fuentes de carga tardía (cargadas después del renderizado inicial). Cada peso de fuente adicional añade entre 15 y 50KB de tamaño de descarga.

Optimizar Scripts

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

• Eliminar JavaScript innecesario: Identifica y elimina el código JavaScript no utilizado para minimizar la cantidad de código que necesita descargarse y ejecutarse. Usa la pestaña Coverage de Chrome DevTools para encontrar código no utilizado. Eliminar código muerto reduce tanto el tiempo de descarga como el procesamiento del hilo principal.
• Priorizar scripts según su función e importancia: Los scripts que hacen grandes cambios al viewport visible deben bloquear el renderizado. Los scripts importantes deben ser diferidos o cargados de forma asíncrona. Los scripts opcionales deben cargarse cuando el navegador esté inactivo. Consulta nuestra guía de priorización de recursos para una estrategia detallada.
• Code splitting y lazy loading: Divide los paquetes grandes de JavaScript en trozos más pequeños y cárgalos solo cuando sea necesario. Esto reduce el tiempo de carga inicial. Los empaquetadores modernos como webpack, Rollup y esbuild soportan la división automática de código basada en importaciones dinámicas.
• Minificar y recompilar 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 de los archivos JavaScript entre un 30 y un 50%.
• Limitar scripts de terceros: Los scripts de terceros pueden introducir una sobrecarga significativa de rendimiento. 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 del hilo principal. Audita los scripts de terceros regularmente usando el panel Network de Chrome DevTools.
• Cargar scripts de terceros de forma asíncrona: Debido a la naturaleza impredecible de los scripts de terceros, nunca permitas que el renderizado sea bloqueado por un tercero. Usa el atributo async o defer en todas las etiquetas de scripts de terceros.
• Monitorear el rendimiento de scripts de terceros: Usa la API de Long Animation Frames (LoAF) o CoreDash para rastrear el impacto real de los scripts de terceros en INP y LCP. Establece presupuestos de rendimiento para JavaScript de terceros y revísalos regularmente.

Optimizar Estilos

Los estilos bloquean el renderizado por defecto. Optimizar los estilos resultará en métricas de pintado optimizadas. Sigue la lista de verificación para mejorar el rendimiento de los estilos de tu página web. El CSS que bloquea el renderizado impacta directamente tanto en First Contentful Paint como en el retraso del renderizado del elemento LCP. Para consejos sobre la limpieza de estilos no utilizados, consulta cómo eliminar CSS no utilizado.

• Minificar archivos CSS: Elimina caracteres innecesarios como espacios en blanco, comentarios y formato de los archivos CSS. Los archivos minificados son más pequeños en tamaño, 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.
• Eliminar CSS no utilizado: 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 analizar, mejorando el rendimiento. Herramientas como PurgeCSS o la pestaña Coverage de Chrome DevTools ayudan a identificar CSS no utilizado.
• Incluir CSS crítico en línea: 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 visitantes nuevos y usar hojas de estilo externas en caché para visitantes recurrentes. Esta técnica puede reducir el FCP al eliminar el viaje de ida y vuelta necesario para obtener una hoja de estilo externa.
• Distribuir equitativamente los tamaños de 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 que el navegador procese los estilos de forma incremental.
• Cargar de forma asíncrona los estilos fuera de pantalla: Para los estilos que se aplican a elementos fuera del viewport inicial, considera usar 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.

Optimizar Resource Hints

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

• Eliminar resource hints no críticos: Elimina las indicaciones de precarga para recursos que no son esenciales para la carga inicial de la página. Esto previene descargas innecesarias o conexiones de red que compiten por esos recursos tempranos de ancho de banda limitado. Cada precarga innecesaria consume ancho de banda que podría usarse para recursos críticos.
• Preconectar a dominios críticos: Establece conexiones con dominios importantes (como redes de distribución de contenido o proveedores de fuentes) de forma temprana. Esto acelera la descarga de recursos críticos de esos dominios al completar los handshakes de DNS, TCP y TLS por adelantado. Usa <link rel="preconnect" href="https://example.com"> para orígenes de terceros críticos.
• Considerar DNS prefetch como alternativa a preconnect: Similar a preconnect, DNS prefetch indica 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 conexión completa de preconnect no esté justificada.
• Precargar el elemento LCP: LCP mide cuánto tiempo tarda en cargarse el contenido principal. Precargar el elemento LCP indica al navegador que priorice 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.
• Precargar fuentes críticas: La precarga de fuentes críticas asegura que el navegador las descargue tempranamente, previniendo retrasos en la visualización del texto y mejorando los cambios de diseño acumulativos causados por el intercambio de fuentes. Usa <link rel="preload" as="font" type="font/woff2" crossorigin> para tus tipografías más importantes.
• Preferir 103 Early Hints para 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, agrega elementos <link> al <head> de la página como fallback. La entrega temprana de hints significa un descubrimiento más rápido de recursos.
• Precargar 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 analizado. Al precargar fuentes directamente en el <head> del HTML, eliminas la dependencia del análisis de CSS y permites que las fuentes se carguen en paralelo, reduciendo tanto FCP como el riesgo de cambios de diseño.

Optimizar Iconos

Los iconos pueden agregar 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 utilizados. Optimizar los iconos impacta tanto en LCP (peso reducido de HTML/CSS) como en CLS (reserva adecuada de dimensiones).

• Evitar iconos SVG en línea en el HTML: Incluir iconos SVG grandes en línea 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 de los iconos. Una hoja de sprites SVG externa es a menudo el mejor equilibrio entre rendimiento y flexibilidad.
• Evitar fuentes de iconos grandes: Nunca uses conjuntos de iconos grandes como Font Awesome en su totalidad. Usa subset 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 conjunto completo de Font Awesome puede superar los 100KB, mientras que un subset con 20 iconos puede ser inferior a 5KB.
• Reservar ancho y alto para los iconos: Similar a las imágenes, especificar ancho y alto para los iconos ayuda al navegador a reservar espacio y previene cambios de diseño mientras se cargan. Usa los atributos width y height en los elementos SVG o establece dimensiones explícitas en CSS.
• Desprioritizar conjuntos 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 se cargue primero y minimiza el impacto en las métricas de Core Web Vitals. Usa lazy loading o carga las hojas de estilo de iconos de forma asíncrona después del pintado inicial.

Optimizar los Tiempos de Respuesta del Servidor

Los tiempos de respuesta del servidor, medidos por 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 sigue. Para estrategias detalladas de optimización, explora nuestras guías sobre cómo diagnosticar problemas de TTFB y configurar Cloudflare para rendimiento.

• Usar un proveedor de hosting rápido y confiable: Un proveedor de hosting rápido con una infraestructura sólida puede mejorar significativamente los tiempos de respuesta del servidor y el rendimiento general del sitio web. Evalúa los proveedores de hosting usando mediciones reales de TTFB, no afirmaciones de marketing sintéticas.
• Optimizar el código del servidor y las consultas a la base de datos: Registra frecuentemente la ejecución del código y el tiempo de 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.
• Implementar estrategias de caché: Utiliza el almacenamiento en caché del navegador y del servidor para almacenar datos de acceso frecuente, reduciendo la necesidad de recuperación repetida de datos y mejorando los tiempos de carga. El almacenamiento en 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 del caché.
• Renderizado del lado del cliente o en el borde para personalización: Considera el renderizado del lado del cliente o en el borde de pequeñas personalizaciones como el conteo del carrito, el estado de inicio de sesión o cambios menores en el menú para mantener la funcionalidad de caché de página completa. Esto evita invalidar el caché de toda la página por elementos dinámicos menores.
• Optimizar las configuraciones del servidor: Revisa y ajusta la configuración de tu servidor web para rendimiento. Esto incluye la configuración de keep-alive de conexiones, el número de procesos worker, la asignación de memoria y los valores de timeout. Servidores mal configurados pueden desperdiciar recursos y aumentar los tiempos de respuesta.
• Usar una Red de Distribución de Contenido (CDN): Una CDN distribuye el contenido estático de tu sitio web a través de múltiples nodos de borde (servidores). Esto reduce la distancia física que los usuarios necesitan recorrer para acceder a tu contenido, resultando en tiempos de carga más rápidos para audiencias globales. Además, las CDNs generalmente están mejor configuradas que tu propio servidor. Consulta nuestra guía sobre configurar Cloudflare para un recorrido práctico de configuración.
• Reducir el procesamiento del lado del servidor: Minimiza la cantidad de trabajo que tu servidor realiza por solicitud. Pre-calcula operaciones costosas, usa algoritmos eficientes y mueve el procesamiento no esencial a tareas en segundo plano. Analiza el ciclo de vida de las solicitudes de tu aplicación para encontrar y eliminar pasos de procesamiento innecesarios.
• Usar HTTP/3: HTTP/3 es la última versión del Protocolo de Transferencia de Hipertexto. HTTP/3 es más rápido y 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.
• Configurar encabezados Server-Timing: Estos encabezados proporcionan información detallada sobre cuánto tiempo tardan las diferentes partes de tu página en procesarse en el servidor. Con estos datos, puedes identificar cuellos de botella y áreas de mejora, enfocándote específicamente en mejorar 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.
• Registrar consultas lentas a la base de datos y optimizarlas regularmente: Habilita 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.
• Usar 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 archivos aproximadamente un 70% más pequeños. Brotli normalmente logra entre un 15 y un 20% mejor compresión que GZIP. Archivos más pequeños se traducen en tiempos de carga más rápidos.

Optimizar la Interactividad

Interaction to Next Paint (INP) mide la rapidez con la que tu sitio responde a las interacciones del usuario. La mala interactividad a menudo es causada por tareas de JavaScript de larga duración que bloquean el hilo principal. Para un desglose completo de las tres fases de INP, consulta nuestras guías sobre input delay, processing time y presentation delay.

• Implementar 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 hilo principal del navegador esté inactivo. Esto asegura que tareas críticas como el renderizado y las interacciones del usuario no sean bloqueadas por scripts de larga duración. Usa requestIdleCallback para programar trabajo no urgente. Aprende más sobre optimizar el processing time.
• Dividir tareas largas cediendo el control al hilo principal: Las tareas complejas de JavaScript pueden bloquear el hilo principal, retrasando la capacidad de respuesta. Dividir estas tareas en trozos más pequeños y ceder el control al hilo principal entre trozos permite al navegador manejar las interacciones del usuario y mantener una experiencia fluida. Usa scheduler.yield() (donde sea compatible) o setTimeout(0) para dividir tareas largas. Consulta nuestra guía sobre mejorar INP eliminando el desplazamiento con JavaScript.
• Proporcionar retroalimentación inmediata después de la entrada: Los usuarios esperan una respuesta inmediata después de interactuar con tu sitio web. Proporciona señales visuales o confirma la entrada del usuario de forma rápida, incluso mientras las tareas de larga duración se procesan en segundo plano. Usa transiciones CSS y la pseudo-clase :active para retroalimentación visual instantánea. Esto ayuda a mantener una sensación de interactividad y evita que los usuarios sientan que el sitio web está congelado.
• Usar event listeners pasivos para scroll y touch: Agrega { passive: true } a los event listeners de scroll y touch. Los listeners pasivos le indican al navegador que el handler nunca llamará a preventDefault(), permitiéndole comenzar a desplazar inmediatamente sin esperar a JavaScript. Esto es especialmente impactante en dispositivos móviles y mejora directamente INP para interacciones adyacentes al desplazamiento.

Monitoreo de Core Web Vitals

Monitorear tus Core Web Vitals de forma continua es esencial para detectar regresiones tempranamente y validar que las optimizaciones tengan el impacto esperado. Usa una combinación de herramientas de laboratorio, datos de campo y monitoreo de usuarios reales para obtener una imagen completa.

• Revisar Lighthouse regularmente: Lighthouse es una herramienta de auditoría gratuita y de código abierto 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 tu sitio web periódicamente bajo condiciones reguladas y estandarizadas. Ejecuta Lighthouse en pipelines de CI/CD para detectar regresiones antes del despliegue.
• Revisar los datos históricos de CrUX regularmente: CrUX (Chrome User Experience Report) es un conjunto de datos público de Google que proporciona datos de rendimiento del mundo real. CrUX es la fuente de datos utilizada por Google para determinar si pasas o no los Core Web Vitals. Usa los datos históricos para detectar regresiones rápidamente. Puedes acceder a los datos de CrUX a través de PageSpeed Insights, el Panel de CrUX o la API de CrUX.
• Configurar seguimiento RUM: RUM (Real User Monitoring) implica rastrear las experiencias reales de los usuarios en tu sitio web. Las herramientas RUM recopilan datos sobre cuánto tiempo realmente tardan las páginas en cargarse para tus visitantes en diferentes ubicaciones y en varios dispositivos. Esto proporciona información valiosa sobre el rendimiento del mundo real, complementando los datos simulados de Lighthouse y CrUX. Recomendamos CoreDash como tu herramienta de seguimiento RUM para datos detallados de atribución de Core Web Vitals.
• Establecer presupuestos de rendimiento: Los presupuestos de rendimiento establecen objetivos específicos de rendimiento (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 referencias para guiar tus esfuerzos de optimización. Verificar regularmente tu rendimiento contra estos presupuestos te ayuda a identificar áreas que necesitan atención inmediata y priorizar optimizaciones.
• Usar segmentación: Usa la segmentación para rastrear tus tipos de visitantes más valiosos y diferentes tipos de páginas. Mayores cantidades de tráfico podrían 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.

Optimizar la Ruta Crítica de Renderizado

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

• Minimizar el número de recursos críticos: Cada recurso que bloquea el renderizado (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 hojas de estilo no críticas.
• Optimizar el orden de carga de recursos: Asegúrate de que el CSS crítico y las fuentes se carguen primero, seguidos de las imágenes above-the-fold, y luego los scripts diferidos. Usa el atributo fetchpriority y las indicaciones de priorización de recursos para comunicar la importancia al navegador.
• Reducir la profundidad del árbol DOM: Los árboles DOM profundamente anidados aumentan el tiempo de cálculo de estilos y el trabajo de diseño. Apunta a una profundidad máxima de 32 niveles y menos de 1.500 elementos DOM totales donde sea posible. Una estructura DOM más plana mejora tanto el rendimiento de pintado como el presentation delay de INP.
• Preferir clases e IDs sobre etiquetas y atributos de elementos: 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 la coincidencia de estilos, resultando en un recálculo de estilos más rápido.
• Evitar anidar selectores profundamente: Cuanto más profundamente anides 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 de selectores a 3 niveles como máximo.
• Minimizar selectores descendientes: Los selectores como .container > .content obligan al navegador a verificar cada elemento dentro del contenedor. Si es posible, usa una clase más directa en el elemento de contenido para una coincidencia de selectores más rápida.
• Consolidar 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 nombres BEM (Block Element Modifier) para mejor mantenibilidad y una salida CSS más pequeña.

Optimizar el Consentimiento de Cookies

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

• Considerar consentimiento de cookies del lado del servidor para páginas dinámicas: Para páginas renderizadas dinámicamente del lado del 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 solicitud de red adicional y la sobrecarga de evaluación de scripts.
• Cargar de forma asíncrona los scripts de consentimiento de cookies en páginas cacheadas: Para páginas cacheadas, carga de forma asíncrona tu script de consentimiento de cookies y considera agregar fetchpriority="high" al script para asegurar que se cargue lo suficientemente temprano para mostrarse antes de la interacción del usuario.
• Mantener el texto de consentimiento corto para evitar interferencia con LCP: Los textos largos de aviso de cookies pueden apoderarse del elemento LCP porque el navegador considera el bloque de texto visible más grande como un candidato potencial de LCP. Considera escribir textos más cortos o dividir los textos en múltiples párrafos con un área visible más pequeña.
• Auto-alojar scripts de notificación de cookies: Almacena en caché y auto-aloja los scripts y 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.

Optimizar Aplicaciones de Página Única

Las Aplicaciones de Página Única (SPAs) construidas con React, Vue, Angular o frameworks similares enfrentan desafíos únicos de Core Web Vitals. El renderizado del lado del cliente puede retrasar tanto FCP como LCP, mientras que la hidratación puede bloquear INP.

• Siempre usar renderizado del lado del servidor o prerenderizado: Las SPAs que dependen únicamente del renderizado del lado del cliente obligan al navegador a descargar, analizar 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.
• Preferir prerenderizados estáticos sobre generación dinámica: Los prerenderizados estáticos (generados en tiempo de compilación) 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 solicitud.
• Cargar scripts de terceros después de la hidratación: Durante la hidratación, el framework ya está consumiendo un tiempo significativo del hilo principal para hacer la página interactiva. Cargar scripts de terceros simultáneamente agrava el problema y empeora el input delay. Difiere todos los scripts no esenciales hasta que el proceso de hidratación se complete.

Evitar un Tamaño Excesivo del DOM

Un DOM grande (más de 1.500 elementos o una profundidad que excede los 32 niveles) aumenta el uso de memoria, ralentiza los cálculos de estilos y causa costosos reflujos de diseño. Esto impacta directamente tanto en el presentation delay de INP como en las métricas de pintado. Consulta cómo solucionar el tamaño excesivo del DOM.

• Reducir elementos DOM innecesarios: Audita tu HTML en busca de elementos contenedores que no sirven ningún propósito de estilo o estructura. Reemplaza las estructuras profundamente anidadas de <div> con elementos HTML semánticos. Considera virtualizar listas largas con bibliotecas como react-window o virtual-scroller para mantener el DOM activo pequeño.
• Usar selectores eficientes de JavaScript y CSS: 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 clase específicos y limita el alcance de las consultas DOM a subárboles siempre que sea posible.
• Usar content-visibility: auto para contenido fuera de pantalla: La propiedad CSS content-visibility: auto le indica al navegador que omita el renderizado de elementos fuera de pantalla hasta que se desplacen a la vista. Esto puede reducir drásticamente el trabajo de renderizado inicial para páginas con secciones de contenido extensas.

Optimizar Solicitudes API

Las solicitudes API que bloquean el renderizado o retrasan el contenido pueden impactar negativamente LCP y TTFB. La obtención de datos del lado del cliente es una fuente común de LCP lento en aplicaciones de página única.

• Minimizar el número de solicitudes API: Cada solicitud API añade al tiempo total de carga de la página. Evalúa la funcionalidad de tu sitio web e identifica oportunidades para reducir el número de solicitudes API necesarias para renderizar el contenido inicial. Técnicas como el agrupamiento de datos (combinar múltiples solicitudes en una) y GraphQL pueden reducir los viajes de ida y vuelta.
• Usar APIs eficientes y optimizadas: El diseño e implementación de las APIs en sí puede impactar el rendimiento. Asegúrate de usar APIs bien diseñadas que estén optimizadas para velocidad y eficiencia. Implementa mecanismos de caché en el lado de la API para reducir los tiempos de respuesta para datos solicitados frecuentemente.
• Precargar solicitudes API críticas: Similar a precargar recursos críticos como imágenes, precargar solicitudes API esenciales puede mejorar significativamente el rendimiento percibido. Usa <link rel="preload" as="fetch"> para indicar al navegador que obtenga APIs críticas tempranamente, minimizando retrasos cuando se necesitan para renderizar el contenido inicial. Consulta nuestra guía de priorización de recursos para más técnicas.

Optimizar Widgets de Chat

Los widgets de chat son una causa común de cambios de diseño y podrían incluso causar problemas con el LCP si se cargan tempranamente. Para un enfoque paso a paso, lee cómo implementar un widget de chat con Core Web Vitals perfectos.

• Cargar widgets de chat después de que el contenido principal se haya cargado: Nadie en la historia de internet ha necesitado chatear antes de que el contenido principal de la página se haya cargado. Difiere la inicialización del widget de chat hasta que la página haya completado su renderizado inicial, usando requestIdleCallback o un activador basado en desplazamiento.
• Prevenir cambios de diseño del widget de chat: Si los widgets de chat causan un cambio de diseño, generalmente es buena idea ocultarlos con opacity: 0 hasta que se hayan renderizado completamente en la página. Esto permite que el widget se disponga en segundo plano sin causar que el contenido visible salte. Usa una transición CSS para hacer aparecer el widget suavemente.
• Elegir 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 paquete JavaScript, el número de solicitudes de red y el impacto en INP de diferentes proveedores antes de comprometerte.

Optimizar el Rendimiento del Service Worker

Los service workers pueden mejorar significativamente el rendimiento de visitas repetidas al almacenar en caché activos e incluso respuestas de páginas completas, reduciendo el TTFB para visitantes recurrentes. Sin embargo, un service worker mal implementado puede ralentizar la navegación. Aprende más sobre la optimización de la duración del caché.

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

Optimizar Contenido de Video

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

• Comprimir y optimizar videos: Usa codecs modernos como H.264, VP9 o AV1 con configuraciones de calidad apropiadas. Reduce la resolución del video para que coincida con el tamaño máximo de visualización. Un video que se muestra a 400px de ancho no necesita codificarse a 1920px. Usa codificación de dos pasadas para la mejor relación calidad-tamaño de archivo.
• Usar lazy loading para videos: Para videos debajo del pliegue, usa el atributo loading="lazy" en elementos <iframe> o retrasa la carga del video con la API Intersection Observer. Reemplaza los videos de fondo con reproducción automática por imágenes de póster y carga el video solo cuando el usuario se desplace cerca.
• Alojar videos en una CDN rápida: Los archivos de video son grandes y se benefician enormemente de la distribución CDN. Usa una CDN de video dedicada o un servicio de alojamiento (como Cloudflare Stream, Mux o Bunny.net) que proporcione streaming con tasa de bits adaptativa, distribución geográfica y entrega optimizada.
• Usar imágenes de póster para elementos de video: Siempre establece un atributo poster en los elementos <video>. La imagen de póster le da al navegador algo que pintar inmediatamente mientras el video se carga, lo cual puede servir como elemento LCP. Optimiza la imagen de póster igual que cualquier otra imagen LCP.