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 de optimización de Core Web Vitals
  • Optimizar imágenes
  • Optimizar fuentes web
  • Optimizar scripts
  • Optimizar estilos
  • Optimizar resource hints
  • Optimizar iconos
  • Optimizar tiempos de respuesta del servidor
  • Optimizar interactividad
  • Monitorización de Core Web Vitals
  • Optimizar la ruta de renderizado crítico
  • Optimizar el consentimiento de cookies
  • Optimizar Single Page Applications
  • 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 realizar para el LCP. Usa estos elementos de la lista de verificación de Core Web Vitals para mejorar la velocidad de las imágenes. Para profundizar, lee nuestra guía sobre cómo optimizar la imagen LCP.

• Redimensiona las imágenes para que coincidan con las dimensiones más grandes 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 el tamaño de los archivos de imagen en un 50% o más sin ninguna pérdida visible de calidad.
• Usa lazy loading para las imágenes below-the-fold: El lazy loading retrasa la carga de imágenes fuera del viewport hasta que se hace scroll hacia ellas, mejorando el First Contentful Paint (FCP) y la velocidad general de carga de la página. Nunca uses lazy loading en la imagen LCP, ya que esto la retrasará significativamente.
• Precarga imágenes visualmente importantes como el elemento LCP: El Preloading indica al navegador que busque imágenes críticas antes que el resto del contenido, priorizando el LCP. Usa <link rel="preload" as="image"> combinado con fetchpriority="high" para obtener los mejores resultados. Esto es especialmente importante cuando la imagen LCP se referencia desde CSS o se carga mediante JavaScript.
• Establece el ancho y el alto: Definir las dimensiones de la imagen por adelantado evita cambios de diseño causados por el navegador esperando a que las imágenes se carguen. 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 se haya cargado, reservando la cantidad correcta de espacio.
• 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, lo que lleva a 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 una máxima compatibilidad con el navegador.
• Usa lazy loading nativo y deshabilita el lazy loading basado en JavaScript: El lazy loading retrasa la carga de imágenes fuera del viewport hasta que se hace scroll hacia ellas. El lazy loading nativo ofrecido por los navegadores a través del atributo loading="lazy" es generalmente más eficiente que depender de JavaScript para esta tarea, ya que no requiere análisis o ejecución extra de scripts.
• 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 que el motor de renderizado continúe pintando otros elementos mientras la decodificación de la imagen ocurre en paralelo.
• Elimina los metadatos de la imagen: 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 compilación.
• Evita 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 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 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 mejores prácticas de alojamiento de fuentes, consulta nuestra guía sobre alojar Google Fonts localmente.

• 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 de respaldo 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.
• Usa font-display: optional combinado con preloading para eliminar el cambio de diseño causado por fuentes: Combinar font-display: optional con preloading 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 respaldo. El preloading indica al navegador que busque la fuente web temprano, minimizando el tiempo dedicado a las fuentes de respaldo y reduciendo los cambios de diseño.
• Usa descriptores font-face para hacer que la fuente de respaldo coincida con las dimensiones de la fuente web: Esto asegura un CLS mínimo 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 respaldo, puedes evitar que el contenido salte a medida que la fuente carga.
• Subconjunta fuentes para incluir solo los caracteres necesarios: Reduce el tamaño del archivo de fuente creando subconjuntos de fuentes para incluir solo los caracteres necesarios para tu contenido. Herramientas como Font Squirrel, pyftsubset o glyphhanger pueden ayudar a generar subconjuntos. Una fuente con el conjunto de caracteres latinos completo a menudo se puede reducir de 100KB+ a menos de 20KB con el subconjunto adecuado.
• Limita el número de pesos y estilos de fuente: Evita cargar variaciones de fuente excesivas. Cíñete 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 de 15 a 50KB de tamaño de descarga.

Optimizar 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 pintura (LCP y FCP). Para una guía completa, consulta 14 métodos para diferir JavaScript.

• Elimina JavaScript innecesario: Identifica y elimina código JavaScript no utilizado para minimizar la cantidad de código que necesita ser descargado y ejecutado. 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.
• Prioriza scripts según su función e importancia: Los scripts que hacen grandes cambios en el viewport visible deben bloquear el renderizado. Los scripts importantes deben ser diferidos o cargados de forma asíncrona. Los scripts prescindibles 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 fragmentos 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 code splitting automático basado en importaciones dinámicas.
• Minifica y recompila 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 hilo principal. Audita los scripts de terceros regularmente usando el panel Network de Chrome DevTools.
• Carga scripts de terceros de forma asíncrona: 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 script de terceros.
• Monitoriza 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 en el INP y el 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 pintura 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 el First Contentful Paint como en el retraso de renderizado del elemento LCP. Para consejos sobre cómo limpiar estilos no utilizados, consulta cómo eliminar CSS no utilizado.

