Come misura WP Footprint.

Questa pagina documenta esattamente cosa viene misurato, come viene aggregato e come viene calcolato il grade da A a E. Il metodo è pubblico: può criticarlo, verificarlo, rifare il calcolo da sé e proporre miglioramenti.

Metodologia in vigore: v4.1. Versionata ad ogni evoluzione — la storia completa vive nel codice sorgente.

Misura differenziale: baseline poi disattivazione

WP Footprint misura una pagina più volte con tutti i plugin attivi (la baseline). Successivamente, per ogni plugin e per il tema attivo, riproduce la stessa pagina dopo averlo disattivato temporaneamente tramite un MU-loader, e misura di nuovo.

L'impatto specifico di un componente è la differenza: delta = mediana(baseline) − mediana(baseline senza il componente). Questo approccio per differenza neutralizza l'effetto del server, del tema e degli altri plugin — è ciò che rende legittimi i confronti tra siti, senza dover strumentare il codice PHP in profondità.

Più passate, mediana, intervallo di confidenza

Per assorbire il rumore naturale di un web server (cache, GC, latenza DB), ogni misurazione viene ripetuta: fino a 5 passate per la baseline e fino a 3 passate per ogni componente disattivato. Il plugin può fermarsi prima — già a 3 passate baseline o 2 passate componente — quando il campione è già stretto (dispersione sotto max(50 ms; 10 % della mediana)): nessuna precisione persa, soltanto nessuna passata superflua. I valori anomali vengono rimossi con un filtro Tukey k=1.5 sull'intervallo interquartile, poi conserviamo la mediana delle passate rimanenti (la mediana resiste agli outlier, a differenza della media).

Una semilarghezza dell'intervallo di confidenza al 95 % viene calcolata tramite la legge di Student t(0,975, n−1) — non tramite un'approssimazione gaussiana, che sottostimerebbe l'incertezza per piccoli campioni. Un delta indistinguibile dal rumore non viene conteggiato nel punteggio pubblico.

Misura del pavimento server (host-floor)

Ad ogni scansione il plugin esegue anche 3 passate sintetiche in cui WordPress viene avviato senza alcun plugin attivo e con un tema di default. La richiesta viene cortocircuitata presto (azione init priorità 1) e restituisce un body minimo — nessun routing, nessun lookup del post, nessun rendering del template. Ciò che catturiamo è il tempo puro di boot WP+server su questa macchina.

Questa misura è indipendente dall'URL scansionato e riproducibile. Sarà utilizzata per normalizzare i punteggi per host: lo stesso delta di +90 ms significa cose molto diverse su un pavimento di 80 ms (+112 % di overhead) rispetto a un pavimento di 250 ms (+36 %). Per ora il dato viene raccolto e archiviato; la ponderazione arriverà in una revisione successiva del calcolo.

Limiti di isolamento: plugin non misurabili

Alcuni plugin non possono essere disattivati in sicurezza: la loro API è invocata direttamente (a livello PHP) dal tema o da altri plugin. Disattivarli farebbe andare in errore la richiesta, rendendo impossibile qualsiasi misura differenziale. Quando lo scanner rileva questo caso (errore fatale alla prima passata), interrompe i tentativi, contrassegna il componente come non misurabile e non lo invia a Pulse. Gli altri componenti vengono misurati normalmente.

Per i plugin diffusi la cui API è largamente utilizzata dai temi (ACF, Polylang, Yoast, Rank Math, Meta Box, Pods, WPML, The Events Calendar, Gravity Forms…), il MU-loader carica degli stub di compatibilità durante la passata: le funzioni del plugin restano definite e restituiscono valori neutri, così la pagina viene resa senza errori e il costo proprio del plugin resta misurato correttamente. L'elenco dei plugin coperti è esposto in /api/v1/methodology sotto pipeline.isolation.compatibility_shims.covered_slugs.

Le cinque metriche misurate

Cinque grandezze sono catturate ad ogni passata — due sono normalizzate come rapporto della baseline, tre restano in valore assoluto:

• CPU PHP — tempo CPU consumato tramite getrusage(), espresso come frazione della CPU PHP della richiesta baseline. Auto-normalizzante tra server: 18 % di CPU su uno Xeon equivale a 18 % su un hosting condiviso.
• Memoria — picco di memoria aggiuntivo, come frazione del picco di memoria baseline. Stesso ragionamento: la frazione parla, il valore assoluto dipende dal server.
• Query SQL aggiunte — conteggio assoluto. 1 query = 1 query, indipendente dalla macchina.
• Asset aggiunti — script + stili accodati dal componente. Conteggio assoluto.
• Chiamate HTTP esterne — conteggio assoluto delle chiamate di rete uscenti.

