Reposo silencioso: actividad en segundo plano de Windows antes y después de la optimización
En esta página
Respuesta breve
Sección titulada «Respuesta breve»Desactivar los componentes en segundo plano de Windows realmente hace más silencioso el reposo: en dos series independientes de mediciones, el número de procesos cayó un 49–56 %, el uso de CPU en reposo — un 17–67 %, y el volumen de compromisos de memoria (commit) — un 52 % en la segunda serie. Pero bajo carga total de CPU, el rendimiento solo creció un 0,2–0,5 %. El «reposo silencioso» es una reducción confirmada del trabajo en segundo plano y de la competencia por recursos, no un aumento de FPS: el efecto final en juegos no se midió en este estudio.
Estado: la dirección del efecto se reprodujo en dos series independientes sobre una misma compilación de Windows 11 en una máquina virtual. Las magnitudes entre series difieren porque el trabajo en segundo plano de Windows llega a ráfagas: en una ventana con análisis de Microsoft Defender la diferencia de uso de CPU alcanza −67 %, en una ventana ya silenciosa — −17 %.
Afirmación verificable
Sección titulada «Afirmación verificable»Verificamos cuatro afirmaciones:
- Desactivar los componentes en segundo plano reduce notablemente la actividad del sistema en reposo.
- Reduce notablemente la actividad en los primeros minutos tras el arranque.
- Reduce notablemente el consumo de memoria.
- Aporta un aumento medible de rendimiento bajo carga total de CPU.
Alcance del estudio
Sección titulada «Alcance del estudio»- Windows 11 Pro, build 26300.9457 (26H2);
- máquina virtual: 4 vCPU, 8 GB de RAM, virtualización VMware;
- dos estados de una misma instalación: el original («antes») y tras aplicar el perfil de optimización de BoosterX (la compilación vigente en las fechas de medición);
- dos series independientes de mediciones: 2026-09-18 y 2026-09-19; los estados se compararon sobre copias independientes del disco, para que las mediciones no se influyeran entre sí;
- fases: 5 minutos tras el arranque, 5 minutos de estabilización, 5 minutos de reposo;
- cargas sintéticas cortas: 1, 4 y 8 hilos, carga de memoria, carga con pausas y mezclas de prioridades.
Las mediciones no incluyeron juegos reales, carga de GPU, hardware físico ni ventanas prolongadas (horas y días).
Metodología
Sección titulada «Metodología»El protocolo corresponde a «Cómo investigamos Windows»:
- cada fase se registró con trazas ETW (Windows Performance Recorder, perfiles ligeros de CPU, disco, archivos y red) y contadores de rendimiento con intervalo de 5 segundos (sistema) y 15 segundos (por procesos);
- la fase «tras el arranque» se inició con un reinicio controlado y se activó con un tiempo de actividad de alrededor de un minuto;
- en cada traza se verificó el número de eventos perdidos — en todas las ventanas presentadas es igual a cero;
- el promedio se calculó solo sobre intervalos completos de cinco segundos dentro de los límites de la fase (59 intervalos por fase);
- en la serie 2 se excluyó la primera ejecución «antes» debido a que la máquina virtual entró en suspensión; se usó la repetición;
- las pruebas de carga se ejecutaron dos veces, se presentan las medianas; el uso de CPU está normalizado a cuatro vCPU.
«Antes» y «después» son estados de una misma instalación de Windows: «después» se obtuvo aplicando el perfil de optimización, «antes» es el estado original. Se modificó el conjunto de ajustes en su totalidad, por lo que no se evaluó la contribución aislada de una desactivación concreta.
Resultados
Sección titulada «Resultados»Serie 1 (2026-09-18) — reposo establecido sin mantenimiento activo:
| Métrica | Antes | Después | Cambio |
|---|---|---|---|
| Uso de CPU, % | 2,48 | 2,06 | −17 % |
| DPC + ISR, % CPU | 1,73 | 1,59 | −8 % |
| Cambios de contexto, /s | 469 | 381 | −19 % |
| Procesos (promedio) | 134,9 | 69,3 | −49 % |
| Hilos (promedio) | 1 444,6 | 738,7 | −49 % |
| CPU total de todos los procesos, % | 1,22 | 1,06 | −13 % |
| Memoria disponible, MB | 5 490 | 6 518 | +1 028 |
| Lectura de disco, KB/s | 22,6 | 24,4 | +8 % |
| Escritura en disco, KB/s | 311,3 | 262,1 | −16 % |
| Red (recepción), KB/s | 132,6 | 2,2 | −98 % |
| Red (envío), KB/s | 43,2 | 4,7 | −89 % |
Serie 2 (2026-09-19) — la misma ventana de reposo, pero en el estado «antes» se ejecutaba un análisis en segundo plano de Microsoft Defender:
| Métrica | Antes | Después | Cambio |
|---|---|---|---|
| Uso de CPU, % | 33,37 | 11,03 | −67 % |
| Cambios de contexto, /s | 3 737 | 291 | −92 % |
| Procesos (promedio) | 142,3 | 61,9 | −56 % |
| Hilos (promedio) | 1 494,7 | 637,1 | −57 % |
| Memoria disponible, MB | 5 174 | 6 653 | +1 479 |
| Memoria física ocupada, MB | 3 017 | 1 538 | −49 % |
| Compromisos de memoria (commit), MB | 2 617 | 1 249 | −52 % |
| Nonpaged pool, MB | 298,2 | 212,9 | −29 % |
| Paged pool, MB | 258,5 | 86,0 | −67 % |
| DPC, % CPU | 0,89 | 0,19 | −78 % |
| Lectura de disco, MB/s | 7,42 | 0,01 | −99,9 % |
| Escritura en disco, MB/s | 4,57 | 0,23 | −95,0 % |
En el reposo de la serie 2 casi no hubo red en ambos estados (decenas de bytes por segundo), por lo que no se presentan las filas de red para ella. La diferencia entre series no es una contradicción, sino una propiedad del propio fondo: cuando Windows realiza mantenimiento, desactivar los componentes en segundo plano ahorra más; cuando la ventana ya está silenciosa — menos.
Primeros minutos tras el arranque
Sección titulada «Primeros minutos tras el arranque»| Métrica | Serie 1 (antes → después) | Serie 2 (antes → después) |
|---|---|---|
| Uso de CPU, % | 3,42 → 2,59 | 14,62 → 11,88 |
| Cambios de contexto, /s | 1 114 → 600 | 1 257 → 393 |
| Procesos | 132 → 74 | 139 → 64 |
| Hilos | — | 1 719 → 746 |
| Memoria física ocupada, MB | — | 2 821 → 1 581 |
| Memoria disponible, MB | — | 5 370 → 6 610 |
| Lectura de disco, KB/s | — | 826 → 433 |
| Escritura en disco, KB/s | 634 → 418 | 709 → 298 |
| Red (recepción), KB/s | — | 1,15 → ~0 |
El guion significa que en esa serie la métrica no se registró para la fase.
Composición y memoria
Sección titulada «Composición y memoria»Instantánea del inventario en reposo (serie 1):
| Antes | Después | |
|---|---|---|
| Procesos | 136 | 70 |
| Hilos | 1 679 | 842 |
| Working set total, MB | 3 841 | 1 868 |
| Private bytes totales, MB | 1 524 | 660 |
Los mayores consumidores de memoria antes de la optimización: el proceso antivirus MsMpEng.exe (257 MB), explorer.exe (213 MB), StartMenuExperienceHost (144 MB), msedge.exe (133 MB), SearchHost.exe (122 MB). Tras la optimización, la lista quedó encabezada por explorer.exe (170 MB), msedgewebview2 (119 MB), SearchHost.exe (115 MB) y StartMenuExperienceHost (106 MB).
La memoria disponible creció 1,0–1,5 GB, y el volumen de compromisos (commit) se redujo un 52 %. Qué de esto se puede «liberar» realmente y por qué la suma del working set de los procesos no es lo mismo que la memoria libre se analiza en «Cuánta memoria se puede liberar realmente en Windows».
Bajo carga total
Sección titulada «Bajo carga total»Pruebas sintéticas cortas (serie 2, medianas de dos repeticiones):
| Escenario | Cambio de rendimiento | Uso de CPU: antes / después |
|---|---|---|
| Un hilo | +5,4 % | 21,9 / 22,6 % |
| Cuatro hilos (total) | +0,19 % | 88,9 / 89,4 % |
| Ocho hilos (total) | +0,50 % | 88,9 / 88,8 % |
| Carga de memoria | +11,2 % | 84,8 / 87,5 % |
| Con pausas (pausas de 1 ms) | +5,4 % | 64,3 / 67,7 % |
| Prioridades mixtas | +8,5 % | 21,2 / 22,5 % |
| Prioridad en segundo plano | +77,1 % | 38,8 / 65,2 % |
Bajo carga total de cuatro hilos, el proceso útil recibió alrededor del 89 % de la capacidad de cuatro vCPU tanto antes como después de la optimización. El ~11 % restante en la máquina virtual no se puede declarar «ruido de Windows» eliminable: la planificación del hipervisor no se ve desde la traza del invitado. Los hilos de trabajo se distribuyeron de manera uniforme (la dispersión del volumen de trabajo entre ellos — 0,994–0,997), no se observó inanición, y la cola de CPU en reposo tras la optimización está prácticamente vacía.
A dónde va el fondo
Sección titulada «A dónde va el fondo»Fuentes medidas de actividad en segundo plano en el estado «antes»:
- el análisis antivirus — la principal fuente en la ventana de la serie 2: el proceso
MsMpEng.execonsumió 212 segundos de CPU en una ventana de reposo de cinco minutos; - en el estado original funcionaban el servicio de búsqueda, el servicio SysMain, la telemetría, el administrador de impresión y otros componentes — el perfil de optimización pone en estado desactivado alrededor de 50 servicios en segundo plano y 58 tareas programadas;
- tras el arranque, la actividad acompaña al orquestador de actualizaciones de Windows.
Desactivar los componentes en segundo plano no elimina el fondo por completo: en el estado optimizado seguía funcionando la evaluación de compatibilidad de aplicaciones (alrededor de 3,7 ms de CPU por segundo en la ventana de mantenimiento), y el fondo residual total en reposo establecido fue de 4,8 ms de CPU por segundo — alrededor del 0,12 % de la capacidad de cuatro vCPU (medido por traza).
Qué se ha confirmado
Sección titulada «Qué se ha confirmado»- Reproducido (dos series independientes): número de procesos −49…−56 %, hilos −49…−57 %, memoria disponible +1,0–1,5 GB.
- Medido (serie 2): commit −52 % en reposo; memoria física ocupada −49 % en reposo y −44 % en la fase tras el arranque.
- Medido: uso de CPU en reposo −17 % en una ventana silenciosa y −67 % en una ventana con análisis; cambios de contexto −19 % y −92 %; DPC −78 % (ventana de la serie 2); actividad tras el arranque menor en ambas series.
- Medido: bajo carga total de CPU, el aumento de rendimiento fue +0,19 % (4 hilos) y +0,50 % (8 hilos); con carga parcial y mixta — de +5,4 a +11,2 %.
- Medido: la carga de clase de prioridad en segundo plano se aceleró un 77,1 % — en el estado «antes» competía con el trabajo en segundo plano de Windows mismo, incluido el análisis antivirus.
- Observado: las principales fuentes de fondo son el análisis antivirus, el mantenimiento y las tareas de compatibilidad; tras la optimización el fondo residual es cercano a cero, pero no nulo.
Qué no se ha confirmado
Sección titulada «Qué no se ha confirmado»- El aumento de FPS, la reducción de input lag o frametime en juegos reales: no se midió. Las pruebas sintéticas de CPU no modelan un juego con GPU y no demuestran el efecto en juegos.
- La contribución aislada de cada desactivación concreta: se aplicó un conjunto de cambios.
- La transferencia de magnitudes absolutas a hardware físico, otras compilaciones y otros perfiles de optimización.
- La estabilidad en ventanas largas: cada fase es de 5 minutos; el trabajo en segundo plano de Windows llega a ráfagas, por lo que no se midió un «día promedio».
Limitaciones
Sección titulada «Limitaciones»- Las mediciones se realizaron en una máquina virtual. La virtualización aporta su propia cuota de DPC/ISR y oculta la planificación del host; en hardware físico los valores absolutos serán distintos. Las proporciones y la dirección de la comparación «antes/después» en condiciones idénticas se mantienen.
- La métrica ISR se excluyó de las tablas: en una máquina virtual el contador ISR por PDH diverge de los controladores de interrupciones por ETW en aproximadamente un 10 % y no cuadra en una suma exacta.
- La ventana «antes» de la serie 2 contenía un análisis activo de Defender, y la carga del host entre ventanas era distinta (en promedio 44 % frente a 24 %). Por eso las magnitudes están ligadas a ventanas concretas; la dirección se confirmó con dos series.
- En la serie 1, parte de la fase de reposo se interrumpió por una pausa externa de la máquina virtual de aproximadamente 26 segundos; la captura terminó tras la reanudación, no hay eventos perdidos.
- Las pruebas de carga son dos repeticiones: es estadística descriptiva, no se evaluó la significación estadística.
- Parte de la ganancia en reposo está relacionada con la desactivación de componentes de protección de Microsoft Defender. Un sistema sin protección antivirus es un compromiso consciente, no una optimización sin costes; hay que desactivar la protección entendiendo el precio.
- La capa de medición (traza y contadores) crea por sí misma una pequeña carga en segundo plano; está presente en ambos estados.
El estudio y las herramientas utilizadas pertenecen al desarrollador de BoosterX, por lo que el desarrollador tiene un interés directo en los resultados. La metodología y los límites de aplicabilidad se describen arriba, y las conclusiones se pueden verificar con los datos abiertos y las fuentes públicas enumeradas.
Conclusión práctica
Sección titulada «Conclusión práctica»La reducción del ruido en segundo plano es un efecto real, reproducido dos veces: la mitad de procesos e hilos, la mitad de compromisos de memoria, un orden de magnitud menos de actividad de disco y de red en reposo. Esto es útil por sí mismo — para la capacidad de respuesta del sistema, las tareas en segundo plano, la temperatura, el ruido de los ventiladores y la duración de la batería — y no requiere promesas de FPS.
Lo que no hay que esperar de esto: un aumento de rendimiento bajo carga total. Si la CPU ya está cargada con trabajo útil al ~89 % de su capacidad, desactivar la actividad en segundo plano no añadirá el 11 % restante — en la máquina virtual no pertenece a Windows. Cuanto más ocupado esté el sistema en el momento de la comparación, mayor será el efecto visible: en una ventana de mantenimiento la diferencia es múltiple, en una ventana silenciosa — moderada.
Recomendación: evalúe el fondo antes y después de cualquier cambio en su computadora (Task Manager → «Rendimiento» y «Procesos», Monitor de recursos), y no se guíe por porcentajes ajenos. Si el objetivo son los FPS en un juego concreto, mida precisamente eso antes y después del cambio.
Restauración del estado
Sección titulada «Restauración del estado»Ambas series se realizaron en máquinas virtuales aisladas sobre copias independientes del disco; tras las mediciones las máquinas volvían a sus estados originales. El artículo no exige del lector cambiar parámetros, por lo que no se necesita una acción de restauración aparte en la computadora del usuario.
Fuentes primarias públicas
Sección titulada «Fuentes primarias públicas»- Microsoft: Windows Performance Recorder — herramienta de grabación de trazas ETW utilizada en la metodología; verificado el 2026-09-20.
- Microsoft: About Event Tracing — modelo ETW y verificación de eventos perdidos; verificado el 2026-09-20.
- Microsoft: Microsoft Defender Antivirus en Windows — procesos y servicios de Defender, incluido
MsMpEng.exe(«Antimalware Service Executable» en el Task Manager); verificado el 2026-09-20. - Cómo investigamos Windows — niveles de evidencia y protocolo de mediciones.
- Service Host y componentes en segundo plano de Windows 11 — cómo Windows distribuye los servicios en segundo plano por procesos.
- Cuánta memoria se puede liberar realmente en Windows — análisis detallado de la memoria de este mismo experimento.
- Escritorio frente a pantalla de inicio de sesión — continuación: de qué se compone el ruido de la sesión de usuario.
Historial de cambios
Sección titulada «Historial de cambios»- 2026-09-20: primera publicación — dos series independientes de mediciones de reposo, fases tras el arranque, inventario y pruebas de carga.
- 2026-09-20: se precisó la atribución de resultados por series (commit y memoria física ocupada — solo serie 2; procesos −49…−56 %); el descargo de responsabilidad sobre el conflicto de intereses se llevó a la formulación canónica.