La importancia de la velocidad de carga para el posicionamiento SEO

La velocidad influye en el posicionamiento, pero no como un interruptor que sube tu web en Google al activarlo. Google mide cómo se vive una página con tres métricas, las Core Web Vitals, y las incluye entre las señales que sus sistemas de clasificación tienen en cuenta. Aun así, la relevancia del contenido pesa más. Donde una web lenta se nota antes es en el comportamiento de quien la visita: si la página tarda en mostrarse, no responde o se mueve mientras lees, el usuario se va.

Qué dice Google sobre velocidad y posicionamiento

La documentación de Google sobre experiencia de página es bastante concreta. Afirma que no existe una única «señal de experiencia de página»: sus sistemas principales de clasificación miran varias señales alineadas con esa experiencia, y las Core Web Vitals son una de ellas. Añade dos matices importantes. El primero, que tener buenos valores no garantiza aparecer en las primeras posiciones. El segundo, que la Búsqueda siempre intenta mostrar el contenido más relevante, aunque la experiencia de la página sea mejorable.

En la práctica, cuando varias páginas responden igual de bien a una consulta, la que carga y se usa mejor parte con ventaja. Una web rápida con un contenido flojo no adelanta a otra más lenta que da la mejor respuesta. Google recomienda, eso sí, que los propietarios de sitios consigan buenos resultados en Core Web Vitals para que les vaya bien en la Búsqueda y para ofrecer una buena experiencia en general. Si quieres el contexto de cómo llegó Google hasta aquí, lo explicamos en el artículo sobre la actualización de experiencia de página.

Qué se mide hoy: las tres Core Web Vitals

Estos son los umbrales oficiales que publica web.dev:

Métrica	Qué mide	Bueno	Necesita mejorar	Deficiente
LCP (Largest Contentful Paint)	Cuánto tarda en verse el elemento principal de la página, normalmente una imagen grande o un bloque de texto	hasta 2,5 s	de 2,5 a 4 s	más de 4 s
INP (Interaction to Next Paint)	Cuánto tarda la página en reaccionar tras un clic, un toque o una pulsación de tecla, a lo largo de toda la visita	hasta 200 ms	de 200 a 500 ms	más de 500 ms
CLS (Cumulative Layout Shift)	Cuánto se mueve el contenido de forma inesperada mientras se carga y se usa	hasta 0,1	de 0,1 a 0,25	más de 0,25

Los umbrales se evalúan en el percentil 75: para que una página se considere buena, al menos tres de cada cuatro visitas deben cumplirlos. No basta, por tanto, con que a ti te cargue rápido desde tu ordenador y tu fibra. Y una precisión que conviene tener clara: el INP sustituyó al FID como métrica oficial en marzo de 2024, así que cualquier guía que hable de FID está desfasada. Cómo interpretar cada resultado lo detallamos en esta guía para leer el test de Core Web Vitals.

Cómo medir la velocidad de tu web: datos de campo y de laboratorio

Antes de tocar nada hay que distinguir dos tipos de dato, porque pueden contradecirse y cada uno sirve para una cosa distinta.

• Datos de campo. Son mediciones de visitas reales, con sus dispositivos, redes y comportamientos. Proceden del Informe de experiencia del usuario de Chrome (CrUX), que trabaja con una ventana móvil de 28 días. Son los datos con los que Google evalúa las Core Web Vitals y los que muestran las herramientas que citamos abajo.
• Datos de laboratorio. Son una prueba simulada, con un dispositivo y una conexión fijos, como la que hace Lighthouse. Sirven para depurar y para comprobar un cambio antes de publicarlo, pero no recogen la variedad de tus visitantes reales. Según web.dev, esa es la razón de que ambos datos difieran: dispositivos distintos, usuarios que hacen scroll o interactúan, caché de visitas repetidas o funciones del navegador como la caché de página completa.

Con esa distinción, las herramientas encajan así:

• PageSpeed Insights analiza una URL y muestra los datos de campo, si hay suficientes, junto a una prueba de laboratorio. Cuando una URL no tiene tráfico suficiente, puede ofrecer los datos del conjunto del dominio, que no son los de esa página. Puedes ver cómo lo explica Google.
• El informe de Core Web Vitals de Search Console agrupa las URLs parecidas y las clasifica en buenas, mejorables o deficientes, para móvil y escritorio, con los datos de CrUX de 28 días. Necesita un mínimo de datos: una web nueva o con poco tráfico puede aparecer sin información.
• Lighthouse y las herramientas para desarrolladores del navegador son el laboratorio: no dicen cómo va tu web para los usuarios, pero ayudan a encontrar por qué va así.

