Optimizar la subparte Connection Duration (TCP + TLS) del Time to First Byte

Optimizar la Connection Duration (TCP + TLS) Subparte del Time to First Byte

Este artículo forma parte de nuestra guía sobre el Time to First Byte (TTFB). La connection duration es la cuarta subparte del TTFB y representa el tiempo que el navegador dedica a establecer una conexión TCP y a negociar el cifrado TLS con el servidor. Para los usuarios que están geográficamente distantes del servidor, la connection duration puede añadir de 100 a 500 milisegundos al TTFB debido a los múltiples viajes de ida y vuelta (round trips) necesarios para los handshakes TCP y TLS.

El Time to First Byte (TTFB) puede desglosarse en las siguientes subpartes:

• Waiting + Redirect (o waiting duration)
• Worker + Cache (o cache duration)
• DNS (o DNS duration)
• Connection (o connection duration)
• Request (o request duration)

¿Busca optimizar el Time to First Byte? Este artículo cubre la parte de connection duration del Time to First Byte. Si busca comprender o corregir el Time to First Byte y no sabe qué significa connection duration, lea qué es el Time to First Byte e identificar y corregir problemas de Time to First Byte antes de comenzar con este artículo.

La parte de connection duration del Time to First Byte consiste en el tiempo en el que el navegador se conecta al servidor web. Después de esa conexión, el navegador y el servidor suelen añadir una capa de cifrado (TLS). El proceso de negociación de estas 2 conexiones llevará algún tiempo, y ese tiempo se añade al Time to First Byte.

Proceso de conexión en detalle

El Transmission Control Protocol (TCP) es responsable de establecer una conexión fiable entre el cliente (navegador) y el servidor. Este proceso implica un saludo de tres vías (three-way handshake):

• Paquete SYN (Synchronize): El cliente envía un paquete SYN al servidor para iniciar la conexión y solicitar la sincronización.
• Paquete SYN-ACK (Synchronize-Acknowledge): El servidor responde con un paquete SYN-ACK, confirmando la recepción del paquete SYN y aceptando establecer una conexión.
• Paquete ACK (Acknowledge): El cliente envía un paquete ACK de vuelta al servidor, confirmando la recepción del paquete SYN-ACK. En este punto, se establece una conexión TCP, lo que permite transferir datos de forma fiable entre el cliente y el servidor.

TCP garantiza que los datos se envíen y reciban en el orden correcto, retransmitiendo cualquier paquete perdido y gestionando el control de flujo para adaptarse a la capacidad de la red.

Una vez establecida la conexión TCP, se utiliza el protocolo Transport Layer Security (TLS) para asegurar la conexión. El handshake TLS implica varios pasos para autenticar al servidor y establecer un canal de comunicación seguro:

• ClientHello: El cliente envía un mensaje "ClientHello" al servidor, indicando las versiones de TLS soportadas, los conjuntos de cifrado (cipher suites) y un número aleatorio (Client Random).
• ServerHello: El servidor responde con un mensaje "ServerHello", seleccionando la versión de TLS y el conjunto de cifrado de la lista del cliente, y proporcionando su certificado digital y un número aleatorio (Server Random).
• Intercambio de certificados y llaves: El servidor envía su certificado digital al cliente para su autenticación. El cliente verifica el certificado contra autoridades de certificación de confianza.
• Premaster Secret: El cliente genera un secreto maestro previo (premaster secret), lo cifra con la llave pública del servidor (del certificado) y lo envía al servidor.
• Generación de la llave de sesión: Tanto el cliente como el servidor utilizan el premaster secret, junto con el Client Random y el Server Random, para generar una llave de sesión compartida para el cifrado simétrico.
• Mensajes Finished: El cliente y el servidor intercambian mensajes cifrados con la llave de sesión para confirmar que el handshake se ha realizado correctamente y que ambas partes tienen la llave de sesión correcta.

Una vez completado el handshake TLS, el cliente y el servidor han establecido una conexión segura y cifrada. Esto garantiza que cualquier dato intercambiado esté protegido contra la escucha y la manipulación por parte de terceros.

TLS 1.3 vs TLS 1.2: Por qué es importante para el TTFB

La versión de TLS que utiliza su servidor tiene un impacto directo en la connection duration. TLS 1.3 es más rápido que TLS 1.2 porque reduce el número de viajes de ida y vuelta necesarios para completar el handshake:

