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

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

Este artículo es parte de nuestra guía sobre el Time to First Byte (TTFB). La duración de conexión es la cuarta parte 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 los usuarios geográficamente distantes del servidor, la duración de la conexión puede sumar entre 100 y 500 milisegundos al TTFB debido a los múltiples viajes de ida y vuelta requeridos para los handshakes de TCP y TLS.

El Time to First Byte (TTFB) se puede dividir en las siguientes partes:

• 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)
• Petición (o duración de petición)

¿Buscas optimizar el Time to First Byte? Este artículo cubre la parte de duración de conexión del Time to First Byte. Si buscas entender o solucionar problemas del Time to First Byte y no sabes qué significa la duración de conexión, lee qué es el Time to First Byte e identifica y soluciona problemas del Time to First Byte antes de empezar con este artículo.

La parte de duración de conexión del Time to First Byte consiste en el tiempo que el navegador emplea conectándose al servidor web. Tras esa conexión, el navegador y el servidor normalmente añaden una capa de cifrado (TLS). El proceso de negociar estas dos conexiones lleva un tiempo, y ese tiempo se suma al Time to First Byte.

Proceso de conexión en detalle

El Transmission Control Protocol (TCP) se encarga 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 sincronización.
• Paquete SYN-ACK (Synchronize-Acknowledge): El servidor responde con un paquete SYN-ACK, acusando recibo del paquete SYN y aceptando establecer una conexión.
• Paquete ACK (Acknowledge): El cliente devuelve un paquete ACK al servidor, confirmando la recepción del paquete SYN-ACK. En este punto, se establece una conexión TCP, permitiendo transferir datos de forma fiable entre cliente y servidor.

TCP asegura que los datos se envíen y reciban en el orden correcto, retransmitiendo los paquetes perdidos y gestionando el control de flujo para ajustarse 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 compatibles, las suites de cifrado y un número aleatorio (Client Random).
• ServerHello: El servidor responde con un mensaje "ServerHello", seleccionando la versión de TLS y la suite de cifrado de la lista del cliente, y proporcionando su certificado digital y un número aleatorio (Server Random).
• Intercambio de certificado y claves: El servidor envía su certificado digital al cliente para su autenticación. El cliente verifica el certificado usando autoridades de certificación de confianza.
• Secreto pre-maestro (Premaster Secret): El cliente genera un secreto pre-maestro, lo cifra con la clave pública del servidor (obtenida del certificado) y se lo envía al servidor.
• Generación de clave de sesión: Tanto el cliente como el servidor usan el secreto pre-maestro, junto al Client Random y el Server Random, para generar una clave de sesión compartida para el cifrado simétrico.
• Mensajes Finished: El cliente y el servidor intercambian mensajes cifrados con la clave de sesión para confirmar que el handshake tuvo éxito 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 frente a escuchas e intentos de manipulación por parte de terceros.

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

La versión de TLS que usa tu servidor impacta directamente en la duración de la conexión. 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 a 100 ms de distancia del servidor (tiempo de ida y vuelta), esto ahorra unos 100 ms 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 al reconectar, reutilizando la información de sesión intercambiada previamente. Esto puede reducir la sobrecarga del handshake TLS a casi cero para quienes vuelven a visitar el sitio.

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 combinando los procesos del handshake en uno solo, y soporta reanudación 0-RTT para reconexiones más veloces. Además, el uso de UDP en QUIC elimina el head-of-line blocking y mejora el control de congestión, lo que resulta en transmisiones de datos más eficientes y cargas de página más rápidas.

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

• Handshake combinado: Con HTTP/2 sobre TCP, el handshake de TCP y el handshake de TLS ocurren de manera secuencial (3 viajes de ida y vuelta en total para una nueva conexión). HTTP/3 sobre QUIC combina el handshake de transporte y el de TLS en un solo viaje de ida y vuelta. En 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 soporta la reanudación 0-RTT. Los visitantes recurrentes pueden empezar a enviar datos inmediatamente sin esperar a que termine ningún handshake. Esto es especialmente efectivo en usuarios móviles que alternan a menudo entre Wi-Fi y redes celulares.
• Sin head-of-line blocking: Con HTTP/2 sobre TCP, un solo paquete perdido bloquea todos los streams de esa conexión hasta que el paquete se retransmite. QUIC usa UDP y gestiona los streams de manera independiente, por lo que un paquete perdido solo afecta a su stream específico. Esto proporciona un rendimiento de conexión más consistente en redes inestables.
• Migración de conexión: Las conexiones QUIC se identifican mediante un ID de conexión en lugar de por una IP y un puerto de origen. Esto significa que cuando un usuario móvil pasa de Wi-Fi a una red celular (y su dirección IP cambia), la conexión QUIC sobrevive sin necesidad de restablecerse. Así se evita tener que realizar todo el handshake TCP + TLS de nuevo.

¿Cómo impacta el tiempo de conexión en el 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 sugerencia de recurso <link rel="preconnect"> le dice al navegador que establezca una conexión (DNS + TCP + TLS) hacia un origen especificado antes de que los recursos de ese origen sean realmente necesarios. Esto saca la duración de la conexión fuera de la ruta crítica cuando finalmente se solicita el recurso:

<!-- Preconnect a orígenes de terceros críticos -->
<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 (entre 3 y 5 orígenes como máximo). Cada preconnect abre una conexión TCP + TLS completa, lo que consume CPU y recursos de red. Usa preconnect únicamente en orígenes que se necesitan en cada carga de página. Para los orígenes que se necesitan solo ocasionalmente, emplea 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: implementa 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 mayor 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 recurrentes enviar datos cifrados inmediatamente al reconectar, 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 enviar datos anticipadamente antes de que el handshake TLS se complete.
• OCSP Stapling: acelera la validación de certificados 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;

    # Suites de cifrado TLS 1.3
    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 tu servidor
}

Para Apache, habilita 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 tu virtual host
</VirtualHost>

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

Medir la duración de conexión con JavaScript

Puedes medir la parte 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('Duración de conexión:', 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 usó para la conexión. Los valores comunes son "h2" (HTTP/2), "h3" (HTTP/3) y "http/1.1". Si tu servidor soporta HTTP/3 pero tus datos de RUM muestran que la mayoría de las conexiones usan "h2", podría indicar que el soporte de HTTP/3 no se está anunciando correctamente a través de la cabecera Alt-Svc.

Cómo encontrar problemas de TTFB causados por tiempos de conexión lentos

Para ver el impacto que experimentan los usuarios reales a causa de la latencia en la conexión, necesitarás usar una herramienta RUM como CoreDash. El Real User Monitoring te permitirá rastrear las Core Web Vitals con mayor detalle y sin el retraso de 28 días de Google.

En CoreDash, haz clic en "Time to First Byte breakdown" para visualizar la parte de conexión del Time to First Byte.

Lecturas adicionales: Guías de optimización

Guías relacionadas:

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

Partes del TTFB: Guías completas

La duración de la conexión es una de las cinco partes del TTFB. Explora las demás partes para comprender el panorama completo:

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