• Minifica archivos CSS: Elimina caracteres innecesarios como espacios en blanco, comentarios y formato de los archivos CSS. Los archivos minificados son más pequeños, lo que lleva a tiempos de carga más rápidos. Herramientas como cssnano, PostCSS o la compresión integrada de tu preprocesador CSS pueden automatizar esto.
• Elimina CSS no utilizado: Identifica y elimina 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.
• Incluye 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 pintura. Considera servir CSS crítico solo a nuevos visitantes y usar hojas de estilo externas en caché para visitantes recurrentes. Esta técnica puede reducir el FCP eliminando el viaje de ida y vuelta necesario para buscar una hoja de estilo externa.
• Distribuye equitativamente los tamaños de archivo 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 incrementalmente.
• Carga asíncrona de estilos fuera de pantalla: Para 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 buscar 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 suelen ponerse en cola para su descarga y están disponibles para el navegador mucho antes de lo que lo estarían sin la precarga. El uso efectivo de resource hints puede reducir significativamente el retraso de carga de recursos LCP. Para una implementación avanzada, lee sobre 103 Early Hints.

• Elimina resource hints no críticos: Elimina las sugerencias de precarga para recursos que no son esenciales para la carga inicial de la página. Esto evita 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 genuinamente críticos.
• Preconecta a dominios críticos: Establece conexiones con dominios importantes (como redes de entrega de contenido o proveedores de fuentes) desde el principio. Esto acelera la descarga de recursos críticos de esos dominios completando los apretones de manos 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 una alternativa a preconnect: Similar a preconnect, DNS prefetch sugiere 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.
• Precarga el elemento LCP: El 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.
• Precarga fuentes críticas: Precargar fuentes críticas asegura que el navegador las busque temprano, evitando 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 tipos de letra más importantes.
• Prefiere 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, añade elementos <link> al <head> de la página como alternativa. Una entrega más temprana de sugerencias significa un descubrimiento de recursos más rápido.
• Precarga fuentes antes de que los archivos CSS las descubran: Las fuentes referenciadas en CSS solo se descubren después de que el archivo CSS ha sido descargado y analizado. Al precargar fuentes directamente en el <head> HTML, eliminas la dependencia del análisis CSS y permites que las fuentes se carguen en paralelo, reduciendo tanto el FCP como el riesgo de cambio de diseño.

Optimizar iconos

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

• Evita iconos SVG en línea en HTML: Incluir iconos SVG grandes en línea puede aumentar el tamaño de tu 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.
• Evita fuentes de iconos grandes: Nunca uses conjuntos de iconos grandes como Font Awesome en su totalidad. Usa subconjuntos 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 subconjunto con 20 iconos puede tener menos de 5KB.
• Reserva 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 evita cambios de diseño a medida que cargan. Usa los atributos width y height en elementos SVG o establece dimensiones explícitas en CSS.
• Desprioriza 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 cargue primero y minimiza el impacto en las métricas de Core Web Vitals. Usa lazy loading o carga hojas de estilo de iconos de forma asíncrona después del primer pintado.

Optimizar 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 pintura. Una respuesta lenta del servidor retrasa todo lo que sigue. Para estrategias de optimización detalladas, explora nuestras guías sobre diagnosticar problemas de TTFB y configurar Cloudflare para rendimiento.

• Usa un proveedor de hosting rápido y fiable: 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. Compara proveedores de hosting 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 de código y el tiempo de consulta a la base de datos para encontrar cuellos de botella y mejorar la velocidad general. Usa herramientas de perfilado de consultas y monitorización del rendimiento de aplicaciones (APM) para identificar endpoints lentos.
• Implementa estrategias de caché: Utiliza el almacenamiento en caché del navegador y del lado del servidor para almacenar datos accedidos frecuentemente, reduciendo la necesidad de recuperación de datos repetida 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 de la caché.
• Renderizado del lado del cliente o en el borde para personalización: Considera el renderizado del lado del cliente o en el borde para pequeñas personalizaciones como el recuento del carrito, 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 la caché 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 configuraciones de conexión keep-alive, recuentos de procesos de trabajo, asignación de memoria y valores de tiempo de espera. 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 de borde (servidores). Esto reduce la distancia física que los usuarios necesitan para acceder a tu contenido, lo que lleva a tiempos de carga más rápidos para audiencias globales. Además, las CDNs suelen estar mejor configuradas que tu propio servidor. Consulta nuestra guía sobre configurar Cloudflare para un tutorial de configuración práctica.
• Reduce el procesamiento del lado del servidor: Minimiza la cantidad de trabajo que hace tu servidor por solicitud. Pre-calcula operaciones costosas, usa algoritmos eficientes y mueve el procesamiento no esencial a trabajos en segundo plano. Analiza el ciclo de vida de la solicitud de tu aplicación para encontrar y eliminar pasos de procesamiento innecesarios.
• Usa 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.
• Configura encabezados Server-Timing: Estos encabezados proporcionan información detallada sobre cuánto tiempo tardan en procesarse diferentes partes de tu página en el servidor. Con estos datos, puedes identificar cuellos de botella y áreas de mejora, enfocá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 consultas lentas a la base de datos y optimízalas 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.
• Usa compresión GZIP o Brotli: GZIP, o el más nuevo 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 un 15 a 20% mejor que GZIP. Tamaños de archivo más pequeños se traducen en tiempos de carga más rápidos.

