Qué importancia tiene la velocidad de la página para el SEO | Estándares de aprobación de Google Core Web Vitals (LCP, FID, CLS)

Google ha confirmado oficialmente que los Core Web Vitals (LCP inferior a 2,5 segundos, FID inferior a 100 ms, CLS inferior a 0,1) son ahora una señal de clasificación clave, y el 75 % de las páginas móviles pierden así la oportunidad de alcanzar el Top 3.

Googlebot interrumpe el rastreo si el tiempo supera 1 segundo, lo que provoca un retraso de hasta el 47 % en la indexación de contenido nuevo. Cuando el tiempo de carga de una página aumenta de 1 segundo a 5 segundos, la tasa de rebote se dispara un 90 % (datos de Adobe), y el 53 % de los usuarios móviles abandonan la página inmediatamente si no se carga en 3 segundos.

HTTP Archive muestra que el LCP promedio mundial alcanza los 2,9 segundos (62 % no cumplen con el estándar), y cada reducción de 100 ms en el tiempo de respuesta del servidor aumenta la tasa de conversión en un 8,4 %.

LCP (Largest Contentful Paint)

Imagina que abres una página web y solo ves una pantalla en blanco o un icono de carga girando. Si pasan más de 3 segundos sin ver el contenido principal, ¿cerrarías la página? Google descubrió que si la página tarda más de 2,5 segundos en cargar, la probabilidad de que el usuario se vaya aumenta un 32%. Si supera 3 segundos, el 53 % de los usuarios móviles abandona inmediatamente.

Esto es LCP, que significa Largest Contentful Paint (Tiempo de carga del contenido más grande). Sirve para medir cuándo aparece el contenido más importante y grande de la página, como la imagen principal, un gran banner o un vídeo de portada. No mide el tiempo de carga completo de la página, sino cuánto tarda en aparecer el contenido principal que el usuario nota primero.

¡Cada segundo que se retrasa el LCP puede reducir la tasa de conversión en un 7%!

¿Cuál es el límite aceptable para LCP?

Google clasifica el rendimiento del LCP en tres niveles, diferenciados por colores:

Excelente (Verde): ≤ 2,5 segundos

—— Este es el objetivo. Google requiere que al menos el 75 % de los visitantes experimenten este tiempo de carga para que la página se considere una “buena experiencia”.

Necesita mejorar (Amarillo): 2,5–4 segundos

—— Más de una cuarta parte de los usuarios percibirá la página como lenta, la tasa de rebote aumentará entre un 5–10%, y el ranking de búsqueda puede verse afectado.

Deficiente (Rojo): > 4 segundos

—— La experiencia es muy mala. Hasta la mitad de los usuarios puede abandonar la página inmediatamente, la tasa de conversión puede ser 20–30% más baja, y el ranking de búsqueda caerá significativamente.

Cómo comprobar la puntuación LCP de tu sitio web

• PageSpeed Insights (PSI): Ingresa la URL para ver el valor exacto de LCP, la codificación por colores y los datos de usuarios reales.

• Lighthouse: Disponible en las herramientas de desarrollo de Chrome, permite simular la velocidad de carga y proporciona la puntuación LCP (objetivo: 90+).

• Extensión Web Vitals: Extensión de Chrome que muestra LCP, FID y CLS en tiempo real.

• Informe de Search Console: Resume el rendimiento de LCP de todas las páginas de tu sitio web en los últimos 28 a 90 días y te ayuda a identificar qué páginas necesitan optimización.

Objetivo muy claro: Mantener el LCP por debajo de 2,5 segundos y asegurarse de que al menos el 75% de las visitas alcancen esta velocidad.

Problemas comunes de LCP

Hay muchas razones por las que LCP puede ser lento. A continuación, las más comunes:

Respuesta del servidor lenta (TTFB demasiado alto)

—— Si el servidor responde lentamente, el contenido de la página no se carga rápidamente. El TTFB (Time To First Byte) debería estar idealmente por debajo de 200 ms y no superar 500 ms.

Factores que influyen:

• Bajo rendimiento del servidor
• Consultas lentas a la base de datos
• No usar CDN o CMS demasiado pesado

Recursos del primer vistazo demasiado grandes o lentos

