Raciocínio Proporcional para Performance Web

O Lighthouse informa um número. Ele não diz se esse número é o problema. Converta cada fase em uma porcentagem do total. A maior porcentagem é o seu gargalo. Não a fase que excede algum limite absoluto. Isso muda quais correções realmente afetam seus Core Web Vitals.

Última revisão por Arjen Karel em março de 2026

O problema com limites absolutos

O Lighthouse diz "O Render Delay é de 350ms". O que você faz com isso?

Se o seu LCP total for de 700ms, sim, 350ms de Render Delay é metade do problema. Corrija isso.

Mas se o seu LCP total for de 4.200ms e o TTFB for de 3.800ms, esses 350ms de Render Delay são 8% do total. Reduzi-lo a zero economiza 350ms. Você ainda tem um LCP de 3.850ms que falha. O problema de 90% é o seu servidor.

Números absolutos sem contexto levam a um esforço desperdiçado. Converta para porcentagens e o gargalo se torna óbvio.

Corrija a maior porcentagem primeiro

Tanto o LCP quanto o INP se dividem em fases. Cada fase consome uma parte do total. A maior parte é o seu gargalo. Corrija essa primeiro.

Isso não é complicado. Mas é surpreendente quantas ferramentas de performance, e agora agentes de IA, pulam esta etapa e otimizam qualquer coisa que exceda um limite fixo.

Exemplo de LCP

O LCP nas suas páginas de produtos mobile: 3.820ms (ruim). A divisão de fases de usuários reais:

• TTFB: 420ms (11%)
• Load Delay: 2.100ms (55%)
• Load Time: 680ms (18%)
• Render Delay: 620ms (16%)

Reduzir os 16% de Render Delay para zero economiza 620ms. Corrigir o problema de 55% de Load Delay economiza mais de 2.000ms. Ambos são problemas reais. Um deles é o gargalo.

Um Load Delay de 55% significa que o navegador recebeu o HTML, mas não solicitou a hero image por mais de dois segundos. O navegador não consegue encontrar a imagem. Ela não está no HTML onde o preload scanner pode vê-la. Adicione um preload hint e você corta o LCP quase pela metade.

Exemplo de INP

O INP na página de checkout: 350ms (precisa de melhorias). A divisão de fases:

• Input Delay: 70ms (20%)
• Processing: 80ms (23%)
• Presentation: 200ms (57%)

Sem as porcentagens, um agente otimiza o Input Delay porque 70ms excede algum limite. Mostre as porcentagens e ele foca na Presentation. 57% é para onde o tempo vai.

Corrigir a Presentation (DOM grande, falta de contenção CSS, repaint custoso) muda o INP de 350ms para menos de 200ms. Isso leva você de "precisa de melhorias" para "bom". Reduzir o Input Delay de 70ms para 0ms (improvável, mas hipotético) economiza 70ms. Você ainda falha com 280ms. O mesmo esforço, resultado diferente.

O que acontece quando os agentes pulam isso

Um agente de IA sem contexto proporcional faz o que a ferramenta diz. O Lighthouse sinaliza um TBT longo. O agente otimiza o TBT. A alteração está tecnicamente correta. O impacto no mundo real é mínimo porque o TBT era 20% do problema e o gargalo de 57% permanece intocado.

Eu vejo esse padrão constantemente em correções de performance geradas por IA. A correção aborda um sintoma. O gargalo permanece. Os dados de campo não melhoram. O desenvolvedor se pergunta por que uma otimização "correta" não fez nada.

Uma abordagem desperdiça o seu tempo. A outra corrige o problema real.

Como fazer isso sem o CWV Superpowers

Você pode fazer isso manualmente. Para o LCP: abra o Chrome DevTools, execute um rastreamento de performance, encontre o marcador LCP na linha do tempo e meça as quatro fases. Converta cada uma em uma porcentagem do LCP total. Corrija a maior porcentagem primeiro.

Para o INP: use a extensão do Chrome Web Vitals ou um PerformanceObserver com o tipo de entrada event. Grave a interação INP, obtenha as durações das três fases, converta para porcentagens.

Ou deixe que o CWV Superpowers faça isso automaticamente com dados de campo de milhares de sessões reais em vez de um único rastreamento de laboratório.