Velocidad web y SEO: por qué la carga lenta te hace perder posiciones (y cómo solucionarlo)
Cuando audito una web por primera vez —un restaurante de Gràcia, una clínica de Tarragona o una tienda online de Sabadell— lo primero que miro no es el contenido ni los backlinks. Miro la velocidad. Y en la mayoría de los casos es el problema más grande que nadie ha tocado nunca. La velocidad web es un factor de posicionamiento SEO confirmado por Google, pero su impacto va mucho más allá del ranking: determina cuántos usuarios se quedan, navegan y acaban comprando o contactando.
Qué mide Google exactamente (y cómo lo compruebas tú)
Google no mide el tiempo total de carga como hacía hace diez años. Ahora evalúa la experiencia percibida: cuándo aparece el primer contenido útil, cuándo el usuario puede hacer clic sin errores y si la página «salta» mientras carga. Tres herramientas que deberías tener abiertas ahora mismo:
- Google PageSpeed Insights: entra la URL de tu portada y de tu página de servicio o producto principal. Muchos negocios optimizan la portada y olvidan las páginas que realmente convierten. La puntuación en móvil es la que cuenta: Google indexa en modo mobile-first.
- Google Search Console → Experiencia de página → Core Web Vitals: aquí ves cuántas URLs reales de tu sitio están en «Deficiente», «Necesita mejora» o «Buena». Esto no es una simulación: son datos de usuarios reales con Chrome. Si tienes URLs en rojo, Google ya sabe que tu web es lenta.
- GTmetrix: útil para identificar exactamente qué recurso —una imagen concreta, un script de terceros, una fuente web— es el que bloquea la carga. PageSpeed te dice el «qué»; GTmetrix te ayuda con el «cuál».
| Métricas objetivo | LCP < 2,5 s · INP < 200 ms · CLS < 0,1 |
|---|---|
| Puntuación PageSpeed móvil | Mínimo 70 · Ideal ≥ 85 |
| Dónde lo ves en Search Console | Experiencia de página → Core Web Vitals |
| Frecuencia de revisión | Mensual o después de cualquier cambio importante |
Core Web Vitals: las tres métricas que importan
Desde 2021, Google utiliza tres indicadores para evaluar la velocidad y la estabilidad de cualquier página. Entender cada uno te ayuda a saber dónde actuar primero, en lugar de tocarlo todo a ciegas.
Un detalle que muchos artículos pasan por alto: el LCP se calcula sobre datos reales de usuarios (Chrome User Experience Report), no sobre simulaciones de laboratorio. Esto significa que si tus clientes utilizan móviles de gama media o conexiones 4G irregulares —muy habitual en zonas rurales de Lleida o Tarragona—, tu puntuación real puede ser significativamente peor de lo que ves cuando haces la prueba desde tu ordenador de oficina con fibra.
El impacto real en negocios catalanes
Las generalidades no ayudan a nadie. Aquí tienes tres casos concretos de lo que nos hemos encontrado trabajando con clientes:
Comercio de moda online en Girona. La web tardaba entre 6 y 8 segundos en cargar en móvil, y el 70% de su tráfico era móvil. El problema principal era un carrusel de banners en la portada con imágenes de más de 2 MB cada una, cargadas todas a la vez. Cuando redujimos el LCP por debajo de los 2,5 segundos —comprimiendo imágenes, eliminando el carrusel y activando caché—, la tasa de rebote bajó y las sesiones de más de dos páginas aumentaron. Las posiciones para keywords de producto mejoraron en las semanas siguientes.
Clínica de fisioterapia en Tarragona. Aquí el problema no era la velocidad bruta sino el CLS: un banner de cookies mal configurado hacía saltar todo el contenido cuando aparecía, generando clics accidentales y una experiencia terrible en móvil. La solución fue reservar espacio fijo para el banner en el CSS. Tiempo de implementación: menos de una hora. Resultado: CLS de 0,38 a 0,04.
Restaurante de Gràcia (Barcelona) con WordPress. Tenían un slider de fotos en la portada con imágenes de 4 MB cada una. El LCP era de 9 segundos. Comprimimos las imágenes, eliminamos el slider —que, además, no aportaba nada a la conversión— y activamos caché. Resultado: LCP de 2,1 segundos y mejora de visibilidad en Google en menos de dos meses.
Los errores que encuentro una y otra vez
Ordenados por frecuencia real en auditorías de webs catalanas:
- Imágenes sin comprimir ni convertir a WebP. El problema número uno, sin discusión. Una foto subida directamente desde el móvil puede pesar 3-4 MB. En WebP, la misma imagen puede bajar a 80-120 KB sin pérdida visible de calidad. El impacto en el LCP es inmediato.
- Hosting compartido de gama baja. Es el techo de todo. Si tu TTFB (Time to First Byte) supera los 600 ms, el problema es el servidor, no el código. Ningún plugin de caché compensará un servidor que tarda más de medio segundo en responder. Mide el TTFB con GTmetrix antes de tocar nada más.
- Plugins de WordPress sin auditar. Cada plugin activo carga archivos CSS y JS en todas las páginas, incluso cuando no se utiliza en esa página concreta. He visto webs con 50 plugins activos donde 20 eran redundantes o no se habían tocado en años.
- Scripts de terceros sin defer ni async. Píxeles de Meta, Google Tag Manager mal configurado, chats en vivo, widgets de Instagram… Si se cargan de manera síncrona, bloquean todo el renderizado. Añadir
deferoasynca los scripts que no son críticos es uno de los cambios con mejor ratio impacto/esfuerzo. - No revisar PageSpeed después de actualizar. He visto webs que pasaban de 78 a 44 puntos de un día para otro por una actualización de tema o plugin que añadía un nuevo script. Configurar una alerta mensual en el calendario para revisar PageSpeed y Search Console es la medida preventiva más sencilla que existe.
Plan de acción por prioridad: por dónde empezar
La clave no es hacerlo todo a la vez. Es hacer primero lo que tiene más impacto con menos esfuerzo. Este es el orden que sigo en mis proyectos:
| Prioridad | Acción | Dificultad | Impacto principal |
|---|---|---|---|
| 1 | Comprimir y convertir imágenes a WebP | Baja | LCP (muy alto) |
| 2 | Activar caché (WP Rocket, LiteSpeed Cache…) | Baja | LCP + TTFB (alto) |
| 3 | Conectar Cloudflare (plan gratuito) | Baja-Media | TTFB + CDN (alto) |
| 4 | Auditar y desactivar plugins innecesarios | Baja | INP + LCP (medio) |
| 5 | Cargar scripts de terceros con defer/async | Media | INP + LCP (alto) |
| 6 | Cambiar hosting si TTFB > 600 ms | Alta | Todo (muy alto) |
| 7 | Minificar CSS/JS y eliminar código no usado | Alta | LCP + INP (medio) |
Para WordPress, la combinación Imagify + WP Rocket + Cloudflare cubre el 70% de los problemas habituales con una inversión mínima de tiempo. No es la solución perfecta para todos los casos, pero es el punto de partida que recomiendo para la mayoría de pymes.
Para webs a medida, Shopify o Prestashop, las prioridades son las mismas —imágenes, caché, scripts de terceros, servidor— pero la ejecución requiere perfil técnico. Si tu equipo no lo tiene, o simplemente quieres saber exactamente dónde pierdes puntos antes de decidir nada, escríbenos y hacemos una revisión inicial gratuita de tu web. Te explicamos el diagnóstico y el orden de actuación sin compromiso.
Preguntas frecuentes
¿Cuánto tarda en mejorar el posicionamiento después de optimizar la velocidad?
Google tarda entre 4 y 12 semanas en reflejar mejoras técnicas en los resultados. En los proyectos que hemos gestionado, las primeras mejoras de visibilidad aparecen alrededor de las 6-8 semanas. Depende mucho de la competencia del sector y de cuánto había empeorado el SEO por culpa de la lentitud acumulada.
¿La velocidad web afecta el SEO local (Google Maps) igual que el SEO orgánico?
El SEO local depende principalmente del Google Business Profile, las reseñas y la relevancia geográfica. Pero la velocidad afecta indirectamente: si el usuario hace clic en tu perfil y la web carga lento, se va, y Google registra ese comportamiento. Además, las páginas de aterrizaje lentas reducen las conversiones de las visitas que sí que llegan.
¿Qué puntuación de PageSpeed es suficiente para una pyme?
Superar los 70 puntos en móvil es el objetivo mínimo. Por encima de 85, estás en muy buena posición. Pero lo que realmente importa es estar por encima de tus competidores directos: si todos están entre 40 y 55, llegar a 75 ya te da una ventaja clara en el ranking.
¿Puedo mejorar la velocidad web sin programar?
Sí, especialmente con WordPress. Comprimir imágenes con Imagify o ShortPixel, activar WP Rocket y conectar Cloudflare no requiere tocar código. Estas tres acciones solas pueden transformar una web lenta en una web aceptable. Para optimizaciones avanzadas —defer de scripts específicos, optimización del servidor, eliminación de CSS no usado— hará falta ayuda técnica.
¿Cómo sé si mi hosting es el problema principal?
Mide el TTFB (Time to First Byte) con GTmetrix o WebPageTest. Si supera los 600 ms, el problema es el servidor. Ningún plugin de caché lo compensará: hay que cambiar de proveedor o de plan. Hostings como Kinsta, SiteGround o Raiola Networks ofrecen rendimientos notablemente mejores que los hostings compartidos de gama baja.