Se você pesquisou "como testar a velocidade de um site", provavelmente já caiu em dois extremos. O primeiro é a obsessão pelo 100/100 do Lighthouse. O segundo é olhar meia dúzia de números do window.performance e achar que isso já explica a experiência do usuário. Na prática, nenhum dos dois caminhos fecha a conta sozinho.
O Lighthouse entrega uma visão de laboratório. Ele é ótimo para comparar versões, encontrar JavaScript sobrando, imagens mal otimizadas e recursos que travam o render. Já o Window Performance API mostra o que acontece dentro do navegador de verdade: quais arquivos estão lentos, quando o conteúdo principal aparece e se a página parece pronta sem estar realmente responsiva.
Essa combinação é valiosa para SEO e para conversão. Um LCP ruim, uma interação travada ou um layout pulando não irritam só o usuário. Eles também fazem a página perder tração.
Por que vale cruzar as duas leituras
Lighthouse é excelente para uma auditoria rápida. O problema é que ele não representa todos os cenários reais. Seu público não navega apenas em notebook novo, Wi-Fi estável e sem script de terceiro.
Com window.performance, você começa a responder perguntas mais úteis:
- O gargalo está no HTML inicial, no backend ou em um script externo?
- O hero demora por causa da imagem, da fonte ou do bloqueio de renderização?
- A tela já apareceu, mas o thread principal continua ocupado?
É aí que o diagnóstico deixa de ser genérico.
Como usar o Lighthouse do jeito certo
O caminho mais simples continua sendo o Chrome DevTools. Abra a URL, pressione F12, entre na aba Lighthouse, escolha Mobile ou Desktop e rode a análise. Se você precisa comparar builds ou automatizar testes, o CLI também entra muito bem.
Antes disso, vale passar a página pelo SEO Analyzer para enxergar rapidamente quais URLs têm mais chance de concentrar problema de performance e experiência mobile.
Depois do score, olhe o que realmente mexe no resultado:
- JavaScript não utilizado
- recursos que bloqueiam o render
- imagens pesadas acima da dobra
- scripts de terceiros que elevam o TBT
Se você lê o relatório assim, o Lighthouse para de ser troféu e vira checklist de prioridade.
Métricas que merecem sua atenção primeiro
Você não precisa decorar tudo. Para ranqueamento, UX e conversão, eu começaria por estas:
- LCP: quando o conteúdo principal fica visível.
- INP: quão rápido a página responde a cliques, toques e interações reais.
- CLS: o quanto o layout se move sem aviso.
- FCP: quando sai da tela em branco.
- TBT: um ótimo proxy de laboratório para entender travas no thread principal.
Muitos guias antigos ainda batem em TTI ou FID. Não faz mal conhecer, mas para priorização prática hoje, LCP, INP, CLS e TBT dão um norte melhor.
O que o Window Performance API mostra com mais precisão
É aqui que você sai da visão geral e entra nos detalhes.
Com performance.getEntriesByType('navigation'), dá para ler tempos de navegação. Com resource, você encontra arquivos lentos. Com paint, entende quando algo útil aparece. E para observar LCP, CLS ou long tasks de forma moderna, use PerformanceObserver.
1const nav = performance.getEntriesByType('navigation')[0]; 2const resources = performance.getEntriesByType('resource'); 3 4console.log('DOMContentLoaded:', nav.domContentLoadedEventEnd); 5console.log('Load event:', nav.loadEventEnd); 6console.log( 7 'Top 5 slowest resources:', 8 resources.sort((a, b) => b.duration - a.duration).slice(0, 5) 9);
1const observer = new PerformanceObserver((list) => { 2 for (const entry of list.getEntries()) { 3 console.log(entry.entryType, entry.startTime, entry.duration || entry.value); 4 } 5}); 6 7observer.observe({ type: 'largest-contentful-paint', buffered: true }); 8observer.observe({ type: 'layout-shift', buffered: true }); 9observer.observe({ type: 'longtask', buffered: true });
Se você precisa medir INP com confiança em produção, faz mais sentido integrar isso ao seu RUM ou a uma implementação web-vitals do que improvisar uma coleta na mão.
Esse tipo de comparação por rede costuma revelar a verdade. A página que parece rápida no Wi-Fi do escritório pode desmoronar quando cai num Fast 3G ou num aparelho mediano.
Um fluxo de trabalho que funciona no mundo real
O melhor processo costuma ser simples:
- Rode Lighthouse para encontrar páginas críticas e priorizar.
- Use
window.performancepara localizar o gargalo exato. - Cruze depois com dados de campo para validar se o problema afeta usuários reais.
- Corrija e meça de novo nas mesmas condições.
Se os relatórios apontarem arquivos pesados demais, vale reduzir peso com o JavaScript Compressor, o CSS Compressor e o HTML Compressor antes de publicar.
Conclusão
Teste de performance não deveria terminar em um print bonito do score. Ele deveria terminar com uma resposta clara: por que a página está lenta, o que está puxando o desempenho para baixo e qual correção vai trazer mais impacto.
Lighthouse te dá o primeiro alerta. Window Performance te ajuda a fechar o diagnóstico. Se você quiser começar por uma visão mais ampla antes de ir para o DevTools, rode a URL no SeoSpeedup e use essa auditoria como ponto de partida.
