Melhorar as Core Web Vitals: a ordem que realmente ajuda

Ativar um plugin de cache é o primeiro passo e, muitas vezes, o único que se dá. Depois disso, o valor fica em «a precisar de melhorias» e não sai daí. A razão: as três métricas medem três coisas diferentes, e o cache só ajuda a sério numa delas.

Os três valores, numa frase cada

Daí resulta a ordem: primeiro as imagens, depois os scripts, depois o layout. O cache atua sobretudo no tempo de servidor — ou seja, numa parte do LCP, e quase nada no INP.

Passo 1: a maior imagem

Na maioria das páginas, a imagem hero é a candidata a LCP. Três coisas ajudam de imediato, por esta ordem:

1. Reduzir para o tamanho realmente necessário — uma fotografia com 4000 píxeis de largura numa área com 1200 píxeis de largura é a causa isolada mais frequente.
2. Converter para um formato moderno (WebP ou AVIF), com alternativa para browsers antigos.
3. NÃO usar lazy-load. A imagem lá no topo deve ser carregada de imediato — aqui, o lazy-load piora o valor em vez de o melhorar.

Verifica onde é feita a conversão. Alguns plugins enviam as tuas imagens para um serviço do fabricante. Quem não quiser isso precisa de uma ferramenta que converta localmente — a primeira passagem demora mais, mas nada sai de casa.

Passo 2: o JavaScript

O INP é o valor em que o cache não ajuda. Mede quanto tempo o browser demora a reagir a um clique — e o que o bloqueia são scripts que estão a trabalhar exatamente nesse momento.

A alavanca mais eficaz é eliminar: um slider em que ninguém mexe; uma janela de chat em todas as páginas; três famílias de tipos de letra, das quais duas passam despercebidas. Só depois compensam o defer, a concatenação e o adiamento até à primeira interação.

Passo 3: acabar com os saltos

• Cada imagem precisa de width e height no markup — assim o browser reserva o espaço
• Colocar os conteúdos incorporados num contentor com altura fixa
• Servir os tipos de letra localmente e controlá-los com font-display, em vez de os carregar mais tarde a partir do exterior
• Integrar banners de cookies e barras de aviso de forma a sobreporem-se ao conteúdo, em vez de o empurrarem

Só depois: cache, Minify, preload

Um cache de páginas poupa a geração da página — o que é muito se o servidor for lento, e pouco se for rápido. O Minify poupa bytes e é a causa mais frequente de páginas estragadas depois de uma otimização. O preload é uma ordem, não um pedido: demasiados preloads afastam precisamente o que é preciso primeiro.

Ativa as opções de Minify uma a uma e verifica de cada vez uma página com formulário, o carrinho e uma página com vídeo. Quem ativa tudo de uma vez anda, em caso de erro, à procura entre dez interruptores.

Medir corretamente

Há duas medições que convém não confundir. Um teste de laboratório mede em condições fixas e é bom para comparar o antes e o depois. Os dados de campo vêm de visitantes reais, com dispositivos e ligações reais — são eles que decidem como o Google classifica a página.

Por isso: mede sempre nas mesmas condições, três vezes em vez de uma, e os dados de campo precisam de semanas até mostrarem uma alteração. Quem vai ver ao fim de uma hora e não nota nada não otimizou de menos — foi ver cedo demais.

Quando o plugin já não ajuda

Há um limite a partir do qual nenhum plugin de cache consegue fazer mais: um construtor de páginas sobrecarregado com trinta scripts, um fornecedor de alojamento com uma carga de base elevada, um tema que carrega tudo em todas as páginas. Se a resposta do servidor já é lenta sem conteúdo, o problema não está no plugin.

Perguntas frequentes