Como o WP Footprint mede.

Esta página documenta exatamente o que é medido, como é agregado e como a nota A a E é calculada. O método é público: pode criticá-lo, verificá-lo, refazer o cálculo por si próprio e propor melhorias.

Metodologia em vigor: v4.1. Versionada a cada evolução — o histórico completo vive no código fonte.

Medição diferencial: baseline e depois desativação

O WP Footprint mede uma página várias vezes com todos os plugins ativos (a baseline). Em seguida, para cada plugin e para o tema ativo, repete a mesma página depois de o desativar temporariamente via um MU-loader, e mede de novo.

O impacto próprio de um componente é a diferença: delta = mediana(baseline) − mediana(baseline sem o componente). Esta abordagem por diferença neutraliza o efeito do servidor, do tema e dos outros plugins — é o que torna as comparações entre sites legítimas, sem ter de instrumentar o código PHP em profundidade.

Várias passagens, mediana, intervalo de confiança

Para absorver o ruído natural de um servidor web (cache, GC, latência DB), cada medição é repetida: até 5 passagens para a baseline e até 3 passagens por componente desativado. O plugin pode parar antes — a partir de 3 passagens baseline ou 2 passagens componente — quando a amostra já está apertada (dispersão abaixo de máx(50 ms; 10 % da mediana)): nenhuma precisão perdida, apenas nenhuma passagem inútil. Os valores aberrantes são eliminados por filtro Tukey k=1.5 sobre o intervalo interquartil, depois conservamos a mediana das passagens restantes (a mediana resiste aos outliers, ao contrário da média).

Uma semilargura de intervalo de confiança a 95 % é calculada via a lei de Student t(0,975, n−1) — não por aproximação gaussiana, que subestimaria a incerteza em pequenas amostras. Um delta indistinguível do ruído não é contabilizado na pontuação pública.

Medição do piso do servidor (host-floor)

Em cada scan o plugin executa também 3 passagens sintéticas em que o WordPress é iniciado sem qualquer plugin ativo e com um tema por defeito. O pedido é curto-circuitado cedo (ação init prioridade 1) e devolve um body mínimo — sem routing, sem lookup de post, sem renderização de template. O que capturamos é o tempo puro de arranque WP+servidor nesta máquina.

Esta medição é independente do URL analisado e reproduzível. Servirá para normalizar as pontuações por alojamento: o mesmo delta de +90 ms significa coisas muito diferentes num piso de 80 ms (+112 % de overhead) face a um piso de 250 ms (+36 %). Por agora os dados são recolhidos e arquivados; a ponderação chegará numa revisão posterior do cálculo.

Limites de isolamento: plugins não mensuráveis

Alguns plugins não podem ser desativados em segurança: a sua API é invocada diretamente (ao nível PHP) pelo tema ou por outros plugins. Desativá-los faria com que o pedido fosse abortado por erro fatal, impossibilitando qualquer medição diferencial. Quando o scanner deteta este caso (fatal na primeira passagem), interrompe as novas tentativas, marca o componente como não mensurável e não o envia para o Pulse. Os restantes componentes são medidos normalmente.

Para os plugins populares cuja API é amplamente utilizada pelos temas (ACF, Polylang, Yoast, Rank Math, Meta Box, Pods, WPML, The Events Calendar, Gravity Forms…), o MU-loader carrega stubs de compatibilidade durante a passagem: as funções do plugin permanecem definidas e devolvem valores neutros, para que a página seja renderizada sem erros e o custo próprio do plugin continue a ser medido corretamente. A lista dos plugins cobertos é exposta em /api/v1/methodology em pipeline.isolation.compatibility_shims.covered_slugs.

As cinco métricas medidas

Cinco grandezas são capturadas em cada passagem — duas são normalizadas como rácio da baseline, três permanecem em valor absoluto:

• CPU PHP — tempo CPU consumido via getrusage(), expresso como fração do CPU PHP do pedido baseline. Auto-normalizante entre servidores: 18 % de CPU num Xeon equivale a 18 % num alojamento partilhado.
• Memória — pico de memória adicional, como fração do pico de memória baseline. Mesmo raciocínio: a fração fala, o valor absoluto depende do servidor.
• Consultas SQL adicionadas — contagem absoluta. 1 consulta = 1 consulta, independente da máquina.
• Assets adicionados — scripts + estilos enqueued pelo componente. Contagem absoluta.
• Chamadas HTTP externas — contagem absoluta das chamadas de rede de saída.

