¿Por qué «queda 1 segundo» tarda tanto? — Cómo funcionan las barras de progreso y las estimaciones de tiempo

Lleva 30 segundos viendo «queda 1 segundo». Justo cuando espera que termine, cambia a «quedan 2 minutos».

Copias de archivos, instalaciones de aplicaciones, exportaciones de vídeo: las barras de progreso son útiles, pero a veces parecen funcionar en un mundo distinto del reloj.

En realidad, una barra de progreso no es un reloj. El porcentaje describe cuánto trabajo se ha completado; la estimación de tiempo predice cuánto podría tardar el trabajo restante; el término significa que las operaciones necesarias han tenido éxito. Separar esas tres ideas cambia cómo se lee una tarea que no acaba al 99 %.

Este artículo explica los mecanismos generales usando la documentación de las API y la interfaz de Windows. No aplica ingeniería inversa al algoritmo interno de una versión concreta del Explorador de archivos. Los ejemplos numéricos y la demo comparativa usan cargas de trabajo ficticias, no mediciones en un PC o una conexión de red.

1. Pregunte primero: ¿100 % de qué?

Imagine que revisa 100 documentos. Si 99 son notas breves y el último un contrato extenso, «99 documentos terminados» puede ser correcto sin significar «ha transcurrido el 99 % del tiempo».

Un indicador de progreso también cambia de significado según su denominador.

Por ejemplo, la devolución de llamada de progreso que usa la API de Windows CopyFileEx recibe el tamaño total del archivo y los bytes transferidos. Esos valores describen trabajo, no segundos futuros. ¹

flowchart TB
    accTitle: Porcentaje de progreso, tiempo restante y término
    accDescr: El diagrama separa una proporción calculada a partir del trabajo realizado, una estimación de tiempo basada en una velocidad supuesta y un término acreditado por resultados correctos.
    A["Trabajo realizado y trabajo total"] --> B["Porcentaje de progreso"]
    C["Trabajo restante y velocidad prevista"] --> D["Tiempo restante estimado"]
    E["Las operaciones necesarias tienen éxito"] --> F["Tarea completa terminada"]

Figura 1: Una proporción, una predicción y un resultado no son tres nombres para la misma información.

A lo largo de este artículo, porcentaje de progreso significa la fracción de trabajo medible completada, barra de progreso su indicador visual, y tiempo restante estimado la duración prevista. No poder hacer una predicción fiable no borra el progreso ya medido.

En el diagrama, una línea continua marca una relación que siempre se cumple y una línea discontinua una relación condicional (las condiciones están en la explicación de cada relación en la página de detalle). La lista completa de relaciones (9 en total, con evidencia y grado de certeza) y las definiciones de los conceptos principales están reunidas en la página de detalle del mapa de conocimiento (en japonés). Datos: JSON-LD / Turtle

2. Cómo 10 segundos restantes se convierten en 79

La estimación más sencilla usa esta ecuación:

Tiempo restante ≈ trabajo restante ÷ velocidad de procesamiento futura estimada

Lo difícil no es la división. Es que la velocidad futura todavía no se ha observado. Por eso usamos la velocidad pasada para predecirla. En una explicación de 2004 sobre las estimaciones de tiempo de copia, Raymond Chen, de Microsoft, describió esa dificultad de predecir el futuro. Aquel artículo no es una especificación del cálculo que usa el Windows actual. ²

Considere una copia ficticia de 1.000 MiB. Un MiB son 1.048.576 bytes. Suponga que primero avanza a 80 MiB/s constantes durante 2,5 segundos y luego baja a 10 MiB/s durante el segundo siguiente.

La tarea ha avanzado durante ese segundo. Aun así, la velocidad estimada para el trabajo restante ha caído a una octava parte de su valor anterior, de modo que la duración prevista aumenta. Este ejemplo usa directamente la velocidad del último intervalo de observación.

flowchart TB
    accTitle: Por qué el tiempo restante puede subir mientras el trabajo avanza
    accDescr: Si la velocidad prevista cae lo suficiente, su efecto supera la reducción del trabajo restante y el tiempo restante calculado aumenta.
    A["10 MiB completados en un segundo"] --> B["Queda menos trabajo"]
    C["La velocidad prevista cae bruscamente"] --> D["El tiempo restante puede aumentar"]
    B --> D