La regla práctica es decidir con los datos de campo y depurar con los de laboratorio. Una puntuación de 100 en una prueba simulada no es el objetivo; lo es que las visitas reales pasen en verde. Y ten paciencia con los resultados: como la ventana es de 28 días, un arreglo tarda semanas en reflejarse del todo en el informe.

Velocidad y conversión: qué se puede decir y qué no

Es muy habitual encontrar frases como «cada segundo de retraso reduce las conversiones un tanto por ciento». Las hemos quitado de este artículo, porque el efecto depende del sector, del dispositivo y del tipo de página, y no existe una cifra universal con una fuente que la respalde.

Lo que sí hay son casos documentados. En 2021, Vodafone publicó en web.dev el resultado de un test A/B en una página de aterrizaje: una de las dos versiones, idénticas a la vista, estaba optimizada en rendimiento; según la propia compañía, una mejora del 31 % en LCP fue acompañada de un 8 % más de ventas. Es el caso de una empresa grande medido con rigor, no una promesa para tu web. Lo útil es la idea de fondo: se puede medir en tu propio sitio, comparando la tasa de conversión de tus páginas rápidas con la de las lentas o haciendo una prueba como esa. Medirlo así forma parte del trabajo de optimización CRO y UX.

Qué suele hacer lenta una web y cómo atacarlo

Cada métrica tiene sus causas típicas:

• LCP alto. Un servidor que responde tarde (hosting sobrecargado, sin caché), una imagen principal demasiado pesada o que empieza a cargar tarde, y CSS o JavaScript que bloquean el pintado. web.dev recomienda que la imagen principal se pueda descubrir en el HTML inicial, darle prioridad con el atributo fetchpriority="high" y no aplicarle carga diferida (lazy loading). Para repasar todas las fases, tiene una guía de optimización del LCP.
• INP alto. Demasiado JavaScript ejecutándose en el hilo principal: scripts de terceros (chats, mapas, etiquetas de seguimiento, ventanas emergentes), código que se carga y se procesa de golpe y eventos pesados. La solución es cargar menos, cargar más tarde y dividir las tareas largas.
• CLS alto. Imágenes y vídeos sin ancho y alto definidos, anuncios o incrustaciones que aparecen sin espacio reservado, fuentes web que cambian el aspecto del texto al cargar y contenido que se inserta de golpe, como un banner que empuja todo hacia abajo. Hay más detalle en la guía de web.dev para el CLS.

Más allá de las métricas, hay decisiones de base que lo condicionan todo. La calidad del hosting marca el tiempo de respuesta del servidor, que es el primer tramo del LCP. Las imágenes deben tener el tamaño que se muestra y un formato moderno como WebP o AVIF. La caché y la compresión de los archivos reducen lo que se descarga, y una CDN acerca los recursos al visitante. En WordPress, el origen habitual son los temas pesados y los plugins innecesarios; en estos consejos para WordPress tienes un repaso.

En nuestras auditorías es habitual que el problema no esté repartido por toda la web, sino concentrado en una o dos plantillas, como la portada con un carrusel pesado o la ficha de producto, y en imágenes demasiado grandes sobre la primera pantalla. Por eso conviene empezar por ahí y no por «optimizar todo».

Por dónde empezar

1. Abre el informe de Core Web Vitals de Search Console y mira primero el móvil. Apunta qué grupo de URLs falla y en qué métrica.
2. Pasa una URL representativa de ese grupo por PageSpeed Insights y revisa el diagnóstico de laboratorio.
3. Ataca la causa más grande de la métrica que falla. En el LCP, web.dev propone fijarse en cuál de sus cuatro fases es la más lenta: respuesta del servidor, inicio de la carga del recurso, descarga y pintado.
4. Publica el cambio, inicia la validación en Search Console y espera. No cambies diez cosas a la vez si quieres saber qué ha funcionado.

Y conviene saber cuándo parar: si tus tres métricas ya están en verde en datos de campo, mejorar más la velocidad no te va a subir posiciones por sí solo, y el esfuerzo rinde más en contenido o enlaces. Si tu web tiene poco tráfico y no aparecen datos de campo, usa el laboratorio como guía y no interpretes la falta de datos como un problema. Si quieres saber qué plantillas de tu web fallan y por qué, lo revisamos en una auditoría SEO.