Monitorização de desempenho para WordPress enterprise

A monitorização de desempenho para WordPress enterprise responde a três perguntas: o que os visitantes reais experienciam, se o próximo lançamento piorou alguma coisa e que camada da stack é a responsável. Cada pergunta precisa de um instrumento diferente. Os dados de campo de utilizadores reais (RUM) respondem à primeira, os testes sintéticos no pipeline de deployment à segunda, e as ferramentas do lado do servidor (Query Monitor, um agente APM, traces de OpenTelemetry, o slow query log do MySQL, as estatísticas do Redis) à terceira.

Um checkout lento ou um Interaction to Next Paint (INP) a subir no site de um mercado custa receita e visibilidade nos motores de pesquisa muito antes de alguém abrir um pedido de suporte. As instalações modernas de WordPress repartem-se entre uma CDN, workers PHP, uma base de dados, uma cache de objetos e, por vezes, um frontend separado, por isso “o servidor está a funcionar?” deixou há anos de ser uma pergunta útil. Este guia descreve uma stack de monitorização para esse tipo de instalação, com cada limiar e cada configuração retirados da documentação do fornecedor ou da norma referida no texto.

#Qual a diferença entre RUM e monitorização sintética no WordPress

Para ter uma visão completa do seu ecossistema, precisa de monitorizar a partir de duas perspetivas. Não competem entre si: cada uma vê algo que a outra não consegue ver.

#Real user monitoring (RUM)

O RUM regista a experiência de cada visitante, no seu dispositivo e na sua rede.

• Fragmentação de dispositivos: como o site se comporta num iPhone novo em comparação com um Android de gama média numa ligação móvel congestionada.
• Interatividade: cada interação que alimenta o INP, para encontrar os elementos concretos da interface que os utilizadores sentem como lentos.
• Desempenho Edge: a latência real entre um visitante e a localização CDN mais próxima, por país.

Uma média de todo o site esconde quase tudo o que importa. Divida os dados RUM por classe de dispositivo, tipo de ligação, país, template (artigo, arquivo, produto, carrinho) e primeira visita versus visita recorrente. Reporte o percentil 75, porque é o valor com que a Google avalia os Core Web Vitals. O artigo do web.dev sobre Web Vitals formula a regra de medição assim:

“o percentil 75 dos carregamentos de página, segmentado entre dispositivos móveis e de secretária”

Fonte: Web Vitals, web.dev (tradução própria)

#Monitorização sintética e testes de uptime

Os testes sintéticos carregam as suas páginas com browsers guiados por script, em condições controladas.

• Integração CI/CD: uma execução do Lighthouse sempre que um programador envia uma alteração ao código do tema ou dos plugins WordPress.
• Testes de uptime e de percursos: execuções por script dos percursos que geram receita (“adicionar ao carrinho”, “enviar formulário de contacto”), a partir das regiões onde vende, com uma cadência fixa.

Os testes sintéticos não veem utilizadores reais, por isso nunca substituem o RUM. A sua vantagem é que as condições do teste se mantêm constantes. Quando um resultado sintético piora, a causa está no código ou na infraestrutura, e não em quem visitou o site nesse dia.

#Como recolher Core Web Vitals com a biblioteca web-vitals

Não precisa de um script pesado de terceiros para começar. A biblioteca web-vitals da Google descreve-se como uma biblioteca minúscula (cerca de 3K com brotli) e modular e mede cada métrica da mesma forma que as ferramentas da própria Google a reportam. Lê as APIs de desempenho do browser na página e entrega cada resultado a um callback; depois, navigator.sendBeacon envia o valor para o seu coletor, e o README da biblioteca indica que este método funciona mesmo enquanto a página está a ser descarregada.

import { onCLS, onINP, onLCP } from 'web-vitals';

function sendToTelemetry(metric) {
  const body = JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating,
    delta: metric.delta,
    id: metric.id,
    page: window.location.pathname
  });

  if (navigator.sendBeacon) {
    navigator.sendBeacon('/api/telemetry/vitals', body);
  } else {
    fetch('/api/telemetry/vitals', { body, method: 'POST', keepalive: true });
  }
}

onCLS(sendToTelemetry);
onINP(sendToTelemetry);
onLCP(sendToTelemetry);

