Trilha 10 · Internet e redes

Como uma página web carrega

Do DNS ao primeiro pixel: cada milissegundo importa. Veja o waterfall completo de carregamento de uma página.

① Intuição

Uma cascata de dependências

Acessar uma página parece instantâneo, mas por baixo é uma cascata de eventos encadeados: DNS resolve o IP → TCP conecta → TLS negocia → HTML chega → HTML referencia CSS/JS → eles são baixados → JS pode gerar mais requests → finalmente o browser renderiza.

Cada etapa tem um custo e podem ser otimizadas. Um CSS desnecessário atrasa o primeiro pixel. Um JS pesado bloqueia o browser. Uma imagem fora de tela que carrega antes do conteúdo principal compete por banda. Entender o waterfall é o primeiro passo para performance web.

1 segundo de atraso = -7% em conversões (Amazon, 2006). Performance web não é detalhe técnico — é negócio. O Google usa Core Web Vitals como fator de ranking desde 2021.
② Visualização interativa

Waterfall de carregamento

Clique em Carregar página para ver a cascata animada. Clique em cada barra para entender o que acontece nessa etapa.

0 / 620 ms— clique numa barra para detalhes
DNS Lookup
TCP Conectar
TLS Handshake
HTML (index.html)
CSS (style.css)
JS (app.js)
Fonte (Inter.woff2)
Imagem (logo.png)
First Contentful Paint
Renderizar página
0ms100ms200ms300ms400ms500ms620ms
③ Explicação técnica

O Critical Rendering Path

# Critical Rendering Path — o caminho para o primeiro pixel

1. Browser recebe HTML → constrói DOM (Document Object Model)
2. Encontra <link rel="stylesheet"> → bloqueia renderização, baixa CSS → CSSOM
3. DOM + CSSOM → Render Tree (apenas elementos visíveis)
4. Layout (Reflow): calcula posição e tamanho de cada elemento
5. Paint: preenche os pixels (cores, sombras, bordas)
6. Composite: envia camadas à GPU para exibir na tela

# Scripts bloqueiam o parser HTML:
<script src="app.js"></script>         # bloqueia — ruim
<script src="app.js" defer></script>   # executa após HTML — bom
<script src="app.js" async></script>   # executa quando baixa — analytics

Core Web Vitals — o que o Google mede

# Core Web Vitals (métricas de performance do Google)

LCP — Largest Contentful Paint   → maior elemento visível carregado
      Meta: < 2,5s   Ruim: > 4s

FID — First Input Delay          → tempo até o browser reagir ao primeiro clique
      Meta: < 100ms  Ruim: > 300ms

CLS — Cumulative Layout Shift    → quanto o layout "pula" durante o carregamento
      Meta: < 0,1   Ruim: > 0,25

# Ferramentas: Chrome DevTools → Lighthouse, Performance tab
Pré-conexão e pré-busca: o browser pode antecipar recursos com hints no HTML: <link rel="preconnect" href="https://fonts.gstatic.com"> inicia o TCP+TLS antes de precisar, <link rel="preload" as="font"> baixa fontes antes de o CSS pedí-las. Esses otimizações reduzem o waterfall drasticamente.
④ Projeto para programar

Meça e otimize

Mini projeto: abra o DevTools do Chrome (F12) → aba Network → recarregue uma página qualquer. Identifique: qual recurso levou mais tempo? Qual bloqueou a renderização? Qual foi cacheado?

Projeto principal: rode o Lighthouse (DevTools → Lighthouse) em um site que você construiu ou de sua escolha. Implemente pelo menos 3 das otimizações sugeridas e compare o score antes e depois.

Desafio extra: implemente Resource Timing API em JavaScript: performance.getEntriesByType("resource") retorna o waterfall completo programaticamente. Crie um relatório HTML com as métricas de cada recurso.

⑤ Exercícios rápidos

Teste sua intuição

Por que um arquivo CSS no <head> pode impactar o tempo até o primeiro pixel?
O que o atributo defer faz num elemento <script>?
O que o LCP (Largest Contentful Paint) mede?
⑥ Aplicações no mundo real

Onde você encontra isso

SSR e SSG

Next.js, Nuxt e Astro geram HTML no servidor para que o browser receba conteúdo já pronto — FCP muito mais rápido que SPAs puras.

🖼️

Lazy loading

<img loading="lazy"> e Intersection Observer adiam o carregamento de imagens fora da viewport, economizando banda e acelerando o LCP.

📦

Code splitting

Webpack, Vite e Rollup dividem o JS em chunks: só o necessário para a página atual é baixado. O resto vem sob demanda.

🌐

Service Workers

Scripts que interceptam requests e podem servir recursos do cache local — tornando apps web funcionarem offline e carregarem instantaneamente.

← Anterior: HTTP e HTTPS Próxima: APIs e REST →