Otimize a Subparte de Duração da Conexão (TCP + TLS) do Time to First Byte

Otimize a Subparte de Duração da Conexão (TCP + TLS) do Time to First Byte

Este artigo faz parte do nosso guia sobre Time to First Byte (TTFB). A duração da conexão é a quarta subparte do TTFB e representa o tempo que o navegador gasta estabelecendo uma conexão TCP e negociando a criptografia TLS com o servidor. Para usuários geograficamente distantes do servidor, a duração da conexão pode adicionar de 100 a 500 milissegundos ao TTFB devido às múltiplas viagens de ida e volta (round trips) necessárias para os handshakes TCP e TLS.

O Time to First Byte (TTFB) pode ser dividido nas seguintes subpartes:

• Waiting + Redirect (ou duração de espera)
• Worker + Cache (ou duração de cache)
• DNS (ou duração de DNS)
• Connection (ou duração da conexão)
• Request (ou duração da requisição)

Quer otimizar o Time to First Byte? Este artigo cobre a parte da duração da conexão do Time to First Byte. Se você quer entender ou consertar o Time to First Byte e não sabe o que significa a duração da conexão, por favor leia o que é o Time to First Byte e como identificar e corrigir problemas de Time to First Byte antes de começar este artigo.

A parte da duração da conexão do Time to First Byte consiste no tempo em que o navegador está se conectando ao servidor web. Após essa conexão, o navegador e o servidor geralmente adicionarão uma camada de criptografia (TLS). O processo de negociação dessas 2 conexões levará algum tempo, e esse tempo é adicionado ao Time to First Byte.

O Processo de Conexão em Detalhes

O Transmission Control Protocol (TCP) é responsável por estabelecer uma conexão confiável entre o cliente (navegador) e o servidor. Esse processo envolve um handshake de três vias (three-way handshake):

• Pacote SYN (Synchronize): O cliente envia um pacote SYN ao servidor para iniciar a conexão e solicitar sincronização.
• Pacote SYN-ACK (Synchronize-Acknowledge): O servidor responde com um pacote SYN-ACK, confirmando o recebimento do pacote SYN e concordando em estabelecer a conexão.
• Pacote ACK (Acknowledge): O cliente envia um pacote ACK de volta ao servidor, confirmando o recebimento do pacote SYN-ACK. Neste ponto, uma conexão TCP é estabelecida, permitindo que os dados sejam transferidos de forma confiável entre o cliente e o servidor.

O TCP garante que os dados sejam enviados e recebidos na ordem correta, reenviando quaisquer pacotes perdidos e gerenciando o controle de fluxo para corresponder à capacidade da rede.

Uma vez que a conexão TCP é estabelecida, o protocolo Transport Layer Security (TLS) é usado para proteger a conexão. O handshake TLS envolve várias etapas para autenticar o servidor e estabelecer um canal de comunicação seguro:

• ClientHello: O cliente envia uma mensagem "ClientHello" ao servidor, indicando as versões de TLS suportadas, as suítes de criptografia (cipher suites) e um número aleatório (Client Random).
• ServerHello: O servidor responde com uma mensagem "ServerHello", selecionando a versão do TLS e a suíte de criptografia da lista do cliente, e fornecendo seu certificado digital e um número aleatório (Server Random).
• Troca de Certificado e Chave: O servidor envia seu certificado digital ao cliente para autenticação. O cliente verifica o certificado contra as autoridades certificadoras confiáveis.
• Premaster Secret: O cliente gera um premaster secret, criptografa-o com a chave pública do servidor (do certificado) e o envia ao servidor.
• Geração de Chave de Sessão: Tanto o cliente quanto o servidor usam o premaster secret, junto com o Client Random e o Server Random, para gerar uma chave de sessão compartilhada para criptografia simétrica.
• Mensagens Finished: O cliente e o servidor trocam mensagens criptografadas com a chave de sessão para confirmar que o handshake foi bem-sucedido e que ambas as partes têm a chave de sessão correta.