• Imágenes/Vídeos demasiado grandes: 2MB, 5MB o más, especialmente imágenes grandes en la página de inicio. Usar formatos WebP o AVIF puede reducir el tamaño 30%-50%.

JavaScript/CSS bloqueando el renderizado: JS demasiado grande o sin defer/async, y un orden de carga de CSS incorrecto, pueden bloquear la carga del contenido principal.

Orden de carga de recursos desordenado

—— El navegador no sabe qué imagen es el elemento LCP principal, lo que hace que se carguen primero contenidos menos importantes. La solución es usar preload o fetchpriority="high" para indicar al navegador cuál es el elemento prioritario.

Problemas de renderizado del lado del cliente (CSR)

—— En páginas construidas con React/Vue, si no se hace renderizado del lado del servidor, el usuario ve inicialmente una pantalla en blanco hasta que se ejecuta el JS. Los paquetes JS grandes (más de 1MB) y la ejecución lenta pueden hacer que LCP supere fácilmente los 4 segundos.

No usar CDN o CDN mal configurado

—— Los usuarios que están lejos del servidor (por ejemplo, usuarios en China accediendo a un servidor en EE. UU.) experimentan carga lenta. Un CDN distribuye recursos más cerca del usuario, acelerando significativamente la velocidad.

Demasiados scripts de terceros o muy pesados

—— Publicidad, herramientas de análisis, rastreadores, etc., ocupan el hilo principal y retrasan el renderizado de la página. Un solo script publicitario puede ralentizar la página más de 500 ms.

Cómo optimizar el LCP

Mejorar la velocidad de respuesta del servidor (TTFB)

Usar un CDN: Distribuye imágenes, CSS y JS a través de Cloudflare u otros CDN. Esto reduce la carga del servidor y acelera la respuesta. La velocidad de acceso global puede mejorar un 30%-70%.

Optimizar el rendimiento del servidor: Aumenta la memoria, optimiza la base de datos, usa caché (Redis, Memcached) y actualiza el entorno de ejecución.

Elegir un buen hosting: ¿El hosting compartido es lento? Cambia a VPS o hosting en la nube optimizado. Gastar unos pocos euros más al mes puede acelerar el LCP un segundo y mejorar significativamente la tasa de conversión.

Optimizar imágenes y videos

Identificar el elemento de contenido más grande (LCP): Normalmente es la imagen o el video principal de la primera pantalla. Usa herramientas para localizarlo.

Estrategias de optimización de imágenes:

• Tamaño adecuado: No uses imágenes grandes en pantallas pequeñas. Usa imágenes pequeñas en móviles y grandes en escritorio.
• Formatos modernos: Usa WebP o AVIF en lugar de JPG/PNG para reducir significativamente el tamaño del archivo.
• Compresión: Usa herramientas como Squoosh para reducir el tamaño a unos pocos cientos de KB.
• Carga diferida (Lazy loading): Las imágenes debajo de la primera pantalla deben usar loading="lazy". ¡Pero no uses lazy loading en la imagen LCP!

Ajustar la prioridad de carga de recursos

• Precargar recursos clave: Usa <link rel="preload"> para cargar primero los elementos LCP (imágenes, CSS, fuentes).
• Aumentar prioridad: Usa fetchpriority="high" para indicar al navegador qué recursos son más importantes.
• Cargar JS no esencial de manera asincrónica: Scripts de publicidad o análisis deben usar async o defer para no bloquear el hilo principal.

Reducir bloqueo de renderizado

• CSS crítico en línea: Los estilos necesarios para la primera pantalla deben ir directamente en el HTML, idealmente menos de 15 KB.
• Renderizado del lado del servidor (SSR) o generación estática (SSG): Proyectos React/Vue usando Next.js o Nuxt.js generan HTML con contenido desde el servidor, permitiendo reducir el LCP de 4–6 segundos a 1–2 segundos.

Gestionar scripts de terceros

• Simplificar y revisar: Usa herramientas para identificar scripts lentos (carga >500ms o ejecución >300ms). Elimina los que sea posible o reemplaza por versiones más ligeras.
• Carga diferida: Scripts no esenciales deben ejecutarse después de que la página haya cargado (por ejemplo, después de window.onload).
• Aislamiento con sandbox: Usa iframe para aislar scripts de alto riesgo y que no afecten el rendimiento de la página principal.