Figura 2: Un aumento de la estimación de tiempo no significa que la operación haya retrocedido.

Lo mismo vale para «queda 1 segundo». Una cantidad que a la velocidad anterior tardaría un segundo tardará más si la siguiente operación es más lenta. Los intervalos de observación y el redondeo también afectan a la pantalla. Ahora bien, una cifra que nunca cambia no debe darse por normal sin más: distinga, como se explica abajo, fases de procesamiento, actualizaciones de interfaz y atascos reales.

3. ¿Haría exacta la estimación promediar?

Refleje cada breve cambio de velocidad y la estimación salta arriba y abajo. Use solo la media desde el inicio y un periodo inicialmente rápido puede mantener la estimación optimista mucho después de una ralentización sostenida.

Esto se deriva de cómo se combinan las observaciones. Supongamos que damos el mismo peso a una velocidad previa de 80 y a una nueva de 10. La velocidad prevista pasa a ser 45. Cambia de forma menos abrupta que una estimación basada solo en el último valor de 10, pero si la velocidad realmente se mantiene en 10, sigue siendo optimista un tiempo. La suavidad y la capacidad de reacción al cambio son objetivos distintos.

flowchart TB
    accTitle: El compromiso al suavizar las estimaciones de velocidad
    accDescr: Dar más peso a las observaciones recientes hace la estimación reactiva pero variable, mientras que dar más peso al historial la hace más suave pero más lenta en adaptarse.
    A["Observaciones de velocidad"] --> B["Más peso a los datos recientes"]
    A --> C["Más peso al historial"]
    B --> D["Reactiva pero variable"]
    C --> E["Suave pero más lenta en adaptarse"]

Figura 3: Una cifra de apariencia estable no es necesariamente una predicción exacta.

Este es un ejemplo para razonar sobre la estimación, no la descripción de un producto concreto. Mi recomendación de diseño es evitar forzar una cuenta atrás justo después del arranque o de un cambio de fase. Espere a tener observaciones útiles y presente después una estimación como «alrededor de un minuto». Decir que se está recalculando la estimación puede inducir menos a error que mantener un «queda 1 segundo» sin fundamento.

4. 99 archivos terminados, pero solo el 9,9 % de los datos

Considere ahora la unidad que se cuenta en lugar de la velocidad. Hay 100 archivos: los primeros 99 de 1 MiB cada uno y el último de 901 MiB. El total son 1.000 MiB.

Tras los primeros 99 archivos, el número de archivos da 99 ÷ 100 = 99 %. El volumen de datos da 99 ÷ 1.000 = 9,9 %. Solo queda un archivo, pero contiene el 90,1 % de los datos. Ambos cálculos son correctos: miden cosas distintas.

flowchart TB
    accTitle: Cuando el último archivo es grande
    accDescr: Un archivo final grande tras 99 archivos pequeños hace que el progreso por número difiera mucho del progreso por bytes.
    A["99 archivos pequeños"] --> B["Casi terminado por número de archivos"]
    C["Queda un archivo grande"] --> D["Queda gran parte de los datos"]
    B --> E["Vistas distintas de una misma tarea"]
    D --> E

Figura 4: El 99 % por número de archivos no promete que solo quede el 1 % del tiempo.

¿Bastan entonces los recuentos de bytes? No. Transferir muchos archivos pequeños por SMB acarrea repetidamente el coste de crear archivos y de los viajes de ida y vuelta de las peticiones. El mismo número total de bytes no tiene por qué tardar lo mismo que un único archivo grande. ³

En consecuencia, «quedan 500 MiB» puede ser una medición exacta mientras el tiempo necesario varía con el contenido de esos 500 MiB. Mostrar tanto archivos como bytes es útil no porque una cifra sea errónea, sino porque cada una revela algo que la otra deja fuera.

5. «Preparando» puede significar: se está averiguando el denominador

Un porcentaje necesita un total como denominador. Pero pedirle a una aplicación que procese una carpeta entera no significa necesariamente que ya haya enumerado todos los archivos que contiene.

Suponga que la aplicación cree que hay 100 elementos, procesa 80 y luego descubre otros 100. Esos mismos 80 elementos completados representan ahora 80/200 en lugar de 80/100. La pantalla baja del 80 % al 40 %, pero el trabajo realizado no se ha esfumado. Presentar un total provisional como definitivo creó el desajuste con la expectativa de quien lee.