Assim que o handshake TLS é concluído, o cliente e o servidor estabelecem uma conexão segura e criptografada. Isso garante que quaisquer dados trocados fiquem protegidos contra interceptação e adulteração por terceiros.

TLS 1.3 vs TLS 1.2: Por Que Isso Importa Para o TTFB

A versão do TLS que seu servidor usa tem um impacto direto na duração da conexão. O TLS 1.3 é mais rápido que o TLS 1.2 porque reduz o número de round trips necessários para concluir o handshake:

O TLS 1.3 reduz o handshake de dois round trips para um. Para um usuário que está a 100ms de distância do servidor (tempo de round trip), isso economiza aproximadamente 100ms em cada nova conexão. Para visitantes recorrentes, a retomada 0-RTT (zero round trip time) do TLS 1.3 permite que o cliente envie dados criptografados imediatamente ao reconectar, reutilizando informações de sessão trocadas anteriormente. Isso pode reduzir a sobrecarga do handshake TLS a quase zero para visitantes que retornam.

HTTP/3 e QUIC: O Futuro das Conexões Rápidas

O HTTP/3 acelera as conexões TLS integrando-se ao protocolo QUIC, que reduz o número de round trips necessários para estabelecer uma conexão segura combinando os processos de handshake em um só, e suporta a retomada 0-RTT para reconexões mais rápidas. Além disso, o uso de UDP pelo QUIC elimina o bloqueio de início de fila (head-of-line blocking) e melhora o controle de congestionamento, levando a uma transmissão de dados mais eficiente e carregamentos de página mais rápidos.

O HTTP/3 traz várias melhorias em relação ao HTTP/2 que afetam diretamente a duração da conexão:

• Handshake combinado: Com HTTP/2 sobre TCP, o handshake TCP e o handshake TLS ocorrem sequencialmente (3 round trips no total para uma nova conexão). O HTTP/3 sobre QUIC combina o transporte e o handshake TLS em um único round trip. Para novas conexões, isso economiza um round trip inteiro em comparação com o HTTP/2.
• Retomada de conexão 0-RTT: Assim como o TLS 1.3, o QUIC suporta a retomada 0-RTT. Os visitantes que retornam podem começar a enviar dados imediatamente, sem esperar pela conclusão de qualquer handshake. Isso é particularmente eficaz para usuários mobile que alternam frequentemente entre conexões Wi-Fi e de rede celular.
• Sem bloqueio de início de fila (head-of-line blocking): Com HTTP/2 sobre TCP, um único pacote perdido bloqueia todos os streams naquela conexão até que o pacote seja retransmitido. O QUIC usa UDP e lida com os streams de forma independente, portanto, um pacote perdido afeta apenas o stream específico ao qual pertence. Isso resulta em um desempenho de conexão mais consistente em redes não confiáveis.
• Migração de conexão: As conexões QUIC são identificadas por um ID de conexão em vez de um IP e porta de origem. Isso significa que quando um usuário mobile muda do Wi-Fi para o celular (e seu endereço IP muda), a conexão QUIC sobrevive sem precisar ser restabelecida. Isso evita o handshake TCP + TLS completo que seria exigido de outra forma.

Como o Tempo de Conexão Impacta o Time to First Byte?

Como Minimizar o Impacto do Tempo de Conexão no TTFB

Use o Preconnect para Origens Críticas

O resource hint <link rel="preconnect"> diz ao navegador para estabelecer uma conexão (DNS + TCP + TLS) com uma origem especificada antes que qualquer recurso dessa origem seja realmente necessário. Isso elimina a duração da conexão do caminho crítico (critical path) quando o recurso for finalmente solicitado:

<!-- 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">