Il calcolo del punteggio 0-100 per componente

Convenzione: 100 = perfetto, 0 = pessimo, come un voto scolastico. Per ogni metrica si applica una rampa lineare tra una soglia bassa (sotto la quale il componente perde 0 punti) e una soglia alta (sopra la quale perde il peso massimo). Le cinque penalità vengono sommate (max 100) e poi si restituisce punteggio = 100 − penalità. Il punteggio è ricalcolato lato server ad ogni ingestione, a partire dalle passate grezze — il client non decide mai il proprio voto.

Metrica	Bassa (0 pt persi)	Alta (perdita max)	Peso max
CPU (% baseline)	2 %	30 %	30 pt
Memoria (% baseline)	2 %	40 %	20 pt
Query SQL	2	60	20 pt
Asset	1	15	15 pt
HTTP esterno	0	5	15 pt

Perché CPU e memoria in rapporto mentre SQL/asset/HTTP restano in assoluto? Le prime due grandezze variano con la macchina; normalizzarle alla baseline annulla il fattore di scala. Le altre tre sono conteggi interi, intrinsecamente invarianti rispetto alla scala.

Il punteggio globale della pagina

Il punteggio grande in cima al rapporto di scansione riflette la reale pesantezza della pagina renderizzata, non la somma degli impatti attribuiti ai componenti. La distinzione conta: con ~10 plugin o più, l'attribuzione differenziale conta più volte gli hook condivisi (due plugin che si dividono uno stesso hook si vedono attribuire ognuno il costo totale). Sommare quei delta e dividerli per la baseline produceva un rapporto saturato al 100 % quasi meccanicamente → 50 punti persi prima ancora di guardare se la pagina fosse lenta. La metodologia v4.0 risolve il problema leggendo direttamente i valori assoluti della baseline.

Stesse cinque dimensioni, in assoluto: tempo server, picco di memoria, query SQL, script/stili accodati, chiamate HTTP esterne. Stesse rampe lineari del punteggio per-componente, ma con soglie più tolleranti (un sito intero fa più di un singolo plugin).

Metrica	Bassa (0 pt persi)	Alta (perdita max)	Peso max
Tempo server	400 ms	3000 ms	30 pt
Picco memoria	24 MB	192 MB	20 pt
Query SQL	80	1500	20 pt
Script + stili	15	120	15 pt
HTTP esterno	2	25	15 pt

Dal punteggio al grade A–E

Il punteggio viene mappato su una lettera da A a E secondo soglie assolute sulla scala 0-100. Se l'intero ecosistema WordPress si ottimizzasse, tutti i plugin potrebbero passare in A — è voluto: valutiamo un impatto, non una classifica relativa.

A	85 – 100	Impatto trascurabile, componente molto leggero
B	65 – 84	Impatto moderato, ragionevole
C	45 – 64	Impatto significativo, da monitorare
D	25 – 44	Impatto importante, alternativa consigliata
E	0 – 24	Impatto molto pesante, critico

Aggregazione tra siti

Quando più siti misurano la stessa versione di un plugin, conserviamo la mediana per (plugin, versione, page_type) — separatamente per la homepage e l'admin, che non sono confrontabili. La mediana resiste meglio agli outlier (siti mal configurati, misurazioni interrotte) della media.

Le scansioni grezze sono conservate in database per 3 anni. Se la metodologia evolve, possiamo ricalcolare retroattivamente tutti i punteggi senza dover chiedere ai siti di rifare la scansione.

Punteggio consolidato sulla scheda pubblica

Il punteggio mostrato sulla scheda di un plugin o di un tema è consolidato sugli ultimi 90 giorni. Tutte le scansioni valide di questa finestra alimentano la mediana, indipendentemente dalla versione su cui sono state raccolte. Senza questa finestra mobile, ogni nuova release azzererebbe il punteggio pubblico e un plugin attivamente mantenuto resterebbe in permanenza in « dati non ancora sufficienti ».

L'etichetta di versione mostrata sulla card (es. « v4.1.0 ») è la versione più recente rappresentata nella finestra — così Lei può capire quale release viene misurata adesso — mentre il punteggio resta stabile. Il dettaglio versione per versione rimane accessibile nella tabella storica più in basso nella scheda.

