Cómo reducir el tiempo de respuesta del servidor: diagnóstico y mejora de TTFB

Para reducir el tiempo de respuesta del servidor, mide dónde espera la solicitud y corrige esa parte del recorrido. Un primer byte lento puede deberse a redirecciones, establecimiento de conexión, un origen lejano, trabajo de aplicación, consultas a la base de datos o un fallo de caché. Cambiar de alojamiento sin separar esas causas puede trasladar el mismo cuello de botella a un servidor más caro.

Time to First Byte, o TTFB, es el tiempo hasta que el navegador recibe el primer byte de respuesta de la navegación. Abarca más que el tiempo empleado por la aplicación en generar HTML. El objetivo práctico es entregar antes contenido útil, por lo que debes comprobar el efecto sobre el renderizado además del primer byte.

Define la medición antes de elegir un objetivo

La guía de optimización de TTFB de Google considera 800 milisegundos o menos una orientación aproximada de buen rendimiento. TTFB no es una de las tres Core Web Vitals. Superar esa referencia merece una investigación, pero la valoración final debe incluir cuánto tarda en aparecer contenido significativo.

Una página renderizada en el servidor puede dedicar más tiempo a preparar HTML y mostrar contenido útil antes que otra que entrega inmediatamente una estructura vacía y depende del cliente. Esto no convierte en deseable el trabajo lento del servidor. Significa que reducir el primer byte aplazando todo lo útil hasta ejecutar JavaScript puede ser una mala compensación.

Las mediciones también tienen alcances distintos. El TTFB de navegación en datos de campo puede incluir retrasos que una auditoría de laboratorio del documento final excluye. La antigua auditoría de tiempo de respuesta de Lighthouse no representaba toda la secuencia de DNS, redirecciones y conexión. La documentación actual de Chrome utiliza también el diagnóstico Document request latency; un nombre antiguo puede no coincidir con tu informe.

Anota qué valor estás optimizando: TTFB de navegación real, tramo de espera de una solicitud del navegador, cronómetro de aplicación o primer byte de una herramienta de línea de comandos. Compararlos como equivalentes produce conclusiones contradictorias aunque cada medición sea correcta.

Sigue la solicitud hasta obtener HTML útil

Varias etapas pueden preceder a la primera respuesta útil del documento. Su coste depende de DNS almacenado, conexiones existentes, redirecciones, protocolos y recorrido por la infraestructura.

No supongas que todas las etapas ocurren en cada solicitud. Un visitante recurrente puede reutilizar una conexión. Un acierto de caché puede evitar ejecutar la aplicación. Una página privada de cuenta no debe reutilizar HTML público destinado a otra persona.

La comparación más reveladora suele ser entre dos recorridos legítimos hacia el mismo contenido. Una página pública ya almacenada y otra sin caché pueden tener tiempos muy diferentes. Esa diferencia muestra qué parte del sistema protege actualmente a los visitantes del trabajo lento del origen.

Establece una referencia con el recorrido real del visitante

Abre DevTools antes de navegar e inspecciona la solicitud del documento en Network. Registra URL final, estado, protocolo, cabeceras y desglose temporal. Mantén visibles las redirecciones. Una prueba que empieza en el destino final no explica los retrasos de una redirección anterior desde una campaña o un enlace interno antiguo.

Separa pruebas con caché fría y caliente. Desactivar la caché del navegador modifica su reutilización, pero no necesariamente evita el CDN o la caché de páginas del servidor. Una ventana privada tampoco garantiza un edge vacío. Identifica qué capa intentas controlar.

Prueba contenido representativo. El inicio puede ser muy visitado y estar casi siempre almacenado, mientras que artículos antiguos se generan a petición. Búsquedas, cuentas y pagos pueden seguir recorridos distintos. Mantén privadas las pruebas autenticadas y no incluyas cookies de sesión en informes compartidos.

