Core Web Vitals para Ecommerce: Por Que Visitantes de Alta Intenção Têm o Pior Desempenho

O problema invisível de desempenho no ecommerce

Muitos dos meus clientes se importam profundamente em ser aprovados nos Core Web Vitals. Ser aprovado 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 pequeno, porém crítico, grupo de cerca de 5% é negligenciado: os visitantes que se converterão em clientes.

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

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

Por que seus dados do CrUX escondem o problema

A otimização dos 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. Esses são os visitantes que se convertem em clientes.

De acordo com uma 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 em sites de varejo. Esse é também o exato momento em que o cache para de funcionar para eles.

Geralmente podemos identificar esses usuários pelo número de itens no carrinho.

Há outro ponto cego. O CrUX (Chrome User Experience Report) rastreia apenas usuários do Chrome que têm a sincronização ativada. Muitos compradores de ecommerce usam o Safari no celular ou navegadores sem sincronização. Seu painel do CrUX pode mostrar pontuações verdes enquanto 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.

Plugins de cache desativam o cache de página inteira para usuários com conteúdo dinâmico. Algo tão simples quanto "itens em um 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. Em um site típico do WooCommerce, o TTFB vai de cerca de 100ms (em cache) para 1.600ms ou mais (sem cache). Isso é um aumento de 16x no tempo de resposta do servidor no exato momento em que alguém adiciona um produto ao carrinho. Já vi casos em que usuários logados no 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. Sua página inicial, suas páginas de produtos, suas páginas de categorias: todas sem cache. Além disso, o WooCommerce dispara uma requisição AJAX para /?wc-ajax=get_refreshed_fragments em cada carregamento de página para manter o widget do mini-carrinho atualizado. Essa requisição por si só pode levar de 2 a 3 segundos em hospedagem compartilhada.

Esse é um dos motivos pelos quais o WooCommerce tem a menor taxa de aprovação nos Core Web Vitals de todas as principais plataformas de ecommerce. De acordo com o Web Almanac 2025, apenas 33% dos sites WooCommerce são aprovados em todos os três Core Web Vitals no desktop, em comparação com 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 que contenham objetos customer ou cart. A diferença é que o TTFB base do Shopify (cerca de 0,51 segundos) já é rápido o suficiente para que a penalidade por não ter 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 ao usuário, status do estoque) é buscado no lado do cliente (client-side) via AJAX para /customer/section/load/ e armazenado no localStorage do navegador. A página em si permanece no cache de página inteira. Este é o problema "lento por design" resolvido em nível de arquitetura.

Seus melhores clientes recebem suas piores páginas

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

Um visitante navega pelo seu site rápido e em cache. Ele encontra um produto que gosta. Ele clica em "adicionar ao carrinho". Nesse exato momento, o cache para e o 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 com maior probabilidade de comprar agora estão navegando na versão mais lenta do seu site.

Em sites monitorados pelo CoreDash, vemos usuários com carrinho experimentando um TTFB 3 a 5 vezes pior do que visitantes anônimos em plataformas de ecommerce auto-hospedadas (self-hosted). Em plataformas gerenciadas como o Shopify, a diferença é 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. Suas pontuações de laboratório parecerão ótimas enquanto seus compradores reais enfrentam dificuldades.

Para encontrar esse problema, você precisa de Real User Monitoring. Segmente seus dados de RUM por usuários que tenham um cookie de carrinho definido. Compare o TTFB, o FCP e o LCP entre esses dois segmentos. Se você vir uma diferença de 2x ou maior, ignorar o cache é o seu problema.

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

Como corrigir o desempenho para visitantes de alta intenção

Corrija o backend antes de depender do cache. Não dependa exclusivamente de plugins de cache. Analise o código do seu backend, otimize as consultas ao 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 os usuários com carrinho. A subparte de duração do cache do TTFB (cache duration sub-part of TTFB) não deveria estar fazendo todo o trabalho pesado.

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

Renderize componentes dinâmicos no lado do cliente (client-side). Esta é a abordagem do Magento 2 e funciona. Sirva a maior parte da página como HTML em cache (renderizado no lado do servidor ou server-side rendered). Em seguida, use JavaScript e uma pequena chamada de API para buscar as partes dinâmicas (contagem do carrinho, saudação ao usuário, recomendações personalizadas) após o carregamento da página. O navegador recebe o HTML rápido e em cache imediatamente. Os pedaços dinâmicos são preenchidos um momento depois. Seu LCP e FCP permanecem rápidos porque são impulsionados pelo shell em cache, e não pelo conteúdo dinâmico.

O framework headless do Shopify (Hydrogen) faz exatamente isso: os dados do produto são armazenados em cache agressivamente com TTLs longos, enquanto os dados do carrinho e do cliente 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 de forma assíncrona, em vez de bloquear a interação do usuário.

Implemente um gerenciamento eficaz de chaves de cache. Use chaves simples para elementos estáticos (a URL costuma ser suficiente como uma chave de cache) e chaves complexas para conteúdo dinâmico que inclua o ID do usuário, IDs dos produtos e timestamps. Isso permite que você armazene em cache no nível do usuário, em vez de escolher entre "totalmente em cache" e "sem nenhum cache".

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

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