Optimiza las Core Web Vitals para dispositivos de gama baja

Optimiza las Core Web Vitals para dispositivos de gama baja

Las Core Web Vitals deberían ser parte de un punto de referencia objetivo para la calidad del sitio. En la práctica, ¡no lo son! Las métricas están estrechamente vinculadas a los dispositivos que utilizan los usuarios. Si un negocio vende productos o servicios de alta gama, sus clientes tienden a tener teléfonos rápidos, computadoras de escritorio y conexiones confiables.
Contrasta eso con los negocios dirigidos a compradores conscientes de los costos o a mercados emergentes. Sus audiencias se apoyan en teléfonos obsoletos, procesadores débiles o malas condiciones de red.
El mismo sitio web que pasa sin problemas una prueba en un iPhone de gama alta tiene dificultades para cargar de manera aceptable en un Android de gama media o en países con conectividad de bajo ancho de banda.

Última revisión por Arjen Karel en marzo de 2026

Los números cuentan la historia

Según el Web Almanac de 2025, solo el 48% de los orígenes móviles aprueban las Core Web Vitals frente al 56% en escritorio. La brecha más pronunciada es el INP: el 97% de los orígenes de escritorio aprueban, pero solo el 77% en móviles. Esa brecha de 20 puntos porcentuales es causada casi en su totalidad por CPU más lentas en dispositivos Android.

La mediana del Total Blocking Time en móviles es de 1.916 milisegundos. ¿En escritorio? 92 milisegundos. Esa es una proporción de 20:1. Si tus scripts se ejecutan bien en tu MacBook, definitivamente no se ejecutan bien en un teléfono económico.

Según la investigación de Alex Russell, aproximadamente el 30% de los dispositivos en uso son de gama baja (4 núcleos o menos, 4GB de RAM o menos). Estos dispositivos tienen un rendimiento de un solo núcleo que es hasta 9 veces más lento que el de un iPhone actual. En los datos de Real User Monitoring de CoreDash, vemos que los sitios optimizados para dispositivos de gama baja aprueban las CWV en el 62% de las cargas de página móviles, en comparación con solo el 41% para los sitios que solo realizan pruebas en hardware de alta gama.

Paso 1: Generar un Client Capability Score

Para evaluar si un visitante está utilizando un dispositivo de gama alta o de gama baja, se puede calcular un Client Capability Score directamente en el navegador. Esta puntuación varía desde 0 (extremadamente limitado) hasta 100 (hardware de primer nivel). En la práctica, cualquier dispositivo con una puntuación por debajo de 40 debería clasificarse como deficiente.

La función a continuación calcula el Client Capability Score utilizando indicadores de hardware y red que se correlacionan fuertemente con los datos reales de RUM y las Core Web Vitals de Google. Una puntuación más alta indica que el dispositivo es más capaz de ofrecer un rendimiento de página rápido con menos limitaciones de recursos.

function getClientCapabilityScore() {
  const mem = navigator.deviceMemory || 4;
  let cpu = navigator.hardwareConcurrency || 4;
  cpu = Math.min(cpu, 8);

  let net = 4;
  if (navigator.connection) {
    const { effectiveType, rtt = 300 } = navigator.connection;
    const map = { 'slow-2g': 1, '2g': 2, '3g': 3, '4g': 4, '5g': 5 };
    net = map[effectiveType] || 4;
    if (rtt > 500) net = Math.max(net - 3, 1);
    else if (rtt > 300) net = Math.max(net - 2, 1);
    else if (rtt < 150) net = Math.min(net + 1, 5);
  }

  const score = mem + cpu * 0.5 + net * 2;
  return Math.min(100, Math.round(score * 5));
}

getClientCapabilityScore();

Consejo de Core Web Vitals: Estas optimizaciones ayudan a todos. Pero si alguien tiene una conexión lenta o utiliza un dispositivo con memoria limitada, importan mucho más. Las desventajas de omitirlas aparecen más rápido.
Tomemos como ejemplo las descargas de imágenes. En una conexión normal, generalmente representan alrededor del 10% del tiempo de Largest Contentful Paint. En una lenta, eso puede duplicarse sin mucho esfuerzo. Por eso no ponemos la optimización de imágenes en el primer lugar de la lista para la mayoría de los usuarios, pero al tratar con visitantes de bajo ancho de banda o con limitaciones de memoria, se convierte rápidamente en una prioridad.

Habilita HTTP/3 con QUIC y 0-RTT

Los visitantes lejos de tus servidores o atrapados en redes lentas enfrentan altos tiempos de ida y vuelta (RTT). HTTP/3, junto con QUIC y 0-RTT, mejora directamente tu velocidad de conexión inicial. Esta es una optimización importante para todos los visitantes, pero especialmente crítica para los visitantes con bajo ancho de banda. Según Cloudflare Radar, HTTP/3 ahora maneja el 21% del tráfico web global. Si usas Cloudflare, puedes habilitar HTTP/3 en el panel de control de Cloudflare.

• Configuración de conexión más rápida: QUIC colapsa los saludos de transporte y cifrado en uno solo. 0-RTT va más allá: los visitantes recurrentes envían datos de inmediato, omitiendo por completo los saludos.
• Menor latencia para usuarios recurrentes: 0-RTT permite a los clientes reanudar sesiones y enviar solicitudes sin pausas. Cientos de milisegundos ahorrados, algo especialmente valioso para usuarios distantes o móviles.
• Resiliente en largas distancias: HTTP/3 (sobre UDP) evita el bloqueo de cabeza de línea de TCP. QUIC maneja la pérdida de paquetes y las redes inestables con mayor elegancia. Esto marca una verdadera diferencia en conexiones intercontinentales o conexiones móviles inestables.

