Módulo 6 · 6.1

O que torna uma site lenta, e como se mede?

Módulo 6: Velocidade · Tempo de leitura: 9 minutos

Objetivo de aprendizagem: Após esta lição, saberá medir onde se perde o tempo e reconhecer a diferença entre lentidão no servidor e lentidão no navegador.

Conceitos-chave: TTFB, Core Web Vitals (LCP, INP, CLS), dados de laboratório, dados de campo, PageSpeed Insights, separador de rede, compressão, scripts externos, limites do pacote de alojamento, 503

Primeiro medir, só depois ajustar

"O site está lento" pode ter dez causas diferentes. Quem, sem medir, instala ao mesmo tempo um plugin de cache, um plugin de otimização de imagens e um pacote maior, depois não sabe o que ajudou e fica ainda com três coisas para gerir. Por isso, comece sempre por três perguntas (as mesmas que constam no manual do seu fornecedor de alojamento):

Está tudo lento, ou só o painel de administração? Um painel lento com uma parte visível rápida aponta para plugins que fazem muito trabalho no painel, ou para bots a atacar a página de início de sessão.
É sempre, ou apenas em determinados momentos? Só em horas de pico ou quando corre uma tarefa agendada: nesse caso, o seu pacote está a atingir os seus limites.
Acontece a toda a gente, ou só a si? Experimente no seu telemóvel via 4G ou 5G, ou peça a outra pessoa para testar. Se for lento apenas para si, o problema está na sua ligação ou VPN.

Duas metades: servidor e navegador

O tempo que um visitante espera é composto por duas partes (lição 1.2):

O servidor gera o HTML: servidor web, PHP, plugins, base de dados. Isto vê-se como TTFB (time to first byte), o tempo até ao primeiro byte da resposta. O web.dev indica como regra geral que a maioria dos sites deve procurar um TTFB de 0,8 segundos ou menos.
O navegador lê esse HTML e depois obtém tudo o que lá está indicado: folhas de estilo, scripts, tipos de letra, imagens, vídeo, códigos de análise, widgets de chat. Só quando o suficiente disso estiver carregado é que o visitante vê algo.

Um TTFB elevado resolve-se do lado do servidor: cache (lição 6.2), menos plugins ou plugins mais leves, uma versão de PHP mais recente, uma base de dados organizada (lição 6.3) ou mais capacidade de processamento. Um TTFB baixo com uma página ainda assim lenta aponta para o lado do navegador: imagens demasiado grandes, demasiados scripts, elementos externos.

Core Web Vitals

O Google mede a experiência dos visitantes com três indicadores, os Core Web Vitals:

Medição	O que mede	Bom quando
LCP (Largest Contentful Paint)	Quão rapidamente o maior elemento de conteúdo (geralmente a imagem grande ou o título) fica visível	2,5 segundos ou menos
INP (Interaction to Next Paint)	Quão rapidamente a página reage quando clica, toca ou escreve	200 milissegundos ou menos
CLS (Cumulative Layout Shift)	Quanto a página se desloca durante o carregamento	0,1 ou menos

O INP substituiu em março de 2024 a métrica mais antiga FID. O Google utiliza estes indicadores, entre outras coisas, na classificação dos resultados de pesquisa, mas a principal razão para os melhorar é simples: os visitantes desistem perante uma página lenta ou que se desloca.

Dados de laboratório e dados de campo

Existem dois tipos de medições, que dão números diferentes:

Dados de laboratório: um teste num único momento, a partir de um único local, com um telemóvel e uma ligação simulados. Útil para comparar (antes e depois de uma alteração), mas não é um visitante real.
Dados de campo: medições junto de visitantes reais que utilizam o Chrome, ao longo dos últimos 28 dias. É isto que os visitantes realmente experienciam. Sites pequenos têm, muitas vezes, visitantes insuficientes para gerar dados de campo.

O PageSpeed Insights (pagespeed.web.dev) apresenta ambos: no topo os dados de campo (quando existem), e abaixo um teste de laboratório com uma pontuação e recomendações concretas. Não olhe apenas para a pontuação de 0 a 100. Observe os componentes: o LCP está mau porque o servidor é lento (TTFB) ou porque a imagem grande tem 3 MB?