O cálculo da pontuação 0-100 por componente

Convenção: 100 = perfeito, 0 = pior, igual a uma nota escolar. Para cada métrica aplicamos uma rampa linear entre um limiar baixo (abaixo, o componente perde 0 pontos) e um limiar alto (acima, perde o peso máximo). As cinco penalizações são somadas (máx. 100), depois devolve-se pontuação = 100 − penalização. A pontuação é recalculada no servidor em cada ingestão, a partir das passagens em bruto — o cliente nunca decide a sua própria nota.

Métrica	Baixo (0 pt perdido)	Alto (perda máx.)	Peso máx.
CPU (% baseline)	2 %	30 %	30 pts
Memória (% baseline)	2 %	40 %	20 pts
Consultas SQL	2	60	20 pts
Assets	1	15	15 pts
HTTP externo	0	5	15 pts

Porquê CPU e memória em rácio enquanto SQL/assets/HTTP permanecem em absoluto? As duas primeiras grandezas variam com a máquina; normalizá-las à baseline anula o fator de escala. As outras três são contagens inteiras, intrinsecamente invariantes à escala.

A pontuação global da página

A pontuação grande no relatório de scan reflete o peso real da página renderizada, não a soma dos impactos atribuídos aos componentes. A distinção importa: com ~10 plugins ou mais, a atribuição diferencial conta várias vezes os hooks partilhados (dois plugins que partilham um hook recebem cada um o custo total). Somar esses delta e dividi-los pela baseline produzia um rácio saturado a 100 % quase mecanicamente → 50 pontos perdidos antes mesmo de verificar se a página estava lenta. A metodologia v4.0 corrige isto lendo diretamente os valores absolutos da baseline.

As mesmas cinco dimensões, em absoluto: tempo do servidor, pico de memória, consultas SQL, scripts/estilos enfileirados, chamadas HTTP externas. As mesmas rampas lineares da pontuação por-componente, mas com limiares mais tolerantes (um site inteiro faz mais que um plugin único).

Métrica	Baixo (0 pt perdido)	Alto (perda máx.)	Peso máx.
Tempo do servidor	400 ms	3000 ms	30 pts
Pico de memória	24 MB	192 MB	20 pts
Consultas SQL	80	1500	20 pts
Scripts + estilos	15	120	15 pts
HTTP externo	2	25	15 pts

Da pontuação à nota A–E

A pontuação é mapeada numa letra A a E segundo limites absolutos na escala 0-100. Se todo o ecossistema WordPress se otimizasse, todos os plugins poderiam passar a A — é intencional: classificamos um impacto, não uma classificação relativa.

A	85 – 100	Impacto desprezável, componente muito leve
B	65 – 84	Impacto moderado, razoável
C	45 – 64	Impacto significativo, a vigiar
D	25 – 44	Impacto importante, alternativa recomendada
E	0 – 24	Impacto muito pesado, crítico

Agregação entre sites

Quando vários sites medem a mesma versão de um plugin, conservamos a mediana por (plugin, versão, page_type) — separadamente para a homepage e a admin, que não são comparáveis. A mediana resiste melhor aos outliers (sites mal configurados, medições interrompidas) do que a média.

As análises em bruto são conservadas em base de dados durante 3 anos. Se a metodologia evoluir, podemos recalcular retroativamente todas as pontuações sem ter de pedir aos sites para voltarem a analisar.

Pontuação consolidada na ficha pública

A pontuação apresentada na ficha de um plugin ou tema é consolidada nos últimos 90 dias. Todas as análises válidas desta janela alimentam a mediana, independentemente da versão em que foram recolhidas. Sem esta janela deslizante, cada nova versão reiniciaria a pontuação pública a zero e um plugin ativamente mantido apareceria permanentemente como « dados insuficientes ».

A etiqueta de versão apresentada no cartão (ex.: « v4.1.0 ») é a versão mais recente representada na janela — para se perceber qual lançamento está atualmente a ser medido — enquanto a pontuação se mantém estável. O detalhe versão a versão continua acessível na tabela de histórico mais abaixo na ficha.

