O que é RTT e por que isso é importante?
O tempo de ida e volta (RTT) mede o percurso de um sinal até a outra ponta e seu retorno. Não é o tempo total da resposta: DNS, conexão, processamento do servidor e transferência podem acrescentar demora. Solicitações paralelas não somam necessariamente um RTT após o outro.
Como o RTT influencia os Web Vitals
- LCP: HTML e recursos críticos lentos podem atrasar o conteúdo principal.
- INP: mede a resposta até o próximo quadro, não o término de uma solicitação assíncrona. Os resultados podem demorar mesmo com INP bom; meça os dois tempos.
- TTFB: inclui mais que um RTT, como conexão e processamento. Não é um Core Web Vital.
- CLS: um recurso tardio pode deslocar o layout se não houver espaço reservado. RTT alto sozinho não implica deslocamento.
Causas comuns de RTT elevado
- Servidor de origem distante ou etapas extras entre CDN e backend.
- Solicitações dependentes e cadeias de redirecionamentos.
- Novas conexões quando seria possível reutilizá-las.
- Recursos críticos de terceiros descobertos tarde.
- Processamento lento do servidor, que pode parecer um problema de rede no tempo total.
Como reduzir o RTT na prática
- Compare regiões e considere CDN ou processamento próximo do público. Verifique quais respostas são realmente servidas na borda.
- Teste HTTP/2 e HTTP/3 onde forem suportados. Eles não eliminam a distância; HTTP/2 mantém o bloqueio no nível TCP.
- Armazene em cache recursos estáticos versionados. Para HTML e APIs, respeite privacidade e atualização.
- Use
<link rel="preconnect">,dns-prefetche preload de fontes somente para recursos críticos confirmados. Eles não reduzem o RTT físico. - Remova solicitações inúteis e adie JavaScript não crítico. Use lazy loading em conteúdo adequado abaixo da primeira tela, não na imagem LCP.
- Reduza redirecionamentos e reutilize conexões ou sessões TLS. Verifique 0-RTT e ajustes de certificados no ambiente real.
Investigar o RTT com os resultados do Milten
- Compare RTT, latência do servidor e taxa de transferência por origem nas condições da análise.
- Examine dicas de recursos e a cascata, sobretudo antes de LCP/FCP. Uma dica ausente é uma hipótese a investigar.
- Separe processamento do servidor e atraso de transporte.
- Repita as análises após os lançamentos. Para comparar localidades, confirme as regiões disponíveis e mantenha condições equivalentes.
Lista breve de verificações
- Identifique a origem lenta e a cadeia crítica.
- Confira o protocolo navegador–borda e, se houver, borda–origem.
- Acrescente apenas dicas úteis de conexão ou preload.
- Reduza redirecionamentos mantendo a URL final prevista.
- Respeite privacidade e atualização ao usar cache ou stale-while-revalidate.
- Compare várias execuções equivalentes e dados de visitas reais.
Comece pela medição
No milten.io, execute o Speed Scanner, examine os resultados de rede e escolha um gargalo confirmado. Salve as condições e o resultado inicial, faça uma mudança específica e compare novamente.