Teste sempre várias vezes (os valores variam) e teste também uma página comum, não apenas a página inicial.

Observar diretamente com o navegador

As ferramentas de desenvolvimento do seu navegador (F12) mostram o que realmente acontece:

Separador Rede: atualize a página com a cache desativada (opção "Desativar cache"). Verá cada ficheiro carregado, o seu tamanho e o tempo que demorou. Ordene por tamanho: os ficheiros maiores são frequentemente imagens. Ordene por domínio: quanto vem de terceiros (tipos de letra, códigos de análise, vídeos)?
O primeiro pedido (o próprio HTML): clique nele, separador Tempo (Timing). "A aguardar resposta do servidor" é o TTFB.
Cabeçalhos desse primeiro pedido: há compressão (content-encoding: br ou gzip), e veio a página de uma cache (lição 6.2)?

Os culpados habituais

Na prática, a lentidão no WordPress deve-se geralmente a um destes fatores:

Ausência de cache de páginas: cada página é gerada novamente a cada visita (lição 6.2).
Plugins em excesso ou pesados, sobretudo plugins que, em cada pedido, chamam serviços externos ou executam consultas pesadas (lição 5.3).
Imagens grandes: uma fotografia de 5 MB tirada de um telemóvel colocada na página inicial (lições 4.4 e 6.3).
Um tema pesado ou um criador de páginas que carrega muitos scripts e folhas de estilo em cada página (lição 5.1).
Elementos externos: tipos de letra, vídeos, widgets de chat, códigos de análise, botões de redes sociais de terceiros. Cada um é uma ligação a outro servidor que pode ser lento.
Uma versão antiga de PHP (lição 8.4).
Uma base de dados desarrumada: milhares de revisões, spam, tabelas de registos de plugins (lição 6.3).
Bots: crawlers, crawlers de IA e tentativas de início de sessão ocupam o seu pacote (lição 7.3).
O pacote está a atingir os seus limites: capacidade de processamento (CPU), processos ou memória insuficientes para o tráfego.

Os limites do seu pacote

No alojamento partilhado, cada pacote recebe uma parte fixa do servidor: capacidade de processamento, memória, velocidade do disco e um número de processos simultâneos. Se o seu site utilizar mais do que isso, é abrandado, ou os visitantes recebem um erro 503 (Service Unavailable, em alguns fornecedores de alojamento "Resource Limit Is Reached"). No DirectAdmin com CloudLinux vê isto em Resource Usage (com "faults" se o seu site foi abrandado) e com X-Ray vê, por página, que plugin ou consulta consome o tempo. Outros fornecedores de alojamento têm resumos semelhantes, por vezes apenas mediante pedido.

Um pacote maior ajuda se o seu site realmente precisar de mais (uma loja online com muito movimento). Não resolve um site mal configurado: o problema volta mais tarde. Procure primeiro a causa.

Resumo

Meça primeiro: tudo ou só o painel de administração, sempre ou às vezes, toda a gente ou só você.
O TTFB é o lado do servidor (procure 0,8 segundos ou menos); o resto é o que o navegador carrega.
Core Web Vitals: LCP (2,5 s), INP (200 ms) e CLS (0,1); o INP substituiu o FID em 2024.
O PageSpeed Insights mostra dados de campo e dados de laboratório; o separador de rede mostra o que realmente está a carregar.
A maior parte da lentidão deve-se à ausência de cache, plugins pesados, imagens grandes e elementos externos; um pacote maior é apenas o último passo.

Questionário

Exercício

Exercício A6.1: Meça o seu TTFB e a compressão. Introduza o endereço do seu site e, se desejar, uma página comum (por exemplo, a sua página de contacto). O programa pede cada página três vezes sem cookies e indica o TTFB médio, o tamanho do HTML e se o servidor envia o HTML comprimido (content-encoding gzip ou br). Compare o resultado com um teste no PageSpeed Insights e anote o que lhe chama a atenção.

Leitura adicional

Estes artigos descrevem os passos nos painéis da WebOké; noutros painéis funcionam de forma semelhante.

Cookies na WebOké

Definições de cookies

Necessários

Marketing