import BackToPillarButton from ‘@ui/components/common/BackToPillarButton.astro’; import CTABox from ‘@ui/components/common/CTABox.astro’; import ComparisonTable from ‘@ui/components/common/ComparisonTable.astro’;
TTFB Alto en WordPress: Cómo Bajarlo Por Debajo de 200ms
PageSpeed Insights te muestra el mensaje “Reduce initial server response time” en rojo. Tu TTFB marca 800ms, 1.2 segundos, o peor. Y no importa cuántas imágenes comprimas: el problema empieza antes de que el navegador reciba un solo byte.
El Time to First Byte (TTFB) es la métrica más crítica y menos comprendida del rendimiento WordPress. Según Google, representa el 40% del Largest Contentful Paint (LCP), lo que significa que un TTFB alto arruina automáticamente tus Core Web Vitals.
La buena noticia: bajar de 800ms a menos de 200ms es completamente alcanzable con las optimizaciones correctas. En esta guía técnica te muestro exactamente cómo hacerlo, paso a paso, con comandos, queries SQL y configuraciones reales.
Índice de contenidos
- Qué es el TTFB y por qué 200ms es el objetivo
- Cómo medir tu TTFB correctamente
- Los 5 componentes del TTFB (y cuál optimizar primero)
- Solución 1: Optimizar el servidor (hosting + stack)
- Solución 2: Implementar caché a nivel servidor
- Solución 3: Optimizar la base de datos
- Solución 4: Auditar plugins y tema
- Solución 5: Configurar CDN correctamente
- Solución 6: Actualizar PHP y tecnologías
- Caso práctico: de 780ms a 165ms
- Preguntas frecuentes
- Conclusión
Qué es el TTFB y por qué 200ms es el objetivo {#que-es-ttfb}
El Time to First Byte (TTFB) mide el tiempo desde que el navegador solicita una página hasta que recibe el primer byte de respuesta del servidor.
Los umbrales de TTFB según Google
Google solía recomendar 200ms como objetivo. Actualmente marca como problemático cualquier TTFB superior a 600ms. Pero para competir en SERPs, 200ms sigue siendo el estándar profesional.
Por qué el TTFB afecta todo lo demás
El TTFB es el punto de partida de la cascada de carga:
TTFB (servidor responde) → FCP (primer contenido) → LCP (contenido principal) → TTI (interactivo)Si tu TTFB es 800ms, el LCP no puede empezar hasta que pasen esos 800ms. Es físicamente imposible tener un LCP de 2 segundos con un TTFB de 1.5 segundos.
“TTFB es el 40% del LCP y la métrica más importante para mejorar Core Web Vitals. Tu host y CDN son los 2 factores principales.” — OnlineMediaMasters, 2025
Cómo medir tu TTFB correctamente {#como-medir-ttfb}
Antes de optimizar, necesitas datos precisos. Estas herramientas te dan métricas fiables:
Herramientas de medición
Medir TTFB con comando curl
Para una medición rápida desde terminal:
curl -s -w "\nTTFB: %{time_starttransfer}s\n" -o /dev/null https://tudominio.comEsto te da el TTFB real sin procesar. Ejecuta varias veces para obtener un promedio.
Dónde medir: la ubicación importa
El TTFB varía según la distancia entre el usuario y el servidor:
- Madrid → Servidor en Madrid: ~50-100ms
- Madrid → Servidor en Frankfurt: ~80-150ms
- Madrid → Servidor en Nueva York: ~180-300ms
- Madrid → Servidor en Los Ángeles: ~250-400ms
Si tu audiencia está en España, un servidor en USA añade 100-200ms de latencia física que ninguna optimización puede eliminar.
Los 5 componentes del TTFB (y cuál optimizar primero) {#componentes-ttfb}
El TTFB se compone de varias fases. Entenderlas te ayuda a saber dónde atacar:
Desglose del TTFB
Dónde está el problema (casi siempre)
En el 90% de los casos, el cuello de botella está en el procesamiento del servidor:
- Hosting compartido sobrecargado
- Base de datos sin optimizar
- Plugins ejecutando queries lentas
- Sin caché a nivel servidor
- PHP desactualizado
La latencia de red solo es problema si el servidor está muy lejos de los usuarios. DNS y TLS rara vez son el issue principal.
Solución 1: Optimizar el servidor (hosting + stack) {#solucion-servidor}
El servidor es la base de todo. Si es lento, nada más importa.
Stack tecnológico ideal para TTFB bajo
LiteSpeed vs Apache: la diferencia real
Un estudio de LiteSpeed Technologies muestra que LiteSpeed Enterprise puede ser hasta 6x más rápido que Apache para servir WordPress.
La razón: LiteSpeed procesa PHP de forma más eficiente y tiene caché integrado a nivel servidor (LSCache), que no requiere cargar WordPress para servir páginas cacheadas.
Señales de que tu hosting es el problema
- TTFB > 400ms incluso con caché activado
- Backend
/wp-adminlento - Errores 503 frecuentes
- TTFB inconsistente (varía mucho entre mediciones)
- El hosting usa Apache y no ofrece LiteSpeed
Si identificas estos síntomas, cambiar de hosting puede reducir tu TTFB en un 50-70% instantáneamente.
{/* URL real: http://localhost:4321/hosting-web */}
Solución 2: Implementar caché a nivel servidor {#solucion-cache}
El caché es la optimización con mayor impacto inmediato en el TTFB.
Tipos de caché y su efectividad
Por qué el caché de servidor es superior
Un plugin de caché (WP Rocket, W3 Total Cache) funciona así:
- Usuario solicita página
- WordPress se carga (~100-300ms)
- Plugin verifica si hay caché
- Si existe, sirve el HTML cacheado
Un caché a nivel servidor (LSCache, Varnish):
- Usuario solicita página
- Servidor verifica caché sin cargar WordPress
- Si existe, sirve HTML directamente (~20-50ms)
La diferencia: el caché de servidor no necesita ejecutar PHP para servir páginas cacheadas.
Configurar LiteSpeed Cache (LSCache)
Si tu hosting usa LiteSpeed, instala el plugin LiteSpeed Cache (gratuito):
// Configuración recomendada en LiteSpeed Cache
// Cache → TTL: 604800 (1 semana para páginas estáticas)
// Cache → Cache Logged-in Users: OFF
// Cache → Cache REST API: ON
// CDN → QUIC.cloud CDN: Activar para full page caching globalCon QUIC.cloud activado, el caché se distribuye globalmente y puedes alcanzar TTFB de 50-100ms desde cualquier ubicación.
Configurar Varnish (si no tienes LiteSpeed)
Si tu hosting usa Varnish, verifica que esté activado. Prueba de Cloudways:
“Sin Varnish, el TTFB era 759ms. Con Varnish activado, bajó a 141ms.” — Cloudways, 2022
Solución 3: Optimizar la base de datos {#solucion-base-datos}
Una base de datos inflada es una de las causas más comunes de TTFB alto en WordPress.
El problema: wp_options y autoload
WordPress carga todos los datos con autoload='yes' en cada petición de página. Si tienes 3MB de datos autoloaded, WordPress carga 3MB en memoria antes de hacer cualquier cosa.
Límite recomendado: 800KB de datos autoloaded.
Comprobar tu tamaño de autoload
Ejecuta esta query en phpMyAdmin o WP-CLI:
SELECT SUM(LENGTH(option_value)) / 1024 AS autoload_size_kb
FROM wp_options
WHERE autoload = 'yes';Si el resultado es mayor a 800KB, tienes un problema.
Encontrar los mayores culpables
SELECT option_name, LENGTH(option_value) / 1024 AS size_kb
FROM wp_options
WHERE autoload = 'yes'
ORDER BY LENGTH(option_value) DESC
LIMIT 20;Los culpables típicos:
_transient_*y_site_transient_*(transients expirados)- Datos de plugins desactivados
- Caché de plugins mal configurados
- Datos de analytics o logs
Limpiar transients expirados
DELETE FROM wp_options
WHERE option_name LIKE '%_transient_%'
AND option_value < UNIX_TIMESTAMP();Deshabilitar autoload en opciones grandes
UPDATE wp_options
SET autoload = 'no'
WHERE option_name = 'nombre_opcion_grande';⚠️ Precaución: Haz backup antes de modificar la base de datos. Algunas opciones necesitan autoload para funcionar.
Object Cache: Redis o Memcached
Object cache almacena resultados de queries en RAM, evitando consultas repetidas a la base de datos.
# Verificar si Redis está activo
wp redis statusCon Redis activo, las queries repetidas se sirven desde memoria en microsegundos en lugar de milisegundos.
Solución 4: Auditar plugins y tema {#solucion-plugins}
Los plugins son responsables de la mayoría de queries lentas en WordPress.
Identificar plugins problemáticos
Instala Query Monitor (gratuito) para ver:
- Tiempo de ejecución de cada query
- Qué plugin genera cada query
- Queries duplicadas o lentas
Los plugins que más afectan al TTFB
Test de impacto de plugins
- Desactiva todos los plugins
- Mide el TTFB (debería bajar significativamente)
- Activa plugins uno a uno, midiendo después de cada uno
- Identifica cuáles añaden más tiempo
Optimizar admin-ajax.php
Muchos plugins usan admin-ajax.php para funcionalidad frontend. Cada llamada a admin-ajax carga WordPress completo.
Soluciones:
- Desactivar funciones de plugins que no necesitas
- Usar plugins que implementen REST API en lugar de admin-ajax
- Cachear respuestas de AJAX cuando sea posible
Solución 5: Configurar CDN correctamente {#solucion-cdn}
Un CDN bien configurado reduce el TTFB globalmente. Mal configurado, puede aumentarlo.
Tipos de CDN para WordPress
CDNs con Full Page Caching
- Cloudflare APO: $5/mes, mejora TTFB en 72% según sus tests
- QUIC.cloud: Gratuito con LiteSpeed Cache, CDN nativo
- Cloudflare Enterprise: Incluido en hostings premium (Kinsta, Rocket.net)
- Bunny.net: Económico, buen rendimiento
Configurar Cloudflare correctamente
# Configuración recomendada Cloudflare para TTFB
SSL/TLS → Full (Strict)
Speed → Auto Minify: ON para CSS, JS, HTML
Speed → Brotli: ON
Caching → Browser Cache TTL: 1 year
Caching → Always Online: ON
Network → HTTP/3: ON
Network → 0-RTT Connection Resumption: ONError común: CDN que aumenta TTFB
Si el CDN no tiene full page caching, cada petición:
- Va al edge de Cloudflare
- Cloudflare va a tu servidor origen
- Tu servidor procesa la página
- Respuesta vuelve por la misma ruta
Esto añade un “hop” extra que puede aumentar el TTFB si no hay caché.
Solución 6: Actualizar PHP y tecnologías {#solucion-php}
Cada versión de PHP trae mejoras significativas de rendimiento.
Rendimiento por versión de PHP
Actualizar de PHP 7.4 a PHP 8.2 puede mejorar el rendimiento un 25-30%.
Verificar compatibilidad antes de actualizar
# Con WP-CLI
wp plugin list --fields=name,update_version
# Verificar errores en modo debug
# En wp-config.php:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);Configurar OPcache correctamente
OPcache almacena bytecode PHP compilado, evitando recompilar en cada petición.
; Configuración recomendada php.ini
opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.revalidate_freq=60
opcache.fast_shutdown=1Usar HTTP/3 y QUIC
HTTP/3 reduce la latencia de conexión. Según Cloudflare, HTTP/3 es 12.4% más rápido que HTTP/2 para TTFB.
Verifica si tu sitio soporta HTTP/3: HTTP/3 Check
Caso práctico: de 780ms a 165ms {#caso-practico}
Veamos un caso real de optimización TTFB paso a paso.
Situación inicial
- Hosting: Compartido tradicional (Apache, SSD SATA)
- TTFB medio: 780ms
- Autoload data: 2.4MB
- Plugins activos: 28
- PHP: 7.4
- Caché: WP Super Cache
Paso 1: Cambio de hosting
Migración a hosting LiteSpeed con NVMe.
Resultado: TTFB bajó a 420ms (-46%)
Paso 2: Configurar LSCache
Instalación y configuración de LiteSpeed Cache con QUIC.cloud.
Resultado: TTFB bajó a 280ms (-33% adicional)
Paso 3: Limpiar base de datos
- Eliminados 45.000 transients expirados
- Reducido autoload de 2.4MB a 680KB
- Activado Redis object cache
Resultado: TTFB bajó a 210ms (-25% adicional)
Paso 4: Auditar plugins
- Eliminados 12 plugins innecesarios
- Sustituido page builder por Gutenberg + GenerateBlocks
- Desactivada carga de analytics en admin-ajax
Resultado: TTFB bajó a 175ms (-17% adicional)
Paso 5: Actualizar PHP
Actualización de PHP 7.4 a PHP 8.2.
Resultado final: TTFB 165ms (-6% adicional)
Resumen de mejoras
De 780ms a 165ms: una mejora del 79%, logrando un TTFB por debajo del objetivo de 200ms.
{/* URL real: http://localhost:4321/hosting-wordpress */}
Preguntas frecuentes {#preguntas-frecuentes}
¿Es posible conseguir TTFB < 200ms con hosting compartido?
Difícil pero posible si el hosting usa LiteSpeed + NVMe + caché a nivel servidor. Con Apache y hosting sobrepoblado, es prácticamente imposible mantener <200ms de forma consistente.
¿Por qué mi TTFB varía tanto entre mediciones?
Causas comunes:
- “Noisy neighbors” en hosting compartido
- Caché no está activado o se invalida frecuentemente
- El servidor tiene picos de carga
- Mides desde diferentes ubicaciones geográficas
¿Cloudflare mejora o empeora el TTFB?
Depende de la configuración. Cloudflare con APO activado (full page caching) mejora significativamente el TTFB. Sin APO, puede añadir latencia si no hay caché.
¿Cuánto impacta actualizar PHP en el TTFB?
Actualizar de PHP 7.4 a 8.2 típicamente reduce el tiempo de procesamiento un 25-30%. En términos de TTFB, puede significar 50-100ms menos si el procesamiento PHP era el cuello de botella.
¿Object cache (Redis) es necesario para TTFB bajo?
Para sitios con muchas queries a base de datos (WooCommerce, membership, BuddyPress), Redis es casi imprescindible. Para blogs simples con buen page cache, el impacto es menor.
¿Por qué el backend de WordPress sigue lento aunque el frontend va rápido?
El backend (/wp-admin) es dinámico y generalmente no se cachea. Si el backend es lento:
- Recursos de servidor insuficientes
- Base de datos sin optimizar
- Plugins con procesos pesados en admin
- Hosting con límites de CPU agresivos
¿El CDN afecta al TTFB del admin de WordPress?
Generalmente no, porque el admin no debería estar cacheado. El CDN mejora principalmente el frontend público.
¿Cuánto tarda en notarse la mejora de TTFB en Google?
Los cambios en Core Web Vitals tardan 28 días en reflejarse en los datos de campo de Google. Los datos de laboratorio (PageSpeed Insights) se actualizan inmediatamente.
¿Puedo tener TTFB < 100ms globalmente?
Sí, con full page caching en un CDN global (Cloudflare Enterprise, QUIC.cloud). El contenido se sirve desde el edge más cercano al usuario, no desde tu servidor origen.
¿LiteSpeed Cache es mejor que WP Rocket?
Para TTFB, sí. LiteSpeed Cache funciona a nivel servidor y no requiere cargar PHP para servir páginas cacheadas. WP Rocket funciona a nivel aplicación (necesita cargar WordPress primero).
Conclusión {#conclusion}
El TTFB es la métrica fundacional del rendimiento WordPress. Si es alto, nada de lo que hagas en el frontend compensará ese retraso inicial.
Las claves para un TTFB < 200ms:
- Hosting con LiteSpeed + NVMe cerca de tu audiencia
- Caché a nivel servidor (LSCache, Varnish), no solo plugins
- Base de datos optimizada: autoload < 800KB, transients limpios
- Plugins auditados: menos es más
- PHP actualizado: 8.2 o superior
- CDN con full page caching: no solo para estáticos
El caso práctico demuestra que pasar de 780ms a 165ms es posible con optimizaciones sistemáticas. La mayoría del impacto viene del hosting y el caché a nivel servidor.
Si tu TTFB está por encima de 400ms, el primer paso es evaluar tu hosting. Las optimizaciones de base de datos y plugins ayudan, pero no pueden compensar un servidor lento o sobrecargado.
Artículos relacionados del cluster
Profundiza en otros aspectos de la velocidad WordPress:
- Hosting lento: cómo detectarlo y los 5 hostings más rápidos
- Base de datos WordPress inflada: cómo limpiar wp_options
- Los 7 plugins que más ralentizan WordPress
- Core Web Vitals en WordPress: guía para aprobar en 2026
- WP Rocket vs LiteSpeed Cache vs FlyingPress: comparativa
Fuentes y referencias
- Google Web Vitals Documentation
- OnlineMediaMasters TTFB Analysis 2025
- LiteSpeed Technologies Performance Benchmarks
- Cloudways TTFB Optimization Guide
- WP Engine Database Optimization Guide
- Elementor WordPress MySQL Optimization Guide
- WordPress Developer Handbook - Performance
WordPress Gestionado
Olvídate de las actualizaciones y problemas técnicos. Nosotros nos encargamos de todo.
