Velocidad web y SEO: impacto real en 2026 - Ighenatt Blog

Hay algo que cambia cuando empiezas a revisar velocidad de verdad: dejas de hablar de “puntuaciones” y empiezas a hablar de causas. En nuestra experiencia, la mayoría de sitios lentos tienen el mismo conjunto de problemas (imágenes sin optimizar, JavaScript que bloquea el renderizado, un TTFB alto por el servidor), pero los propietarios suelen conocer el síntoma sin haber tocado la raíz.

Google mide la velocidad con datos de campo reales, no con tu puntuación de laboratorio. Eso significa que el dispositivo de tu usuario, su red y la geografía desde la que carga cuentan. Un 90 en PageSpeed Insights puede coexistir con un LCP de 4 segundos en el percentil 75.

Lo que este artículo cubre no es genérico: son los factores de velocidad que más correlacionan con posiciones y conversiones, con el orden en que deberías atacarlos.

La relación entre velocidad web y SEO: qué dice Google oficialmente

Google ha sido explícito sobre la importancia de la velocidad web. En enero de 2018, la Speed Update confirmó que la velocidad de carga en mobile es una señal de ranking. En 2021, los Core Web Vitals se convirtieron en parte de las señales de experiencia de página, reforzando esa posición.

La documentación de Google Search Central lo plantea así: la velocidad no es el factor principal de ranking (la relevancia del contenido lo sigue siendo), pero es la señal de desempate. Cuando dos páginas compiten por la misma posición y ofrecen contenido de calidad similar, la más rápida gana.

Hay un matiz importante que muchos ignoran: Google no usa la puntuación de laboratorio de PageSpeed Insights para el ranking. Usa los datos de campo del Chrome UX Report (CrUX), que refleja la experiencia real de usuarios con Chrome. Un sitio puede tener 95 en PageSpeed Insights en laboratorio y fallar en datos de campo si sus usuarios reales navegan con conexiones lentas o dispositivos de gama baja.

Las tres métricas de Core Web Vitals que Google mide actualmente son:

• LCP (Largest Contentful Paint): el tiempo hasta que el elemento visual más grande es visible. Objetivo: menos de 2.5 segundos.
• INP (Interaction to Next Paint): la latencia de respuesta a interacciones del usuario. Objetivo: menos de 200 milisegundos.
• CLS (Cumulative Layout Shift): la estabilidad visual de la página. Objetivo: menos de 0.1.

Cómo la velocidad afecta al CTR y la conversión

El estudio Milliseconds Make Millions de Google y Deloitte analizó el impacto de mejoras de velocidad de tan solo 0.1 segundos en sitios de retail y viajes. Los resultados fueron concretos: un 8.4% más de conversiones en retail y un 10.1% en viajes. No es un cambio menor para negocios que procesan miles de transacciones al día.

Google publicó que el 53% de los usuarios mobile abandona un sitio si tarda más de 3 segundos en cargar. Este dato se traduce directamente en bounce rate, una métrica que Google observa como señal indirecta de calidad.

WPO Stats, un repositorio de casos reales de optimización de rendimiento web, documenta decenas de ejemplos verificables:

• Pinterest redujo el tiempo de espera percibido un 40% y aumentó el tráfico de búsqueda y los registros un 15%.
• BBC comprobó que perdía un 10% de usuarios por cada segundo adicional de carga.
• Vodafone mejoró su LCP un 31% y aumentó las ventas un 8%.

La velocidad afecta al tráfico orgánico por dos vías: directa (mejor ranking) e indirecta (páginas rápidas generan mejor engagement, más páginas por sesión y más enlaces naturales, factores que retroalimentan el posicionamiento).

Las 5 causas más frecuentes de una web lenta

1. Imágenes sin optimizar

Según HTTP Archive, las imágenes representan el 50% del peso total de una página media. Muchos sitios sirven imágenes en PNG o JPEG sin comprimir, en resoluciones que exceden el viewport del dispositivo. La solución es usar formatos modernos como WebP o AVIF, aplicar compresión con pérdida aceptable y servir imágenes adaptadas al tamaño de pantalla con srcset.