Salvaguardie prima della pubblicazione

Tre filtri vengono applicati prima che una scansione partecipi alla mediana pubblica. Le scansioni rifiutate restano memorizzate per audit ma non influenzano il grade visualizzato.

• Baseline troppo leggera: se la richiesta baseline consuma meno di 50 ms di CPU, i rapporti diventano estremi e rumorosi → scansione esclusa.
• Baseline appesantita: se la richiesta baseline supera 3 × la mediana mondiale dello stesso tipo di pagina, il sito è probabilmente già saturo di altri plugin → scansione esclusa (altrimenti un plugin pesante apparirebbe trascurabile).
• Plausibilità statistica: sette euristiche tra metriche (es. « 50 MB allocati senza alcun tempo CPU consumato » è fisicamente impossibile) attribuiscono un punteggio 0-100 a ciascuna scansione. Sotto 40/100, la scansione viene rifiutata come sospetta.

Identità verificata dei siti contributori

Ogni sito contributore genera localmente una coppia di chiavi Ed25519 e firma ogni invio. L'identità è verificata una volta all'arruolamento tramite challenge crittografica su admin-ajax.php. Nessuna chiave condivisa — fabbricare una falsa identità richiede di possedere un vero dominio WordPress, il che rende il barare economicamente non redditizio. Veda la politica di privacy per ciò che transita (e soprattutto ciò che non transita).

Componenti esclusi dalla classifica pubblica

I proprietari del sito possono contrassegnare un plugin o un tema — tipicamente un modulo interno o un prodotto proprietario — come privato nelle impostazioni del plugin WordPress. Il componente viene quindi inviato a Pulse con un flag private: true.

Il server calcola e restituisce il punteggio (così il rapporto locale è completo) ma non persiste nulla: nessuna riga in plugin_scans, nessuna voce nel catalogo pubblico, nessun contributo alle mediane comunitarie. Lo slug transita solo nella richiesta firmata e viene poi dimenticato. Questa separazione tra «nessun punteggio» e «non pubblicato» è stata introdotta nella metodologia v3.2.

Soglia di pubblicazione

Finché una versione di plugin o tema conta meno di 15 scansioni uniche (siti distinti verificati), il suo grade non viene visualizzato pubblicamente. WP Footprint Pulse indica « dati insufficienti » al suo posto, per non indurre mai in errore sulla base di un campione troppo piccolo.

Rifaccia il calcolo da sé

Tutte le soglie, i pesi e le salvaguardie descritti sopra sono esposte in JSON sull'endpoint pubblico https://www.wpfootprint.com/api/v1/methodology, versionato per metodologia. Può anche leggere direttamente il codice di scoring nel repository — sta in quattro file di meno di 200 righe ciascuno.

Limiti riconosciuti

• Nessun tracing PHP fine. L'attribuzione è differenziale: se un plugin A innesca un hook che esegue codice di un plugin B, l'impatto misurato può essere parzialmente attribuito all'uno o all'altro. È il compromesso per restare non-intrusivi (nessun bisogno di Xdebug).
• Bias d'ambiente residuo. I rapporti CPU/memoria annullano il bias di frequenza del server, ma restano sensibili alla versione PHP maggiore (PHP 7.4 non distribuisce i costi come PHP 8.3). Stratificazione per versione PHP prevista in v1.1.
• Campione auto-selezionato. I siti che installano WP Footprint sono probabilmente più tecnici della media. Il ranking è « vero per i siti che scansionano », non per tutto WordPress.
• Nessuna misura del valore fornito. Un plugin pesante che fa molto e un plugin leggero che fa poco avranno lo stesso grade se i loro delta sono identici. La categorizzazione aiuterà ma non risolverà tutto.
• Plugin asincroni. I plugin che svolgono la maggior parte del loro lavoro in cron differito o in coda (worker, webhook) avranno un impatto frontale sottostimato su una scansione di pagina singola.
• Plugin non isolabili. Alcuni plugin generano un errore fatale quando vengono disattivati perché la loro API è utilizzata a livello PHP dal tema o da un altro plugin. Vengono contrassegnati come «non misurabili» nel rapporto locale ed esclusi dalla classifica pubblica. Il loro elenco viene comunicato in forma anonima per dare priorità a nuovi stub di compatibilità.

Suggerimenti e critiche sono benvenuti — ci scriva a [email protected]. Ogni miglioramento accettato è documentato nel changelog della metodologia.