Os Core Web Vitals (CWV) tornaram-se em 2024 um fator de classificação direto para a Google, e o seu peso no posicionamento das páginas de e-commerce continua a aumentar em 2026. No PrestaShop 8, otimizar os CWV é ao mesmo tempo trabalho de SEO e trabalho de qualidade de experiência: um LCP que passa de 4,2 s para 1,8 s dá mecanicamente 20 % a 40 % mais conversão em telemóvel, segundo os estudos da Google e as nossas próprias medições nas lojas que acompanhamos. Ainda assim, a otimização dos CWV continua mal compreendida. A maioria dos comerciantes lança um Lighthouse, vê uma pontuação vermelha, instala um módulo de cache genérico e constata que a pontuação quase não mexe, porque as verdadeiras alavancas não estão na cache, mas em detalhes técnicos precisos.
Esta checklist detalha as otimizações de CWV que produzem mesmo resultados no PrestaShop 8 em 2026, com código PHP e SQL real adaptado à arquitetura do PrestaShop, e não conselhos genéricos copiados de uma documentação da Google.
Os 3 Core Web Vitals de 2026 e os seus limiares
A Google mede três métricas para avaliar a qualidade de carregamento e de interação de uma página.
LCP (Largest Contentful Paint) mede o tempo entre o início do carregamento e a renderização do maior elemento visível (tipicamente a imagem principal de uma página de produto, ou o texto do hero de uma página de categoria). Limiares: bom abaixo de 2,5 s, a melhorar entre 2,5 e 4 s, mau acima de 4 s.
INP (Interaction to Next Paint) substituiu o FID em março de 2024. Mede a latência entre uma interação do utilizador (clique, toque, tecla) e a renderização visível seguinte. Limiares: bom abaixo de 200 ms, a melhorar entre 200 e 500 ms, mau acima de 500 ms.
CLS (Cumulative Layout Shift) mede os deslocamentos visuais imprevistos durante o carregamento (imagem que empurra o texto, faixa que aparece tarde). Limiares: bom abaixo de 0,1, a melhorar entre 0,1 e 0,25, mau acima de 0,25.
Para uma página passar a «Boa» na Search Console, as três métricas têm de estar no verde no percentil 75 dos carregamentos reais (os 25 % de visitas mais lentas podem ficar acima, mas os 75 % mais rápidos têm de ser bons). É isso que torna a otimização difícil: a loja pode ser rápida para um visitante em fibra num computador e catastrófica para um visitante em 4G degradado num Android de entrada de gama, e a Google calcula a pontuação sobre os utilizadores reais (dados de campo via Chrome User Experience Report).
Medir os CWV na loja: dados de laboratório e dados de campo
Há dois tipos de medições a distinguir.
Dados de laboratório (medição sintética). PageSpeed Insights, Lighthouse, WebPageTest. A página é carregada por um robô num ambiente normalizado (3G simulado, telemóvel de gama média). Os números são reprodutíveis mas não refletem a experiência dos seus visitantes reais. Úteis para diagnóstico e desenvolvimento.
Dados de campo (medições reais). Chrome User Experience Report (CrUX), acessível em Search Console > Melhorias > Core Web Vitals. São os números que a Google usa para a classificação. Medição agregada dos carregamentos reais dos seus visitantes nos últimos 28 dias. É a métrica que conta para o SEO.
A diferença entre os dois pode ser enorme: um site com pontuação Lighthouse de 95 pode ter dados de campo a vermelho se a maioria dos visitantes usar dispositivos mais lentos do que o perfil padrão do Lighthouse. Ao contrário, um site com Lighthouse de 60 pode estar correto em dados de campo se a audiência for sobretudo de computador.
A ferramenta a montar desde já. Configure o Real User Monitoring (RUM) na loja. Há várias opções gratuitas: a biblioteca web-vitals da Google, que se integra em poucas linhas de JS e envia as medições para o GA4, ou ferramentas como Cloudflare Web Analytics, SpeedCurve ou Calibre. As medições RUM são as mais fiéis ao que a Google vê e permitem segmentar por tipo de dispositivo, país e navegador, o que revela onde estão os problemas reais.
LCP: as otimizações que funcionam mesmo
O LCP é geralmente a métrica com mais impacto no negócio em PrestaShop, porque diz diretamente respeito à perceção de velocidade ao abrir uma página de produto. Aqui ficam as alavancas por ordem de impacto típico.
1. Identificar com precisão o elemento LCP
Antes de tudo, identifique que elemento desencadeia o LCP nas páginas-chave. O Lighthouse indica-o no relatório, mas a ferramenta mais precisa é a extensão do Chrome Web Vitals Extension, que destaca em tempo real o elemento LCP em qualquer página. Numa página de produto PrestaShop, o LCP é quase sempre a imagem principal do produto. Numa categoria, é geralmente a primeira imagem visível da grelha. Na página inicial, é o hero ou o slider.
Depois de identificado, é esse elemento que deve ser prioritário na otimização: pré-carregamento, conversão para formato moderno, dimensionamento e lazy loading desativado.
2. Pré-carregamento da imagem LCP
Nas páginas de produto, acrescentar um <link rel="preload"> no head para a imagem principal do produto ganha 200 a 500 ms no LCP, porque o navegador começa a transferir a imagem antes sequer de ter analisado o HTML que a contém.
Implementação no template da página de produto (themes/o-seu-tema/templates/catalog/product.tpl em Smarty, ou o ficheiro equivalente em Twig nos temas modernos):
{if isset($product.cover.bySize.large_default.url)}
<link rel="preload" as="image"
href="{$product.cover.bySize.large_default.url}"
imagesrcset="..." imagesizes="..." fetchpriority="high">
{/if}O atributo fetchpriority="high" é importante: indica ao navegador que este recurso é crítico e deve passar à frente dos outros na fila de transferência.
3. Conversão para WebP e AVIF com dimensões corretas
Servir as imagens de produto em WebP reduz o peso em 25 % a 35 % face ao JPEG com qualidade visual equivalente. O AVIF poupa ainda mais 20 %, mas com uma descodificação ligeiramente mais cara do lado do navegador. O compromisso de 2026 continua a ser WebP na maioria e AVIF nas imagens hero críticas.
No PrestaShop 8, vários módulos fazem a conversão automática (o nativo tem uma opção WebP básica, os módulos de terceiros fazem melhor com AVIF e compressão adaptativa). Confirme também que as dimensões servidas correspondem à exibição real: servir uma imagem de 2000×2000 mostrada em 400×400 desperdiça largura de banda e aumenta o LCP. Use srcset para propor vários tamanhos consoante o viewport.
4. TTFB e consultas SQL no servidor
O LCP tem como limite inferior o TTFB (Time To First Byte): enquanto o servidor não começar a enviar HTML, o navegador não consegue renderizar nada. Em PrestaShop, o TTFB pode ser arrastado por consultas SQL não otimizadas em hooks pesados.
A auditoria a fazer: ativar o profiling do PrestaShop (Configuração > Desempenho > ativar o modo debug mais o profiler) e olhar para o separador Database. Se vir uma consulta a executar 50 vezes por carregamento de página de produto com um tempo acumulado de 200 ms, é provavelmente uma consulta N+1 num módulo mal escrito. O módulo tem de ser corrigido ou desativado.
Os módulos mais frequentemente culpados nas lojas que auditamos: módulos de avaliações que consultam a nota média de cada produto mostrado sem cache, módulos de produtos relacionados que fazem uma consulta por produto recomendado, módulos de stock que calculam a disponibilidade a cada exibição. A nossa categoria Desempenho e Core Web Vitals cobre vários destes padrões.
INP: o assassino moderno do desempenho (e o mais mal compreendido)
O INP substituiu o FID em março de 2024 e é agora a métrica mais difícil de otimizar em PrestaShop. A razão: o FID media só a primeira interação, o INP mede todas as interações e guarda o pior percentil 98. Assim, uma única interação lenta em 50 (por exemplo um clique num filtro de categoria que congela 500 ms) pesa mais do que 49 interações rápidas.
1. Identificar as interações lentas
A extensão Web Vitals do Chrome mostra o INP em tempo real durante a navegação. Clique em tudo na loja (filtros, adição ao carrinho, popups, acordeões de FAQ, swiper de produto) e veja que interações passam dos 200 ms. Em PrestaShop, os culpados típicos são:
- os filtros de categoria (navegação por facetas) que recarregam toda a grelha em AJAX;
- as adições ao carrinho que disparam hooks pesados;
- as aberturas de modal de produto (Quick View);
- as mudanças de variante de produto (cor, tamanho).
2. Long tasks e ceder a thread principal
Uma interação lenta é quase sempre causada por uma «long task» de JavaScript (uma função que bloqueia a thread principal durante mais de 50 ms). O navegador não consegue responder aos cliques seguintes enquanto a long task não terminar.
A solução moderna: partir as long tasks com scheduler.yield() (API nativa nos Chromium recentes) ou com um padrão setTimeout(fn, 0) para devolver o controlo ao navegador entre pedaços de cálculo. Exemplo: se tem um ciclo que trata 1000 produtos do lado do cliente, divida-o em blocos de 50 com um yield entre cada bloco.
async function processProducts(products) {
for (let i = 0; i < products.length; i += 50) {
const chunk = products.slice(i, i + 50);
chunk.forEach(processProduct);
if ('scheduler' in window && 'yield' in scheduler) {
await scheduler.yield();
} else {
await new Promise(r => setTimeout(r, 0));
}
}
}3. Debounce e throttle nos inputs
Nos filtros de pesquisa, nos selects de variante e nos campos de quantidade, não dispare o AJAX a cada tecla. Debounce de 200 a 300 ms antes de enviar o pedido. Sem este detalhe, um visitante que escreve depressa gera 10 pedidos AJAX que saturam todos a thread principal.
4. Code splitting de JS e carregamento diferido
Muitos módulos PrestaShop carregam o seu JS em todas as páginas quando só são usados nalgumas (um módulo de Quick View a carregar na página inicial, um módulo de FAQ a carregar nas categorias). Audite os seus controladores e use $this->context->controller->registerJavascript() com o controlador certo em parâmetro para limitar o carregamento às páginas onde o JS é necessário.
Para as funcionalidades realmente pesadas (um slider Swiper, um editor WYSIWYG), carregue o JS de forma diferida com import() dinâmico no momento da primeira interação, e não no carregamento da página.
CLS: a estabilidade visual
O CLS é geralmente a métrica mais fácil de corrigir em PrestaShop, porque as causas são poucas e bem conhecidas.
1. Reserva de espaço para as imagens. Toda a imagem no HTML deve ter atributos width e height explícitos (ou um aspect-ratio em CSS). Sem isso, a imagem faz variar a disposição ao carregar. Em PrestaShop, as imagens de produto geradas pelos hooks displayProduct... devem ter todas as dimensões. Verifique o código do tema: qualquer <img src="..." /> sem width e height é suspeito.
2. Tipos de letra web e FOIT/FOUT. Se usa Google Fonts ou tipos de letra personalizados, o navegador pode mostrar texto invisível (FOIT) e depois trocar bruscamente (FOUT) quando o tipo de letra chega, o que desloca todo o conteúdo. Solução: font-display: optional no CSS para os tipos de letra secundários, e font-display: swap com um fallback de métricas compatíveis (use size-adjust em CSS para ajustar o fallback ao tipo de letra personalizado e eliminar o deslocamento).
3. Banners e popups diferidos. As faixas de cookies, os popups de newsletter e as barras de topo que aparecem 1 a 3 segundos depois do carregamento são fontes frequentes de CLS. Solução: reserve o espaço em CSS desde o início (com min-height) se souber que o banner vai aparecer, ou mostre-o em sobreposição (position fixed ou absolute) sem deslocar o conteúdo existente.
4. Iframes externas e embeds. As iframes do YouTube, Vimeo ou Calendly que carregam em diferido deslocam o conteúdo. Reserve sempre o espaço com um wrapper em aspect-ratio: 16/9 ou equivalente.
Otimizações SQL e de base de dados específicas do PrestaShop
Em PrestaShop, uma parte importante do TTFB (e portanto do LCP) vem das consultas SQL. Aqui ficam os padrões a conhecer.
Profiling com EXPLAIN
Quando o profiler do PrestaShop revela uma consulta lenta (mais de 50 ms), passe-a no MySQL com EXPLAIN para perceber o que se passa. Se vir um type: ALL com muitas linhas percorridas, falta provavelmente um índice. Se vir Using filesort ou Using temporary, a consulta faz trabalho inútil e tem de ser reescrita.
Índices em falta típicos em PrestaShop
Nas lojas com catálogo grande (mais de 5000 produtos) e muitos módulos de terceiros, faltam muitas vezes alguns índices. Os padrões que vemos em auditoria:
- índice em falta em
id_product, id_shopnas tabelas próprias dos módulos; - índice em falta nas colunas usadas pelos filtros de categoria (navegação por facetas);
- índice em falta em
id_order, date_addnas consultas de estatísticas de encomendas.
Acrescente os índices em falta diretamente em SQL, pelo phpMyAdmin ou por uma migração de módulo. Meça antes e depois: um único índice bem colocado pode dividir o tempo de uma consulta por 50.
Consultas N+1 nos hooks
O padrão mais destrutivo em desempenho PrestaShop: um hook que executa para cada produto mostrado e faz uma consulta SQL por produto. Numa categoria com 24 produtos, são 24 consultas adicionais por carregamento.
Deteção: profiler do PrestaShop > Database. Se vir a mesma consulta repetida N vezes com parâmetros diferentes, é uma N+1.
Solução: alterar o módulo para agrupar as consultas. Em vez de fazer uma consulta por produto no hook displayProductMiniature, o módulo deve recolher todos os IDs de produto em actionProductListBefore e fazer uma única consulta WHERE id_product IN (1, 2, 3, ...) que traz todos os resultados de uma vez.
Cache do PrestaShop: Smarty mais cache de módulo
No PrestaShop 8, dois níveis de cache complementam-se. A cache Smarty (compila os templates em PHP) usa-se em produção: confirme SMARTY_CONSOLE_FORCE_COMPILE = 0 e SMARTY_CACHE = 1 em config/defines.inc.php. A cache de módulo (cache própria dentro dos módulos) é mais potente: um módulo bem escrito guarda em cache os cálculos pesados e só os refaz quando os dados mudam. Se um módulo recalcula a mesma coisa em cada página, é um bug a corrigir.
Nas lojas com muito tráfego, acrescente também uma cache HTTP (Varnish, ou a cache LiteSpeed do lado do alojamento) que serve as páginas de produto pré-renderizadas sem sequer chegar ao PrestaShop. Divide o TTFB por 10 nos pedidos repetidos e liberta o servidor para os pedidos realmente dinâmicos.
A armadilha dos módulos de terceiros
Nas lojas que auditamos, 60 % a 80 % dos problemas de CWV vêm de módulos de terceiros mal escritos. O padrão é sempre o mesmo: um módulo instalado para uma funcionalidade útil (chat em direto, popup de newsletter, selo de fidelização, prova social) carrega um JS pesado em todas as páginas, agrava o LCP e o INP, e ninguém faz a ligação.
A auditoria a fazer regularmente:
- Desative todos os módulos de terceiros e lance o Lighthouse: é a sua base «PrestaShop puro».
- Reative os módulos um a um, relançando o Lighthouse de cada vez.
- Identifique os módulos que fazem a pontuação cair mais de 5 pontos: são os culpados.
- Para cada culpado: ou encontra uma definição que o torne mais leve, ou substitui-o por uma alternativa mais bem escrita, ou decide que a funcionalidade não vale a degradação.
Critério de escolha de um módulo novo em 2026: antes de instalar, confirme que o módulo só carrega os ficheiros nas páginas onde é usado, que faz SQL agrupado (sem N+1), que oferece uma cache configurável e que tem um changelog recente (um módulo sem manutenção há 18 meses em PrestaShop 8 é suspeito).
Vários módulos do nosso catálogo foram desenvolvidos com estas restrições em mente, como o módulo DataFirefly SideCart, que só carrega o seu JS nas páginas onde aparece, ou o módulo DataFirefly Cross-Sell, cujos analytics partem em AJAX fora do caminho crítico para não afetar o LCP, tema abordado no nosso artigo sobre a venda cruzada que contribui para o valor médio do carrinho.
Conclusão: um trabalho contínuo, não um projeto pontual
A otimização dos Core Web Vitals no PrestaShop 8 raramente é um trabalho de alguns dias que se faz uma vez e se esquece. É um trabalho contínuo: cada módulo novo pode partir a pontuação, cada atualização do PrestaShop pode introduzir regressões, cada evolução da Google (a chegada do INP em março de 2024, por exemplo) pode redistribuir as prioridades.
O bom reflexo é montar uma monitorização permanente (Search Console mais RUM via web-vitals.js mais GA4) e verificar as métricas por rotina, não só quando um problema se torna visível. Uma degradação detetada na semana 1 corrige-se em poucas horas; a mesma degradação detetada na semana 8, depois de ter acrescentado mais três módulos entretanto, torna-se uma auditoria completa de vários dias.
Para ir mais longe, percorra as categorias Desempenho e Core Web Vitals e Tutoriais PrestaShop para os temas técnicos relacionados. E se identificar módulos da sua stack atual que arrastam os CWV sem trazer valor correspondente, vários módulos do nosso catálogo foram pensados para serem rápidos por construção: o SideCart, o Cross-Sell e toda a gama DataFirefly partilham o mesmo compromisso, sem JS nas páginas onde o módulo não aparece, sem N+1 e sem dependências externas inúteis.
Leia também: o guia completo dos Core Web Vitals.
1 comentário