Salvaguardas antes da publicação

Três filtros são aplicados antes de uma análise participar na mediana pública. As análises rejeitadas ficam armazenadas para auditoria mas não influenciam a nota apresentada.

• Baseline demasiado leve: se o pedido baseline consome menos de 50 ms de CPU, os rácios tornam-se extremos e ruidosos → análise excluída.
• Baseline saturada: se o pedido baseline excede 3 × a mediana mundial do mesmo tipo de página, o site está provavelmente já saturado de outros plugins → análise excluída (caso contrário, um plugin pesado pareceria desprezável).
• Plausibilidade estatística: sete heurísticas inter-métricas (ex. « 50 MB alocados sem qualquer tempo CPU consumido » é fisicamente impossível) atribuem uma pontuação 0-100 a cada análise. Abaixo de 40/100, a análise é rejeitada como suspeita.

Identidade verificada dos sites contribuintes

Cada site contribuinte gera localmente um par de chaves Ed25519 e assina cada envio. A identidade é verificada uma vez no alistamento por desafio criptográfico em admin-ajax.php. Sem chave partilhada — fabricar uma falsa identidade exige possuir um verdadeiro domínio WordPress, o que torna a fraude economicamente não rentável. Veja a política de privacidade para o que transita (e sobretudo o que não transita).

Componentes excluídos da classificação pública

Os proprietários de sites podem marcar um plugin ou tema — tipicamente um módulo desenvolvido internamente ou um produto proprietário — como privado nas definições do plugin WordPress. O componente é então enviado a Pulse com um flag private: true.

O servidor calcula e devolve a pontuação (para que o relatório local fique completo), mas não persiste nada: nenhuma linha em plugin_scans, nenhuma entrada no catálogo público, nenhum contributo para as medianas comunitárias. O slug apenas transita no pedido assinado e é depois esquecido. Esta separação entre «sem pontuação» e «não publicado» foi introduzida na metodologia v3.2.

Limiar de publicação

Enquanto uma versão de plugin ou tema contar com menos de 15 análises únicas (sites distintos verificados), a sua nota não é apresentada publicamente. O WP Footprint Pulse indica « dados insuficientes » em vez disso, para nunca induzir em erro com base numa amostra demasiado pequena.

Refaça o cálculo por si próprio

Todos os limiares, pesos e salvaguardas descritos acima são expostos em JSON no endpoint público https://www.wpfootprint.com/api/v1/methodology, versionado por metodologia. Pode também ler diretamente o código de scoring no repositório — vive em quatro ficheiros de menos de 200 linhas cada.

Limites assumidos

• Sem tracing PHP fino. A atribuição é diferencial: se um plugin A despoleta um hook que executa código de um plugin B, o impacto medido pode recair num ou no outro. É o compromisso para se manter não intrusivo (sem necessidade de Xdebug).
• Viés de ambiente residual. Os rácios CPU/memória anulam o viés de frequência do servidor, mas permanecem sensíveis à versão PHP maior (PHP 7.4 não distribui os custos como PHP 8.3). Estratificação por versão PHP prevista em v1.1.
• Amostra autosselecionada. Os sites que instalam o WP Footprint são provavelmente mais técnicos do que a média. O ranking é « verdadeiro para os sites que analisam », não para todo o WordPress.
• Sem medida do valor fornecido. Um plugin pesado que faz muito e um plugin leve que faz pouco terão a mesma nota se os seus deltas forem idênticos. A categorização ajudará mas não resolverá tudo.
• Plugins assíncronos. Os plugins que fazem a maior parte do seu trabalho em cron diferido ou em fila (workers, webhooks) terão um impacto frontal subestimado numa análise de página única.
• Plugins não isoláveis. Alguns plugins provocam um erro fatal quando são desativados porque a sua API é utilizada ao nível PHP pelo tema ou por outro plugin. São marcados como «não mensuráveis» no relatório local e ficam fora do ranking público. A sua lista é comunicada de forma anónima para dar prioridade a novos stubs de compatibilidade.

Sugestões e críticas são bem-vindas — escreva-nos para [email protected]. Qualquer melhoria aceite é documentada no changelog da metodologia.