Comprime las imágenes de manera más agresiva de lo que le gustaría a tu diseñador

Las imágenes de alta resolución paralizan el LCP, particularmente en dispositivos con poder limitado de descompresión de GPU. El Web Almanac de 2025 muestra que la mediana de una página de inicio móvil carga 911 KB de imágenes. Eso es el 42% del peso total de la página. En un dispositivo económico con un enlace de bajada P75 de 9 Mbps, esas imágenes compiten directamente con tus recursos críticos.

En lugar de ceder a la estética, apunta a imágenes más pequeñas y perceptualmente aceptables. WebP y AVIF ayudan, pero la carga diferida y servir tamaños responsivos importan más.

Una regla clara: para las imágenes principales en dispositivos de gama baja, mantente por debajo de los 100 KB. Si el diseñador se opone, debería probar el mismo sitio en un teléfono Android de 100€ antes de seguir discutiendo.

Reduce el CSS a lo estrictamente necesario

Cuando se trata de estilos, solo hay una regla: haz limpieza. Elimina los selectores no utilizados, reduce la especificidad y colapsa las reglas redundantes.

Concéntrate en diseños predecibles y consistentes con la menor cantidad de anulaciones posible. Usa un conjunto pequeño de clases de utilidad en lugar de estilos complejos específicos de componentes. Eso ayuda tanto a la construcción del CSSOM del navegador como a la mantenibilidad por parte del desarrollador.

Para el contenido por encima del pliegue, inserta en línea solo lo absolutamente necesario. Carga de forma diferida el resto, pero mantén la división al mínimo y de forma clara. Puedes usar el Critical CSS Generator como punto de partida, pero define tu CSS crítico de forma manual y quirúrgica para obtener el mejor resultado.

Sé directo con los scripts

Con una mediana de TBT móvil de 1.916 ms (un aumento del 58% interanual según el Web Almanac de 2025), JavaScript es el mayor problema en los dispositivos de gama baja. La velocidad de red P75 para dispositivos económicos es de aproximadamente 9 Mbps de bajada con 100 ms de RTT. Cada kilobyte de JavaScript que envías se analiza y ejecuta en una CPU que es 9 veces más lenta que la del teléfono en el que realizas las pruebas.

• Ningún script debería bloquear el renderizado: Asegúrate de que todos los scripts no esenciales no sean bloqueantes. Usa los atributos async o defer en tus etiquetas <script>. Si un script no es esencial para la carga inicial de la página o la interacción del usuario, no debe ser síncrono. Para un resumen completo de las técnicas de aplazamiento, consulta 16 métodos para diferir JavaScript.
• Programa los scripts no críticos: Los scripts que no se requieren de antemano deben ser programados. Usa requestIdleCallback para activar los scripts cuando el navegador esté inactivo. Esto te permite descargar tareas pesadas sin interrumpir las rutas de renderizado críticas.
• Usa el Client Capability Score para cargar scripts de forma selectiva: Usa la puntuación para decidir qué cargar. En dispositivos de gama baja, reduce la cantidad de scripts y elige alternativas más ligeras. Si el usuario tiene memoria limitada o una CPU antigua, no desperdicies recursos cargando scripts pesados. Prioriza el rendimiento sobre características superficiales que podrían impresionar en dispositivos de alta gama pero frustrar en los de gama baja.

Usa fuentes del sistema o al menos evita las fuentes personalizadas pesadas

Cargar fuentes personalizadas agrega latencia y produce saltos en el diseño. En dispositivos con memoria limitada, también pueden aumentar la presión sobre la RAM de forma innecesaria. Según el Web Almanac de 2025, el 88% de los sitios cargan al menos una fuente web, pero solo el 12% las precarga. La mejor opción para el rendimiento, font-display: optional, es utilizada solo por el 0,4% de los sitios.

Las fuentes del sistema se renderizan más rápido, respetan la configuración del usuario y reducen el layout shift. Si la marca exige tipografía personalizada, crea subconjuntos de forma agresiva y carga las fuentes más tarde. Considera alojar tus propias fuentes para que puedas controlar su entrega.

Monitorea con hardware real, no solo con pruebas sintéticas

Las herramientas de pruebas sintéticas (como Lighthouse, WebPageTest, etc.) simulan la limitación térmica y de red, pero no imitan todas las peculiaridades del hardware de gama baja: problemas térmicos, limitación térmica bajo carga real, pausas por la recolección de basura y cuellos de botella en el almacenamiento. Ten en cuenta que PageSpeed Insights cambió su limitación de CPU de 4x a 1.2x en diciembre de 2024, haciendo que las puntuaciones de laboratorio sean aún menos representativas del rendimiento real de los dispositivos económicos.

Compra un teléfono Android barato y navega por tu sitio. Si no soportas hacer eso con regularidad, usa una herramienta de RUM como CoreDash y segmenta los datos por clase de dispositivo. Si tu LCP en el P75 está bien en el iPhone 15 pero es terrible en un Xiaomi Redmi 9, es hora de ser honesto sobre para quién estás optimizando.