Repite desde regiones importantes para tu público cuando dispongas de un servicio de pruebas o monitorización apropiado. Una solicitud rápida desde cerca del origen dice poco sobre visitantes lejanos. Describe ubicación y condiciones en lugar de presentar una medición como resultado mundial.

Utiliza curl para separar hitos acumulados

Este comando realiza una solicitud GET, descarta el cuerpo e imprime tiempos acumulados. Sustituye la URL de ejemplo por una página pública que tengas autorización para probar. No sigue redirecciones intencionadamente, de modo que una redirección permanece visible.

curl --silent --show-error --output /dev/null \
  --write-out 'status=%{http_code}\ndns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nfirst_byte=%{time_starttransfer}\ntotal=%{time_total}\n' \
  'https://example.com/'

Los valores son tiempos transcurridos desde el inicio de la transferencia. No los sumes. En una conexión HTTPS nueva y sencilla, restar hitos consecutivos puede ayudar a aislar conexión y TLS, pero proxies, reutilización y comportamiento del protocolo pueden cambiar la interpretación.

El intervalo entre establecer la conexión y recibir el primer byte no es un cronómetro puro de aplicación. Incluye efectos de red y trabajo del servidor. Úsalo para ubicar la zona probable del retraso y después instrumenta el servidor para distinguir base de datos, renderizado y colas.

Comprueba el estado antes de interpretar el rendimiento. Una redirección, página de error o comprobación antibots rápida no equivale a una página correcta rápida. Tampoco sustituyas GET por HEAD por comodidad si la aplicación puede tratarlos de manera diferente.

Guarda varios resultados comparables con fecha y versión desplegada. Una mediana facilita comparar conjuntos pequeños, pero conserva los valores individuales y fallos inusuales. Una sola cifra central puede ocultar solicitudes intermitentes lentas que sí perciben los visitantes.

Instrumenta la aplicación sin exponer información privada

Las trazas del servidor identifican trabajo que el navegador no puede separar. Busca consultas, renderizado de plantillas, solicitudes a servicios superiores, lecturas de caché, esperas de procesos y acceso a archivos. Mantén nombres consistentes entre versiones para comparar sin reconstruir la instrumentación.

La cabecera Server-Timing expone duraciones con nombre a las herramientas del navegador. Este ejemplo PHP completo mide la generación de una pequeña respuesta HTML pública. Usa hrtime, disponible desde PHP 7.3; en producción debes utilizar una versión compatible que siga recibiendo soporte.

<?php
declare(strict_types=1);

$started = hrtime(true);
$title = htmlspecialchars('Performance example', ENT_QUOTES, 'UTF-8');
$html = '<!doctype html><html lang="en"><meta charset="utf-8">'
      . '<title>' . $title . '</title><h1>' . $title . '</h1></html>';
$durationMs = (hrtime(true) - $started) / 1e6;

header('Content-Type: text/html; charset=utf-8');
header('Cache-Control: no-store');
header('Server-Timing: render;dur=' . number_format($durationMs, 3, '.', ''));
echo $html;

La duración se mide al ejecutar el ejemplo; no representa un benchmark. La política no-store mantiene esta respuesta de diagnóstico fuera de las cachés HTTP. No es una política recomendada para todas las páginas públicas.

Coloca temporizadores alrededor de operaciones reales, sin etiquetar toda la solicitud como tiempo de base de datos. Las operaciones paralelas pueden solaparse, por lo que sus duraciones no siempre suman el tiempo total. La espera de un proceso disponible también puede comenzar antes del temporizador de la aplicación.

Utiliza nombres generales como render o database. No expongas SQL, tokens, identificadores de clientes, nombres internos de servidores ni información comercial sensible en cabeceras públicas. Las trazas detalladas pertenecen a sistemas de monitorización con acceso controlado.

Elige la caché que elimina el trabajo costoso

Las cachés de páginas, objetos y código de operación resuelven problemas distintos. Pueden coexistir, pero activar una no demuestra que las otras existan o funcionen.