Optimizar interactividad

El Interaction to Next Paint (INP) mide la rapidez con la que tu sitio responde a las interacciones del usuario. Una interactividad deficiente 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.

• 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 hilo principal del navegador esté inactivo. Esto asegura que las tareas críticas como el renderizado y las interacciones del usuario no sean bloqueadas por scripts de larga duración. Usa requestIdleCallback para programar trabajos no urgentes. Aprende más sobre optimizar el tiempo de procesamiento.
• Divide las tareas largas cediendo al hilo principal: Las tareas complejas de JavaScript pueden bloquear el hilo principal, retrasando la capacidad de respuesta. Dividir estas tareas en fragmentos más pequeños y ceder el control de vuelta al hilo principal entre fragmentos permite al navegador manejar las interacciones del usuario y mantener una experiencia de usuario fluida. Usa scheduler.yield() (donde sea compatible) o setTimeout(0) para dividir tareas largas. Consulta nuestra guía sobre mejorar el INP eliminando el desplazamiento por JavaScript.
• Proporciona retroalimentación inmediata después de la entrada: Los usuarios esperan una capacidad de respuesta inmediata después de interactuar con tu sitio web. Proporciona señales visuales o reconoce la entrada del usuario rápidamente, incluso mientras las tareas de larga duración se procesan en segundo plano. Usa transiciones CSS y la pseudo-clase :active para una 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.
• Usa listeners de eventos pasivos para scroll y touch: Añade { passive: true } a los listeners de eventos de scroll y touch. Los listeners pasivos le dicen al navegador que el manejador nunca llamará a preventDefault(), permitiéndole comenzar a desplazarse inmediatamente sin esperar a JavaScript. Esto es especialmente impactante en dispositivos móviles y mejora directamente el INP para interacciones adyacentes al desplazamiento.

Monitorización de Core Web Vitals

Monitorizar tus Core Web Vitals continuamente es esencial para detectar regresiones temprano y validar que las optimizaciones tengan el impacto esperado. Usa una combinación de herramientas de laboratorio, datos de campo y monitorización de usuarios reales para una imagen completa.

• Revisa 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 gran herramienta para probar y comparar periódicamente tu sitio web bajo condiciones reguladas y estandarizadas. Ejecuta Lighthouse en tuberías CI/CD para detectar regresiones antes del despliegue.
• Revisa 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 apruebas o no los Core Web Vitals. Usa los datos históricos para detectar rápidamente regresiones. Puedes acceder a los datos de CrUX a través de PageSpeed Insights, el CrUX Dashboard o la API de CrUX.
• Configura el seguimiento RUM: RUM (Real User Monitoring) implica rastrear experiencias de usuarios reales en tu sitio web. Las herramientas RUM recopilan datos sobre cuánto tiempo tardan realmente las páginas en cargarse para tus visitantes en diferentes ubicaciones y en varios dispositivos. Esto proporciona información valiosa sobre el rendimiento en el 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.
• Establece presupuestos de rendimiento: Los presupuestos de rendimiento 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 puntos de referencia 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 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 ocultar 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 de renderizado crítico

La ruta de renderizado crítico es la secuencia de pasos que toma el navegador 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. Consulta también cómo evitar un tamaño excesivo del DOM.