flowchart TB
    accTitle: Mostrar el progreso antes de conocer el total
    accDescr: Mientras se descubren los objetivos, evite un porcentaje definitivo; una vez conocido el total, combínelo con el trabajo realizado para mostrar una proporción.
    A["Descubrir los objetivos"] --> B{"¿Se conoce el total?"}
    B -->|"Todavía no"| C["Mostrar la fase y el número descubierto"]
    B -->|"Sí"| D["Mostrar un porcentaje"]

Figura 5: Un denominador desconocido no es lo mismo que un progreso del 0 %.

Windows ofrece controles de progreso tanto para valores determinados como para actividad indeterminada. ⁴ Para esta situación recomiendo mostrar algo como «Buscando elementos: 1.200 descubiertos» y, una vez conocido el total, un porcentaje. La ausencia de una cuenta atrás no es prueba de que no esté ocurriendo nada.

6. «Transferencia 100 %» y «todo terminado» marcan fronteras distintas

6.1 Al final puede quedar otra operación

A modo de ilustración, dividamos el trabajo de una aplicación en tres fases: transferencia, verificación y finalización del resultado. Si el diseño exige una verificación tras la transferencia, la tarea completa no ha terminado cuando acaba la transferencia. Es un ejemplo de diseño de aplicación, no la afirmación de que toda copia o instalación siga estas fases.

flowchart TB
    accTitle: Fin de la transferencia frente a término general
    accDescr: Esta aplicación ficticia verifica y finaliza el resultado tras la transferencia, de modo que los bytes transferidos por sí solos no pueden acreditar el éxito general.
    A["Transferencia"] --> B["Verificación"] --> C["Finalizar el resultado"] --> D["Éxito general"]
    A -.-> E["La transferencia al 100 % acaba aquí"]

Figura 6: Un alcance explícito hace posible explicar por qué tras el 100 % sigue otra fase.

En lugar de mantener una barra general al 99 % con «queda 1 segundo», resulta más coherente cambiar el estado a «Transferencia completada; verificando». Las recomendaciones de interfaz de Microsoft para aplicaciones de escritorio también desaconsejan mostrar un término general antes de que la operación haya acabado realmente. ⁵

6.2 Las escrituras también tienen más de una frontera

Windows normalmente usa caché para las escrituras de archivos. Según los ajustes y los contratos de las API, escribir desde la aplicación y confirmar los datos en el almacenamiento son fronteras distintas. ⁶ FlushFileBuffers es una API para enviar al dispositivo la información almacenada en búfer de un archivo determinado. ⁷

flowchart TB
    accTitle: Una visión conceptual de las escrituras en búfer
    accDescr: Con el uso de búfer, la escritura aceptada por la aplicación y la posterior escritura del lado del almacenamiento no deben tratarse como el mismo evento.
    A["La aplicación escribe"] --> B["Retenido en un búfer"] --> C["Escrito en el almacenamiento"]

Figura 7: Este es un diagrama conceptual de las escrituras en búfer, no el contrato de término de un producto concreto.

Sin embargo, una pausa al 99 % no siempre se debe al vaciado de una caché. Si la tarea está verificando, vaciando o esperando otra cosa hay que determinarlo a partir de su diseño o de sus registros. No deduzca de un mero número de progreso que sea seguro desconectar un dispositivo USB o cortar la alimentación.

7. ¿Se ha parado la tarea o solo la pantalla?

En una aplicación WPF de Windows, el Dispatcher del subproceso de interfaz procesa el trabajo de interfaz. Ocupar ese subproceso mucho tiempo retrasa las actualizaciones y las respuestas a la entrada. Distinga la operación subyacente del trabajo que pone sus resultados en pantalla. ⁸

flowchart TB
    accTitle: El camino del procesamiento a la visualización del progreso
    accDescr: Aunque la operación informe de su progreso, la pantalla no puede reflejarlo hasta que la interfaz procesa la actualización.
    A["Procesamiento real"] --> B["Informar del progreso"] --> C["Procesar la actualización de interfaz"] --> D["Actualizar la pantalla"]
    E["Subproceso de interfaz bloqueado"] -.-> C

Figura 8: Una pantalla congelada no significa necesariamente que la operación en sí esté congelada.