TLS 1.3 reduce el handshake de dos viajes de ida y vuelta a uno. Para un usuario que está a 100ms de distancia del servidor (tiempo de ida y vuelta), esto ahorra aproximadamente 100ms en cada nueva conexión. Para los visitantes recurrentes, la reanudación 0-RTT (zero round trip time) de TLS 1.3 permite al cliente enviar datos cifrados inmediatamente después de la reconexión reutilizando la información de sesión intercambiada previamente. Esto puede reducir la sobrecarga del handshake TLS a casi cero para los visitantes recurrentes.

HTTP/3 y QUIC: El futuro de las conexiones rápidas

HTTP/3 acelera las conexiones TLS al integrarse con el protocolo QUIC, que reduce el número de viajes de ida y vuelta necesarios para establecer una conexión segura al combinar los procesos de handshake en uno solo, y soporta la reanudación 0-RTT para reconexiones más rápidas. Además, el uso de UDP por parte de QUIC elimina el bloqueo de cabeza de línea (head-of-line blocking) y mejora el control de la congestión, lo que conduce a una transmisión de datos más eficiente y a cargas de página más rápidas.

HTTP/3 aporta varias mejoras sobre HTTP/2 que afectan directamente a la connection duration:

• Handshake combinado: Con HTTP/2 sobre TCP, el handshake TCP y el handshake TLS ocurren secuencialmente (3 viajes de ida y vuelta en total para una nueva conexión). HTTP/3 sobre QUIC combina el transporte y el handshake TLS en un solo viaje de ida y vuelta. Para nuevas conexiones, esto ahorra un viaje de ida y vuelta completo en comparación con HTTP/2.
• Reanudación de conexión 0-RTT: Al igual que TLS 1.3, QUIC admite la reanudación 0-RTT. Los visitantes que regresan pueden empezar a enviar datos inmediatamente sin esperar a que se complete ningún handshake. Esto es particularmente eficaz para los usuarios móviles que cambian frecuentemente entre Wi-Fi y conexiones de datos.
• Sin bloqueo de cabeza de línea: Con HTTP/2 sobre TCP, un solo paquete perdido bloquea todos los flujos en esa conexión hasta que el paquete se retransmite. QUIC utiliza UDP y gestiona los flujos de forma independiente, por lo que un paquete perdido solo afecta al flujo específico al que pertenece. Esto da como resultado un rendimiento de conexión más consistente en redes poco fiables.
• Migración de conexión: Las conexiones QUIC se identifican por un ID de conexión en lugar de una IP y puerto de origen. Esto significa que cuando un usuario móvil pasa de Wi-Fi a datos (y su dirección IP cambia), la conexión QUIC sobrevive sin necesidad de restablecerse. Esto evita el handshake TCP + TLS completo que de otro modo sería necesario.

¿Cómo afecta el tiempo de conexión al Time to First Byte?

Cómo minimizar el impacto del tiempo de conexión en el TTFB

Use Preconnect para orígenes críticos

La indicación de recurso <link rel="preconnect"> indica al navegador que establezca una conexión (DNS + TCP + TLS) con un origen específico antes de que se necesiten realmente los recursos de ese origen. Esto elimina la connection duration de la ruta crítica cuando finalmente se solicita el recurso:

<!-- Preconnect a orígenes críticos de terceros -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="preconnect" href="https://cdn.example.com">

Utilice preconnect con moderación (máximo de 3 a 5 orígenes). Cada preconnect abre una conexión TCP + TLS completa, que consume recursos de CPU y red. Solo realice preconnect a los orígenes que se necesitan en cada carga de página. Para los orígenes que solo se necesitan ocasionalmente, utilice dns-prefetch en su lugar (consulte nuestra guía de DNS duration).

Configuración del servidor para TLS 1.3 y HTTP/3

• HTTP/3: trae el protocolo QUIC sobre UDP en lugar de TCP, lo que permite una transferencia de datos más rápida y eficiente.
• TLS 1.3: añade más seguridad y reduce los viajes de ida y vuelta del handshake. Requerido para la reanudación de conexión 0-RTT.
• Reanudación de conexión 0-RTT: característica de TLS 1.3 que permite a los clientes que regresan enviar datos cifrados inmediatamente después de la reconexión reutilizando la información intercambiada previamente.
• TCP Fast Open: permite que los datos se envíen en el paquete SYN inicial, reduciendo el tiempo de ida y vuelta para el handshake TCP.
• TLS False Start: permite el envío temprano de datos antes de que se complete el handshake TLS.
• OCSP Stapling: acelera la validación del certificado al eliminar la necesidad de que el cliente contacte directamente con la autoridad de certificación.

