Optimiza la duración de conexión (TCP + TLS) del Time to First Byte

Optimiza la duración de conexión (TCP + TLS) del Time to First Byte

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

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

• Espera + Redirección (o duración de espera)
• Worker + Caché (o duración de caché)
• DNS (o duración de DNS)
• Conexión (o duración de conexión)
• Solicitud (o duración de solicitud)

¿Buscas optimizar el Time to First Byte? Este artículo ofrece un análisis en profundidad de la parte de duración de conexión del Time to First Byte. Si buscas entender o solucionar el Time to First Byte y no sabes qué significa la duración de conexión, lee qué es el Time to First Byte y cómo solucionar e identificar problemas del Time to First Byte antes de comenzar con este artículo.

La parte de duración de conexión 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 normalmente añaden una capa de cifrado (TLS). El proceso de negociar estas 2 conexiones lleva tiempo, y ese tiempo se suma al Time to First Byte.

Proceso de conexión en detalle

El Protocolo de Control de Transmisión (TCP) es responsable de establecer una conexión fiable entre el cliente (navegador) y el servidor. Este proceso implica un handshake de tres vías:

• 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 la 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 que permite la transferencia fiable de datos entre el cliente y el servidor.

TCP asegura que los datos se envíen y reciban en el orden correcto, reenviando 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 el servidor y establecer un canal de comunicación seguro:

• ClientHello: El cliente envía un mensaje "ClientHello" al servidor, indicando las versiones de TLS compatibles, los conjuntos de cifrado 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).
• Certificado e intercambio de claves: El servidor envía su certificado digital al cliente para autenticación. El cliente verifica el certificado con las autoridades de certificación de confianza.
• Premaster Secret: El cliente genera un premaster secret, lo cifra con la clave pública del servidor (del certificado) y lo envía al servidor.
• Generación de clave 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 clave de sesión compartida para el cifrado simétrico.
• Mensajes de finalización: El cliente y el servidor intercambian mensajes cifrados con la clave de sesión para confirmar que el handshake fue exitoso y que ambas partes tienen la clave 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 interceptación y manipulación por terceros.

TLS 1.3 vs TLS 1.2: por qué importa para el TTFB

La versión de TLS que usa tu servidor tiene un impacto directo en la duración de conexión. TLS 1.3 es significativamente 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 del servidor (tiempo de ida y vuelta), esto ahorra aproximadamente 100ms en cada nueva conexión. Para visitantes recurrentes, la reanudación 0-RTT (zero round trip time) de TLS 1.3 permite al cliente enviar datos cifrados inmediatamente al reconectarse, reutilizando información de sesión intercambiada previamente. Esto puede reducir la sobrecarga del handshake TLS a casi cero para 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 admite la reanudación 0-RTT para reconexiones más rápidas. Además, el uso de UDP por parte de QUIC elimina el bloqueo head-of-line y mejora el control de congestión, lo que resulta en una transmisión de datos más eficiente y cargas de página más rápidas.

HTTP/3 aporta varias mejoras sobre HTTP/2 que afectan directamente la duración de conexión:

• Handshake combinado: Con HTTP/2 sobre TCP, el handshake TCP y el handshake TLS ocurren de forma secuencial (3 viajes de ida y vuelta en total para una nueva conexión). HTTP/3 sobre QUIC combina el handshake de transporte y TLS en un solo viaje de ida y vuelta. Para nuevas conexiones, esto ahorra un viaje de ida y vuelta completo comparado 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 recurrentes pueden comenzar a enviar datos inmediatamente sin esperar a que se complete ningún handshake. Esto es particularmente efectivo para usuarios móviles que cambian frecuentemente entre Wi-Fi y conexiones celulares.
• Sin bloqueo head-of-line: Con HTTP/2 sobre TCP, un solo paquete perdido bloquea todos los flujos en esa conexión hasta que el paquete se retransmite. QUIC usa UDP y gestiona los flujos de forma independiente, por lo que un paquete perdido solo afecta al flujo específico al que pertenece. Esto resulta en 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 de origen y puerto. Esto significa que cuando un usuario móvil pasa de Wi-Fi a datos celulares (y su dirección IP cambia), la conexión QUIC sobrevive sin necesidad de reestablecerse. Esto evita el handshake completo de TCP + TLS 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

Usa preconnect para orígenes críticos

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

<!-- Preconnect to critical third-party origins -->
<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">

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

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

• HTTP/3: incorpora el protocolo QUIC sobre UDP en lugar de TCP, permitiendo 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. Necesario para la reanudación de conexión 0-RTT.
• Reanudación de conexión 0-RTT: función de TLS 1.3 que permite a los clientes recurrentes enviar datos cifrados inmediatamente al reconectarse, reutilizando información intercambiada previamente.
• TCP Fast Open: permite enviar datos en el paquete SYN inicial, reduciendo el tiempo de ida y vuelta del handshake TCP.
• TLS False Start: permite el envío temprano de datos antes de que el handshake TLS se complete.
• 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í tienes 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;

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

    # Enable session resumption (TLS session tickets)
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets on;

    # ... rest of your server configuration
}

Para Apache, habilita TLS 1.3 con:

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

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

    # Enable session resumption
    SSLSessionCache shmcb:/tmp/ssl_gcache_data(512000)
    SSLSessionCacheTimeout 300

    # ... rest of your virtual host configuration
</VirtualHost>

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

Medición de la duración de conexión con JavaScript

Puedes medir la subparte de duración de conexión del TTFB directamente en el navegador usando la Navigation Timing API:

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('  TCP handshake:', (tcpDuration - tlsDuration).toFixed(0), 'ms');
  console.log('  TLS negotiation:', tlsDuration.toFixed(0), 'ms');

  if (nav.nextHopProtocol) {
    console.log('  Protocol:', 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 tu servidor es compatible con HTTP/3 pero tus datos RUM muestran que la mayoría de las conexiones usan "h2", puede indicar que la compatibilidad con HTTP/3 no se está anunciando correctamente mediante 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ás usar una herramienta RUM como CoreDash. El Real User Monitoring te permitirá rastrear los Core Web Vitals con mayor detalle y sin el retraso de 28 días de Google.

En CoreDash, haz 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

Para técnicas de optimización relacionadas que complementan la optimización de conexión, explora estas guías:

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

Subpartes del TTFB: artículos de análisis detallado

La duración de conexión es una de las cinco subpartes del TTFB. Explora las otras subpartes para entender el panorama completo:

• Solucionar e identificar problemas de TTFB: el punto de partida diagnóstico para toda optimización del TTFB.
• Duración de espera: redirecciones, cola del navegador y optimización de HSTS.
• Duración de caché: rendimiento del service worker, consultas de caché del navegador y bfcache.
• Duración de DNS: selección del proveedor DNS, configuración de TTL y dns-prefetch.