Cómo mide WP Footprint.
Esta página documenta exactamente qué se mide, cómo se agrega y cómo se calcula la nota A a E. El método es público: puede criticarlo, verificarlo, rehacer el cálculo usted mismo y proponer mejoras.
Metodología en vigor: v4.1. Versionada en cada cambio — el historial completo vive en el código fuente.
En resumen
Una medición aislada por plugin, mediana móvil de 90 días.
Cada plugin se desactiva por turno para aislar su impacto propio. Las contribuciones de todos los sitios participantes se consolidan en medianas móviles de 90 días, con intervalo de confianza, antes de traducirse en una nota de A a E.
Medición diferencial: baseline luego desactivación
WP Footprint mide una página varias veces con todos los plugins activos (el baseline). Después, para cada plugin y para el tema activo, vuelve a ejecutar la misma página tras desactivarlo temporalmente mediante un MU-loader, y mide de nuevo.
El impacto propio de un componente es la diferencia: delta = mediana(baseline) − mediana(baseline sin el componente). Este enfoque por diferencia neutraliza el efecto del servidor, del tema y de los demás plugins — eso es lo que hace legítimas las comparaciones entre sitios, sin tener que instrumentar el código PHP en profundidad.
Varias pasadas, mediana, intervalo de confianza
Para absorber el ruido natural de un servidor web (caché, GC, latencia DB), cada medición se repite: hasta 5 pasadas para el baseline y hasta 3 pasadas por componente desactivado. El plugin puede detenerse antes — a las 3 pasadas baseline o 2 pasadas componente — cuando la muestra ya está cerrada (dispersión por debajo de máx(50 ms; 10 % de la mediana)): no se pierde precisión, solo evitamos pasadas inútiles. Los valores atípicos se eliminan con un filtro Tukey k=1.5 sobre el rango intercuartílico, luego conservamos la mediana de las pasadas restantes (la mediana resiste a los outliers, a diferencia de la media).
Una semianchura del intervalo de confianza al 95 % se calcula mediante la ley de Student t(0,975, n−1) — no por aproximación gaussiana, que subestimaría la incertidumbre en muestras pequeñas. Un delta indistinguible del ruido no se contabiliza en la puntuación pública.
Medición del suelo del servidor (host-floor)
En cada escaneo el plugin también ejecuta 3 pasadas sintéticas en las que WordPress se inicia sin plugins activos y con un tema por defecto. La petición se cortocircuita pronto (acción init prioridad 1) y devuelve un body mínimo — sin enrutamiento, sin búsqueda del post, sin renderizado de plantilla. Lo que capturamos es el tiempo puro de arranque WP+servidor en esta máquina.
Esta medición es independiente de la URL escaneada y reproducible. Se utilizará para normalizar las puntuaciones por hosting: el mismo delta de +90 ms significa cosas muy distintas en un suelo de 80 ms (+112 % de sobrecarga) frente a uno de 250 ms (+36 %). Por ahora el dato se recopila y archiva; la ponderación llegará en una revisión posterior del cálculo.
Límites de aislamiento: plugins no medibles
Algunos plugins no pueden desactivarse de forma segura: su API es invocada directamente (a nivel PHP) por el tema u otros plugins. Desactivarlos haría fallar la petición, imposibilitando cualquier medición diferencial. Cuando el escáner detecta este caso (fatal en la primera pasada), detiene los reintentos, marca el componente como no medible y no lo envía a Pulse. Los demás componentes se miden con normalidad.
Para los plugins populares cuya API es ampliamente utilizada por los temas (ACF, Polylang, Yoast, Rank Math, Meta Box, Pods, WPML, The Events Calendar, Gravity Forms…), el MU-loader carga stubs de compatibilidad durante la pasada: las funciones del plugin siguen definidas y devuelven valores neutros, de modo que la página se renderiza sin fatales y el coste propio del plugin sigue midiéndose correctamente. La lista de plugins cubiertos se expone en /api/v1/methodology bajo pipeline.isolation.compatibility_shims.covered_slugs.
Las cinco métricas medidas
Cinco magnitudes se capturan en cada pasada — dos se normalizan como ratio del baseline, tres permanecen en valor absoluto:
- CPU PHP — tiempo CPU consumido vía
getrusage(), expresado como fracción del CPU PHP de la solicitud baseline. Auto-normalizante entre servidores: 18 % de CPU en un Xeon equivale a 18 % en un hosting compartido. - Memoria — pico de memoria adicional, como fracción del pico de memoria baseline. Mismo razonamiento: la fracción habla, el valor absoluto depende del servidor.
- Consultas SQL añadidas — conteo absoluto. 1 consulta = 1 consulta, independiente de la máquina.
- Assets añadidos — scripts + estilos en cola por el componente. Conteo absoluto.
- Llamadas HTTP externas — conteo absoluto de llamadas de red salientes.
El cálculo de la puntuación 0-100 por componente
Convención: 100 = perfecto, 0 = peor, igual que una nota escolar. Para cada métrica aplicamos una rampa lineal entre un umbral bajo (por debajo, el componente pierde 0 puntos) y un umbral alto (por encima, pierde el peso máximo). Las cinco penalizaciones se suman (máx. 100) y luego se devuelve puntuación = 100 − penalización. La puntuación se recalcula en el servidor en cada ingestión, a partir de las pasadas brutas — el cliente nunca decide su propia nota.
| Métrica | Bajo (0 pt perdido) | Alto (pérdida máx) | Peso máx |
|---|---|---|---|
| CPU (% baseline) | 2 % | 30 % | 30 pts |
| Memoria (% baseline) | 2 % | 40 % | 20 pts |
| Consultas SQL | 2 | 60 | 20 pts |
| Assets | 1 | 15 | 15 pts |
| HTTP externo | 0 | 5 | 15 pts |
¿Por qué CPU y memoria como ratio mientras SQL/assets/HTTP permanecen en absoluto? Las dos primeras magnitudes varían con la máquina; normalizarlas al baseline anula el factor de escala. Las otras tres son conteos enteros, intrínsecamente invariantes a la escala.
La puntuación global de la página
La puntuación grande de tu informe de escaneo refleja la pesadez real de la página renderizada, no la suma de los impactos atribuidos a los componentes. La distinción importa: con ~10 plugins o más, la atribución diferencial cuenta varias veces los hooks compartidos (dos plugins que comparten un hook se ven cada uno atribuido el coste total). Sumar esos delta y dividirlos por el baseline producía un ratio saturado al 100 % casi mecánicamente → 50 puntos perdidos antes incluso de mirar si la página era lenta. La metodología v4.0 lo arregla leyendo directamente los valores absolutos del baseline.
Las mismas cinco dimensiones, en absoluto: tiempo de servidor, pico de memoria, consultas SQL, scripts/estilos en cola, llamadas HTTP externas. Las mismas rampas lineales que la puntuación por componente, pero con umbrales más tolerantes (un sitio entero hace más que un solo plugin).
| Métrica | Bajo (0 pt perdido) | Alto (pérdida máx) | Peso máx |
|---|---|---|---|
| Tiempo servidor | 400 ms | 3000 ms | 30 pts |
| Pico memoria | 24 MB | 192 MB | 20 pts |
| Consultas SQL | 80 | 1500 | 20 pts |
| Scripts + estilos | 15 | 120 | 15 pts |
| HTTP externo | 2 | 25 | 15 pts |
De la puntuación a la nota A–E
La puntuación se mapea a una letra A a E según límites absolutos sobre la escala 0-100. Si todo el ecosistema WordPress se optimizara, todos los plugins podrían alcanzar A — es voluntario: calificamos un impacto, no un ranking relativo.
| A | 85 – 100 | Impacto despreciable, componente muy ligero |
| B | 65 – 84 | Impacto moderado, razonable |
| C | 45 – 64 | Impacto significativo, a vigilar |
| D | 25 – 44 | Impacto importante, alternativa recomendada |
| E | 0 – 24 | Impacto muy pesado, crítico |
Agregación entre sitios
Cuando varios sitios miden la misma versión de un plugin, conservamos la mediana por (plugin, versión, page_type) — separadamente para la homepage y la admin, que no son comparables. La mediana resiste mejor a los outliers (sitios mal configurados, mediciones interrumpidas) que la media.
Los escaneos brutos se conservan en base de datos durante 3 años. Si la metodología evoluciona, podemos recalcular retroactivamente todas las puntuaciones sin tener que pedir a los sitios que vuelvan a escanear.
Puntuación consolidada en la ficha pública
La puntuación mostrada en la ficha de un plugin o un tema está consolidada sobre los últimos 90 días. Todos los escaneos válidos de esa ventana alimentan la mediana, independientemente de la versión sobre la que se recogieron. Sin esta ventana deslizante, cada nuevo lanzamiento reiniciaría la puntuación pública a cero y un plugin mantenido activamente aparecería permanentemente como « datos insuficientes ».
La etiqueta de versión mostrada en la tarjeta (p. ej. « v4.1.0 ») es la versión más reciente representada en la ventana — para que se vea qué release se está midiendo — mientras la puntuación permanece estable. El detalle versión por versión sigue accesible en la tabla histórica más abajo en la ficha.
Salvaguardas antes de la publicación
Tres filtros se aplican antes de que un escaneo participe en la mediana pública. Los escaneos rechazados quedan almacenados para auditoría pero no influyen en la nota mostrada.
- Baseline demasiado ligero: si la solicitud baseline consume menos de 50 ms de CPU, los ratios se vuelven extremos y ruidosos → escaneo excluido.
- Baseline saturado: si la solicitud baseline supera 3 × la mediana mundial del mismo tipo de página, el sitio probablemente ya está saturado de otros plugins → escaneo excluido (de lo contrario, un plugin pesado parecería despreciable).
- Plausibilidad estadística: siete heurísticas entre métricas (ej. «50 MB asignados sin ningún tiempo CPU consumido» es físicamente imposible) atribuyen una puntuación 0-100 a cada escaneo. Por debajo de 40/100, el escaneo es rechazado como sospechoso.
Identidad verificada de los sitios contribuyentes
Cada sitio contribuyente genera localmente un par de claves Ed25519 y firma cada envío. La identidad se verifica una vez en el alistamiento mediante un desafío criptográfico sobre admin-ajax.php. Sin clave compartida — fabricar una falsa identidad requiere poseer un dominio WordPress real, lo que hace que hacer trampa sea económicamente no rentable. Vea la política de privacidad para lo que se transmite (y sobre todo lo que no se transmite).
Componentes excluidos de la clasificación pública
Los propietarios del sitio pueden marcar un plugin o un tema — típicamente un módulo desarrollado en casa o un producto propietario — como privado en los ajustes del plugin de WordPress. El componente se envía entonces a Pulse con un flag private: true.
El servidor calcula y devuelve la puntuación (para que el informe local esté completo) pero no persiste nada: ninguna fila en plugin_scans, ninguna entrada en el catálogo público, ninguna contribución a las medianas comunitarias. El slug solo transita por la petición firmada y luego se olvida. Esta separación entre «sin puntuación» y «no publicado» se introdujo en la metodología v3.2.
Umbral de publicación
Mientras una versión de plugin o tema cuente con menos de 15 escaneos únicos (sitios distintos verificados), su nota no se muestra públicamente. WP Footprint Pulse indica «datos insuficientes» en su lugar, para no inducir nunca a error a partir de una muestra demasiado pequeña.
Rehaga el cálculo usted mismo
Todos los umbrales, pesos y salvaguardas descritos arriba están expuestos en JSON en el endpoint público https://www.wpfootprint.com/api/v1/methodology, versionado por metodología. También puede leer directamente el código de scoring en el repositorio — vive en cuatro archivos de menos de 200 líneas cada uno.
Límites asumidos
- Sin tracing PHP fino. La atribución es diferencial: si un plugin A activa un hook que ejecuta código de un plugin B, el impacto medido puede atribuirse parcialmente a uno u otro. Es el compromiso para mantenerse no intrusivo (no requiere Xdebug).
- Sesgo de entorno residual. Los ratios CPU/memoria anulan el sesgo de frecuencia del servidor, pero siguen siendo sensibles a la versión PHP mayor (PHP 7.4 no distribuye los costes como PHP 8.3). Estratificación por versión PHP prevista para v1.1.
- Muestra autoseleccionada. Los sitios que instalan WP Footprint son probablemente más técnicos que la media. El ranking es «verdadero para los sitios que escanean», no para todo WordPress.
- Sin medida del valor aportado. Un plugin pesado que hace mucho y un plugin ligero que hace poco tendrán la misma nota si sus deltas son idénticos. La categorización ayudará pero no resolverá todo.
- Plugins asíncronos. Los plugins que realizan la mayor parte de su trabajo en cron diferido o en cola (workers, webhooks) tendrán un impacto frontal subestimado en un escaneo de página única.
- Plugins no aislables. Algunos plugins generan un error fatal al desactivarse porque su API es consumida a nivel PHP por el tema u otro plugin. Se marcan como «no medibles» en el informe local y quedan fuera del ranking público. Su lista se comunica de forma anónima para priorizar nuevos stubs de compatibilidad.
Sugerencias y críticas bienvenidas — escríbanos a [email protected]. Cualquier mejora aceptada se documenta en el changelog de la metodología.