O excerto envia apenas pathname, sem a query string. Essa escolha é importante para a privacidade, como se explica mais abaixo.

A build de atribuição da mesma biblioteca transforma um mau número num pedido de trabalho que alguém consegue resolver. Para o LCP indica o seletor do elemento LCP (target), o URL da imagem quando existe, o tempo até ao primeiro byte, o atraso e a duração do carregamento do recurso e o atraso de renderização do elemento. Para o INP indica o elemento com que o utilizador interagiu, o atraso de entrada, a duração do processamento e o atraso de apresentação, além de longAnimationFrameEntries, as entradas Long Animation Frame que se sobrepuseram à interação nos browsers que suportam essa API. “O INP está mau nas páginas de produto” passa a ser “o seletor de variantes passa a maior parte do tempo num script concreto”.

#Porque é que o Search Console e o PageSpeed Insights não chegam

O Search Console e o PageSpeed Insights mostram dados de campo do Chrome UX Report (CrUX). A documentação da API do CrUX descreve esses dados como uma média móvel de 28 dias de métricas agregadas, atualizada diariamente por volta das 04:00 UTC. Uma regressão lançada esta manhã move essa média devagar, por isso só dá por ela dias ou semanas depois de começar.

A cobertura é o segundo limite. Segundo a metodologia do CrUX, uma página ou origem tem de ser publicamente detetável e suficientemente popular para entrar no conjunto de dados, e só contribuem os utilizadores do Chrome que deram o seu consentimento, em computador e Android. O Chrome em iOS, as apps com Android WebView e outros browsers Chromium, como o Edge, não contribuem com dados. Um portal B2B atrás de um login, o site de um mercado com pouco tráfego ou um público sobretudo em iPhone podem mostrar poucos ou nenhuns dados do CrUX.

O CrUX continua a ser a referência certa para SEO, porque é o conjunto de dados a partir do qual a Google reporta os Core Web Vitals. Para reagir no próprio dia do deployment, precisa de um fluxo RUM próprio, sem janela de média.

#Como fazer monitorização RUM em conformidade com o RGPD

Cada beacon de RUM é um pedido do browser do visitante para o seu coletor. Se incluir um endereço IP, um ID de sessão ou um URL completo com parâmetros (pense num endereço de email num link de newsletter), está a tratar dados pessoais sujeitos ao RGPD, e a autoridade de controlo em Portugal é a CNPD. Armazenar ou aceder a informação no equipamento terminal do utilizador (cookies, localStorage) exige consentimento prévio, assente em informação clara e completa, nos termos do artigo 5.º da Lei n.º 41/2004, na redação dada pela Lei n.º 46/2012. As exceções abrangem o armazenamento técnico com a única finalidade de transmitir uma comunicação ou estritamente necessário a um serviço expressamente pedido pelo utilizador.

Mantenha o beacon enxuto:

• Recolha a métrica, não a pessoa: nome da métrica, valor, tipo de template, país, classe de dispositivo. Não precisa de um endereço IP para calcular o percentil 75 do LCP.
• Retire a query string antes do envio e guarde apenas o caminho.
• Não crie um cookie só para ligar visitas entre si. Perde a distinção entre sessões novas e recorrentes, e a telemetria deixa de depender do consentimento para o armazenamento no dispositivo.
• Configure o coletor para não guardar endereços IP, ou para os truncar à chegada.
• Se o seu fornecedor guarda dados nos EUA, verifique se existe uma região de dados na UE e se está assinado um acordo de subcontratação.

Isto não é aconselhamento jurídico; o seu encarregado de proteção de dados traça a linha para a sua instalação.

#Como bloquear lançamentos lentos com o Lighthouse CI

O Lighthouse CI executa o Lighthouse contra URLs de preview ou staging no seu pipeline e compara os resultados com as asserções que definir. Por omissão, lhci collect executa o Lighthouse três vezes por URL (numberOfRuns), o que suaviza execuções isoladas com ruído. Cada asserção tem um nível: warn mostra o resultado sem falhar, enquanto error faz o comando terminar com um código diferente de zero, e é isso que faz falhar o build.