• Minimiza el número de recursos críticos: Cada recurso que bloquea el renderizado (CSS y JavaScript síncrono) debe ser descargado y procesado antes de que el navegador pueda pintar. Reduce el número de recursos críticos diferidos scripts no esenciales y cargando asíncronamente hojas de estilo no críticas.
• Optimiza el orden de carga de recursos: Asegura que el CSS y las fuentes críticas se carguen primero, seguidos de las imágenes above-the-fold, y luego los scripts diferidos. Usa el atributo fetchpriority y sugerencias 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 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 pintura como el retraso de presentación 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 coincidir estilos, resultando en un recálculo de estilos más rápido.
• Evita 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 más cerca del elemento. Limita la profundidad del selector a 3 niveles máximo.
• Minimiza los 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.
• 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 una 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 en 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 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 es a menudo más rápido que cargar una solución separada basada en JavaScript. Esto elimina la solicitud de red extra y la sobrecarga de evaluación de scripts.
• Carga asíncrona de scripts de consentimiento de cookies en páginas en caché: Para páginas en caché, carga asíncronamente tu script de consentimiento de cookies y considera añadir fetchpriority="high" al script para asegurar que cargue lo suficientemente temprano 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 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.
• Aloja tú mismo los scripts de notificación de cookies: Almacena en caché y aloja tú mismo los scripts y hojas de estilo de notificación de cookies siempre que sea posible. Esto elimina búsquedas DNS y sobrecarga de conexión a plataformas de gestión de consentimiento de terceros y te da control total sobre el comportamiento de carga.

Optimizar 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 del lado del cliente puede retrasar tanto el FCP como el LCP, mientras que la hidratación puede bloquear el INP.

• Siempre usa 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.
• Prefiere prerenders estáticos sobre generación dinámica: Los prerenders estáticos (generados en tiempo de compilación) son mucho más rápidos que los prerenders 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 requieran datos por solicitud.
• Carga 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 después de que se complete el proceso de hidratación.

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 estilo y causa costosos reflujos de diseño. Esto impacta directamente tanto en el retraso de presentación INP como en las métricas de pintura. Consulta cómo solucionar un tamaño excesivo del DOM.

• Reduce elementos DOM innecesarios: Audita tu HTML en busca de elementos envoltorio que no sirvan para ningún propósito de estilo o estructural. Reemplaza estructuras <div> profundamente anidadas con elementos HTML semánticos. Considera virtualizar listas largas con bibliotecas como react-window o virtual-scroller para mantener el DOM activo pequeño.
• Usa selectores 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 clase 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 se haga scroll hacia ellos. Esto puede reducir dramáticamente el trabajo de renderizado inicial para páginas con secciones de contenido largas.

Optimizar solicitudes API

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

• Minimiza el número de solicitudes de API: Cada solicitud de 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 de API necesarias para renderizar el contenido inicial. Técnicas como el procesamiento por lotes de datos (combinar múltiples solicitudes en una) y GraphQL pueden reducir los viajes de ida y vuelta.
• Usa APIs eficientes y optimizadas: El diseño y la implementación de las propias APIs pueden impactar en el rendimiento. Asegura que estás usando 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.
• Precarga solicitudes de API críticas: Similar a la precarga de recursos críticos como imágenes, precargar solicitudes de API esenciales puede mejorar significativamente el rendimiento percibido. Usa <link rel="preload" as="fetch"> para indicar al navegador que busque APIs críticas temprano, 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 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 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 terminado su renderizado inicial, usando requestIdleCallback o un disparador basado en scroll.
• Evita cambios de diseño de widgets de chat: Si los widgets de chat causan un cambio de diseño, generalmente es una buena idea ocultarlos con opacity: 0 hasta que se hayan renderizado completamente en la página. Esto permite que el widget se diseñe en segundo plano sin causar que el contenido visible salte. Usa una transición CSS para desvanecer el widget suavemente.
• Elige proveedores de widgets de chat ligeros: Compara. 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 de JavaScript, el número de solicitudes de red y el impacto en el INP de diferentes proveedores antes de comprometerte.

Optimizar el rendimiento del Service Worker

Los service workers pueden mejorar significativamente el rendimiento de visitas repetidas almacenando en caché activos e incluso respuestas de página completa, 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 de la caché.

• Almacena en caché activos críticos en el service worker: Usa una estrategia cache-first para activos 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. Pre-caché los recursos más importantes durante el evento de instalación del service worker.
• Optimiza 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 pre-caché 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 el ancho de banda con otros recursos críticos.

• Comprime y optimiza videos: Usa códecs 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 aparece a 400px de ancho no necesita ser codificado a 1920px. Usa codificación de dos pasadas para la mejor relación calidad-tamaño de archivo.
• Usa lazy loading para videos: Para videos below the fold, usa el atributo loading="lazy" en elementos <iframe> o retrasa la carga del video con la API Intersection Observer. Reemplaza los videos de fondo de reproducción automática con imágenes de póster y carga el video solo cuando el usuario haga scroll cerca de él.
• Aloja 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 hosting (como Cloudflare Stream, Mux o Bunny.net) que proporcione transmisión de tasa de bits adaptativa, distribución geográfica y entrega optimizada.
• Usa imágenes de póster para elementos de video: Siempre establece un atributo poster en elementos <video>. La imagen de póster le da al navegador algo para pintar inmediatamente mientras el video carga, lo que puede servir como el elemento LCP. Optimiza la imagen de póster igual que cualquier otra imagen LCP.