FID (First Input Delay – Retardo de la primera interacción)

Cuando un usuario hace clic por primera vez en un botón de la página web (por ejemplo, “Comprar ahora” o “Abrir menú”), si la página tarda más de 300 ms en responder, el 76 % de los usuarios sentirá que la página está lenta.

Este tiempo de espera se llama FID (Retardo de la primera interacción). Mide el tiempo entre la primera interacción del usuario y el momento en que el navegador comienza a responder.

El FID no mide cuánto tarda en ejecutarse todo el script, sino si el “hilo principal” del navegador está ocupado con otras tareas, impidiendo que responda inmediatamente a la interacción del usuario.

¿Por qué se produce la lentitud?

Porque el navegador solo puede realizar una tarea a la vez (solo tiene un hilo principal). Cuando haces clic en la página, si el hilo principal está ejecutando otra tarea, como cargar un script publicitario grande, tu clic tendrá que esperar hasta que esa tarea termine.

Los datos móviles de Google de 2023 muestran:

• Si el FID supera los 300 ms, la tasa de conversión disminuye un 22 %

• Cada 100 ms adicionales de retraso aumentan la probabilidad de que el usuario abandone la página en un 8 %

• En páginas de pago de comercio electrónico, si el FID supera los 250 ms, la tasa de abandono del carrito aumenta un 18 %

📌 El FID mide el tiempo real desde el primer clic, toque o entrada de teclado del usuario hasta la respuesta del navegador. Las pruebas simuladas no pueden reproducir esto completamente; el análisis debe basarse en datos de usuarios reales (RUM).

¿Cuántos milisegundos se consideran “fluido”?

Los Core Web Vitals de Google establecen los estándares de FID basados en los datos de usuarios reales de los últimos 28 días:

Límite de aprobación:
Al menos el 75% de las visitas deben ocurrir en menos de 100ms, especialmente en móviles.

Herramientas recomendadas:

• Informe de Experiencia del Usuario de Chrome (CrUX): Ver la distribución de datos FID de todo el dominio

• PageSpeed Insights: Combina datos simulados y datos reales

• Search Console: Verificar el porcentaje de páginas que cumplen con el estándar

¿Por qué no responden los clics?

🔸 Las tareas largas ocupan el hilo principal

Cualquier script JS que se ejecute más de 50ms se considera una “tarea larga”.
Por ejemplo, cargar un script de publicidad no optimizado puede bloquear el hilo principal por más de 400ms, durante los cuales los clics de los usuarios se ignoran completamente.

🔸 Archivos JS demasiado grandes

Cargar archivos JS de más de 500KB, especialmente en móviles de gama baja, puede tardar 800ms solo en analizarse.
Esto es especialmente evidente al usar frameworks como React o Vue, sobre todo durante la fase de hidratación al cargar la página.

🔸 Demasiados scripts de terceros

En promedio, una página carga más de 22 recursos de terceros.
Por ejemplo, los plugins de redes sociales varían mucho en móviles de gama baja, con tiempos de ejecución entre 200ms y 800ms.

🔸 CPU demasiado cargada

Por ejemplo, en un móvil de gama media (Snapdragon 6 series), si el hilo principal está ocupado más del 80%, los clics del usuario entrarán en cola y el tiempo de espera puede variar entre 150ms y 1200ms.

💡 Herramientas recomendadas:

Usa el panel de Rendimiento de Chrome DevTools para revisar tareas largas y el diagrama de cascada del hilo principal.

¿Cómo hacer que las interacciones sean fluidas?

✅ Método 1: Dividir las tareas largas

Antes, una tarea tardaba 120ms en ejecutarse, lo que impedía que el navegador respondiera a las acciones del usuario.

// Después de dividir, limitar cada procesamiento a 30ms como máximo
function chunkedProcess() {
let index = 0;
function doChunk() {
const start = Date.now();
while (index < data.length && Date.now() – start < 30) {
processItem(data[index++]);
}
if (index < data.length) {
setTimeout(doChunk, 0); // liberar el hilo principal
}
}
doChunk();
}

Resultado: Una tarea que originalmente tardaba 250ms ahora se comprime a un máximo de 32ms, y el FID disminuyó en 85%