A la inversa, una animación diseñada para funcionar con independencia del trabajo real puede seguir girando mientras ese trabajo espera. «Se mueve, luego está bien; está quieto, luego está roto» no es una distinción suficiente.

Recomiendo registrar primero la pantalla y la hora de inicio, comprobar si hay avisos a la espera de respuesta y comparar contadores o registros a lo largo del tiempo. Trate las lecturas del Administrador de tareas como pruebas de apoyo. Antes de plantearse terminar el proceso, compruebe el procedimiento de cancelación de la aplicación y qué ocurre con la salida parcial.

La cancelación en .NET también es cooperativa: solicitar la cancelación no detiene por sí mismo la operación de inmediato; la operación debe responder. ⁹ Por eso «cancelando» y «cancelado» deberían ser estados distintos. Una pantalla de progreso por sí sola no puede ofrecer un número universal de minutos tras el cual forzar el cierre de la aplicación resulte seguro.

8. Comparar tres presentaciones de la misma operación

Abrir la demo comparativa de barras de progreso

La demo avanza por observaciones de una carga de trabajo ficticia cuando se pulsa un botón. No hay que esperar, y no lee, escribe ni sube archivos. El primer caso contiene 99 archivos pequeños y uno grande. Para cada observación muestra en paralelo una barra por número de archivos, otra por datos transferidos y el estado general de la tarea.

Mientras se transfiere el último archivo grande, la barra por número se mantiene al 99 % aunque la barra de volumen de datos crezca. Cuando los datos transferidos llegan al 100 %, el estado general sigue siendo «verificando». Solo la siguiente observación marca el éxito. Puede verse cómo un mismo trabajo puede parecer atascado o activo únicamente por la forma de mostrarlo.

flowchart TB
    accTitle: Cómo leer la demo comparativa
    accDescr: Una sola observación de una operación ficticia alimenta tres presentaciones: número de archivos, datos transferidos y estado general.
    A["Una operación ficticia"] --> B["La misma observación"]
    B --> C["Porcentaje por número de archivos"]
    B --> D["Porcentaje por datos transferidos"]
    B --> E["Estado general de la tarea"]

Figura 9: La demo compara tres vistas de una operación, no tres operaciones distintas.

El segundo caso reproduce la ralentización de la sección 2 y muestra el cálculo que convierte 10 segundos en 79. Usa el cálculo siguiente. Es una estimación didáctica deliberadamente sencilla, no una implementación de producción con reintentos, procesamiento paralelo o predicción por fases.

function estimateSeconds(remaining, rate) {
  if (!Number.isFinite(remaining) || remaining < 0) return null;
  if (remaining === 0) return 0;
  if (!Number.isFinite(rate) || rate <= 0) return null;
  const seconds = remaining / rate;
  return Number.isFinite(seconds) ? seconds : null;
}

Use unidades coherentes para remaining y rate, por ejemplo MiB y MiB/s. Un valor devuelto de cero significa que no queda nada de la carga de trabajo medida, no que la tarea completa de la aplicación haya tenido éxito. Con trabajo restante positivo, una velocidad de cero o desconocida produce null, para que una estimación desconocida no se confunda con «quedan 0 segundos».

9. El objetivo es no inducir a error, no solo parecer preciso

Para el diseño del que aquí se habla, mantendría separados la fase actual, el trabajo medido, una estimación de tiempo solo cuando esté justificada y el resultado de éxito, fallo o cancelación. Aun combinando porcentajes de fases en una sola barra, un reparto como «transferencia 80 %, verificación 20 %» representa pesos de diseño, no una garantía sobre el reparto del tiempo de esta ejecución.

flowchart TB
    accTitle: Construir una pantalla de progreso a partir de observaciones
    accDescr: Muestre la fase actual, las cantidades medidas, una estimación de tiempo cuando esté justificada y el resultado final como información separada.
    A["Información procedente de la operación"] --> B["Fase actual"]
    A --> C["Trabajo medido y total"]
    A --> D["Estimación cuando esté justificada"]
    A --> E["Éxito, fallo o cancelación"]

Figura 10: Mantenga distintas las observaciones y las predicciones también en pantalla.

«Verificando: 400 / 1.000 elementos; calculando el tiempo restante» puede ser útil sin cuenta atrás. Si muestra una marca de tiempo, distinga «último aumento del progreso» de «última comunicación correcta con la interfaz». No actualice solo la segunda de un modo que haga parecer que una tarea atascada avanza con normalidad.

