Core Web Vitals para Ecommerce: Por que Visitantes com Alta Intenção Têm a Pior Performance

O problema invisível de performance no ecommerce

Muitos dos meus clientes se importam profundamente em passar nos Core Web Vitals. Passar significa que 75% de todo o tráfego deve ter uma boa experiência. Um objetivo admirável. Mas ao otimizar para esses 75%, um grupo pequeno mas crítico de cerca de 5% é negligenciado: os visitantes que se converterão em clientes.

A ironia? Esses visitantes de alta intenção frequentemente recebem a pior performance no seu site. Não porque você esqueceu de otimizar. Porque o seu sistema de cache os exclui ativamente.

Revisado por último por Arjen Karel em março de 2026

Por que os seus dados do CrUX escondem o problema

A otimização de Core Web Vitals, principalmente devido ao bônus de ranqueamento do Google, tende a focar na otimização para o visitante ligeiramente abaixo da média. No ecommerce, faz muito sentido ir além disso e adicionar um foco extra nos visitantes de alta intenção. Estes são os visitantes se convertendo em clientes.

De acordo com a pesquisa da Deloitte e do Google, uma melhoria de 0,1 segundo na velocidade da página leva a um aumento de 9,1% nas ações de adicionar à cesta para sites de varejo. Esse é também o momento exato em que o cache para de funcionar para eles.

Geralmente podemos identificar esses usuários pelo número de itens em seus carrinhos.

Há outro ponto cego. O CrUX (Relatório de Experiência do Usuário do Chrome) rastreia apenas os usuários do Chrome que têm a sincronização ativada. Muitos compradores de ecommerce usam o Safari no mobile ou navegadores sem sincronização. O seu painel do CrUX pode mostrar pontuações verdes enquanto os seus compradores reais experimentam algo muito diferente. É por isso que uma pontuação de aprovação no CrUX não conta toda a história.

O abismo do cache: o que acontece quando um usuário adiciona ao carrinho

Aqui está o problema: adicionar itens a um carrinho de compras destrói o seu cache. E o cache é o que torna o seu site rápido.

Os plugins de cache desativam o cache de página inteira para usuários com conteúdo dinâmico. Algo tão simples quanto "itens num carrinho de compras" força o servidor a reconstruir a página inteira a cada requisição. Isso aumenta significativamente o seu Time to First Byte, o que retarda diretamente o Largest Contentful Paint e o First Contentful Paint.

Os números são dramáticos. Num site típico do WooCommerce, o TTFB vai de aproximadamente 100ms (com cache) para 1.600ms ou mais (sem cache). Isso é um aumento de 16x no tempo de resposta do servidor no momento em que alguém adiciona um produto ao seu carrinho. Já vi casos em que usuários logados do WooCommerce esperam de 5 a 9 segundos por uma página que carrega em menos de um segundo para visitantes anônimos.

Como cada plataforma lida com isso

O WooCommerce define vários cookies quando um usuário adiciona ao carrinho: woocommerce_cart_hash, woocommerce_items_in_cart e wp_woocommerce_session. No momento em que qualquer plugin de cache (WP Rocket, LiteSpeed Cache, WP Super Cache) detecta esses cookies, ele ignora o cache para todas as páginas. Não apenas a página do carrinho. A sua página inicial, as suas páginas de produto, as suas páginas de categoria: todas sem cache. Além disso, o WooCommerce dispara uma requisição AJAX para /?wc-ajax=get_refreshed_fragments a cada carregamento de página para manter o widget de mini-carrinho atualizado. Apenas essa requisição pode levar de 2 a 3 segundos em uma hospedagem compartilhada.

Essa é uma das razões pelas quais o WooCommerce tem a menor taxa de aprovação nos Core Web Vitals de todas as principais plataformas de ecommerce. Segundo o Web Almanac de 2025, apenas 33% dos sites WooCommerce passam nos três Core Web Vitals no desktop, comparado a 76% do Shopify.

O Shopify lida melhor com isso graças à sua infraestrutura de CDN gerenciada, mas mesmo o Shopify não pode armazenar em cache páginas contendo objetos customer ou cart. A diferença é que o TTFB de base do Shopify (cerca de 0,51 segundos) já é rápido o suficiente para que a penalidade sem cache seja menor.

O Magento 2 encontrou uma solução inteligente: a página inteira é sempre armazenada em cache, mesmo para usuários com carrinho. O conteúdo dinâmico (mini-carrinho, saudação do usuário, status de estoque) é buscado no lado do cliente via AJAX para /customer/section/load/ e armazenado no localStorage do navegador. A página em si permanece no cache de página inteira. Esse é o problema "lento por design" resolvido em nível de arquitetura.

Os seus melhores clientes recebem as suas piores páginas

Os números tornam isso doloroso. A Farfetch mediu uma queda de 1,3% na taxa de conversão a cada 100ms de aumento no LCP. A Blue Triangle descobriu um declínio na taxa de conversão de 40 a 50% quando o LCP vai de 2 segundos para 4 a 5 segundos.