Aquí hay un ejemplo de configuración de Nginx que habilita TLS 1.3 y OCSP Stapling:

server {
    listen 443 ssl http2;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;

    # TLS 1.3 cipher suites
    ssl_ciphers TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;

    # Habilitar OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 1.1.1.1 8.8.8.8 valid=300s;
    resolver_timeout 5s;

    # Habilitar reanudación de sesión (TLS session tickets)
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets on;

    # ... resto de la configuración de su servidor
}

Para Apache, habilite TLS 1.3 con:

<VirtualHost *:443>
    SSLEngine on
    SSLProtocol -all +TLSv1.2 +TLSv1.3

    # Habilitar OCSP Stapling
    SSLUseStapling On
    SSLStaplingCache shmcb:/tmp/stapling_cache(128000)

    # Habilitar reanudación de sesión
    SSLSessionCache shmcb:/tmp/ssl_gcache_data(512000)
    SSLSessionCacheTimeout 300

    # ... resto de la configuración de su host virtual
</VirtualHost>

CONSEJO sobre Time to First Byte: un CDN no solo ofrece tiempos de ida y vuelta más cortos. El uso de un CDN a menudo mejorará inmediatamente los tiempos de conexión TCP y TLS porque los proveedores de CDN premium habrán configurado correctamente estos ajustes por usted. Consulte nuestra guía sobre cómo configurar Cloudflare para el rendimiento para comenzar.

Medir la Connection Duration con JavaScript

Puede medir la subparte connection duration del TTFB directamente en el navegador utilizando la API Navigation Timing:

new PerformanceObserver((entryList) => {
  const [nav] = entryList.getEntriesByType('navigation');

  const tcpDuration = nav.connectEnd - nav.connectStart;
  const tlsDuration = nav.connectEnd - nav.secureConnectionStart;
  const totalConnection = tcpDuration;

  console.log('Connection Duration:', totalConnection.toFixed(0), 'ms');
  console.log('  Handshake TCP:', (tcpDuration - tlsDuration).toFixed(0), 'ms');
  console.log('  Negociación TLS:', tlsDuration.toFixed(0), 'ms');

  if (nav.nextHopProtocol) {
    console.log('  Protocolo:', nav.nextHopProtocol);
  }
}).observe({
  type: 'navigation',
  buffered: true
});

La propiedad nextHopProtocol revela qué protocolo se utilizó para la conexión. Los valores comunes son "h2" (HTTP/2), "h3" (HTTP/3) y "http/1.1". Si su servidor admite HTTP/3 pero sus datos de RUM muestran que la mayoría de las conexiones utilizan "h2", puede indicar que el soporte de HTTP/3 no se anuncia correctamente a través de la cabecera Alt-Svc.

Cómo encontrar problemas de TTFB causados por un tiempo de conexión lento

Para encontrar el impacto que experimentan los usuarios reales causado por la latencia de conexión, necesitará utilizar una herramienta de RUM como CoreDash. El Real User Monitoring le permitirá rastrear los Core Web Vitals con mayor detalle y sin el retraso de 28 días de Google.

In CoreDash, haga clic en "Desglose del Time to First Byte" para visualizar la parte de conexión del Time to First Byte.

Lectura adicional: Guías de optimización

Guías relacionadas:

• 103 Early Hints: el servidor puede enviar indicaciones de recursos (preload, preconnect) mientras aún procesa la respuesta principal, lo que permite al navegador comenzar a establecer conexiones antes.
• Configurar Cloudflare para el rendimiento: Cloudflare habilita automáticamente HTTP/3, TLS 1.3 y OCSP Stapling. El uso de un CDN también acerca su servidor a los usuarios, reduciendo los tiempos de ida y vuelta para todas las conexiones.

Subpartes del TTFB: Guías completas

La connection duration es una de las cinco subpartes del TTFB. Explore las otras subpartes para comprender el panorama completo:

• Identificar y corregir problemas de TTFB: el punto de partida del diagnóstico para toda la optimización del TTFB.
• Waiting Duration: redirecciones, colas del navegador y optimización de HSTS.
• Cache Duration: rendimiento del service worker, búsquedas en la caché del navegador y bfcache.
• DNS Duration: selección del proveedor de DNS, configuración de TTL y dns-prefetch.
• Request Duration: tiempo de procesamiento del servidor, consultas a la base de datos y optimización del backend.