O preset lighthouse:recommended é um ponto de partida razoável. Segundo a documentação do Lighthouse CI, verifica se cada auditoria fora do desempenho obteve a pontuação máxima e avisa quando os valores das métricas descem abaixo de uma pontuação de 90. As auditorias que não se adequam ao projeto desligam-se uma a uma. Acrescente limites explícitos para aquilo que a sua equipa controla diretamente, como o peso total de JavaScript e CSS nos templates que geram receita.

O Lighthouse corre em laboratório, por isso os seus números não coincidem com o CrUX. Use-o para comparar um build com o anterior nas mesmas condições, não para prever valores de campo.

#Testes de regressão visual com Playwright

Desempenho também é estabilidade. Uma atualização de plugin que, de repente, desloca o layout em telemóveis prejudica ao mesmo tempo o CLS e as conversões.

O Playwright inclui esta verificação como a asserção toHaveScreenshot. Na primeira execução gera capturas de ecrã de referência; as execuções seguintes comparam-se com elas. Depois de uma alteração de design intencional, a referência é regenerada com npx playwright test --update-snapshots. A opção maxDiffPixels define quantos píxeis podem diferir antes de o teste falhar. A documentação do Playwright avisa também que a renderização varia com o sistema operativo, a versão do browser, as definições e o hardware, por isso gere as referências no mesmo ambiente onde os testes correm, normalmente o contentor de CI, e não no portátil de um programador.

A configuração prática é modesta: capturas dos templates que geram receita (página inicial, categoria, produto, carrinho, checkout) em três larguras de viewport. As diferenças pequenas dentro da tolerância passam; as maiores esperam por uma decisão humana no pull request.

#Como usar o Query Monitor e a Saúde do site para diagnosticar o WordPress

O Query Monitor, de John Blackbourn, é o plugin de diagnóstico de referência para um único pedido. Em cada carregamento de página lista as consultas à base de dados e assinala as lentas, duplicadas ou com erro, mostra os erros de PHP com o componente responsável e a pilha de chamadas, e lista os pedidos da HTTP API com o código de resposta, o componente responsável e o tempo gasto. Cobre também hooks e ações, a hierarquia de templates, os scripts e estilos em fila e as atualizações de transients. Por omissão, a sua saída só é visível para Administradores em sites individuais e para Super Administradores em Multisite; um cookie de autenticação pode alargar o acesso a outros utilizadores.

Usamos o Query Monitor em staging para diagnóstico, não como monitorização contínua de produção: explica um pedido em profundidade, enquanto um agente APM agrega todos.

A Saúde do site (Ferramentas, Saúde do site) acrescenta uma camada gratuita de alerta precoce. O separador Estado agrupa as conclusões em problemas críticos, melhorias recomendadas e testes aprovados. Desde o WordPress 6.6, a Saúde do site reporta um problema crítico quando o tamanho total das opções com autoload ultrapassa 800 KB, como descreve a nota de desenvolvimento do WordPress 6.6 sobre opções com autoload. A mesma versão deixa, por omissão, de carregar automaticamente opções individuais com mais de 150 000 bytes, um limite separado controlado pelo filtro wp_max_autoloaded_option_size. Dados de autoload inchados são carregados em cada pedido, por isso vale a pena ler esta verificação depois de cada auditoria de plugins.

#Como usar APM no servidor WordPress com o agente PHP da New Relic

Um agente APM regista cada pedido em produção e mostra para onde foi o tempo. O suporte ao WordPress do agente PHP da New Relic é um bom exemplo de instrumentação que conhece o WordPress:

• newrelic.framework.wordpress.hooks está ativo por omissão desde a versão 5.3 do agente; defini-lo como false desativa as métricas específicas do WordPress.
• As métricas de hooks mostram o tempo gasto dentro de cada hook do WordPress, medido a partir de apply_filters, apply_filters_ref_array, do_action e do_action_ref_array.
• As métricas de plugins e temas mostram o tempo gasto dentro de cada plugin e tema, o que responde a “que plugin tornou esta página lenta” sem adivinhar.
• Desde a versão 10.16 do agente, newrelic.framework.wordpress.hooks.options controla quanto é registado. No modo threshold, o agente regista apenas os hooks mais lentos do que newrelic.framework.wordpress.hooks.threshold, que por omissão é 1 ms. Isso reduz a sobrecarga e o volume de dados em sites com muito tráfego.

