Raciocínio Proporcional para Desempenho 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 impactam seus Core Web Vitals.

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

O problema com limites absolutos

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

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

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

Números absolutos sem contexto levam a 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 desempenho e, agora, agentes de IA, pulam essa etapa e otimizam o que quer que exceda um limite fixo.

Exemplo de LCP

O LCP nas suas páginas de produto em dispositivos móveis: 3.820ms (ruim). O detalhamento das 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 a zero economiza 620ms. Corrigir o problema de 55% de Load Delay economiza mais de 2.000ms. Ambos são problemas reais. Um é 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 possa vê-la. Adicione um preload hint e você reduzirá o LCP quase pela metade.

Exemplo de INP

O INP na página de checkout: 350ms (precisa de melhorias). O detalhamento das fases:

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

Sem as porcentagens, um agente otimiza o Input Delay porque 70ms excedem algum limite. Mostre-lhe as porcentagens e ele terá como alvo a Presentation. É para os 57% que o tempo vai.

Corrigir a Presentation (DOM grande, falta de CSS containment, repintura custosa) move o INP de 350ms para menos de 200ms. Isso leva você de "precisa de melhorias" para "bom". Corrigir o Input Delay de 70ms para 0ms (improvável, mas hipotético) economiza 70ms. Você ainda falha com 280ms. 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 manda. 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 desempenho 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 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 performance trace, encontre o marcador do LCP na timeline e meça as quatro fases. Converta cada uma para 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 entry type event. Registre a interação do 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 lab trace.