Para una publicación que muestra el mismo artículo a visitantes anónimos, la caché de página completa suele ser un punto de partida útil. Comprueba cómo se invalida al editar contenido. Un artículo obsoleto después de una corrección sigue siendo un fallo editorial aunque su rendimiento sea excelente.

En páginas dinámicas, una caché de objetos puede reducir consultas repetidas mientras la aplicación construye una respuesta personalizada. En WordPress, la caché de objetos predeterminada no persiste automáticamente entre solicitudes. Un backend persistente requiere una implementación apropiada, y el beneficio depende de qué almacene realmente la aplicación.

PHP OPcache evita compilaciones repetidas, no consultas lentas ni llamadas lejanas. Comprueba configuración y compatibilidad, pero no esperes que repare un diseño ineficiente. En plataformas gestionadas, pregunta qué capas controla el proveedor antes de añadir otras superpuestas.

La caché del navegador ayuda sobre todo después de recibir los recursos. No garantiza una primera visita rápida. Consulta la guía de caché del navegador para distinguir vigencia, validación y prohibición de almacenamiento.

Protege sesiones, carritos y contenido personalizado

Empieza a almacenar HTML compartido con una lista reducida de páginas públicas permitidas. Excluye cuentas, carritos, pago y otras rutas personalizadas salvo que exista una estrategia diseñada y probada para ellas. Trata explícitamente cookies de sesión y autorización en las reglas.

Una cookie no garantiza por sí sola que todos los intermediarios consideren privada una respuesta. Lee y verifica el comportamiento del CDN y de la caché de aplicación. Ten especial cuidado con reglas que fuerzan el almacenamiento contra las cabeceras o ignoran parámetros sin entender su significado.

Prueba con dos sesiones independientes y un navegador sin iniciar sesión. Confirma que ninguno recibe el nombre, carrito, precio o estado de cuenta de otro visitante. Una buena tasa de aciertos es irrelevante si la respuesta pertenece a otra persona.

Mantén comprensibles las claves de caché. Los parámetros exclusivos de atribución publicitaria pueden fragmentar innecesariamente contenido público, pero selectores de producto, moneda, idioma y estado de acceso pueden modificar la respuesta. Normaliza solo entradas cuya irrelevancia para contenido y autorización hayas demostrado.

Corrige el origen lento aunque la caché funcione

Los fallos de caché siguen ocurriendo. Contenido nuevo, URL poco visitadas, invalidaciones y tráfico que llega a otro nodo pueden exigir trabajo nuevo. Ocultar un origen lento durante la prueba habitual no elimina la necesidad de entenderlo.

Utiliza perfiles de consultas para identificar trabajo costoso o repetido. Inspecciona planes de ejecución antes de añadir índices. Un índice útil para una lectura ocupa espacio y puede afectar las escrituras. Cambia lo necesario para una consulta medida, sin asumir que más índices siempre mejoran.

Busca llamadas repetidas en bucles, datos innecesarios y trabajo costoso en cada visita. Saca tareas secundarias del recorrido crítico cuando la corrección funcional lo permita. Una página no debe esperar registros administrativos ajenos solo porque comparten el mismo controlador.

Las API externas necesitan tiempos de espera, caché adecuada y comportamiento ante fallos. Decide qué datos son esenciales para la respuesta inicial y cuáles pueden llegar después. Aplazar contenido importante puede perjudicar renderizado y uso: evalúa la tarea completa, no solo TTFB.

Compara versiones del entorno y dependencias en pruebas antes de actualizar. Una versión PHP o Node con soporte forma parte del mantenimiento, pero debes verificar compatibilidad y rendimiento con tu aplicación. No prometas porcentajes universales de mejora por cambiar de versión.

Utiliza un CDN cuando la distancia y la reutilización lo justifiquen

