Utilizamos cookies para melhorar a sua experiência, analisar o tráfego do site e personalizar conteúdos. Pode aceitar todos os cookies ou escolher quais categorias permitir. Saber mais
Otimização de INP para Páginas de Detalhes de Produtos (PDP) em 2026 | Ordiko
Guia
Otimização de INP para Páginas de Detalhes de Produtos (PDP) em 2026
Um guia focado para corrigir a Interação até o Próximo Pintar (INP) em PDPs de ecommerce em 2026, cobrindo troca de variantes, galeria, adicionar ao carrinho e os padrões de Componentes de Servidor React que consistentemente mantêm o INP abaixo de 200ms.
PT1H30M
TL;DR. INP no PDP é corrigido ao enviar menos JavaScript e tornar as interações otimistas. Use React Server Components para partes estáticas. Use useOptimistic para troca de variantes e adição ao carrinho. Use startTransition para atualizações não urgentes. Debounce a busca com AbortController. Eleve regex e evite spread em manipuladores de eventos. Meta: < 200ms p75, alcançável < 100ms.
O que o INP mede
Interaction to Next Paint (INP) mede o maior tempo de interação até a pintura em uma página durante a visita do usuário. Uma "interação" é um clique, toque ou pressionamento de tecla que aciona JavaScript.
O INP é calculado como o pior caso (excluindo outliers raros), não a média. Um clique lento em um filtro pode arruinar sua pontuação de INP, mesmo que 99 outras interações tenham sido rápidas.
Valor do INP
Veredicto
≤ 200ms
Bom
200ms – 500ms
Precisa de melhorias
> 500ms
Ruim
Passo 1: Perfil, não adivinhe
Perguntas frequentes
Por que o INP é muito mais difícil que o LCP?
O LCP é principalmente um problema de CDN e otimização de imagens com correções bem compreendidas. O INP é o tempo de execução do JavaScript na interação do usuário; cada clique pode ter um gargalo diferente. Corrigir o INP requer disciplina em nível de componente em cada elemento interativo na página.
Os Componentes de Servidor React corrigem o INP automaticamente?
Em grande parte sim. O RSC reduz o pacote JS enviado para o navegador, o que reduz o trabalho na thread principal, o que melhora o INP. Mas as partes interativas da página ainda precisam de JS do cliente — o RSC sozinho não corrigirá um componente do cliente mal escrito que cria regex em onClick.
Qual é o maior assassino de INP em PDPs?
Renderização pesada do lado do cliente de widgets de recomendação ('Frequentemente comprados juntos', 'Você também pode gostar') que enviam 50–200KB de JS e hidratam agressivamente na primeira interação. Mova esses para Componentes de Servidor ou carregue-os de forma preguiçosa atrás do IntersectionObserver.
Quão rápido uma PDP bem otimizada pode ficar em INP?
Um INP p75 do mundo real abaixo de 100ms é alcançável. PDPs Ordiko têm um INP p75 padrão de 80–160ms sem otimização manual. Temas personalizados que seguem os padrões deste guia podem ficar abaixo de 100ms consistentemente.
Leituras relacionadas
Use a aba Performance do Chrome DevTools para gravar uma sessão de interação do PDP. Procure por:
Tarefas longas (barras amarelas > 50ms) durante interações.
Reflows forçados (barras roxas).
Atribuição pesada para entradas de INP.
Ou use a API Long Animation Frames (LoAF) em seu RUM:
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
if (entry.duration > 200) {
console.log('Long frame:', entry);
}
}
});
observer.observe({ type: 'long-animation-frame', buffered: true });
Passo 2: Adiar JS não crítico
As maiores vitórias de INP na maioria dos PDPs vêm da remoção ou adiamento de scripts que você não precisava carregar de forma ansiosa:
// PDPPage (Server Component)
import { ProductGallery } from './product-gallery'; // Server
import { ProductInfo } from './product-info'; // Server
import { AddToCartButton } from './add-to-cart-button'; // Client (interativo)
import { VariantSelector } from './variant-selector'; // Client (interativo)
import { RelatedProducts } from './related-products'; // Server
import { ReviewSummary } from './review-summary'; // Server
export default async function PDP({ params }) {
const product = await getProduct(params.slug);
return (
<article>
<ProductGallery images={product.images} />
<ProductInfo product={product} />
<VariantSelector variants={product.variants} />
<AddToCartButton productId={product.id} />
<ReviewSummary reviews={product.reviews} />
<RelatedProducts productId={product.id} />
</article>
);
}
Apenas AddToCartButton e VariantSelector são Client Components. Todo o resto permanece no servidor. O tamanho do pacote cai 60–80% em comparação com um PDP totalmente cliente.
Passo 4: Troca otimista de variantes
O fluxo de clique de variante ingênuo:
O usuário clica na variante.
POST para /api/variant/select com o novo ID da variante.
O servidor retorna o preço/SKU/imagem atualizado.
Re-renderiza com o novo estado.
Total: 200–500ms de latência percebida. Pontuação de INP: ruim.
function handleClick(text) {
if (/[<>]/.test(text)) { ... } // regex criado em cada clique
setItems(prev => [...prev, ...newItems]); // spread no acumulador
}
Bom:
const TAG_REGEX = /[<>]/; // elevado ao escopo do módulo
function handleClick(text) {
if (TAG_REGEX.test(text)) { ... }
setItems(prev => prev.concat(newItems));
}
Passo 8: Carregar preguiçosamente abaixo da dobra
Recomendações, avaliações, produtos relacionados: coloque-os abaixo da dobra e carregue-os preguiçosamente com dynamic + ssr: false para widgets puramente clientes, ou carregue na interseção:
Para seções renderizadas no servidor, envolva em <Suspense> com PPR habilitado para que sejam transmitidas após a shell estática.
Medindo o sucesso
Após implantar correções, as melhorias de INP aparecem em:
Chrome DevTools sob Performance → Web Vitals overlay (sintético, imediato).
Seu próprio RUM com a biblioteca web-vitals (usuário real, quase em tempo real).
Search Console → Core Web Vitals (usuário real, p75 ao longo de 28 dias, 2–4 semanas de atraso).
Um PDP típico que começou com 350ms p75 INP e segue este guia alcança 80–120ms p75 INP dentro de 2–4 semanas após a implantação.
Como a Ordiko envia PDPs bons em INP por padrão
As partes estáticas do PDP são RSC (sem JS do cliente enviado).
O seletor de variantes usa useOptimistic + Server Actions.
A galeria usa startTransition + pré-carregamento de imagem ao passar o mouse.
A busca é debounced em 200ms com AbortController.
O carrinho renderiza a contagem conhecida mais recente de forma otimista.
INP p75 padrão: 80–160ms.
FAQ
Por que o INP é muito mais difícil que o LCP? O LCP é principalmente um problema de CDN e otimização de imagem com correções bem compreendidas. O INP é o tempo de execução do JavaScript na interação do usuário; cada clique pode ter um gargalo diferente. Corrigir o INP requer disciplina em nível de componente em todos os elementos interativos na página.
Os React Server Components corrigem o INP automaticamente? Em grande parte, sim. O RSC reduz o pacote de JS enviado para o navegador, o que reduz o trabalho na thread principal, melhorando o INP. Mas as partes interativas da página ainda precisam de JS do cliente — o RSC sozinho não corrigirá um componente cliente mal escrito que cria regex em onClick.
Qual é o maior assassino de INP em PDPs? A renderização pesada do lado do cliente de widgets de recomendação ('Frequentemente comprados juntos', 'Você também pode gostar') que enviam 50–200KB de JS e hidratam agressivamente na primeira interação. Mova esses para Server Components ou carregue-os preguiçosamente atrás do IntersectionObserver.
Quão rápido um PDP bem otimizado pode ficar em INP? INP p75 no mundo real abaixo de 100ms é alcançável. Os PDPs da Ordiko têm como padrão 80–160ms p75 INP sem otimização manual. Temas personalizados que seguem os padrões deste guia podem ficar abaixo de 100ms de forma consistente.