2. JavaScript excesivo o no utilizado

El JavaScript no solo tarda en descargarse: tarda en parsearse y ejecutarse. Un sitio con 2 MB de JS tiene un problema de rendimiento en dispositivos móviles de gama media, donde el procesador necesita tiempo real para interpretar cada script. Las auditorías de Lighthouse identifican el JS no utilizado, que puede superar el 50% del total descargado en sitios con múltiples plugins o dependencias.

3. Servidor lento o mal configurado

Un TTFB (Time to First Byte) superior a 600 ms indica problemas de servidor: hosting compartido saturado, bases de datos sin optimizar o falta de caché en servidor. Un CDN reduce el TTFB entre un 40% y un 70% dependiendo de la distancia geográfica, pero no corrige un backend ineficiente.

4. CSS que bloquea el renderizado

Los archivos CSS se descargan y procesan antes de que el navegador pueda pintar la página. Un archivo CSS de 200 KB con estilos para toda la aplicación, incluidos componentes que no aparecen en la página actual, añade latencia innecesaria. La solución es el CSS crítico inline y la carga diferida del resto.

5. Ausencia de caché del navegador

Sin cabeceras de caché adecuadas, cada visita obliga al navegador a descargar todos los recursos desde cero. Configurar Cache-Control con tiempos largos para assets estáticos (imágenes, fuentes, CSS, JS) y tiempos cortos para HTML reduce drásticamente los tiempos de carga en visitas repetidas.

Cómo medir la velocidad de tu web correctamente

Existen dos tipos de medición: datos de laboratorio y datos de campo. Ambos son necesarios pero miden cosas distintas.

Herramientas de laboratorio (condiciones controladas)

• Google PageSpeed Insights: el punto de partida. Muestra datos de laboratorio y datos de campo (cuando están disponibles).
• Lighthouse: integrado en Chrome DevTools. Proporciona auditorías de rendimiento, accesibilidad y SEO.
• WebPageTest: permite pruebas desde diferentes ubicaciones y dispositivos con cascadas de red detalladas.

Datos de campo (experiencia real de usuarios)

• Chrome UX Report (CrUX): los datos que Google usa para ranking. Accesibles desde PageSpeed Insights o BigQuery.
• Google Search Console: la sección Core Web Vitals muestra el estado de tus URLs agrupadas por estado (bueno, necesita mejoras, pobre).

Las métricas de campo son las que realmente importan para SEO. Un sitio puede tener una puntuación de laboratorio perfecta y fallar en campo porque sus usuarios reales navegan con conexiones 3G o dispositivos con poca memoria RAM.

Velocidad web en mobile vs desktop: prioridades distintas

Google usa mobile-first indexing desde 2019. La versión mobile de tu sitio es la que Google indexa y evalúa. Un sitio rápido en desktop pero lento en mobile tiene un problema de SEO.

Las diferencias técnicas entre mobile y desktop afectan directamente al rendimiento:

• Ancho de banda: una conexión 4G media ofrece 20 Mbps frente a los 100+ Mbps de una conexión de fibra. Los recursos pesados tardan más en descargarse.
• CPU: un procesador mobile de gama media es entre 3x y 5x más lento que un procesador de escritorio para parsear y ejecutar JavaScript.
• Memoria: los dispositivos móviles tienen menos RAM, lo que limita el número de recursos que el navegador puede procesar en paralelo.

La optimización mobile requiere presupuestos más estrictos: menos de 200 KB de JavaScript, menos de 100 KB de CSS y menos de 500 KB de imágenes en el viewport inicial.

Casos reales: webs que mejoraron velocidad y multiplicaron su tráfico

Caso 1: ecommerce de moda (España). Un retailer con 15.000 productos migró de un hosting compartido a una infraestructura con CDN, optimizó imágenes con WebP y eliminó 800 KB de JavaScript no utilizado. Resultado: LCP de 4.2s a 1.8s, bounce rate del 58% al 34%, y un incremento del 23% en tráfico orgánico en 4 meses.

