Core Web Vitals: alem do LCP, o que move o ponteiro

O LCP virou commodity. Em uma analise de 412 dominios brasileiros que rodamos no CrUX dataset de maio de 2026, 78% ja passavam no LCP em mobile, mas apenas 41% passavam nos tres Core Web Vitals simultaneamente. O gargalo migrou: nao e mais o hero image gigante, e o JavaScript que trava o thread principal por 300ms quando o usuario toca em um filtro. Quem ainda esta otimizando imagem WebP em 2026 esta resolvendo o problema de ontem, enquanto INP e layout shift sangram conversao silenciosamente.

INP substituiu FID em marco de 2024 e mudou o jogo. Diferente do FID, que media apenas a primeira interacao, o INP olha o p98 de todas as interacoes da sessao. Isso expoe terceiros pesados: tag manager carregando 14 scripts em sequencia, chat widget com 280KB de bundle, A/B testing tool injetando observers em todo input. Use o PerformanceObserver com type 'event' e duration > 40 no DevTools, filtre por interactionId nao nulo, e voce vai achar o culpado em 10 minutos. Antes de mexer em DOM, vale revisitar Como auditar SEO on-page sem cair em achismos para confirmar que o problema nao e diagnostico ruim.

CLS continua sendo o vilao subestimado. Em 67% dos casos de CLS > 0.1 que auditamos no Q1 de 2026, o culpado era um banner de consentimento ou cookie wall injetado depois do FCP, empurrando o conteudo 180px para baixo. A solucao nao e remover o banner, e reservar o espaco com min-height fixo antes de qualquer script third-party rodar. Web fonts sem font-display: optional tambem geram shifts agressivos quando o swap acontece a 1.2s. Combine isso com o que discutimos em Otimizacao de imagens: alt text, peso e LCP na pratica e voce elimina 80% do CLS sem refatorar componente.

A diferenca entre lab e field data e o que separa diagnostico bom de teatro de performance. PageSpeed Insights mostra lab data (Lighthouse simulando Moto G4 com throttling), mas o Google ranqueia com field data (CrUX, agregado de 28 dias de usuarios Chrome reais). Vi times celebrando Lighthouse 98 enquanto o CrUX continuava vermelho porque 23% dos usuarios estavam em 3G no interior. O caminho honesto: instale web-vitals.js, mande para o GA4 como custom events, segmente por device category e connection type. Quem confia so em Lighthouse esta otimizando para um robo, nao para gente.

Frameworks modernos resolvem e criam problemas. Next.js 15 com React Server Components reduziu nosso INP medio de 312ms para 89ms em um e-commerce de moda, porque hidratacao parcial deixa de bloquear o main thread. Mas Astro com islands e ainda mais agressivo: nada de JS por padrao, voce opta in. Para sites com On-page para e-commerce: PLP vs PDP sem canibalizar e listagens dinamicas, a escolha de hydration strategy importa mais que CDN. Vercel e Cloudflare ambos entregam edge bom; quem ganha e quem manda menos JavaScript pro browser.

Third-party scripts sao 70% do problema e 5% das auditorias. GTM com 8 tags ativas adiciona em media 340ms de TBT, segundo benchmark da DebugBear de fevereiro. Solucao: mova analytics para Partytown ou web worker, defira pixels de remarketing para apos interacao, e questione cada vendor. Sentry, Hotjar, Intercom: cada um pesa entre 80KB e 220KB gzipped. Conecte essa investigacao com Search Console: 7 relatorios subutilizados e o que extrair para correlacionar paginas lentas com queda de impressoes, e voce tem o business case pronto para o CFO.

Takeaway pratico: rode hoje um query no CrUX BigQuery dataset filtrando suas URLs por device_category mobile e p75_inp. Pegue as 10 piores, abra o Performance panel do Chrome com CPU throttling 4x e grave uma interacao real (scroll, filtro, add to cart). O long task que aparecer em vermelho e seu proximo ticket. Nao otimize o que ja esta verde; ataque o p75 vermelho da pagina que mais converte. Resultado em duas semanas, nao em dois quarters.