# Core Web Vitals: o guia completo para PrestaShop e WordPress em 2026 > O guia completo dos Core Web Vitals (LCP, CLS, INP) para PrestaShop e WordPress em 2026: medição, otimização, ferramentas e erros frequentes. - Página: - Idioma: pt - Publicado em: 2026-05-01 - Atualizado em: 2026-05-01 - Outros idiomas: [fr](https://www.datafirefly.com/2026/05/01/core-web-vitals-guide-prestashop-wordpress-2026/index.md), [en](https://www.datafirefly.com/en/2026/05/01/core-web-vitals-prestashop-wordpress-guide-2026/index.md), [es](https://www.datafirefly.com/es/2026/05/01/core-web-vitals-guia-prestashop-wordpress-2026/index.md), [de](https://www.datafirefly.com/de/2026/05/02/core-web-vitals-leitfaden-prestashop-wordpress-2026/index.md), [it](https://www.datafirefly.com/it/2026/05/01/core-web-vitals-guida-prestashop-wordpress-2026/index.md), [pl](https://www.datafirefly.com/pl/2026/05/01/core-web-vitals-przewodnik-prestashop-wordpress-2026/index.md), [nl](https://www.datafirefly.com/nl/2026/05/01/core-web-vitals-gids-prestashop-wordpress-2026/index.md) - Índice: Os Core Web Vitals não são apenas um tema para técnicos. Desde 2024, a Google usa-os como sinal de classificação real nas pesquisas comerciais, e o impacto na conversão é mensurável: um site que passa de 4 segundos para 2 segundos de LCP ganha tipicamente entre 10 % e 25 % de conversão em telemóvel. Este guia explica com precisão as três métricas atuais, como medi-las e como otimizá-las no PrestaShop e no WordPress em 2026. ## Os três Core Web Vitals a conhecer ### LCP: Largest Contentful Paint O LCP mede o tempo entre o início do carregamento da página e o aparecimento do maior elemento visível na janela. Numa loja online, esse elemento é quase sempre uma imagem: a foto principal do produto numa página de produto, o hero da página inicial, a imagem de banner da categoria. Objetivos oficiais da Google: - **Bom**: menos de 2,5 segundos - **A melhorar**: entre 2,5 e 4 segundos - **Mau**: mais de 4 segundos ### CLS: Cumulative Layout Shift O CLS mede a estabilidade visual da página durante o carregamento. Na prática: um botão que se desloca depois de o utilizador ter começado a clicar, uma imagem que empurra o conteúdo para baixo por chegar tarde, um banner de cookies que desalinha tudo. Quanto mais baixa a pontuação, melhor. - **Bom**: menos de 0,1 - **A melhorar**: entre 0,1 e 0,25 - **Mau**: mais de 0,25 ### INP: Interaction to Next Paint O INP substituiu o FID (First Input Delay) em março de 2024. Mede o intervalo entre a interação do utilizador (clique, toque, escrita) e a resposta visível do navegador, em todas as interações da sessão e não apenas na primeira. - **Bom**: menos de 200 ms - **A melhorar**: entre 200 e 500 ms - **Mau**: mais de 500 ms O INP é mais exigente do que o FID porque inclui todas as interações. Os sites que passavam o FID à tangente falham muitas vezes no INP, sobretudo em WooCommerce com os seus scripts de variações e de adição ao carrinho em AJAX. ## Como medir os Core Web Vitals Quatro ferramentas complementares: - **PageSpeed Insights** (gratuito, da Google), que dá uma nota sintética com recomendações específicas. Distingue dados de laboratório (teste simulado) de dados de campo (reais, com base no Chrome User Experience Report) - **Lighthouse** (integrado nas Chrome DevTools), auditoria completa em local, útil para identificar estrangulamentos - **Google Search Console → Experiência → Core Web Vitals**, vista agregada do site com base nos dados reais dos utilizadores do Chrome - **WebPageTest**, teste detalhado com waterfall e escolha do tipo de ligação Importante: os dados de laboratório de um teste isolado não refletem o que os seus utilizadores vivem. Os dados de campo na Search Console são mais representativos, e são esses que contam para a Google. ## Otimizar o LCP ### Identificar o elemento LCP No Lighthouse, a secção _Largest Contentful Paint element_ indica exatamente qual é o elemento LCP da sua página. Numa página de produto PrestaShop ou WooCommerce, é quase sempre a fotografia principal. ### Otimizar as imagens Três ações essenciais: 1. **Converter para WebP ou AVIF**, o que reduz o tamanho do ficheiro em 30 % a 60 % sem perda visível. No PrestaShop, existem módulos dedicados que fazem a conversão automática. No WordPress, plugins como o _ShortPixel_, o _Imagify_ ou o _Smush_. 2. **Servir as dimensões certas**: não envie uma imagem de 2000 × 2000 para um espaço de 400 × 400. Use `srcset` e `sizes` para servir a imagem adequada a cada viewport. 3. **Pré-carregar a imagem LCP**: acrescente `` no `` para a imagem principal. O navegador transfere-a com prioridade absoluta. ### Ativar uma cache HTTP No PrestaShop: cache Smarty mais cache de página completa através de um módulo ou de um proxy inverso como o Varnish. No WordPress: um plugin de cache (LiteSpeed Cache se o servidor correr LiteSpeed Web Server, caso contrário o WP Rocket). O ganho de LCP com uma cache HTTP bem configurada é tipicamente de 1 a 2 segundos. ### Usar uma CDN Cloudflare, BunnyCDN, ou uma CDN integrada no seu alojamento, para imagens, vídeos e ficheiros estáticos. Reduz o LCP dos utilizadores geograficamente afastados do seu servidor, o que conta em particular se serve os arquipélagos ou o Brasil a partir de um servidor europeu. ## Otimizar o CLS O CLS costuma ser o mais simples de corrigir. Três ações principais: ### Especificar sempre `width` e `height` nas imagens O navegador precisa de reservar o espaço da imagem antes de esta carregar. Sem dimensões, o espaço reservado é nulo e o conteúdo abaixo desloca-se quando a imagem chega. ``` ... ``` O que conta é a proporção. O navegador usará o CSS para adaptar ao tamanho real de exibição, mas reserva o espaço com o rácio certo. ### Reservar o espaço dos banners e popups As faixas de cookies, os popups de newsletter e as barras de urgência no topo da página criam CLS se forem injetados depois do carregamento. Soluções: renderizá-los do lado do servidor (HTML já presente no carregamento, apenas tornado visível por CSS), ou reservar a altura em CSS desde o início. ### Carregar corretamente os tipos de letra web O FOUT (Flash of Unstyled Text) e o FOIT (Flash of Invisible Text) provocam CLS quando o tipo de letra de substituição e o final têm dimensões diferentes. Soluções: `font-display: swap` com um fallback bem escolhido (métricas próximas), pré-carregamento dos tipos de letra críticos com ``, ou uso de `font-size-adjust` para alinhar as métricas. ## Otimizar o INP O INP é o mais difícil dos três. Depende da qualidade do JavaScript executado quando o utilizador interage com a página. ### Reduzir o JavaScript bloqueante Audite os scripts de terceiros: analytics, chat, testes A/B, retargeting, popups. Cada um acrescenta tempo de execução na thread principal. Seja implacável: se um script não gera receita mensurável, elimine-o. Para os scripts que ficam, carregue-os em `defer` ou `async` sempre que for possível. As etiquetas de tracking podem quase sempre ser diferidas. ### Dividir o JavaScript em blocos Em sites com muito JS, o code splitting (carregar apenas o código necessário à página atual) reduz o INP. No PrestaShop 8, com os seus bundles, a margem é limitada. No WordPress com plugins pesados, costuma ser uma otimização de peso. ### Otimizar as interações As interações comuns que prejudicam o INP: - Adição ao carrinho, sobretudo em WooCommerce - Aplicação de uma variação de produto - Pesquisa num mega-menu com preenchimento automático - Aplicação de um filtro numa listagem de produtos Em cada caso, a otimização passa pelo profiling do Chrome (separador Performance) para identificar as funções lentas e depois refatorizá-las. ## Específico do PrestaShop No PrestaShop, as ações mais rentáveis: - Ativar a cache Smarty e a combinação e minificação dos ficheiros em **Parâmetros avançados → Desempenho** - Compilar os templates Smarty e desativar a recompilação a cada visita - Usar um módulo de geração de CSS crítico para a zona acima da dobra - Auditar os módulos de terceiros: um único módulo mal escrito pode acrescentar 500 ms de tempo de servidor ## Específico do WordPress e do WooCommerce No WordPress, as ações principais: - Plugin de cache obrigatório (LiteSpeed Cache, WP Rocket, W3 Total Cache) - Auditoria dos plugins: desativar e eliminar os que não são usados - Conversão em massa das imagens para WebP através do ShortPixel ou equivalente - Limitar os scripts do WooCommerce nas páginas onde não servem (página inicial, artigos do blogue), com um plugin como o _Asset CleanUp_ - Alojamento sério: num partilhado de gama baixa, nunca passará de uma pontuação Lighthouse móvel de 50 ## Os erros frequentes - Otimizar apenas a pontuação Lighthouse em computador. O que conta para a Google é o telemóvel. - Ignorar os dados de campo a favor dos dados de laboratório - Instalar 5 plugins de cache «para ter a certeza», que entram em conflito e pioram o resultado - Comprimir as imagens até ficarem feias: aponte a 75 % a 85 % de qualidade, não menos - Bloquear o JavaScript essencial por excesso de zelo, ao ponto de o botão de adicionar ao carrinho deixar de funcionar ## Para ir mais longe Todos os nossos artigos dedicados ao desempenho estão arrumados na categoria [Desempenho e Core Web Vitals](https://www.datafirefly.com/pt/category/desempenho-core-web-vitals/). Para as soluções técnicas, explore os nossos [módulos SEO para PrestaShop](https://www.datafirefly.com/pt/categorie-produit/modulos-prestashop-pt/seo-posicionamento/), que incluem otimizações de Core Web Vitals (geração de CSS crítico, lazy loading avançado, conversão para WebP). Uma loja rápida é uma loja que converte, e é provavelmente o melhor investimento técnico de 2026. Para passar à ação: [a nossa seleção de plugins para acelerar uma loja WooCommerce](https://www.datafirefly.com/pt/solutions/wordpress/desempenho-velocidade/).