A primeira vez que um cliente WooCommerce alojado na Amen.pt abriu o PageSpeed Insights e viu LCP de 4,0 s ao lado de um hero PNG de 200 KB, o diagnóstico demorou trinta segundos e a correção uma tarde. A conversão do hero para AVIF mais fetchpriority="high" levou a página para 1,4 s de LCP. O lado do CSS foi mais difícil: uma folha de estilos de 800 KB de um tema page-builder bloqueava a renderização em mobile, e só a extração de critical CSS com 12 KB inline puxou o FCP para baixo de um segundo. Estes dois padrões repetem-se em quase todos os sites WordPress portugueses que auditamos.
Este guia percorre a pipeline que efetivamente move os Core Web Vitals numa instalação WordPress portuguesa: escolha de formato entre AVIF, WebP e JPEG XL face à realidade atual dos navegadores (Safari 16+ entrega AVIF, Chrome descodifica JPEG XL apenas atrás de uma flag, Firefox arquivou o JPEG XL em 2024); seleção de plugin entre ShortPixel, Imagify, Smush e EWWW com os limites de API e particularidades de DPA que cada um traz sob RGPD e supervisão da CNPD; a regra dos 14 KB above-the-fold que vem do TCP slow start, não de um slide de marketing; e as configurações do LiteSpeed Cache que produzem um delta mensurável de LCP em vez de placebo. Hosts portugueses como Amen.pt, PTisp e CloudWays-PT já suportam WebP nativamente em planos LiteSpeed, e isso muda o cálculo de adoção.
De onde vêm realmente as perdas de LCP e FCP
Abra o painel Network num site WordPress português típico alojado na Amen.pt, PTisp ou Webhs e verá dois culpados a comer o orçamento de LCP: uma imagem hero de 1-2 MB entregue como JPEG ou PNG, e uma folha de estilos principal de 300-800 KB marcada como bloqueadora de renderização. O terceiro culpado, fontes web carregadas sem font-display: swap, é menor em bytes mas bloqueia o paint até chegarem.
A imagem hero é o alvo óbvio porque o LCP, por definição, é o maior elemento visível acima da dobra, e na maioria das páginas iniciais WordPress portuguesas esse elemento é um JPEG. O WebP corta esse ficheiro em cerca de 25-35% com qualidade visual equivalente, e o AVIF corta-o novamente, frequentemente aterrando 40-55% mais pequeno do que o JPEG original consoante o conteúdo. O suporte AVIF é agora amplo: Chrome desde a 85, Firefox desde a 93, Safari desde a 16. O JPEG XL é o ausente ruidoso: o Chromium retirou a flag de descodificação, o Firefox parqueou-o indefinidamente, apenas o Safari o entrega nativamente, portanto para uma audiência portuguesa não é um formato de produção em 2026.
O lado do CSS é onde a regra dos 14 KB importa. O TCP slow start abre uma ligação com cerca de dez pacotes, aproximadamente 14 KB depois dos cabeçalhos, antes do primeiro round-trip de ACK. Inline mais do que isso no seu <head> e estende o primeiro paint num RTT completo. Esta é a razão completa por que os extratores de critical CSS apontam para um teto de 14 KB e não para um número redondo numa checklist.
Escolha do plugin de otimização de imagens
Quatro plugins fazem a maior parte do trabalho de otimização de imagens WordPress em 2026, e a escolha entre eles raramente se resume só à qualidade de compressão. Limites de API, onde a conversão corre, e que dados saem do seu servidor importam tanto sob RGPD e supervisão da CNPD como o tamanho final do ficheiro.
ShortPixel Image Optimizer
O ShortPixel comprime através da sua API na nuvem e entrega WebP e AVIF como standard. Três modos: lossy, glossy, lossless. Em sites com muitas fotografias, o preset glossy aterra normalmente dentro de uns pontos percentuais da qualidade visual lossless por metade dos bytes. O senão nas execuções em massa é o teto de rate da API: empurrar 10 000+ imagens num dia num plano pequeno aciona throttling, e o processador em massa do plugin recua em vez de falhar visivelmente, o que faz uma execução parada parecer uma execução partida. Vertente CNPD: o ShortPixel tem subcontratante de tratamento publicada, mas os endpoints estão parcialmente fora da UE, portanto o fornecedor entra no registo de atividades de tratamento.
Pontos fortes principais:
- Geração de AVIF em produção desde 2023
- Processamento em massa com fila em segundo plano
- Preset glossy como predefinição prática para editorial e e-commerce
- Preços por quota e individuais
Imagify
Construído pela equipa por trás do WP Rocket, o Imagify integra-se perfeitamente com esse plugin de cache. Oferece três modos de compressão (normal, agressivo, ultra) e gera ficheiros WebP automáticamente.
Pontos fortes principais:
- Integração profunda com WP Rocket para otimização combinada
- Ferramenta de comparação visual para pré-visualizar resultados de compressão
- Redimensionamento automático de uploads sobredimensionados
- Geração de WebP com um clique
- Preços baseados em quota (individual, varia conformé o uso)
Smush
O Smush da WPMU DEV é a opção mais amigável para iniciantes. A versão gratuita lida com compressão básica e lazy loading. A versão Pro adiciona conversão WebP, entrega CDN é otimização mais agressiva.
Pontos fortes principais:
- Nível gratuito com imagens ilimitadas (até 5 MB cada)
- Lazy loading integrado
- CDN incluído com Pro
- Smush ao nível de diretório para imagens fora da biblioteca de media
- Preços Pro variam conformé o plano
EWWW Image Optimizer
O EWWW é o único plugin desta lista que pode correr inteiramente no servidor sem uma API externa. Isso conta sob RGPD: nenhuma transferência para país terceiro de imagens carregadas, nenhum subcontratante de tratamento adicional necessário, nenhuma entrada no registo de atividades de tratamento para um processador SaaS de imagens, uma vantagem clara em revisões da CNPD. O modo local usa jpegoptim, optipng, pngquant e cwebp executados a partir de PHP, portanto os binários têm de estar em disco; em hosts portugueses como a Amen.pt e a PTisp essa é uma conversa rápida com o suporte.
Pontos fortes principais:
- Modo de compressão local sem round-trip à nuvem
- Conversão WebP e AVIF
- Opção CDN ExactDN com entrega por negociação de conteúdo
- Comandos WP-CLI para execuções em massa via cron
- Preços variam conforme o modo, local é gratuito, planos API são individuais
Comparação de plugins de relance
| Funcionalidade | ShortPixel | Imagify | Smush | EWWW |
|---|---|---|---|---|
| Suporte WebP | Sim | Sim | Apenas Pro | Sim |
| Suporte AVIF | Sim | Não | Não | Sim |
| Compressão local | Não | Não | Não | Sim |
| Processamento em massa | Sim | Sim | Sim | Sim |
| Integração WP Rocket | Básica | Nativa | Não | Básica |
| Nível gratuito | 100 imagens/mês | 20 MB/mês | Ilimitado (limitado) | Modo local |
Para a maioria dos sites WordPress profissionais, ShortPixel ou EWWW oferecem a melhor combinação de suporte de formatos, qualidade de compressão e flexibilidade.
Configurar a entrega de WebP e AVIF
Instalar um plugin dé otimização é apenas metade do trabalho. Também precisa de garantir qué os navegadores realmente recebem o formato moderno em vez do JPEG ou PNG original.
Método 1: Reescrita do elemento picture
A abordagem mais fiável útiliza o elemento HTML <picture> para oferecer múltiplos formatos com fallback automático:
<picture>
<source srcset="image.avif" type="image/avif">
<source srcset="image.webp" type="image/webp">
<img src="image.jpg" alt="Descrição" width="800" height="600" loading="lazy">
</picture>A maioria dos plugins dé otimização gere está reescrita automáticamente. ShortPixel e EWWW inserem tags <picture> quando configurados para tal.
Método 2: Negociação de conteúdo via .htaccess
Sé o seu servidor útiliza Apaché ou LiteSpeed, pode servir ficheiros WebP de forma transparente usando negociação de conteúdo. O navegador envia um cabeçalho Accept listando formatos suportados, é o servidor responde com o melhor ficheiro disponível:
<IfModule mod_rewrite.c>
RewriteEngine On
# Servir AVIF se disponível e suportado
RewriteCond %{HTTP_ACCEPT} image/avif
RewriteCond %{REQUEST_FILENAME} (.+)\.(jpe?g|png|gif)$
RewriteCond %{REQUEST_FILENAME}.avif -f
RewriteRule (.+)\.(jpe?g|png|gif)$ $1.$2.avif [T=image/avif,E=REQUEST_image,L]
# Servir WebP se disponível e suportado
RewriteCond %{HTTP_ACCEPT} image/webp
RewriteCond %{REQUEST_FILENAME} (.+)\.(jpe?g|png|gif)$
RewriteCond %{REQUEST_FILENAME}.webp -f
RewriteRule (.+)\.(jpe?g|png|gif)$ $1.$2.webp [T=image/webp,E=REQUEST_image,L]
</IfModule>
<IfModule mod_headers.c>
Header append Vary Accept env=REQUEST_image
</IfModule>Está abordagem é invisível para o seu HTML e funciona com qualquer tema ou construtor de páginas.
Método 3: Filtro WordPress para controlo programático
Para programadores que querem controlo preciso, pode filtrar a saída de imagens ao nível do PHP:
<?php
declare(strict_types=1);
add_filter('wp_get_attachment_image_attributes', function (array $attr, WP_Post $attachment): array {
$webp_url = preg_replace('/\.(jpe?g|png)$/i', '.webp', $attr['src']);
$upload_dir = wp_get_upload_dir();
$webp_path = str_replace($upload_dir['baseurl'], $upload_dir['basedir'], $webp_url);
if (file_exists($webp_path)) {
$attr['src'] = $webp_url;
if (isset($attr['srcset'])) {
$attr['srcset'] = preg_replace('/\.(jpe?g|png)/i', '.webp', $attr['srcset']);
}
}
return $attr;
}, 10, 2);Limpar os tamanhos de imagem do WordPress
O WordPress é o WooCommerce registam númerosos tamanhos de imagem por defeito. Cada imagem carregada gera uma cópia em cada tamanho registado, consumindo armazenamento é atrasando a otimização em massa. Remover tamanhos que não útiliza é uma vitória rápida.
Remover tamanhos predefinidos não útilizados
<?php
declare(strict_types=1);
add_action('after_setup_theme', function (): void {
// Remover tamanhos que não útiliza
remove_image_size('1536x1536');
remove_image_size('2048x2048');
});
add_filter('intermediate_image_sizes_advanced', function (array $sizes): array {
// Manter apenas os tamanhos qué o seu tema realmente útiliza
$remove = ['medium_large'];
foreach ($remové as $size) {
unset($sizes[$size]);
}
return $sizes;
});Registar apenas o que precisa
<?php
declare(strict_types=1);
add_action('after_setup_theme', function (): void {
add_image_size('hero-banner', 1200, 630, true);
add_image_size('card-thumb', 400, 300, true);
add_image_size('logo-small', 200, 0, false);
});Definir dimensões máximas de upload
Impedir qué os útilizadores carreguem originais de 6000 px que desperdiçam armazenamento e tempo de processamento:
<?php
declare(strict_types=1);
add_filter('wp_handle_upload', function (array $upload): array {
$max_width = 2400;
$max_height = 2400;
if (!str_starts_with($upload['type'], 'image/')) {
return $upload;
}
$image = wp_get_image_editor($upload['file']);
if (is_wp_error($image)) {
return $upload;
}
$size = $image->get_size();
if ($size['width'] > $max_width || $size['height'] > $max_height) {
$image->resize($max_width, $max_height, false);
$image->save($upload['file']);
}
return $upload;
});Compreender o critical CSS é os recursos que bloqueiam a renderização
Quando um navegador carrega uma página WordPress, tem de descarregar é analisar a folha de estilos CSS completa antes de renderizar qualquer coisa no ecrã. Num site WordPress típico com um tema de construtor de páginas, essa folha de estilos pode ter 300-500 KB de CSS, sendo qué a maioria sé aplica a elementos abaixo da dobra ou em páginas completamente diferentes.
O critical CSS resolve isto extraindo apenas os estilos necessários para o conteúdo acima da dobra e inserindo-os diretamente inline no <head> do HTML. A folha de estilos completa é então carregada de forma assíncrona, removendo-a do caminho crítico de renderização.
Como funciona a extração de critical CSS
- Uma ferramenta renderiza a página num navegador headless num tamanho de viewport padrão (tipicamente 1300x900 para desktop, 375x812 para dispositivos móveis).
- Identifica quais regras CSS sé aplicam aos elementos visíveis nesse viewport.
- Essas regras são extraídas e minificadas.
- O CSS extraído é inserido inline em tags
<style>no cabeçalho do documento. - A folha de estilos original é carregada com
media="print"e trocada paramedia="all"no carregamento.
Padrão manual de pré-carregamento de critical CSS
Se não está a usar um plugin que gere isto automáticamente, pode implementar o padrão com um filtro WordPress:
<?php
declare(strict_types=1);
add_action('wp_head', function (): void {
$critical_css_file = get_template_directory() . '/critical.css';
if (!file_exists($critical_css_file)) {
return;
}
$critical_css = file_get_contents($critical_css_file);
if ($critical_css === false) {
return;
}
echo '<style id="critical-css">' . $critical_css . '</style>' . "\n";
}, 1);
add_filter('style_loader_tag', function (string $html, string $handle): string {
// Adiar folhas de estilos não críticas
$defer_handles = ['theme-style', 'woocommerce-layout', 'woocommerce-general'];
if (in_array($handle, $defer_handles, true)) {
$html = str_replace(
"media='all'",
"media='print' onload=\"this.media='all'\"",
$html
);
}
return $html;
}, 10, 2);Pré-carregar recursos críticos com tags link
Para recursos qué o navegador precisa imediatamente, as dicas de preload indicam-lhe para começar a descarregar antes de descobrir o recurso naturalmente no HTML:
<!-- Pré-carregar a imagem hero -->
<link rel="preload" as="image" href="/wp-content/uploads/hero.webp" type="image/webp">
<!-- Pré-carregar fonte crítica -->
<link rel="preload" as="font" href="/wp-content/themes/theme/fonts/main.woff2"
type="font/woff2" crossorigin>No WordPress, adicione-os programaticamente:
<?php
declare(strict_types=1);
add_action('wp_head', function (): void {
if (!is_front_page()) {
return;
}
$hero_image = get_template_directory_uri() . '/images/hero.webp';
echo '<link rel="preload" as="image" href="' . esc_url($hero_image) . '" type="image/webp">' . "\n";
}, 1);Configurar o LiteSpeed Cache para WordPress
O LiteSpeed Cache é o plugin de cache mais rápido disponível para WordPress porqué opera ao nível do servidor web em vez dé através do PHP. Sé o seu alojamento útiliza OpenLiteSpeed ou LiteSpeed Enterprise, este plugin comúnica diretamente com o motor de cache integrado do servidor, contornando o PHP totalmente para pedidos em cache.
Definições essenciais do LiteSpeed Cache
Cache de página (separador Cache):
- Ativar cache: Ligado
- Cache de útilizadores autenticados: Desligado (a menos que tenha conteúdo de membros)
- Cache móvel: Ligado (com cache separada para dispositivos móveis sé o tema serve markup diferente)
- TTL: 604800 (7 dias para sites com conteúdo estático), 86400 (1 dia para sites frequentementé atualizados)
Cache do navegador (separador Cache):
- Cache do navegador: Ligado
- TTL da cache do navegador: 31557600 (1 ano, confie em nomes de ficheiro versionados para invalidação da cache)
Cache dé objetos (separador Cache):
- Cache dé objetos: Ligado (requer Redis ou Memcached no servidor)
- TTL da cache dé objetos: 3600
Definições dé otimização CSS/JS
Navegué até LiteSpeed Cache, depois Otimização:
- Minificação CSS: Ligado
- Combinação CSS: Ligado (teste cuidadosamente, pode quebrar alguns temas)
- Gerar critical CSS: Ligado
- Carregamento assíncrono CSS: Ligado
- Minificação JS: Ligado
- Combinação JS: Desligado (causa problemas frequentemente, testé antes dé ativar)
- Adiamento JS: Ligado
- Inline JS após DOM Ready: Ligado
Otimização de imagens no LiteSpeed Cache
O LiteSpeed Cache inclui o seu próprio serviço dé otimização de imagens através do QUIC.cloud:
- Substituição de imagens WebP: Ligado
- Lazy load de imagens: Ligado
- Placeholder responsivo: Ligado
- Imagens do viewport (primeiras N imagens excluídas do lazy load): 2-3
Regras .htaccess do LiteSpeed para cache do navegador
Adicione estas regras ao seu .htaccess para cabeçalhos de caché ao nível do servidor:
# LiteSpeed cache do navegador e compressão
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/avif "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/svg+xml "access plus 1 year"
ExpiresByType text/css "access plus 1 year"
ExpiresByTypé application/javascript "access plus 1 year"
ExpiresByType font/woff2 "access plus 1 year"
ExpiresByType font/woff "access plus 1 year"
</IfModule>
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/json
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE font/woff
</IfModule>
# Cabeçalhos de segurança que também melhoram o desempenho
<IfModule mod_headers.c>
Header set X-Content-Type-Options "nosniff"
Header set Referrer-Policy "strict-origin-when-cross-origin"
Header set Permissions-Policy "interest-cohort=()"
</IfModule>Configuração do crawler do LiteSpeed
O crawler mantém a cache quente visitando páginas antes dos útilizadores reais:
- Crawler: Ligado
- Duração de execução: 200 (segundos)
- Intervalo entre execuções: 600 (segundos)
- Atraso de crawl: 500 (milissegundos)
- Limite de carga do servidor: 1
Defina estes valores de forma conservadora em alojamento partilhado. Num servidor dedicado ou VPS, podé aumentar a duração e reduzir o intervalo.
Medir resultados com o PageSpeed Insights
Otimização sem medição é adivinhação. O Google PageSpeed Insights fornece tanto dados laboratoriais (testes simulados) como dados de campo (métricas reais de útilizadores do Chrome User Experience Report).
O que verificar após a otimização
Executé o PageSpeed Insights nas suas páginas-chave e verifique estes itens:
Auditorias aprovadas (verde):
- “Servir imagens em formatos de nova geração” deve passar sé o WebP/AVIF estiver configurado
- “Codificar imagens eficientemente” deve passar após a compressão
- “Dimensionar imagens corretamente” deve passar se removeu tamanhos não útilizados
- “Eliminar recursos que bloqueiam a renderização” deve passar com critical CSS
Core Web Vitals:
- Objetivo LCP: abaixo de 2,5 segundos
- Objetivo CLS: abaixo de 0,1
- Objetivo INP: abaixo de 200 milissegundos
Usar o Chrome DevTools para verificar a entrega de formatos
Abra o DevTools (F12), vá ao separador Network e filtre por “Img”. Verifiqué a coluna “Type”: deverá ver webp ou avif em vez de jpeg ou png. Sé ainda vê formatos originais, as suas regras de reescrita ou a configuração do plugin precisa dé ajuste.
Orçamento de desempenho do Lighthouse
Configuré um orçamento de desempenho para detetar regressões:
[
{
"resourceSizes": [
{ "resourceType": "image", "budget": 300 },
{ "resourceType": "stylesheet", "budget": 50 },
{ "resourceType": "script", "budget": 200 },
{ "resourceType": "total", "budget": 800 }
]
}
]Os valores estão em kilobytes. Esté orçamento garante qué o peso total da página se mantém abaixo de 800 KB, com imagens limitadas a 300 KB.
Técnicas avançadas para 2026
Fetchpriority para imagens hero
O atributo fetchpriority indica ao navegador quais imagens priorizar duranté o carregamento. Aplique-o à sua imagem LCP:
<img src="hero.webp" alt="Banner hero" width="1200" height="630"
fetchpriority="high" decoding="async">No WordPress, podé adicionar esté atributo com um filtro:
<?php
declare(strict_types=1);
add_filter('wp_get_attachment_image_attributes', function (array $attr, WP_Post $attachment, string $size): array {
if ($size === 'hero-banner' && is_front_page()) {
$attr['fetchpriority'] = 'high';
$attr['decoding'] = 'async';
unset($attr['loading']); // Remover lazy loading do hero
}
return $attr;
}, 10, 3);Content-visibility para secções abaixo da dobra
A propriedade CSS content-visibility permite qué o navegador salté a renderização de secções fora do ecrã até que sejam necessárias:
.below-fold-section {
content-visibility: auto;
contain-intrinsic-size: auto 500px;
}Isto reduz significativamenté o trabalho inicial de renderização em páginas longas com muitas imagens.
Imagens responsivas com art direction
Para imagens que necessitam de cortes diferentes em diferentes breakpoints, usé o elemento <picture> com media queries:
<picture>
<source media="(max-width: 640px)" srcset="hero-mobile.avif" type="image/avif">
<source media="(max-width: 640px)" srcset="hero-mobile.webp" type="image/webp">
<source srcset="hero-desktop.avif" type="image/avif">
<source srcset="hero-desktop.webp" type="image/webp">
<img src="hero-desktop.jpg" alt="Imagem hero" width="1200" height="630">
</picture>Lista de verificação de desempenho
Use está lista de verificação para confirmar qué a sua implementação está completa:
- Plugin dé otimização de imagens instalado e configurado
- Geração WebP ativada para todos os novos uploads
- Geração AVIF ativada (sé o plugin suportar)
- Otimização em massa executada na biblioteca de media existente
- Tamanhos de imagem não útilizados removidos
- Dimensões máximas de upload definidas
- Regras de reescrita WebP/AVIF no .htaccess implementadas
- Extração de critical CSS ativada
- Folhas de estilos não críticas adiadas
- Imagem hero pré-carregada com
<link rel="preload"> - Imagem hero marcada com
fetchpriority="high" - Cache de página do LiteSpeed Caché ativada
- Cache do navegador do LiteSpeed Caché ativada
- Otimização CSS/JS do LiteSpeed Cache configurada
- Crawler configurado e em execução
- Pontuação PageSpeed Insights verificada em 90+
- Entrega WebP/AVIF confirmada no DevTools
Dois casos que mapeiam a pipeline para números
O primeiro caso foi uma loja WooCommerce de eletrónica de consumo num host partilhado português que servia um hero PNG de 200 KB, um carrossel de 1,2 MB de JPEGs não otimizados, e uma folha de estilos de page-builder de cerca de 600 KB em cada página. Os dados de campo mostravam LCP móvel em 4,0 s, FCP em 2,8 s, e a loja perdia conversões de tráfego de campanhas Google na temporada de Natal porque as páginas de produto demoravam demasiado. Convertemos o hero para AVIF (28 KB depois de compressão glossy), adicionámos fetchpriority="high" e um <link rel="preload"> correspondente, regenerámos miniaturas nos tamanhos que o tema realmente usava, e corremos o bulk do ShortPixel sobre o catálogo. O LCP desceu para 1,4 s sem tocar em CSS.
O segundo caso era o oposto: as imagens já eram AVIF, mas o FCP recusava-se a descer abaixo de 2,4 s em mobile. O único culpado bloqueador de renderização era um main.css de 800 KB contendo todos os módulos de page-builder que o site nunca usou. Extraímos critical CSS para a página inicial e três templates de landing com Penthouse, inlinámos 12 KB no head, deferimos o resto com o padrão de troca media="print", e adicionámos font-display: swap às declarações WOFF2. O FCP desceu cerca de 600 ms num perfil Android mid-tier limitado, e o painel WP Rocket parou de assinalar “eliminar recursos bloqueadores de renderização”.
O padrão merece nome explícito: quando o LCP é a métrica que falha, a correção é quase sempre do lado da imagem; quando o FCP falha enquanto o LCP é aceitável, a correção é do lado do CSS. Ferramentas que juntam os dois produzem melhorias vagas; tratá-los como estrangulamentos separados produz melhorias mensuráveis.
O que WP Rocket, FlyingPress e Perfmatters realmente fazem
Estes três plugins não são intercambiáveis, e as páginas de marketing tendem a obscurecer isso. O WP Rocket agrupa cache de página, concatenação e defer de CSS/JS, lazy loading e um hook de integração para o Imagify; a sua extração de critical CSS (RUCSS) corre server-side em SaaSWP e recua graciosamente se a extração falhar. O FlyingPress foca-se em servir fontes localmente, inline critical CSS por template e remoção de CSS não utilizado ao nível do URL em vez do site, que é o melhor modelo para sites com layouts variados. O Perfmatters não faz cache: desativa funcionalidades WordPress que o site não precisa (heartbeat polling, scripts de emoji, embed.js, endpoints REST) e adiciona hints preconnect, prefetch e DNS-prefetch. Os três empilham-se de forma limpa: Perfmatters apara, FlyingPress ou WP Rocket lidam com CSS e cache, um plugin de imagens lida com AVIF.
Se o host é OpenLiteSpeed ou LiteSpeed Enterprise (planos LiteSpeed da Amen.pt e da PTisp), a conta muda. O LiteSpeed Cache comunica com o módulo de cache embutido no servidor e pula o PHP inteiramente em cache hits, o que é mais rápido do que qualquer plugin a correr dentro do PHP pode ser. O trade-off é que o QUIC.cloud lida com critical CSS e conversão de imagens off-site, o que tem implicações próprias em termos de RGPD: subcontratante de tratamento com QUIC.cloud, entrada no registo de atividades, e avaliação de transferência se o tráfego sair da UE.
Para CDNs de imagem com presença portuguesa: a Cloudinary publica subcontratante de tratamento com cláusulas contratuais-tipo, mas o endpoint padrão fica fora da UE; a ImageKit oferece um endpoint de região UE com subcontratante de tratamento, o que reduz o esforço de transferência para país terceiro sob orientação da CNPD.
Resultados da pipeline
Em trabalho recente com clientes, o padrão aterra neste intervalo. Trate os números como envelope aproximado em vez de garantia, já que a condição inicial importa mais do que a intervenção.
| Métrica | Antes | Depois |
|---|---|---|
| Pontuação PageSpeed móvel | 35-55 | 90-98 |
| LCP | 4,5-8 s | 1,2-2,0 s |
| Peso total da página | 3-6 MB | 400-800 KB |
| Número de pedidos | 80-120 | 25-40 |
| TTFB | 800 ms+ | 150-300 ms |
A combinação de formatos de imagem modernos, critical CSS e configuração adequada de cache aborda três estrangulamentos independentes: tamanho de ficheiro, bloqueio de renderização e tempo de resposta do servidor. Nenhum substitui os outros.
Onde o wppoland.com se encaixa
Corremos esta pipeline em sites WordPress e WooCommerce em produção: configuração LiteSpeed ao nível do servidor, extração de critical CSS com limpeza manual via separador Coverage onde o Penthouse falha um seletor, entrega AVIF com negociação de conteúdo, e um trilho de auditoria nos dados de campo do PageSpeed Insights para que as alterações se mantenham sob tráfego real do CrUX. Os preços são individuais e dependem do tamanho da biblioteca de média, da pegada do page-builder e de quanto do trabalho é migração versus otimização no local. Se as pontuações PageSpeed estão a bloquear as posições dos sites, contacte-nos para uma auditoria de desempenho.