El mismo principio vale para la accesibilidad. El elemento HTML progress puede representar un progreso indeterminado omitiendo su valor. ¹⁰ Para un indicador de progreso ARIA propio, omita aria-valuenow cuando el valor sea desconocido y proporcione un nombre accesible que identifique qué está progresando. ¹¹ Tanto la presentación visual como la información leída en voz alta deberían reflejar con honestidad lo que se sabe.

10. Preguntas frecuentes

¿«Queda un segundo» sin que termine significa que algo ha fallado?

La pantalla por sí sola no puede decidirlo. Distinga una estimación inexacta, otra fase, actualizaciones de interfaz retrasadas y un atasco real. Tanto «es habitual, así que estará bien» como «ha pasado un segundo, así que está roto» sacan conclusiones precipitadas.

¿El 99 % significa que queda el 1 % del tiempo total?

No. Cuente el porcentaje archivos o bytes, el tiempo por unidad no tiene por qué ser constante. Multiplicar el tiempo transcurrido por el 1 % no da la duración restante.

¿Una animación que gira significa que la tarea va bien?

Un indicador de actividad y una prueba de que el trabajo avanza son cosas distintas. Observe conjuntamente el trabajo realizado, las fases y los registros. La animación por sí sola no garantiza que la tarea pueda llegar a completarse con éxito.

¿Puedo mostrar progreso sin conocer el tiempo restante?

Si se conocen la cantidad total y la completada, puede mostrar su proporción. Omita solo la cuenta atrás cuando la predicción no sea fiable. Cuando el propio total es desconocido, use un indicador indeterminado con la fase y el número de elementos completados.

11. Resumen: el tiempo restante es un pronóstico; el término, un resultado

«Queda un segundo» no tarda mucho porque el ordenador no sepa contar hasta uno. Tarda porque se usa el trabajo observado para estimar un tiempo de procesamiento que todavía no ha ocurrido. Las unidades de recuento, el descubrimiento de los objetivos, las fases finales y las actualizaciones de interfaz retrasadas añaden más complicaciones.

flowchart TB
    accTitle: Preguntas que hacerse ante una pantalla de progreso que no acaba
    accDescr: Compruebe qué mide el porcentaje, si ha cambiado la velocidad prevista, si queda otra fase y si lo atascado es la interfaz o la operación real.
    A["¿Porcentaje de qué?"] --> B["¿Ha cambiado la velocidad prevista?"] --> C["¿Queda otra fase?"] --> D["¿Atasco de la interfaz o del procesamiento?"]

Figura 11: Convierta la irritación ante una cifra en preguntas que pueda investigar.

Como usuario, fíjese en las fases y los cambios más que en las cifras solas. Como desarrollador, no mezcle trabajo medido, predicción y resultados. Más importante que acertar una y otra vez con «un segundo» es explicar qué está pasando ahora y qué sigue siendo desconocido. Ese es el cometido de una buena pantalla de progreso.

Enlaces de referencia

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Una tarea atascada en un segundo restante significa que algo ha fallado?

La pantalla por sí sola no puede decírselo. Distinga una estimación de velocidad inexacta, una fase de procesamiento final, una interfaz detenida y un atasco real. Compruebe los cambios en los contadores y los registros y busque avisos a la espera de una respuesta. No fuerce el cierre de la aplicación solo porque indique un segundo restante.

¿El 99 % significa que solo queda el 1 % del tiempo total?

No. El significado depende de si el porcentaje mide elementos, bytes o fases ponderadas, y esas unidades no tienen por qué requerir el mismo tiempo. Un porcentaje de progreso mide una fracción del trabajo, no el tiempo restante en sí.

¿Una animación que gira demuestra que la tarea va bien?

No. Cuando la animación y el procesamiento son independientes, la animación puede seguir mientras la tarea espera. Distinga la animación de las pruebas de trabajo realizado, como contadores, cambios de fase y registros.

¿Puedo mostrar una barra de progreso sin una estimación de tiempo fiable?

Sí. Cuando se conocen la cantidad total y la completada, puede mostrar su proporción y omitir la estimación de tiempo si la velocidad es inestable. Cuando el propio total es desconocido, muestre la fase o el número de elementos completados en lugar de inventar un porcentaje.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.