Caso 2: portal de noticias. Un medio digital con 200.000 visitas mensuales implementó lazy loading en imágenes, CSS crítico inline y preconnect a dominios de terceros. El LCP cayó de 3.6s a 2.1s, y las páginas por sesión aumentaron de 2.1 a 3.4.

Caso 3: SaaS B2B. Una empresa de software eliminó un widget de chat que añadía 400 KB de JS, comprimió sus assets con Brotli y activó HTTP/2. El TTFB bajó de 820 ms a 190 ms, y el ranking medio de sus landing pages subió de la posición 14 a la 8 en 3 meses.

Estos ejemplos tienen un patrón común: las mejoras de velocidad no solo afectan al ranking, sino que mejoran todas las métricas de engagement que Google observa como señales indirectas.

Hoja de ruta para mejorar la velocidad de tu web

Una mejora de rendimiento web efectiva sigue un orden de prioridad basado en impacto y esfuerzo:

Fase 1: ganancias inmediatas (1-2 días)

• Comprimir y convertir imágenes a WebP/AVIF.
• Activar compresión Brotli o Gzip en el servidor.
• Configurar cabeceras de caché para assets estáticos.
• Eliminar recursos de terceros no utilizados (widgets, trackers, fuentes innecesarias).

Fase 2: optimizaciones de medio plazo (1-2 semanas)

• Implementar lazy loading en imágenes below-the-fold.
• Extraer e inline el CSS crítico.
• Diferir la carga de JavaScript no esencial.
• Implementar un CDN con nodos en la región de tu audiencia.

Fase 3: mejoras estructurales (1-3 meses)

• Migrar a un hosting con mejor rendimiento si el TTFB es superior a 400 ms.
• Auditar y reducir el JavaScript total (code splitting, tree shaking).
• Implementar un service worker para caché offline.
• Evaluar la arquitectura del frontend: frameworks pesados generan sitios lentos.

Cada fase debe incluir mediciones antes y después con las mismas herramientas y condiciones para verificar el impacto real. Los datos del servicio de optimización de Core Web Vitals muestran que la Fase 1 por sí sola resuelve el 60% de los problemas de velocidad en sitios típicos.

Preguntas frecuentes sobre velocidad web y SEO

¿Cuánto afecta la velocidad de carga al SEO?

La velocidad es una señal de ranking confirmada por Google. No es el factor más importante (el contenido relevante sigue siendo el primero), pero es el factor de desempate y afecta indirectamente al SEO a través de métricas de comportamiento: mayor bounce rate, menor tiempo en página y menor número de páginas vistas.

¿Qué puntuación en PageSpeed Insights es buena?

Una puntuación de 90 o superior en PageSpeed Insights se considera buena. Entre 50 y 89 necesita mejoras. Por debajo de 50 es pobre. La puntuación de laboratorio no es lo que Google usa para ranking: para eso mira los datos de campo del Chrome UX Report.

¿Es mejor usar un CDN para mejorar la velocidad?

Un CDN mejora la velocidad para usuarios geográficamente alejados del servidor, reduciendo el TTFB entre un 40% y 70%. Para un sitio con audiencia en España, un CDN con nodos en Europa es suficiente. Si la audiencia es global, un CDN con presencia mundial es imprescindible.

¿Los plugins de caché en WordPress son suficientes?

Los plugins de caché son un buen primer paso, pero no resuelven todos los problemas de velocidad. No pueden optimizar imágenes ya cargadas, no eliminan JavaScript no utilizado, y no corrigen problemas de servidor. Son una capa de mejora, no una solución completa.

La velocidad web requiere monitorización continua. Cada actualización de contenido, cada nuevo plugin y cada cambio de diseño puede afectar al rendimiento, y los datos de campo del CrUX reflejan esos cambios con un retraso de 28 días. Ejecuta PageSpeed Insights en tus diez páginas con más tráfico ahora mismo. Si alguna da LCP por encima de 2,5 segundos o CLS superior a 0,1, tienes un problema concreto que resolver. Dinos qué has encontrado y te indicamos por dónde empezar.