Cómo influye el tiempo de carga en el posicionamiento: Core Web Vitals

Sí, el tiempo de carga influye en el posicionamiento en Google, pero menos de lo que se suele vender. Google usa las Core Web Vitals (LCP, INP y CLS) en sus sistemas de posicionamiento, aunque deja claro que siempre intenta mostrar el contenido más relevante, «aunque la experiencia en la página sea deficiente». La velocidad pesa cuando hay muchas páginas igual de útiles compitiendo por la misma búsqueda. Una web rápida no compensa un contenido flojo, y una lenta tampoco hunde a la mejor respuesta.

De la «velocidad del sitio» a las Core Web Vitals

Escribí la primera versión de esta entrada en abril de 2010, cuando Google anunció en su blog que añadía la velocidad del sitio como señal de posicionamiento. Google ya avisaba entonces de que no tenía tanto peso como la relevancia de una página y de que afectaba a menos del 1% de las consultas.

Hoy no se habla de un único «tiempo de carga». Google mide la experiencia real de los usuarios con tres métricas, y su documentación de Search Central fija lo que considera una buena experiencia:

Métrica	Qué mide	Bueno si
LCP (Largest Contentful Paint)	Cuánto tarda en verse el contenido principal	Menos de 2,5 segundos
INP (Interaction to Next Paint)	Cuánto tarda la página en responder cuando tocas o haces clic	Menos de 200 milisegundos
CLS (Cumulative Layout Shift)	Cuánto se mueve el contenido mientras carga	Menos de 0,1

INP sustituyó en 2024 a la antigua FID como métrica de respuesta. Según web.dev, una página aprueba cuando cumple los tres objetivos en el percentil 75 de las visitas, separando móvil y ordenador. O sea, tiene que ir bien para la gran mayoría de tus visitantes, no solo en tu ordenador con fibra.

Cuánto pesan de verdad en Google

La página de Google sobre experiencia en la página responde a esto sin rodeos. Sus sistemas de posicionamiento usan las Core Web Vitals, pero no hay una única señal de experiencia, y sacar buena nota en Search Console o en otras herramientas «no garantiza que tus páginas vayan a aparecer al principio de los resultados». Y añade que es posible que perseguir una puntuación perfecta solo por SEO «no sea la mejor forma de invertir tu tiempo».

Mi lectura: arregla lo que esté en rojo, porque eso sí lo notan tus visitantes, y no te obsesiones con pasar de 90 a 100 en una herramienta. Ese tiempo rinde más escribiendo mejor.

Cómo medirlas

PageSpeed Insights analiza cualquier URL y te da dos tipos de datos. Los de campo salen de usuarios reales de Chrome durante los últimos 28 días, y solo aparecen si hay datos suficientes, cosa que no pasa con páginas nuevas o con poco tráfico. Los de laboratorio son una prueba con Lighthouse, útiles para depurar y encontrar qué está fallando. Cuando no coinciden, mira primero los de campo, que son los de tus visitantes.

Si la web es tuya, el informe «Core Web Vitals» de Search Console te enseña el rendimiento con datos de uso reales, agrupando URLs parecidas. Cada grupo toma el estado de su peor métrica: si el CLS es deficiente y el INP bueno, el grupo sale como «Deficiente». Solo incluye URLs indexadas con un mínimo de datos, así que en una web con poco tráfico puede no mostrar nada.

Por dónde empezar a mejorar

Para el LCP, la guía de web.dev para optimizarlo recuerda que un tiempo hasta el primer byte alto, por ejemplo por varias redirecciones o por no poder usar la caché, puede hacer imposible bajar de 2,5 segundos. También avisa de que nunca hay que aplicar la carga diferida (loading="lazy") a la imagen principal de la página, porque retrasa su carga.

Para el CLS, el fallo más típico son las imágenes sin dimensiones. Ponerles siempre los atributos width y height permite al navegador reservar el espacio correcto mientras se carga la imagen, y así el texto no salta:

<img src="portada.webp" width="1200" height="630" alt="Descripción de la imagen">

Para el INP, el problema suelen ser las tareas largas de JavaScript que bloquean el hilo principal del navegador. En una web con WordPress, lo primero que miraría son los plugins y los scripts de terceros que se cargan en todas las páginas aunque no hagan falta.

Los trucos que daba aquí en 2010, como juntar imágenes en sprites o unir todos los JavaScript en uno, hoy los dejaría para después de medir. Primero datos reales, y luego a por la métrica que esté peor.

Revisado y actualizado en octubre de 2026.