Un CDN puede servir contenido apto desde un nodo cercano al visitante. Así reduce viajes a un origen distante, especialmente con aciertos de caché. Sin embargo, si solo almacena recursos estáticos, cada petición HTML puede seguir dependiendo del mismo origen lento.

Inspecciona la respuesta y las cabeceras de estado documentadas por el proveedor. Los nombres y significados varían. Confirma si hubo acierto, fallo, omisión, revalidación o entrega de contenido obsoleto según una política. Un nombre de host de CDN no demuestra un acierto.

Mide por separado HTML y recursos estáticos. Una tasa alta de aciertos en imágenes puede convivir con poca reutilización de HTML. Incluye bytes y tipos de solicitud cuando sea posible: un porcentaje agregado puede ocultar la categoría que necesitas mejorar.

Planifica la invalidación antes de ampliar duraciones. Publicar, corregir, cambiar permisos y desplegar una versión necesitan un comportamiento predecible. La guía de CDN y caché perimetral explica estas decisiones sin asumir valores predeterminados comunes a todos los proveedores.

Considera los protocolos como una parte de la entrega

La multiplexación HTTP/2 y el transporte QUIC de HTTP/3 pueden mejorar cómo comparten conexiones las solicitudes. El efecto depende de conexión, red e implementación. Ninguno elimina consultas lentas ni garantiza un primer byte más rápido siempre.

La reutilización de conexiones y la reanudación de sesiones TLS pueden reducir el establecimiento repetido en condiciones apropiadas. Comprueba qué ofrecen ya alojamiento y CDN. La conexión del navegador al CDN y la del CDN al origen pueden utilizar protocolos diferentes.

HTTP 103 Early Hints permite a clientes compatibles empezar recursos importantes antes de la respuesta final. No vuelve instantánea la generación de HTML y depende del navegador y de los intermediarios. Úsalo ante un retraso de descubrimiento demostrado, manteniendo una alternativa que funcione sin la indicación.

Early Hints también puede cambiar qué representa el primer byte. Chrome cuenta actualmente la respuesta provisional en responseStart; finalResponseHeadersStart, cuando está disponible, identifica el inicio de las cabeceras finales. Registra navegador y campo al comparar. Una respuesta provisional anterior no demuestra que el HTML final llegue antes.

La compresión reduce principalmente bytes transferidos. Comprimir sobre la marcha consume CPU, así que evalúa su efecto sin afirmar que una salida menor reduce necesariamente la latencia inicial. La explicación de HTTP/2 y HTTP/3 distingue mejoras de transporte y de aplicación.

Determina cuándo el alojamiento es el cuello de botella

Investiga infraestructura cuando la lentitud coincide con procesos agotados, CPU saturada, falta de memoria, almacenamiento lento o contención de base de datos. La correlación con horas de carga es una pista, pero identifica el recurso limitado antes de contratar más capacidad.

Compara una respuesta estática sencilla con una respuesta representativa de aplicación sin caché, manteniendo un recorrido comparable. Si solo falla la aplicación, inspecciona dependencias y ejecución. Si ambas empeoran bajo carga, examina recursos compartidos y alojamiento.

En alojamiento compartido quizá no accedas a todas las métricas. Presenta pruebas concretas al proveedor: horas, URL, estado de caché, cabeceras y mediciones repetidas. Pregunta qué límites se alcanzaron y si el plan permite la configuración necesaria.

Verifica la mejora en el recorrido que fallaba

Repite el escenario lento original después de cambiar una parte pertinente. Comprueba estados, contenido correcto, aislamiento de sesiones, invalidación y errores además del tiempo. Verifica después que el avance llega al renderizado y no solo aplaza trabajo.

Utiliza el analizador de PageSpeed cuando esté habilitado para inspeccionar una URL pública y conservar condiciones de laboratorio y datos de campo disponibles. Continúa con las guías de rendimiento del servidor cuando aparezca el siguiente cuello de botella. El resultado útil es una respuesta más rápida y repetible para el visitante previsto, con el contenido correcto intacto.