Use o preconnect com moderação (no máximo 3 a 5 origens). Cada preconnect abre uma conexão TCP + TLS completa, o que consome CPU e recursos de rede. Faça o preconnect apenas de origens que sejam necessárias a cada carregamento de página. Para origens que são necessárias apenas ocasionalmente, use dns-prefetch em vez disso (veja nosso guia de duração de DNS).

Configuração de Servidor para TLS 1.3 e HTTP/3

• HTTP/3: traz o protocolo QUIC sobre UDP em vez de TCP, permitindo uma transferência de dados mais rápida e eficiente.
• TLS 1.3: adiciona mais segurança e reduz os round trips do handshake. Necessário para a retomada de conexão 0-RTT.
• Retomada de Conexão 0-RTT: recurso do TLS 1.3 que permite que os clientes recorrentes enviem dados criptografados imediatamente ao reconectar, reutilizando informações trocadas anteriormente.
• TCP Fast Open: permite que os dados sejam enviados no pacote SYN inicial, reduzindo o tempo de round trip do handshake TCP.
• TLS False Start: permite o envio antecipado de dados antes que o handshake TLS seja concluído.
• OCSP Stapling: acelera a validação do certificado, eliminando a necessidade de o cliente contatar a autoridade certificadora diretamente.

Aqui está um exemplo de configuração do Nginx que habilita o TLS 1.3 e o 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 o Apache, ative o TLS 1.3 com:

<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>

DICA do Time to First Byte: uma CDN não oferece apenas tempos de round trip mais curtos. Usar uma CDN muitas vezes melhorará imediatamente os tempos de conexão TCP e TLS porque os provedores de CDN premium terão configurado corretamente essas opções para você. Veja nosso guia sobre como configurar a Cloudflare para desempenho para começar.

Medindo a Duração da Conexão com JavaScript

Você pode medir a subparte da duração da conexão do TTFB diretamente no navegador usando a 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
});

A propriedade nextHopProtocol revela qual protocolo foi usado para a conexão. Valores comuns são "h2" (HTTP/2), "h3" (HTTP/3) e "http/1.1". Se seu servidor suporta HTTP/3, mas seus dados RUM mostram a maioria das conexões usando "h2", pode indicar que o suporte ao HTTP/3 não está sendo anunciado adequadamente por meio do cabeçalho Alt-Svc.

Como Encontrar Problemas de TTFB Causados Pelo Lento Tempo de Conexão

Para descobrir o impacto que os usuários reais experimentam causado pela latência da conexão, você precisará usar uma ferramenta RUM como o CoreDash. O Real User Monitoring permitirá que você rastreie os Core Web Vitals com mais detalhes e sem o atraso de 28 dias do Google.

No CoreDash, clique em "Time to First Byte breakdown" para visualizar a parte de conexão do Time to First Byte.

Leitura Adicional: Guias de Otimização

Guias relacionados:

• 103 Early Hints: o servidor pode enviar resource hints (preload, preconnect) enquanto ainda processa a resposta principal, permitindo que o navegador comece a estabelecer conexões mais cedo.
• Configurar Cloudflare para Desempenho: A Cloudflare ativa automaticamente HTTP/3, TLS 1.3 e OCSP Stapling. Usar uma CDN também aproxima o seu servidor dos usuários, reduzindo os tempos de round trip para todas as conexões.

Subpartes do TTFB: Guias Completos

A duração da conexão é uma das cinco subpartes do TTFB. Explore as outras subpartes para entender o quadro geral:

• Identifique e Corrija Problemas de TTFB: o ponto de partida de diagnóstico para todas as otimizações do TTFB.
• Duração de Espera: redirecionamentos, enfileiramento do navegador e otimização de HSTS.
• Duração de Cache: desempenho do service worker, buscas no cache do navegador e bfcache.
• Duração de DNS: seleção do provedor de DNS, configuração de TTL e dns-prefetch.
• Duração da Requisição: tempo de processamento do servidor, consultas ao banco de dados e otimização do backend.