✅ Método 2: Optimizar la prioridad de carga de JS

Colocar el código JS crítico directamente en el HTML (menos de 15KB)

Cargar los scripts JS no críticos de manera diferida

<!– Scripts no necesarios para la primera pantalla se cargan después –>
<script defer src=”non-critical.js”></script>

<!– Scripts de publicidad o análisis se inyectan después de que la página carga –>
<script>
window.addEventListener(‘load’, () => {
const script = document.createElement(‘script’);
script.src = “ads.js”;
document.body.appendChild(script);
});
</script>

Resultado: La carga en el hilo principal se reduce en 40%~70%

✅ Método 3: Ejecutar código de terceros “aislado”

Usar un iframe sandbox:<iframe sandbox=”allow-scripts” src=”third-party-ad.html”></iframe>

De esta forma, el código de terceros no interfiere con el hilo principal.

• Usar Web Worker para tareas pesadas

// Hilo principal
const worker = new Worker(‘crypto-worker.js’);
worker.postMessage(data);

// El worker procesa las tareas pesadas
self.onmessage = (e) => {
const result = heavyCryptoWork(e.data);
self.postMessage(result);
};

Resultado: Por ejemplo, una tarea de cifrado reduce el tiempo del hilo principal de 300ms a 20ms

CLS (Cumulative Layout Shift)

¿Alguna vez has abierto una página web y de repente la página se mueve, haciendo que hagas clic en el botón equivocado? Esto es un problema de CLS.

CLS significa Cumulative Layout Shift (Desplazamiento acumulativo del diseño), y mide la estabilidad visual de una página durante la carga. La puntuación va de 0 a 1, cuanto más baja, más estable es la página; cuanto más alta, más frecuentes son los saltos. Google recomienda: una puntuación CLS inferior a 0,1 es ideal, inferior a 0,05 es excelente, y si supera 0,25 debe optimizarse de inmediato.

¿Por qué merece atención el CLS? Porque afecta directamente la experiencia del usuario e incluso puede causar pérdidas de ingresos. Por ejemplo:

• Cuando el CLS supera 0,2, la tasa de rebote aumenta en promedio un 25% y la tasa de conversión disminuye un 18%;

• Si la carga de la página se retrasa solo 100 milisegundos, el riesgo de CLS aumenta un 15%;

• Las imágenes sin tamaño predefinido representan el 65% de los eventos que generan CLS;

• Si se puede reducir el CLS a menos de 0,05, la retención de usuarios puede aumentar un 20% y el tiempo promedio de sesión aumenta 30 segundos.

Límites de CLS

Google ha establecido límites claros para el CLS: menor a 0,1 = aceptable, menor a 0,05 = excelente, mayor a 0,25 = alerta. Y el 90% de los sitios web a nivel mundial fijan su objetivo por debajo de 0,1, por una buena razón.

Los datos muestran: las páginas con CLS < 0,1 tienen una tasa de abandono promedio de solo 5%; mientras que las páginas con CLS > 0,25 pueden llegar hasta 30%. Especialmente para sitios de comercio electrónico y noticias, la mediana de CLS debe mantenerse por debajo de 0,08, y la desviación estándar no debe superar 0,02, de lo contrario se verán afectadas el ranking y el tráfico.

Los problemas de carga diferida tampoco se deben ignorar. Si los elementos de la página se cargan con un retraso de 0,3 segundos, la puntuación de CLS aumenta aproximadamente 0,05; y si los anuncios no tienen dimensiones establecidas (por ejemplo, 400px × 200px), el CLS puede subir a 0,15.

Desde el punto de vista económico, cumplir con los estándares de CLS puede aumentar de forma estable la tasa de conversión en un 10% y el ROI en un 8%. Estadísticamente, el 65% de los sitios web tienen un CLS promedio de 0,12, pero hay que tener en cuenta que la mediana para aprobar es 0,07, y las páginas con picos superiores a 0,4 requieren en promedio 3 días para corregirse, con un costo de aproximadamente 500 USD.

