diff --git a/docs/26-atuq-envoltorio-gecko.md b/docs/26-atuq-envoltorio-gecko.md
index 3400f484..7f373a21 100644
--- a/docs/26-atuq-envoltorio-gecko.md
+++ b/docs/26-atuq-envoltorio-gecko.md
@@ -227,6 +227,34 @@ llevan `-fprofile-use`**, el configure encontró `llvm-profdata`, y no hay ni un
 no cuadre. `libxul.so` pasa de 226.078.752 a 227.802.816 bytes, consistente con inlining de caminos
 calientes. Es evidencia de build, no de artefacto, y conviene decirlo así.
 
+**LA GANANCIA, MEDIDA (2026-09-07).** Mismo rootfs, mismo script, corridas INTERCALADAS A/B/A/B
+para que la deriva de carga afecte a las dos, mediana de 7, calentamiento descartado. Lo único que
+cambia entre variantes es un `--ro-bind` de `/usr/lib/firefox`.
+
+| página | sin PGO | con PGO | |
+|---|---|---|---|
+| DOM+layout+strings, **fuera** del corpus de entrenamiento | 23.540 ms | 21.327 ms | **−9,4 %** |
+| SunSpider `3d-raytrace`, **dentro** del corpus | 16.034 ms | 15.878 ms | −1,0 % |
+
+Los rangos no se solapan en ninguna de las dos (23.185–23.654 vs 21.030–21.650), así que las dos
+diferencias son reales y no ruido.
+
+⚠ **Y el resultado sale al revés de lo esperable, que es lo interesante.** La intuición dice que
+medir sobre el conjunto de ENTRENAMIENTO infla la ganancia; acá el corpus da el número MÁS BAJO. La
+razón es que `3d-raytrace` es aritmética pura en un bucle caliente, y ese bucle **no lo ejecuta el
+C++ de SpiderMonkey: lo ejecuta código máquina que el JIT genera en tiempo de ejecución**. El PGO
+optimiza el intérprete, el GC y el propio compilador JIT — no el código que el JIT emite. Un
+benchmark JIT-bound es casi ciego al PGO por construcción.
+
+Donde sí se ve es en el camino DOM/layout/arranque, que es C++ de principio a fin. Y eso es también
+lo que un usuario percibe: la medición cubre el ciclo COMPLETO del proceso (arrancar → renderizar →
+capturar → salir), no el rendimiento en régimen de una página ya cargada. De ahí que hasta la página
+de SunSpider tarde 16 s: casi todo es arranque.
+
+**Corolario para el corpus de entrenamiento:** está sesgado hacia JS (SunSpider domina en número de
+páginas) justo donde el PGO menos rinde. Un corpus con más maquetación y menos aritmética
+probablemente daría más ganancia. Es una unidad de trabajo propia y no se hace de paso.
+
 **Y la pregunta que un insumo no determinista obliga a hacer, respondida: `firefox` SIGUE
 REPRODUCIENDO bit a bit** (`verificar-repro.sh`: REPRODUCEN 1, DERIVA 0, NO-DETERMINISMO 0). Era el
 riesgo real de esta unidad, no el rendimiento: si el `-fprofile-use` hubiera metido cualquier