# Desempenho no PrestaShop 8: a checklist Core Web Vitals 2026 (LCP, INP, CLS) com código PHP e SQL real
> Os Core Web Vitals de 2026 no PrestaShop 8: checklist completa de LCP, INP e CLS com código PHP e SQL real. Diagnóstico, otimizações que funcionam mesmo, módulos de terceiros e cache. Nada de conselhos genéricos copiados da documentação da Google.
- Página:
- Idioma: pt
- Publicado em: 2026-05-09
- Atualizado em: 2026-05-09
- Outros idiomas: [fr](https://www.datafirefly.com/2026/05/09/performance-prestashop-8-checklist-core-web-vitals-2026-lcp-inp-cls/index.md), [en](https://www.datafirefly.com/en/2026/05/09/prestashop-8-performance-core-web-vitals-checklist-2026-lcp-inp-cls/index.md), [es](https://www.datafirefly.com/es/2026/05/09/rendimiento-prestashop-8-checklist-core-web-vitals-2026-lcp-inp-cls/index.md), [de](https://www.datafirefly.com/de/2026/05/09/prestashop-8-performance-core-web-vitals-checkliste-2026-lcp-inp-cls/index.md), [it](https://www.datafirefly.com/it/2026/05/09/performance-prestashop-8-checklist-core-web-vitals-2026-lcp-inp-cls-2/index.md), [pl](https://www.datafirefly.com/pl/2026/05/09/wydajnosc-prestashop-8-lista-kontrolna-core-web-vitals-2026-lcp-inp-cls/index.md), [nl](https://www.datafirefly.com/nl/2026/05/09/prestaties-prestashop-8-checklist-core-web-vitals-2026-lcp-inp-cls/index.md)
- Índice:
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 `` 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)}
{/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](https://www.datafirefly.com/pt/category/desempenho-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 `` 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_shop` nas 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_add` nas 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](https://www.datafirefly.com/pt/produto/carrinho-lateral-prestashop/), que só carrega o seu JS nas páginas onde aparece, ou o [módulo DataFirefly Cross-Sell](https://www.datafirefly.com/pt/produto/venda-cruzada-produtos-associados-prestashop/), 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](https://www.datafirefly.com/pt/2026/05/09/valor-medio-carrinho-prestashop-8-7-estrategias-venda-cruzada-2026/).
## 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](https://www.datafirefly.com/pt/category/desempenho-core-web-vitals/) e [Tutoriais PrestaShop](https://www.datafirefly.com/pt/category/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](https://www.datafirefly.com/pt/produto/carrinho-lateral-prestashop/), o [Cross-Sell](https://www.datafirefly.com/pt/produto/venda-cruzada-produtos-associados-prestashop/) 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](https://www.datafirefly.com/pt/2026/05/01/core-web-vitals-guia-completo-prestashop-wordpress-2026/).