Además, la precisión del CLS también debe considerar las diferencias de dispositivos y la complejidad de la página. Cuando la página tiene más de 100 elementos, el rango de tolerancia del CLS debe mantenerse dentro de ±0,02 y la precisión alcanzar el 95%. De lo contrario, la tasa de rebote puede aumentar un 25% y las ganancias disminuir un 10%.

Problemas comunes de CLS

La primera categoría es carga de contenido dinámico. Por ejemplo, los anuncios o ventanas emergentes, si no tienen un tamaño fijo, pueden empujar otros elementos de la página al cargarse. En estos casos, la puntuación de desplazamiento está entre 0,1 y 0,15 y representa hasta el 60%, y cada vez puede provocar una pérdida del 5% de la interacción del usuario.

La segunda categoría es retraso de scripts de terceros. Muchos sitios cargan scripts externos para atención al cliente en línea o análisis de datos, lo que provoca un retraso de 200 ms y aumenta el CLS en 0,05. El 75% de los sitios web ven afectada la experiencia del usuario debido a esto. Por ejemplo, un script de comercio electrónico que usa 10 Mbps de ancho de banda hace que la página tarde 4 segundos en cargar, el CLS suba a 0,25 y la tasa de rebote aumente un 20%.

La tercera categoría es imágenes/videos sin tamaño definido. Contenido de 800px × 600px sin dimensiones definidas puede desplazar fácilmente otros componentes al cargarse, representando el 45% de los eventos de desplazamiento, con variaciones de CLS ±20%. En una muestra de 50 páginas, la tasa de desviación superó el 70% y el costo de corrección fue de aproximadamente 200 USD por caso.

Luego, tenemos superposición de elementos. Si varios divs de 100px de altura están densamente dispuestos, la carga de la página aumenta un 50% y el riesgo de CLS sube un 30%.

También hay factores temporales: si la carga de recursos supera los 500 ms, cada 10 solicitudes adicionales aumentan el CLS en 0,03; si un anuncio se actualiza automáticamente cada 30 segundos, el CLS puede alcanzar un pico de 0,35.

Si estos problemas no se corrigen a tiempo, se podrían perder entre el 5% y el 10% de los ingresos mensuales, y el CLS podría empeorar un 2% semanalmente.

Cómo mejorar eficazmente el CLS

Paso 1: Comienza por lo básico: “definir tamaños”. Todas las imágenes, anuncios y componentes de video deben tener previamente definidos ancho y alto (por ejemplo, 400px × 250px), lo que reduce en un 40% los problemas de desplazamiento. Usar la propiedad CSS max-width: 100% no solo mejora la adaptabilidad, sino que también acelera la carga aproximadamente 0,2 segundos y reduce el riesgo de CLS en un 35%.

Paso 2: Optimizar la carga de recursos. Comprimir imágenes a menos de 500KB reduce la frecuencia de activación en un 70% y disminuye el CLS en 0,1; además, mantener fuentes, videos y otros recursos por debajo de 10MB y con tiempos de carga inferiores a 100 ms reduce la probabilidad de desplazamiento en un 30%.

Paso 3: Gestionar scripts de terceros. Se recomienda utilizar carga asíncrona o diferida, por ejemplo, retrasando 500 ms la carga de herramientas externas. Esto optimiza la frecuencia de activación, reduce el CLS medio a 0,05 y aumenta la tasa de conversión en un 10%.

El contenido dinámico también debe insertarse “suavemente”. Se puede añadir una transición animada de 50 ms o reservar un 20% de espacio de reserva, reduciendo el error CLS a ±0,01 y asegurando un proceso de carga fluido.

Paso 4: Usar herramientas de prueba adecuadas. Se recomienda Lighthouse y Chrome DevTools, con una precisión de hasta el 95%. Hacer un seguimiento durante una semana y realizar un análisis de regresión ayuda a identificar los objetivos de optimización más importantes.

Costos: El costo promedio de corregir CLS es de aproximadamente 50 USD por caso, y el ciclo de optimización solo toma 1 día. Los beneficios son notables: retención de usuarios aumenta un 15%, la vida útil del sitio se extiende 2 años, el CLS medio disminuye de 0,15 a 0,06, la desviación se reduce a la mitad y los ingresos finales aumentan un 5%.

¡Usa PageSpeed Insights para analizar tu sitio ahora, y en solo 30 minutos encontrarás los puntos de optimización más importantes!