Um visitante navega pelo seu site rápido e com cache. Ele encontra um produto que gosta. Ele clica em "adicionar ao carrinho". Naquele momento exato, o cache para e o seu TTFB salta de 100ms para 1.600ms. A partir daqui, cada página que ele visita (comparando produtos, verificando o frete, indo para o checkout) não tem cache. As pessoas mais propensas a comprar estão agora navegando na versão mais lenta do seu site.

Em sites monitorados pelo CoreDash, vemos usuários com carrinho experimentando um TTFB de 3 a 5 vezes pior do que visitantes anônimos em plataformas de ecommerce hospedadas por conta própria. Em plataformas gerenciadas como o Shopify, a lacuna é menor (1,5 a 2x), mas ainda mensurável.

Como detectar isso nos seus dados de RUM

Você não consegue ver esse problema no Lighthouse ou no PageSpeed Insights. Essas ferramentas testam como visitantes anônimos sem cookies. As suas pontuações de laboratório parecerão ótimas enquanto os seus compradores reais têm dificuldades.

Para encontrar esse problema, você precisa de Real User Monitoring. Segmente os seus dados de RUM definindo se o usuário tem um cookie de carrinho. Compare o TTFB, FCP e LCP entre esses dois segmentos. Se você vir uma lacuna de 2x ou mais, o bypass de cache é o seu problema.

Na maioria das plataformas de analytics você também pode segmentar por tipo de página. Compare as suas páginas de listagem de produtos (geralmente com cache) com as suas páginas de carrinho e checkout (nunca com cache). Uma diferença de TTFB de mais de 500ms entre esses tipos de página é um alerta vermelho de que a duração de espera do servidor precisa de atenção.

Como consertar a performance para visitantes de alta intenção

Conserte o backend antes de depender do cache. Não dependa exclusivamente de plugins de cache. Analise o seu código de backend, otimize consultas de banco de dados e ajuste o seu servidor para garantir um TTFB rápido mesmo sem cache. Um site que é lento sem cache será catastroficamente lento para usuários com carrinho. A sub-parte de duração de cache do TTFB não deveria estar fazendo todo o trabalho pesado.

Use cache parcial (cache de fragmentos). Armazene as partes custosas da sua página separadamente. Descrições de produtos, menus de navegação e conteúdo de rodapé raramente mudam e podem ser cacheados no Memcached ou Redis mesmo quando o cache de página inteira estiver desativado. Quando um usuário com carrinho requisita uma página, o seu CMS a monta a partir de fragmentos cacheados em vez de regenerar tudo do zero. Isso pode cortar o TTFB sem cache em 60 a 80%.

Renderize componentes dinâmicos do lado do cliente. Essa é a abordagem do Magento 2 e funciona. Entregue a maior parte da página como HTML em cache (renderizado no lado do servidor). Depois use JavaScript e uma pequena chamada de API para buscar as partes dinâmicas (contagem do carrinho, saudação do usuário, recomendações personalizadas) após a página carregar. O navegador recebe o HTML rápido e com cache imediatamente. Os pedaços dinâmicos são preenchidos um momento depois. O seu LCP e FCP continuam rápidos porque são impulsionados pelo esqueleto em cache, não pelo conteúdo dinâmico.

O framework headless do Shopify (Hydrogen) faz exatamente isso: os dados de produtos são agressivamente cacheados com longos TTLs, enquanto os dados de carrinho e clientes usam CacheNone() e são buscados no lado do cliente após o carregamento. Esse padrão também evita problemas de INP porque a busca dinâmica acontece assincronamente em vez de bloquear a interação do usuário.

Implemente o gerenciamento efetivo de chaves de cache. Use chaves simples para elementos estáticos (a URL frequentemente é suficiente como uma chave de cache) e chaves complexas para conteúdos dinâmicos que incluem a ID do usuário, IDs de produtos e timestamps. Isso permite que você armazene em cache em nível de usuário, em vez de escolher entre "totalmente cacheado" e "sem cache algum".

Desative fragmentos de carrinho em páginas que não são de carrinho. Se você usa o WooCommerce, desative a chamada de wc-ajax=get_refreshed_fragments em páginas que não exibem um mini-carrinho. Vários plugins de performance (Perfmatters, FlyingPress) oferecem uma opção para isso. Isso elimina uma chamada AJAX de 2 a 3 segundos em cada carregamento de página para usuários com carrinho.

Considere a composição no edge. Se você usar o Cloudflare, os Workers podem montar as páginas na borda (edge): entregue o corpo da página cacheada a partir da CDN e injete fragmentos dinâmicos (carrinho, informações do usuário) via sub-requisições separadas. O Cloudflare publicou uma implementação de Edge Side Includes para Workers que faz exatamente isso, mantendo o seu TTFB rápido enquanto ainda entrega conteúdo personalizado.