Comparativas y alternativas

TTFB alto en hosting compartido: cómo bajarlo y mejorar Core Web Vitals

Aprende por qué el TTFB se dispara en hosting compartido y qué ajustes concretos lo reducen para mejorar tus Core Web Vitals.

Two businessmen analyze financial documents during a meeting, focusing on data trends and performance.

Un TTFB (Time to First Byte) por encima de 800 ms en hosting compartido es suficiente para que Google te penalice en Core Web Vitals y para que tus visitantes abandonen la página antes de verla. El objetivo es llegar a menos de 200 ms para el 75 % de tus visitas — y es alcanzable desde hosting compartido si atacas las causas correctas.

Esta guía explica qué genera el TTFB alto en entornos compartidos y qué ajustes concretos lo reducen sin cambiar de plan de hosting.

¿Qué es el TTFB y por qué le importa a Google?

El TTFB mide el tiempo desde que el navegador envía la solicitud HTTP hasta que recibe el primer byte de respuesta del servidor. No es el tiempo total de carga, pero sí es el primer "candado" de la cadena: si el servidor tarda, todo lo demás espera.

Google lo incluye como señal de diagnóstico dentro de las métricas de Interaction to Next Paint (INP) y Largest Contentful Paint (LCP). Un TTFB alto retarda directamente el LCP, que sí tiene umbral explícito en Core Web Vitals: menos de 2.5 segundos para aprobarlo.

Los umbrales de referencia para TTFB según Google:

Resultado TTFB (p75)
Bueno < 800 ms
Necesita mejora 800 ms – 1,800 ms
Deficiente > 1,800 ms

Para páginas en México y Latinoamérica, apunta a menos de 600 ms desde la región para tener margen ante latencias variables de red.

Por qué el TTFB se dispara en hosting compartido

En un servidor compartido, tu sitio compite por CPU, RAM y conexiones de base de datos con decenas o cientos de vecinos. Las causas más frecuentes de TTFB alto son:

  • PHP sin caché de objetos: WordPress ejecuta docenas de consultas SQL y llamadas PHP en cada petición si no hay opcode cache ni object cache activos.
  • Consultas lentas a MySQL: tablas sin índices adecuados, plugins que hacen queries ineficientes, o la misma base de datos saturada por otros sitios del servidor.
  • Plugins pesados en el inicio: plugins que se cargan en cada petición, incluso cuando no se usan en esa página.
  • Sin caché de página completa: PHP regenera el HTML desde cero en cada visita, incluso para contenido que no cambia.
  • Servidor geográficamente alejado: si tu hosting está en EE.UU. y tus visitas son de México, sumas 30-80 ms solo de latencia de red antes de que el servidor empiece a procesar.

Las 5 soluciones ordenadas por impacto

1. Activar caché de página completa

Este es el cambio de mayor impacto. Con caché de página completa, WordPress sirve HTML estático pregenerado sin ejecutar PHP ni consultar la base de datos. El TTFB puede caer de 1,500 ms a menos de 100 ms en páginas cacheadas.

Opciones recomendadas para hosting compartido:

  • WP Rocket (de pago): la opción más completa y con mejor soporte. Incluye caché de página, minificación y lazy load.
  • LiteSpeed Cache (gratis): si tu hosting usa LiteSpeed Web Server (muchos cPanel en México lo hacen), este plugin aprovecha la caché a nivel servidor — la más rápida posible.
  • W3 Total Cache o WP Super Cache (gratis): alternativas sólidas para servidores Apache convencionales.

2. Habilitar PHP OPcache

OPcache precompila los scripts PHP y los guarda en memoria, eliminando la recompilación en cada petición. En la mayoría de hostings compartidos con cPanel, OPcache ya está disponible — verifica que esté activo desde MultiPHP INI Editor:

opcache.enable=1
opcache.memory_consumption=128
opcache.max_accelerated_files=10000
opcache.revalidate_freq=2

OPcache por sí solo puede reducir el TTFB entre un 20 y 40 % en instalaciones WordPress con muchos plugins.

3. Optimizar la base de datos

Una base de datos WordPress con años de uso acumula revisiones de posts, transientes expirados y autocargas de opciones que ralentizan cada petición. Pasos concretos:

  • Instala WP-Optimize y programa una limpieza semanal: borra revisiones (conserva las últimas 3), transientes expirados, spam en comentarios y tablas huérfanas de plugins desinstalados.
  • Revisa la tabla wp_options con Query Monitor — las opciones con autoload=yes se cargan en cada petición. Desactiva el autoload de opciones de plugins que no lo necesiten.
  • Si tienes acceso a phpMyAdmin, ejecuta OPTIMIZE TABLE en las tablas más grandes (wp_posts, wp_postmeta) trimestralmente.

4. Usar una CDN con edge caching

