O meu portátil mente

Abro o site, carrega em menos de um segundo, tudo fluido. Abro o mesmo site no telemóvel do cliente, em 4G, com trinta separadores abertos: quatro segundos, imagens a saltar, o botão a aparecer depois de eu já ter desistido. É o mesmo código, o mesmo servidor, a mesma página. A diferença é o dispositivo.

Quase todos os problemas de performance que nos chegam começam aqui: alguém testou no sítio errado. Um MacBook com fibra e cache quente não é uma amostra — é o melhor caso possível. E otimizar para o melhor caso é a forma mais eficiente de não resolver nada.

Porque é que o mesmo site tem tempos diferentes

Quatro variáveis explicam quase tudo:

• Processador. O JavaScript que corre em 40ms no vosso portátil pode levar 300ms num telemóvel de gama média — e há muito telemóvel de gama média a comprar coisas.
• Rede. Fibra com 20ms de latência não se compara a 4G com 120ms e perda de pacotes.
• Cache. A vossa segunda visita é sempre mais rápida. O cliente faz a primeira.
• Estado do dispositivo. Bateria em modo de poupança reduz a frequência do processador. Não é um detalhe: é metade dos utilizadores.

Nenhuma destas variáveis aparece num teste feito no escritório. Todas aparecem nas métricas reais dos utilizadores.

As três métricas que interessam

Desde 2024, o Google avalia três métricas principais — e uma delas já foi substituída, o que muita gente ainda não atualizou nos relatórios:

• LCP (Largest Contentful Paint) — quanto tempo até o maior elemento visível aparecer. É a sensação de «abriu». Bom: abaixo de 2,5s.
• INP (Interaction to Next Paint) — quanto tempo o site demora a reagir a um clique ou toque. Substituiu o FID. Bom: abaixo de 200ms.
• CLS (Cumulative Layout Shift) — o quanto a página «salta» enquanto carrega. Bom: abaixo de 0,1.

Repare no que isto significa: nenhuma destas métricas é o tempo total de carregamento. Um site pode demorar 6 segundos a terminar e sentir-se rápido, se o conteúdo principal aparecer cedo e nada saltar. E pode demorar 2 segundos e sentir-se péssimo, se o botão só responder ao terceiro clique.

Onde o tempo se perde, por ordem de impacto

Depois de auditar dezenas de sites, a lista repete-se quase sempre pela mesma ordem:

• Imagens. Ficheiros de 4 MB servidos a 400px de largura. É o problema número um, e o mais fácil de resolver: redimensionar, converter para WebP ou AVIF, e servir o tamanho certo por breakpoint.
• JavaScript de terceiros. Chat, pixel, gestor de tags, mapa, slider, pop-up de cookies. Cada um é uma conexão a outro servidor, muitas vezes bloqueante. Um site com sete scripts externos tem sete pontos de falha.
• TTFB. O tempo até o servidor responder à primeira byte. Se for acima de 600ms, nada do que fizer no front-end compensa — o problema está na base de dados, no PHP ou na cache.
• Tipos de letra. Quatro famílias, oito pesos, sem font-display: swap. O texto fica invisível enquanto a fonte não chega.
• CSS e JS bloqueantes no topo. Ficheiros que impedem o browser de desenhar seja o que for até estarem todos descarregados.

Medir no sítio certo

Há duas formas de medir, e não são sinónimo:

Dados de campo (CrUX, Search Console, RUM) — o que os utilizadores reais experienciaram, agregado no percentil 75. É a verdade desconfortável: se 25% dos utilizadores têm LCP acima de 4s, o site é lento, mesmo que o vosso teste diga 0,9s.

Dados de laboratório (Lighthouse, PageSpeed) — útil para diagnosticar causas, inútil para avaliar experiência. Um score de 98 em laboratório com um telemóvel de gama baixa a 2s é uma má nota à espera de acontecer.

Regra prática: decida com os dados de campo, investigue com os de laboratório. E teste sempre com limitação de rede e CPU — o Chrome DevTools faz isso numa caixa de seleção.

O que fazer, por esta ordem

Não comece pelo que dá mais pontos no relatório. Comece pelo que reduz tempo percebido:

• 1. Imagens. Formato moderno, dimensões corretas, loading="lazy" em tudo o que está abaixo da dobra — mas nunca na imagem principal, que deve carregar com prioridade.
• 2. TTFB. Cache de página, opcache afinado, consultas lentas identificadas. Sem isto, o resto é cosmética.
• 3. Terceiros. Apague o que não usa. Carregue o resto depois da interação ou em diferido. Um chat que não é usado por 95% dos visitantes não pode custar 300ms a todos.
• 4. Fontes. Duas famílias no máximo, com swap e pré-carregamento do peso que aparece acima da dobra.
• 5. JavaScript. Diferir, dividir, e remover plugins que injetam 200KB para resolver um problema de 5 linhas.

O erro de perseguir o score

O número do Lighthouse é uma média ponderada de auditorias, muitas delas irrelevantes para o negócio. Já vimos sites a subir de 60 para 95 e a converter menos, porque o que se ganhou em pontuação se perdeu em funcionalidade.

O que interessa medir é outra coisa: quantos visitantes abandonam antes de ver o conteúdo, quantos cliques ficam sem resposta, e o que isso custa em receita. A pontuação é um meio; tratá-la como fim é otimizar para o relatório, não para o cliente.

Validar depois do deploy

Uma otimização que não é verificada é uma suposição. Depois de cada alteração:

• Meça o mesmo URL, no mesmo perfil de rede, antes e depois. Sem linha de base, não há prova.
• Confirme que a página principal continua a responder 200 — e que a monitorização continua ativa. Uma otimização que parte o site é pior do que a lentidão. É por isso que monitorizamos os servidores e não apenas os tempos.
• Espere 28 dias antes de concluir algo com dados de campo: o CrUX agrega por janelas longas, e a melhoria demora a aparecer.

O mínimo aceitável

Se quiser uma fasquia concreta para 2026: LCP abaixo de 2,5s no percentil 75 em telemóvel, INP abaixo de 200ms, CLS abaixo de 0,1, e TTFB abaixo de 600ms. Não é perfeição — é o limiar a partir do qual o site deixa de ser a razão pela qual as pessoas desistem.

E há um teste que não precisa de ferramenta nenhuma: peça a alguém com um telemóvel de gama média, numa rede móvel, para comprar ou pedir orçamento. Cronometre. Se desistir antes do fim, o resto é conversa. Este tema liga-se ao que já escrevemos sobre configurações de servidor que protegem o WordPress: performance e segurança começam no mesmo sítio — no que o servidor faz antes de entregar a primeira byte.

Em resumo

• O vosso portátil não é uma amostra. Meça em telemóvel, com rede limitada.
• LCP, INP e CLS — não o tempo total, e já não o FID.
• Imagens e terceiros explicam a maior parte do problema.
• Dados de campo decidem; dados de laboratório diagnosticam.
• Não persiga o score. Persiga o abandono.