**TL;DR.** Os Core Web Vitals em 2026 são LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1 no p75. Em sites de ecommerce, o LCP é corrigido através do pré-carregamento da imagem principal, o INP através do adiamento do JS e do uso de recursos concorrentes do React 18+, e o CLS através da reserva de espaço para imagens e regiões dinâmicas. O Google pontua no p75 ao longo de uma janela de 28 dias; as correções levam semanas para refletir.

## Limiares de 2026

| Métrica | Boa    | Precisa de melhoria | Ruim    |
| ------- | ------ | ------------------- | ------- |
| LCP     | ≤ 2.5s | 2.5s – 4.0s         | > 4.0s  |
| INP     | ≤ 200ms| 200ms – 500ms       | > 500ms |
| CLS     | ≤ 0.1  | 0.1 – 0.25          | > 0.25  |
| TTFB    | ≤ 800ms| 800ms – 1.8s        | > 1.8s  |

Fonte: [web.dev/vitals](https://web.dev/articles/vitals). O INP substituiu o FID como um Core Web Vital em março de 2024 e permanece como a métrica para 2026.

## Por que CWV é importante

O Google usa CWV como um sinal de experiência de página na classificação. Dados de usuários reais mostram que páginas com CWV totalmente verdes superam páginas comparáveis com CWV fraco em nichos competitivos.

Além das classificações, o CWV afeta diretamente a conversão. Estudos de 2024–2025 mostram consistentemente:

- Melhoria de 1 segundo no LCP: aumento de 5–15% na conversão em PDP.
- INP abaixo de 200ms: redução de 10–20% na desistência do carrinho.
- CLS abaixo de 0.1: aumento perceptível na qualidade da experiência do usuário.

## Medindo da maneira certa

Duas fontes de dados são importantes:

1. **CrUX (Relatório de Experiência do Usuário do Chrome)**: dados de usuários reais que o Google usa para classificá-lo. Janela de 28 dias, p75. Apresentado no PageSpeed Insights e no Search Console.
2. **Seu próprio RUM**: dados de usuários reais que você coleta através da biblioteca `web-vitals` ou do seu CDN. Mostra dados mais recentes, permitindo segmentar por tipo de página, dispositivo, país.

Ferramentas sintéticas (Lighthouse, WebPageTest) são úteis para diagnóstico, mas não para pontuação.

## Correções de LCP (maior pintura de conteúdo)

Em ecommerce, o LCP é quase sempre:

- A imagem principal na página inicial, PLP e PDP.
- O H1 + primeiro parágrafo em páginas de blog/artigo.

As grandes vitórias:

1. **Pré-carregue a imagem LCP** com `<link rel="preload" as="image" fetchpriority="high">`:

```html
<link rel="preload" as="image" href="/products/leather-bag/hero.avif" fetchpriority="high" imagesrcset="/products/leather-bag/hero-400.avif 400w, /products/leather-bag/hero-800.avif 800w" imagesizes="(max-width: 768px) 100vw, 50vw" />
```

2. **Use Next.js `<Image>` com `priority`** na imagem LCP:

```tsx
<Image
  src={product.heroImage}
  width={800}
  height={800}
  priority
  fetchPriority="high"
  alt={product.altText}
/>
```

3. **Forneça formatos modernos**. AVIF supera WebP que supera JPEG. O Next.js Image lida com isso automaticamente.

4. **Não carregue a imagem LCP de forma preguiçosa**. `loading="lazy"` é apenas para imagens abaixo da dobra.

5. **Inline CSS crítico para estilos acima da dobra**. Evite bloquear carregamentos de folhas de estilo no caminho de renderização crítico.

6. **Use renderização em edge**. TTFB de ≤ 100ms do cache de edge garante a maior parte do orçamento do LCP.

## Correções de INP (interação para a próxima pintura)

O INP mede o pior caso entre todas as interações em uma página. Um clique lento em um filtro pode arruinar seu INP por toda a sessão.

As grandes vitórias:

1. **Reduza o JS do lado do cliente**. Use React Server Components sempre que possível. Cada quilobyte de JS do cliente prejudica o INP.

2. **Use `startTransition` para atualizações de estado não urgentes**:

```tsx
import { startTransition, useState } from 'react';

function FilterButton({ filter }) {
  const [isPending, startTransition] = useTransition();
  return (
    <button onClick={() => startTransition(() => applyFilter(filter))}>
      {filter.label}
    </button>
  );
}
```

3. **Use `useOptimistic` para feedback instantâneo**:

```tsx
import { useOptimistic } from 'react';

function Cart() {
  const [cart, addOptimistic] = useOptimistic(serverCart);
  return (
    <button onClick={() => {
      addOptimistic({ ...newItem });
      addToCartServerAction(newItem);
    }}>Adicionar ao carrinho</button>
  );
}
```

4. **Debounce inputs**. A autocompletação de pesquisa deve ter debounce de 150–250ms com `AbortController` para cancelar requisições em andamento:

```tsx
useEffect(() => {
  const controller = new AbortController();
  const timeout = setTimeout(() => {
    fetch(`/api/search?q=${query}`, { signal: controller.signal });
  }, 200);
  return () => {
    clearTimeout(timeout);
    controller.abort();
  };
}, [query]);
```

5. **Retire literais regex dos manipuladores de eventos** — recriar regex em um caminho crítico custa um INP mensurável.

6. **Adie scripts de terceiros não críticos**. Pixels de marketing, widgets de chat, SDKs de teste A/B: carregue-os com `strategy="afterInteractive"` ou `lazyOnload`.

## Correções de CLS (mudança de layout cumulativa)

As grandes vitórias:

1. **Sempre defina largura/altura em imagens**. Os navegadores reservam o espaço correto.

```html
<img src="/hero.avif" width="800" height="800" alt="..." />
```

2. **Reserve espaço para conteúdo incorporado**. iframes, anúncios, players de vídeo precisam de dimensões explícitas ou contêineres de proporção.

3. **Evite `font-display: swap` sem CSS de fallback de fonte**. O swap reflowa o texto. Use [size-adjust](https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/size-adjust) para corresponder às métricas ou aceite `font-display: optional`.

4. **Não injete conteúdo acima do conteúdo existente**. Notificações de banner, consentimento de cookies, banners de venda — renderize-os em uma posição que não desloque a página.

5. **Carregadores de esqueleto devem corresponder às dimensões do conteúdo real**. Um esqueleto menor que o conteúdo carregado desloca a página.

## Notas específicas por tipo de página

**Página inicial**

- A imagem principal é LCP. Pré-carregue-a.
- Carrosséis são minas terrestres de CLS. Use apenas CSS ou pré-renderize o primeiro slide.

**PLP (lista de produtos / categoria)**

- O LCP é geralmente a imagem do primeiro cartão de produto.
- O INP são cliques em filtros e paginação. Use `startTransition` de forma agressiva.
- O CLS é o reflow da grade de produtos quando os filtros são aplicados. Reserve a altura da grade.

**PDP**

- O LCP é a imagem principal do produto.
- O INP é a troca de variantes e adicionar ao carrinho. UI otimista é obrigatória.
- O CLS são as miniaturas da galeria de produtos carregando após a imagem principal.

**Carrinho / Checkout**

- O INP é crítico aqui. Um botão "fazer pedido" lento custa pedidos.
- CLS do carregamento de iframes de pagamento (Stripe Elements, etc.). Reserve espaço.

## Ferramentas

| Ferramenta                  | Para que é boa                                           |
| --------------------------- | -------------------------------------------------------- |
| PageSpeed Insights          | Diagnóstico de URL única com sobreposição de usuários reais (CrUX) |
| Lighthouse                  | Medição sintética para fluxos de trabalho de desenvolvimento |
| WebPageTest                 | Medição com limitação de rede, em múltiplas localizações |
| Search Console → CWV        | Nível de domínio p75 ao longo de 28 dias                 |
| Seu próprio RUM (web-vitals)| Dados de campo em tempo real segmentados por página, dispositivo, país |

## Como a Ordiko lida com CWV por padrão

A pilha de loja da Ordiko:

- Next.js 16 + React Compiler.
- `cacheComponents: true` + `experimental.ppr: "incremental"`.
- Renderização em edge de shells estáticos (TTFB ≤ 100ms).
- Imagem LCP pré-carregada por padrão em PDP, PLP, página inicial.
- Limites de Suspense em torno de ilhas dinâmicas (carrinho, recentemente visualizados, herói personalizado).
- `startTransition` + `useOptimistic` em controles de filtro e variante.
- Pesquisa com debounce de 200ms com `AbortController`.

O típico p75 de usuários reais em um PDP padrão da Ordiko: LCP 1.0–1.8s, INP 80–160ms, CLS < 0.05.

## FAQ

**Os Core Web Vitals afetam as classificações?**
Sim, desde 2021 — mas como um desempate em vez de um sinal primário. Duas páginas de qualidade de conteúdo igual serão classificadas na ordem do CWV. Corrigir o CWV em uma página mal classificada não fará com que ela suba de classificação se o conteúdo for fraco.

**Por que o INP é mais difícil de corrigir do que o LCP?**
O LCP é principalmente um problema de CDN e otimização de imagem com correções bem compreendidas. O INP é um problema de execução de JavaScript que requer análise componente por componente. Cada evento de interação pode ter um gargalo diferente (clique em filtro vs. adicionar ao carrinho vs. troca de variante).

**Qual é uma boa meta de INP para PDP?**
Abaixo de 200ms p75 é 'bom'. Abaixo de 100ms é alcançável em PDPs modernos com disciplina (RSC, sem scripts pesados de terceiros, inputs com debounce). Acima de 500ms é 'ruim' e provavelmente impacta as classificações.

**Como a Ordiko lida com CWV por padrão?**
A Ordiko envia Next.js 16 Cache Components + PPR, que transmite um shell estático com a imagem LCP já pré-carregada e limites de Suspense para conteúdo dinâmico. O INP padrão fica abaixo de 200ms em PDPs típicos sem otimização personalizada.