Una CDN (Content Delivery Network) acerca tu contenido a tus visitantes geográficamente. Cloudflare gratuito es la opción más accesible y hace dos cosas por el TTFB:

  • Sirve recursos estáticos (CSS, JS, imágenes) desde su edge, sin llegar a tu servidor.
  • Con Cloudflare Cache Rules configuradas, puede cachear páginas HTML completas en el edge — reduciendo el TTFB efectivo a 10-50 ms para visitas repetidas.

Para sitios con tráfico desde México, activa la regla de caché de HTML en Cloudflare y excluye únicamente el carrito de WooCommerce y las páginas de cuenta de usuario.

Si necesitas orientación para elegir el hosting y la CDN adecuados para tu proyecto, en elenlace.com analizamos tu caso sin costo y te recomendamos la combinación óptima para tu presupuesto.

5. Auditar y reducir plugins

Cada plugin activo añade tiempo de carga en el inicio de WordPress (bootstrap). Una instalación típica con 30 plugins puede tardar 300-500 ms solo en el bootstrapping, antes de ejecutar una sola consulta de contenido.

  • Instala Query Monitor y revisa la pestaña "PHP" — verás el tiempo de carga por plugin.
  • Desactiva y elimina plugins que no uses activamente.
  • Reemplaza plugins pesados por alternativas ligeras: por ejemplo, sustituye un plugin de formularios de 200 KB por uno de 20 KB si tu caso de uso es simple.
  • Usa Asset CleanUp para descargar scripts de plugins en páginas donde no se necesitan.

Puedes comparar más estrategias de optimización en nuestra sección de comparativas de hosting y rendimiento web.

Cómo medir el TTFB correctamente

Antes y después de aplicar cambios, mide desde herramientas confiables:

  • PageSpeed Insights (datos de campo reales de usuarios Chrome en tu región).
  • WebPageTest — selecciona un servidor de prueba en Ciudad de México o Dallas para simular usuarios de tu audiencia objetivo.
  • Chrome DevTools → pestaña Network → clic en el primer recurso HTML → revisa "Waiting for server response" en el panel de timing.

Mide siempre con caché fría (primer visitante) y con caché caliente (segunda visita). El primero te dice qué tan rápido responde PHP; el segundo te confirma que la caché funciona.

Conclusiones clave

  • El TTFB alto en hosting compartido casi siempre tiene origen en PHP sin cachear, base de datos lenta o exceso de plugins — no en la conexión de red del usuario.
  • La caché de página completa es el cambio de mayor impacto: puede reducir el TTFB de segundos a decenas de milisegundos.
  • OPcache activo es obligatorio en cualquier hosting compartido con WordPress — sin él, PHP recompila en cada petición.
  • Una CDN como Cloudflare gratuito complementa la caché del servidor y reduce la latencia geográfica.
  • Menos plugins activos = menos tiempo de bootstrapping = TTFB más bajo sin tocar el servidor.

¿Tu TTFB sigue alto después de aplicar estos ajustes? Escríbenos en elenlace.com — hacemos una auditoría de rendimiento completa y te entregamos un plan de acción con resultados medibles.

Preguntas frecuentes

¿El TTFB afecta directamente mi posicionamiento en Google?

El TTFB no tiene un umbral propio en Core Web Vitals, pero impacta directamente el LCP, que sí lo tiene. Un TTFB alto retrasa todo el proceso de renderizado, lo que empuja el LCP por encima de los 2.5 segundos y puede perjudicar tu clasificación en búsquedas donde otros factores son similares.

¿Debo cambiar de hosting compartido para mejorar el TTFB?

No necesariamente. Con caché de página completa bien configurada, un sitio en hosting compartido de calidad puede lograr TTFB por debajo de 200 ms para visitas cacheadas. Si después de optimizar sigues por encima de 800 ms en frío, considera un VPS o un plan de hosting gestionado con más recursos dedicados.

¿LiteSpeed Cache es mejor que WP Rocket en hosting compartido?

Depende del servidor. Si tu hosting usa LiteSpeed Web Server (frecuente en proveedores como Hostinger, NameCheap y muchos cPanel en México), LiteSpeed Cache aprovecha la caché a nivel servidor y suele superar a WP Rocket. En servidores Apache, WP Rocket es generalmente la opción más completa y fácil de configurar.

¿Cloudflare gratuito es suficiente para mejorar el TTFB?

Para la mayoría de sitios informativos y blogs, sí. Cloudflare gratuito ofrece caché de assets estáticos, HTTP/2, y la posibilidad de cachear HTML con Cache Rules. Para e-commerce o sitios con muchas páginas dinámicas, considera Cloudflare Pro o una solución de caché a nivel servidor complementaria.

Compara proveedores

Otros proveedores y guías que vale la pena comparar:

← Todos