A distância que você não otimiza
Os outros cursos desta série trataram do trabalho que o servidor faz. Este trata da parte do tempo de resposta que acontece antes de o servidor entrar na história.
O piso
A luz viaja cerca de 200.000 quilômetros por segundo pela fibra, e uma requisição precisa ir e voltar. Isso dá a todo par de pontos na Terra um piso rígido para a ida e volta, e nenhuma quantidade de cache o move.
As redes reais são mais lentas que isso: o roteamento não é uma linha reta, e cada salto acrescenta um pouco. Idas e voltas típicas até um servidor no leste dos Estados Unidos:
| De | Ida e volta |
|---|---|
| Leste dos Estados Unidos | ~15 ms |
| Europa Ocidental | ~90 ms |
| São Paulo | ~120 ms |
| Mumbai | ~200 ms |
Esses são os números para guardar na cabeça, porque eles definem a escala de todo o resto deste curso.
Por que o custo nunca é uma ida e volta só
Uma primeira requisição leva várias idas e voltas antes de qualquer código da aplicação rodar.
Tem o DNS, se ele não estiver em cache. Tem o handshake do TCP, uma ida e volta. Tem o TLS, mais uma na versão 1.3. Depois vem a requisição em si.
Digamos três idas e voltas até o primeiro byte. Para um visitante em Mumbai falando direto com o seu servidor, isso são 600 milissegundos antes de o servidor ter feito qualquer coisa. Uma requisição aquecida e logada do roadmap desta aplicação leva cerca de 72 milissegundos para ser produzida.
flowchart TB
D["consulta DNS"] --> T["handshake TCP: 1 ida e volta"]
T --> S["handshake TLS: 1 ida e volta"]
S --> R["a requisição: 1 ida e volta"]
R --> A["só agora a aplicação roda"]
A --> N["Mumbai: ~600ms antes de 72ms de trabalho"]
Leia esses dois números juntos. Para quem está longe, o servidor não é a parte lenta, e nunca foi.
O payload importa, mas menos do que você imagina
As respostas desta aplicação são pequenas, e saem comprimidas: o roadmap tem cerca de 50 KB com gzip para quem está logado e cerca de 10 KB para quem não está.
O TCP não envia tudo de uma vez. O slow start faz a primeira rajada ter cerca de 14 KB, e depois ela dobra. 10 KB cabem na primeira rajada. 50 KB precisam de mais duas idas e voltas: 400 milissegundos a mais a partir de Mumbai, para um payload que leva poucos milissegundos para ser transmitido em qualquer banda razoável.
Esse é o formato do trabalho de desempenho a longa distância: idas e voltas, e não bytes. Cortar pela metade um payload que já cabe numa rajada não muda nada.
Onde esta aplicação está
É um servidor numa região. O config/deploy.yml nomeia um único host pelo NOR_SERVER_IP, com um accessory de Postgres ao lado.
A Cloudflare fica na frente dele. Os handshakes TCP e TLS de um visitante terminam numa borda da Cloudflare próxima, e o slow start também roda nesse trecho curto. Folhas de estilo e scripts ficam em cache na borda. O HTML não: as páginas são dinâmicas, e a borda repassa toda requisição de página para a origem única.
Então os handshakes saem baratos, e toda página ainda paga a distância até aquele lugar. Medido do Brasil em 28 de setembro de 2026, pela borda da Cloudflare em São Paulo, uma conexão nova terminou os handshakes em cerca de 30 milissegundos. O primeiro byte do roadmap anônimo chegou depois de cerca de 280 milissegundos. A parte do servidor nisso foi de cerca de 20 milissegundos, e quase todo o resto foi o trajeto entre a borda e a origem.
O resto deste curso trata das três coisas que dá para fazer a respeito, e de quais delas valem a pena aqui.
Pontos-chave
- O tempo de ida e volta é um piso físico: a partir do leste dos EUA, ~90 ms até a Europa, ~120 ms até São Paulo e ~200 ms até Mumbai.
- Uma primeira requisição custa cerca de três idas e voltas antes de o código da aplicação rodar: ~600 ms a partir de Mumbai.
- Esta aplicação produz um roadmap aquecido e logado em cerca de 72 ms, então, para quem está longe, o servidor não é a parte lenta.
- Por causa do slow start do TCP, o tamanho do payload importa em idas e voltas, e não em bytes. 10 KB cabem na primeira rajada, e 50 KB precisam de mais duas.
- Esta aplicação roda um servidor numa região, atrás da Cloudflare. Os handshakes terminam numa borda próxima, mas toda requisição de página ainda viaja até a origem única.
Continue com a aula 2
Três coisas que dá para mover
Compara mover bytes com um CDN, computação com funções de borda e dados com bancos regionais.
Com uma conta grátis você também tem os quizzes, seu progresso e suas anotações, e a discussão.