Hay una creencia muy extendida: "el SEO se gana con contenido y backlinks". Es verdad, pero incompleta. Desde 2021 Google añadió a su algoritmo las Core Web Vitals: tres métricas técnicas que miden la experiencia real del usuario en tu web. Y dos de esas tres dependen, en parte importante, de tu hosting.
No es teoría. Si tu servidor tarda 1 segundo en responder, ese segundo se suma a cada métrica de carga que Google mide. Multiplicado por cada visita, acaba notándose en posiciones, en tasa de rebote y en conversión.
En esta guía explicamos qué mide cada Core Web Vital, cuáles dependen del hosting y cuáles no, y qué buscar en un proveedor para no comprarte un problema de SEO.
Qué son las Core Web Vitals (sin tecnicismos)
Google escogió tres métricas que reflejan la experiencia real del usuario cuando carga tu web:
- LCP (Largest Contentful Paint) — cuánto tarda en aparecer el elemento más grande visible en pantalla. Habitualmente la imagen principal o el bloque de texto del hero.
- INP (Interaction to Next Paint) — cuánto tarda la web en responder a un clic o un toque. Mide la fluidez de la interacción.
- CLS (Cumulative Layout Shift) — cuánto se mueven los elementos de la web mientras carga (textos que saltan, imágenes que aparecen y empujan el contenido).
Objetivos oficiales de Google para que una página esté en verde:
| Métrica | Bueno | Mejorable | Pobre |
|---|---|---|---|
| LCP | < 2,5 s | 2,5-4 s | > 4 s |
| INP | < 200 ms | 200-500 ms | > 500 ms |
| CLS | < 0,1 | 0,1-0,25 | > 0,25 |
Junto a estas tres, hay una cuarta que no es Core Web Vital pero es clave para entender el resto: TTFB (Time to First Byte) — cuánto tarda el servidor en empezar a responder. Es el reloj que empieza a correr antes de cualquier otra métrica.
Cuáles dependen del hosting y cuáles no
No todas las Core Web Vitals dependen del servidor por igual.
| Métrica | ¿Depende del hosting? | Por qué | |---|---|---| | TTFB | Mucho | Es literalmente lo que tarda el servidor en responder. | | LCP | Bastante | Incluye TTFB + descarga del recurso más grande. Si el server es lento, LCP sufre. | | INP | Poco | Depende sobre todo del JavaScript del frontend. El servidor influye solo si la interacción dispara una petición al backend. | | CLS | Nada | Es 100% problema de cómo está hecha la web (CSS, dimensiones de imágenes, fuentes). |
Conclusión rápida: TTFB y LCP son donde el hosting marca diferencia. INP y CLS los arreglas con desarrollo web, no cambiando de servidor.
Cómo afecta el servidor a TTFB (y de paso a LCP)
El TTFB es la suma de tres tiempos:
- DNS lookup — el navegador pregunta dónde está tu dominio.
- Latencia de red — el tiempo físico que tarda la petición en viajar de tu visitante al servidor (y volver).
- Tiempo de procesamiento del servidor — lo que tarda el servidor en generar la respuesta (ejecutar PHP, consultar la base de datos, etc.).
El hosting controla los tres puntos, en distinto grado:
- El DNS suele ser gestionado por el registrador del dominio o por el proveedor de hosting. Buenos DNS reducen 20-50 ms aquí.
- La latencia depende de dónde esté físicamente el datacenter respecto a tu audiencia. Un visitante en Ciudad de México pidiendo una web alojada en Frankfurt va a tener 150 ms extra solo de viaje, frente a un visitante europeo. Si tu audiencia es hispana global, conviene un datacenter bien posicionado o una CDN delante.
- El procesamiento depende de la potencia del servidor, de cuánta gente esté usándolo a la vez (vecinos ruidosos en compartido), de si tienes caché activada, de si hay una capa de Redis o no.
Qué TTFB es aceptable
Rangos de referencia habituales en la industria:
- < 200 ms — excelente.
- 200-600 ms — aceptable.
- > 600 ms — penaliza el LCP y, por extensión, la indexación Google.
Lo importante no es el TTFB "del proveedor" en abstracto, sino el TTFB desde el mercado donde están tus visitantes. Antes de contratar (o de migrar), pide a tu proveedor un dato concreto: cuál es el TTFB típico desde tu país principal. Si no te saben dar una respuesta clara, puedes medirlo tú mismo con WebPageTest eligiendo la ubicación del test.
Cómo afecta el servidor al LCP
LCP = TTFB + tiempo de descarga del recurso principal + tiempo de render.
Si tu hero es una imagen, el LCP incluye descargar esa imagen. Aquí el hosting influye en:
- Velocidad de servir archivos estáticos. Un servidor con caché optimizada para WordPress sirve la imagen al instante; uno sin caché tiene que generar la página en cada petición.
- HTTP/2 o HTTP/3. Permiten al navegador descargar varios recursos en paralelo. Los hostings serios los traen activados por defecto.
- Compresión Brotli o Gzip. Reduce el tamaño de los archivos servidos. Bien configurada ahorra 30-70% del peso.
- CDN integrada. Sirve las imágenes desde un nodo cercano al visitante, no desde el servidor principal.
Configurar bien caché, compresión y CDN no es trivial si nunca lo has hecho. En HispanoHost te lo dejamos preparado en el onboarding: en lugar de pelearte con plugins y paneles, repasamos contigo tu sitio y activamos lo que falte. Si después tienes dudas, preguntas a soporte humano en español, no a un chatbot.
INP: el hosting casi no cuenta (pero sí un poco)
INP mide cuánto tarda la web en responder a una interacción (clic, toque, tecla). El 90% del problema está en el JavaScript del frontend: bundles pesados, librerías mal optimizadas, código bloqueante.
El hosting solo influye en INP si la interacción dispara una petición al servidor. Por ejemplo:
- Clic en "añadir al carrito" en WooCommerce → petición AJAX al backend.
- Búsqueda en vivo en el header → consulta a la base de datos.
- Comentario en un post → escritura en MySQL.
En esos casos, un servidor lento alarga la respuesta y empeora el INP. Pero si tu sitio es básicamente lectura (blog, web institucional), el INP depende casi por completo del desarrollador frontend, no del hosting.
CLS: nada que ver con el hosting
CLS mide saltos de layout durante la carga: textos que se reorganizan, imágenes que aparecen y empujan el contenido, banners que se cargan tarde y descolocan todo.
Las causas típicas:
- Imágenes sin
widthyheightdeclarados. - Fuentes web cargadas sin
font-displaycontrolado. - Anuncios o iframes que se inyectan dinámicamente.
- Banners de cookies mal implementados.
Todo eso se arregla en el desarrollo de la web, no en el servidor. Cambiar de hosting no va a mover tu CLS ni un punto.
Qué buscar en un hosting para no romper Core Web Vitals
Si vas a contratar un nuevo proveedor o pensar en migrar el actual, esta es la checklist técnica que debes pedir (o verificar):
- Ubicación del datacenter — al menos uno cerca de tu audiencia principal. Si vendes a LatAm, pregunta latencia real desde México y Argentina, no solo "tenemos servidores globales".
- Caché optimizada para WordPress / aplicación — server-side caching activado por defecto, no como plugin extra que tú instalas.
- HTTP/3 y Brotli — activados sin que tengas que pedirlo.
- PHP 8.2+ (para WordPress) — versiones antiguas son 2-3x más lentas.
- CDN integrada o fácilmente activable — Cloudflare, BunnyCDN, lo que sea, pero documentado.
- Backups automáticos diarios — no es Core Web Vital pero es lo que te salva cuando algo va mal.
- Soporte que entienda de rendimiento — si tu TTFB sube y respondes a soporte y te dicen "es problema de tu tema", cambia de hosting.
Si te abruma esta checklist o ya estás con otro proveedor y no sabes cuáles tienes activos, en HispanoHost te acompañamos: revisamos contigo qué falta y, si decides migrar, te traemos el sitio sin coste y sin downtime perceptible. Es parte del onboarding, no un extra que se factura.
Cómo medir tus Core Web Vitals actuales
Antes de cambiar nada, mide. Tres herramientas gratuitas:
- PageSpeed Insights (Google) — métricas de tu URL con datos reales del Chrome User Experience Report.
- WebPageTest — test desde distintas ubicaciones (sirve para medir latencia real desde tu mercado).
- Search Console > Core Web Vitals — informe agregado de tu sitio entero en producción.
Recoge los datos antes de migrar y vuelve a medir 7-14 días después. Si tu TTFB y LCP bajan, hiciste bien.
Antes de cambiar de hosting
Si tus Core Web Vitals están en rojo, antes de pensar en cambiar de proveedor, descarta estas dos causas:
- Imágenes sin optimizar. Una sola imagen de 5 MB destroza el LCP. Comprime y sirve en WebP/AVIF.
- Plugins que añaden JavaScript pesado. Auditar con la pestaña "Performance" de Chrome DevTools.
Si después de eso sigues con TTFB > 600 ms, el problema es el servidor. Ahí sí, plantéate migrar.
Y si tienes que migrar, hazlo bien: te explicamos los 8 pasos para migrar WordPress sin perder posiciones en Google.
Para seguir leyendo
- Tipos de hosting explicados — si tu LCP es malo por culpa del servidor, este artículo te ayuda a decidir si necesitas saltar a VPS o cloud.
- Hosting WordPress — nuestro plan para WordPress con migración gratuita y onboarding humano.
- VPS — si tu proyecto ya rebasa lo que aguanta un compartido.