A Datadog, a Tideways e a Blackfire cobrem terreno semelhante com agentes próprios. A escolha depende normalmente do que o resto da organização já usa, porque uma única ferramenta para todos os serviços vale mais do que uma ferramenta melhor que mais ninguém consulta.

#Como fazer tracing do WordPress com OpenTelemetry PHP

O OpenTelemetry é a opção neutra em relação ao fornecedor: os mesmos traces podem ir para o Grafana Tempo, o Jaeger ou um backend comercial. A documentação da autoinstrumentação PHP exige PHP 8.0 ou superior e a extensão instalada com pecl install opentelemetry. A configuração faz-se com variáveis de ambiente:

OTEL_PHP_AUTOLOAD_ENABLED=true
OTEL_SERVICE_NAME=wordpress-shop
OTEL_TRACES_EXPORTER=otlp
OTEL_EXPORTER_OTLP_ENDPOINT=http://collector:4318

Para o WordPress existe um pacote dedicado, open-telemetry/opentelemetry-auto-wordpress, instalado com composer require open-telemetry/opentelemetry-auto-wordpress. O núcleo do WordPress não usa Composer, por isso o README do pacote mostra como carregar o autoloader do Composer antes de o WordPress arrancar, por exemplo com php_value auto_prepend_file /var/www/vendor/autoload.php no Apache. A instrumentação pode voltar a ser desligada com OTEL_PHP_DISABLED_INSTRUMENTATIONS=wordpress.

Para perfis pontuais a partir do terminal, o comando wp profile do WP-CLI não precisa de nenhum plugin. Instala-se com wp package install wp-cli/profile-command; depois, wp profile stage mede as fases de bootstrap, consulta principal e template, wp profile hook as ações e filtros, e wp profile queries as consultas à base de dados. Funciona em servidores onde não pode instalar plugins. O Xdebug dá o perfil mais detalhado de todos, e a sua sobrecarga mantém-no nas máquinas locais.

#Que métricas de base de dados e de cache de objetos monitorizar

O slow query log do MySQL está desativado por omissão. Regista as instruções que demoram mais de long_query_time segundos e examinam pelo menos min_examined_row_limit linhas. O valor por omissão de long_query_time é 10 segundos, demasiado permissivo para um pedido web; o mínimo é 0 e o valor aceita resolução de microssegundos. Cada entrada inclui Query_time, Lock_time, Rows_sent e Rows_examined, e uma grande diferença entre linhas examinadas e linhas enviadas é o sinal clássico de um índice em falta, tipicamente em wp_postmeta por trás dos filtros de produtos. log_queries_not_using_indexes acrescenta ao log as consultas sem índice, e log_throttle_queries_not_using_indexes limita a velocidade a que são escritas. mysqldumpslow resume o ficheiro de log. A forma de corrigir o que o log encontra está no nosso guia de otimização da base de dados WordPress.

Para uma cache de objetos Redis, o comando INFO fornece os contadores em bruto:

• keyspace_hits e keyspace_misses: pesquisas de chaves bem-sucedidas e falhadas. A taxa de acertos é o número de acertos a dividir pela soma de acertos e falhas.
• evicted_keys: chaves removidas pelo limite maxmemory. Se o número sobe, a cache é pequena demais para o conjunto de trabalho.
• mem_fragmentation_ratio: a relação entre used_memory_rss e used_memory.

Não existe uma taxa de acertos “boa” universal, porque depende da parte do site que pode ser colocada em cache. Registe a sua própria linha de base depois de um deployment limpo e crie um alerta para uma queda sustentada: normalmente significa que um plugin novo contorna a cache, que uma configuração mudou ou que o tráfego passou para páginas sem cache.

#Como monitorizar WordPress headless

Quando o WordPress é apenas a API de conteúdo e o frontend corre em Astro ou Next.js, há dois sistemas a vigiar. No backend: o tempo de resposta e a taxa de erros 5xx dos endpoints da REST API ou do WPGraphQL. No frontend: o tempo de build, o tempo de regeneração de páginas e o custo de hidratação no cliente.

