Por qué su servidor tarda en responder
El TTFB es casi por completo un problema de backend y de red, no de frontend. Causas comunes:
- Arranques en frío. Funciones serverless que tienen que iniciar un entorno de ejecución antes de manejar la primera solicitud tras un tiempo de inactividad.
- Renderizado dinámico sin caché. Cada solicitud vuelve a ejecutar consultas a la base de datos y renderizado del lado del servidor que podrían haberse almacenado en caché o calculado una sola vez.
- Consultas de base de datos lentas. Una sola consulta sin índice o un patrón N+1 pueden añadir cientos de milisegundos antes de que el servidor pueda siquiera empezar a escribir una respuesta.
- Larga distancia física hasta el origen. Un visitante en Singapur que accede a un servidor en Virginia paga ese trayecto de ida y vuelta en cada solicitud, sin importar cuán rápido responda el servidor en sí.
- Cadenas de redirección. Cada salto (http → https → www → URL final) es un trayecto de ida y vuelta completo antes de que la respuesta real siquiera empiece.
Cómo identificar qué es realmente lento
Las verificaciones de rendimiento de Scanverra capturan el TTFB como parte de la misma ejecución de Lighthouse usada para LCP y CLS, contra su URL en vivo, así que obtiene la cifra real de tiempo de respuesta del servidor, no un sustituto de ella. Eso importa porque un LCP lento con un TTFB rápido lo orienta hacia soluciones de imagen/renderizado, mientras que un LCP lento con un TTFB lento significa que arreglar el servidor tiene que venir primero.
Para acotar dónde se está yendo realmente el tiempo, revise el desglose de tiempos del lado del servidor de su proveedor de hosting o APM (la mayoría de las plataformas reportan por separado el tiempo dedicado a la inicialización de funciones, las llamadas a la base de datos y la serialización de la respuesta) en lugar de adivinar desde fuera.
Cómo solucionarlo
1. Almacene en caché lo que no necesita regenerarse por solicitud
Todo lo que sea igual para cada visitante, o para cada visitante de un segmento dado, es candidato a caché. Establezca un tiempo de vida de caché explícito en el edge de la CDN en lugar de dejar que cada solicitud llegue a su origen:
1Cache-Control: public, max-age=60, stale-while-revalidate=3002. Ponga su origen (o al menos una capa de caché) cerca de sus usuarios
Despliegue en una región cercana a su tráfico real, o coloque delante de un origen distante una caché edge/CDN para que la mayoría de las solicitudes nunca hagan el trayecto largo de ida y vuelta.
3. Arregle la consulta lenta, no el síntoma
Si su APM muestra que el tiempo de base de datos domina el TTFB, normalmente se trata de un índice faltante, un patrón de consulta N+1, o una consulta que hace más trabajo del que la página realmente necesita: perfile la consulta específica antes de recurrir a la caché como solución provisional.
4. Reduzca la frecuencia de arranques en frío en funciones serverless
Mantenga calientes las funciones para rutas sensibles a la latencia, minimice el código y las dependencias que tienen que inicializarse antes de que se ejecute el manejador, y considere un servidor persistente para patrones de tráfico donde los arranques en frío ocurren constantemente.
5. Reduzca las cadenas de redirección
Cada salto entre la URL que solicita un usuario y la URL que realmente sirve el contenido es un trayecto de ida y vuelta completo añadido al TTFB antes de que pueda empezar el renderizado: apunte los enlaces y las URL canónicas directamente al destino final.
Cómo detecta Scanverra los problemas de TTFB
El TTFB se captura directamente de la misma pasada real de Lighthouse que Scanverra ejecuta para cada verificación de rendimiento, tanto en un perfil de escritorio como en un viewport móvil de 375 px, así que se mide contra la respuesta real de su servidor en vivo, no simulada.