Como uma página web carrega
Do DNS ao primeiro pixel: cada milissegundo importa. Veja o waterfall completo de carregamento de uma página.
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.
Waterfall de carregamento
Clique em Carregar página para ver a cascata animada. Clique em cada barra para entender o que acontece nessa etapa.
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
<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.
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.
Teste sua intuição
<head> pode impactar o tempo até o primeiro pixel?
defer faz num elemento <script>?
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.