Um trace distribuído liga os dois. A recomendação W3C Trace Context define os cabeçalhos traceparent e tracestate, que transportam um ID de trace desde o frontend até à API do WordPress, e o OpenTelemetry suporta-os na propagação de contexto. Um mesmo pedido fica então visível através da CDN, do frontend, da API do WordPress, do MySQL e do Redis. Sem isso, cada equipa vê apenas o seu troço e cada pedido lento parece culpa da camada vizinha.

#Deteção de anomalias no desempenho web

Limiares fixos como “avisar-me se o LCP passar de 2,5 s” disparam tarde demais ou geram falsos alarmes nos picos de tráfego. As linhas de base dinâmicas aprendem o que é normal para cada hora e dia da semana e assinalam desvios antes de se atingir um limite rígido. A maioria das plataformas de APM e observabilidade oferece isto; a configuração importa menos do que o contexto à sua volta.

Uma anomalia só é útil quando se vê o que mudou ao lado dela. Marque deployments, atualizações de plugins e lançamentos de campanhas na mesma linha temporal das métricas: o Grafana faz isto com anotações, a New Relic com marcadores de deployment. Um pico de TTFB mesmo ao lado de uma atualização de plugin encerra a investigação antes de ela começar.

#Como definir um orçamento de desempenho para Core Web Vitals

Um orçamento é um conjunto de limites máximos em que ultrapassar um deles tem uma consequência acordada. Os limiares “bons” da Google no percentil 75 são o mínimo: LCP até 2,5 s, INP até 200 ms, CLS até 0,1, segundo o web.dev. As equipas enterprise costumam fixar objetivos mais exigentes por projeto, além de limites ao JavaScript e CSS enviados, verificados na barreira do Lighthouse CI.

Um orçamento sem responsável dilui-se. Nomeie uma pessoa que reveja a tendência todas as semanas, decida se um limiar ainda faz sentido e possa travar um lançamento. Encaminhe também os alertas por gravidade: um checkout avariado aciona o engenheiro de serviço, uma subida lenta do TTFB vai para um canal da equipa e os pequenos desvios esperam pelo relatório semanal. Se cada alerta acorda alguém, ao fim de um mês ninguém os lê.

#Como a velocidade da página afeta a taxa de conversão

A pergunta útil para a gestão não é “quantos milissegundos”, mas “quanto nos custa uma página mais lenta”. Responda com os seus próprios dados, e não com uma percentagem tirada do caso de estudo de outra empresa. Envie os valores RUM para o mesmo repositório de analítica dos seus eventos de conversão, agrupe as sessões por faixa de LCP ou INP e compare a conversão de cada grupo. O resultado é específico do seu público e do seu checkout, e é a versão que um diretor financeiro aceita quando pede um sprint de desempenho.

#O que inclui um serviço de monitorização WordPress

Na WPPoland, o trabalho de monitorização abrange três coisas.

1. Desenho de monitorização full-stack: RUM, testes sintéticos e APM ou traces de OpenTelemetry ligados numa única vista, para que um incidente seja visível desde o browser até à consulta SQL.
2. Prevenção de regressões: as barreiras de Lighthouse CI e Playwright que travam templates lentos ou avariados antes de chegarem à produção.
3. Relatórios com os quais se pode agir: métricas traduzidas nas decisões que a gestão tem de tomar, com um responsável para cada orçamento.

As ferramentas e a implementação são orçamentadas individualmente, porque o custo depende do número de sites, do volume de tráfego e do fornecedor escolhido.

#Por onde começar a monitorização de desempenho WordPress

Comece pequeno e por ordem. Primeiro, dados de campo de utilizadores reais com a biblioteca web-vitals, porque mostram o que os visitantes realmente experienciam, e o Query Monitor em staging. A seguir, Lighthouse CI e verificações Playwright no pipeline, mais testes sintéticos de percursos a partir das regiões onde vende. Depois, APM ou traces de OpenTelemetry e o slow query log nos endpoints que as duas primeiras camadas apontam. Cada camada responde a uma pergunta levantada pela anterior, e um alerta sem responsável é ruído.

Quando a monitorização mostra para onde vai o tempo, as correções vêm a seguir. O nosso guia de otimização completa do WordPress cobre o trabalho de servidor, cache e frontend, e o guia de performance WordPress e Core Web Vitals dá uma visão mais ampla do desempenho e dos Core Web Vitals. Para uma revisão prática do seu site, veja como acelerar um site baseado em WordPress.