Convertir MiB a kB

Un mebibyte son 1.024 kibibytes, es decir 1.048.576 bytes. Las herramientas de Linux y las cifras de memoria se refieren casi siempre a esto, aunque escriban «MB».

Un kilobyte son 1.000 bytes cuando lo define un organismo de normalización y 1.024 cuando lo define un sistema operativo. Esta página calcula con 1.000; la unidad de 1.024 se llama kibibyte.

El factor es 1048,576, y casi nadie lo lleva encima. Redondeado a 1050 se desvía un 0,14 %, que pasa desapercibido en cifras pequeñas y se convierte en una unidad entera alrededor de 1000 MiB.

Ese es el dato que interesa antes de redondear: no el error en sí, sino a partir de dónde deja de ser despreciable. Por debajo de ahí el factor corto es el sensato; por encima, usa el campo de arriba, que no redondea hasta el momento de escribir el resultado.

Un MiB son 1.024 de la unidad de debajo; un MB, 1.000. En esta página eso es la diferencia entre 1048,576 kB y 1000 kB —un 4,9 %—, y la distancia crece en cada escalón: por eso es un redondeo despreciable en una foto y un trozo visible de un disco duro.

En eso consiste entero el misterio del espacio que falta, y en esta página vale un 4,9 %. Un disco vendido en MB tiene exactamente lo que dice la etiqueta; lo que pasa después es que Windows divide entre 1.024 en vez de entre 1.000, conserva el nombre decimal y muestra 1000 kB donde la caja ponía 1048,576 kB. macOS cuenta estas cifras en unidades decimales desde 10.6, y por eso el mismo disco puede parecer de dos tamaños en dos ordenadores: no falta nada ni redondea nadie, son los mismos bytes con dos nombres.

Las herramientas de compilación cuentan en potencias de dos porque describen lo que ocupa un sistema de archivos, y un empaquetador que imprime KiB y MiB está siendo honesto al hacerlo. Los presupuestos de peso de página se escriben en kilobytes decimales porque describen bytes que cruzan una red, donde las potencias de diez son el convenio desde mucho antes de que nadie enviara un megabyte de JavaScript. Los dos sistemas son coherentes por dentro y no dan el mismo número.

La conversión es una multiplicación por 1.048,576. Un paquete que la compilación llama 1,5 MiB son 1.572,864 kB: ni 1.536 ni 1.500. Frente a un presupuesto de 1.500 kB se pasa casi un cinco por ciento, y lo que esconde ese exceso es precisamente la conversión redonda que uno hace de cabeza, porque «un mebibyte y medio» suena a algo que cabe.

Escrito 1.048,576, el valor es correcto en España y en Argentina, y es otro número entero para cualquier programa configurado en inglés, que lee ahí más de un millón. El uso hispanohablante tampoco es uno solo: México y buena parte de Centroamérica y el Caribe escriben 1,048.576. Una lista de tamaños que pasa por dos equipos con configuraciones regionales distintas puede cambiar de magnitud sin que nadie haya tocado un dígito.

El CSV es donde más ocurre, porque no lleva ninguna indicación de cómo están escritos sus números y la hoja de cálculo aplica la configuración del sistema al abrirlo. La defensa práctica es no exportar cifras formateadas: guarda el recuento de bytes como entero, sin separador de miles ni decimales, y deja el número legible para la columna que solo va a leer una persona. Un entero no tiene región.

Antes de discutir un 4,86 % conviene comprobar que la cifra mide lo que uno cree. La compilación informa del tamaño del archivo que ha escrito; quien visita la página espera los bytes comprimidos que cruzaron la conexión. Los recursos de texto suelen quedarse entre la cuarta y la quinta parte de su tamaño en bruto, así que un paquete de 1,5 MiB pueden ser 350 kB en el cable, y un presupuesto escrito contra la cifra en bruto no se equivoca en un porcentaje sino en un factor.

Nada de eso hace innecesaria la conversión, porque la cifra comprimida también hay que expresarla en alguna unidad y arrastra la misma diferencia. Lo que fija es el orden: primero se decide qué etapa de la cadena describe el número, y después se convierte su unidad. Hacer bien lo segundo y mal lo primero produce una cifra muy precisa sobre la magnitud equivocada.

Un error de medición aleatorio se promedia con suficientes muestras; un error de unidad no, porque es la misma multiplicación siempre y siempre en la misma dirección. Cada recurso parece algo menor de lo que es, el total parece menor de lo que es, y toda comparación contra el presupuesto sale ligeramente optimista. Nada en el informe tiene aspecto de estar mal, y la discrepancia solo aparece frente a datos de campo recogidos por algo que contó bytes.

Lo que lo saca de la pedantería es la acumulación. Una página montada con veinte recursos convertidos con el factor redondo se queda corta en un 4,86 % del total, que en una página mediana son treinta o cuarenta kilobytes. Ese es el tamaño de una biblioteca pequeña entera, de las que un equipo dedica una tarde a quitar. Conviene decirlo en voz alta cuando alguien propone apretar el presupuesto: convertir bien recupera tantos kilobytes como una optimización de verdad, y cuesta una línea de aritmética en lugar de una refactorización.

Rara vez enseñan el mismo número para el mismo recurso, y los motivos se suman. El informe da bytes en bruto en unidades binarias; el panel de red da bytes transferidos, comprimidos, en unidades decimales, y puede incluir o no las cabeceras de la respuesta. Cualquiera de esas tres diferencias basta para separar las cifras en decenas de puntos porcentuales, y las tres juntas hacen que compararlas directamente no signifique nada.

La manera de compararlas es reducir ambas a un recuento de bytes de la misma magnitud. Toma el artefacto comprimido, lee su tamaño exacto y compáralo con el tamaño transferido que informa el navegador; lo que sobre debería ser poco y atribuible al protocolo. Cuando esos dos coinciden, cada herramienta puede seguir mostrando la unidad que prefiera, porque debajo hay un número del que las dos se derivan.

No están repartidos por igual. Los bytes que más pesan son los que bloquean la primera pintura: el CSS crítico, los scripts que deben ejecutarse antes de que aparezca el contenido, las fuentes que retienen el texto. Cincuenta kilobytes ahí valen más que quinientos en algo que se carga con calma cuando la página ya sirve, y un presupuesto que trate todos los bytes como iguales optimizará los equivocados con gran precisión.

Ahí es también donde la cuestión de la unidad deja de ser académica, porque los presupuestos de ruta crítica son los estrechos. Un objetivo de 150 kB de JavaScript bloqueante casi no tiene holgura, y convertir una cifra de 0,15 MiB como si fueran 150 kB en lugar de 157,2864 gasta un cinco por ciento del presupuesto en aritmética. En un fragmento diferido con un presupuesto diez veces mayor, el mismo error es invisible y nadie debería dedicarle un minuto.

Un presupuesto es un número que otra persona aplicará meses después sin el contexto que tú tenías. Necesita por tanto tres cosas dichas a su lado: la magnitud, la unidad con su sistema, y la etapa de la cadena — comprimido o en bruto, por recurso o por página. Cualquiera de las tres que se deje implícita la rellenará una suposición, y la suposición diferirá de la tuya con la frecuencia suficiente para importar.

La versión mecánica consiste en expresar el presupuesto en bytes allí donde se comprueba, y dejar la cifra legible en la documentación de al lado. Los bytes no se pueden malinterpretar, se comparan directamente con la medición interna de cualquier herramienta y ahorran a quien venga detrás tener que averiguar si quien fijó el número pensaba en 1.000 o en 1.024.

Multiplica por mil y añade un cinco por ciento. 2,4 MiB son 2.400 más 120, o sea unos 2.520 kB frente a 2.516,58 exactos. Eso basta para una conversación y para detectar un error de un orden de magnitud, que es para lo que sirve el cálculo mental. No basta para nada que vaya a escribirse en un archivo de configuración y a comprobarse automáticamente.

El umbral es si el número va a compararse con otro número. Una cifra citada en una discusión puede ser aproximada; una cifra que una herramienta va a verificar, o que va a quedar en una tabla junto a una medición de otra procedencia, tiene que ser la multiplicación exacta, porque una discrepancia de unos kilobytes en una comparación es indistinguible de una regresión real. Ese es el coste verdadero del atajo: no un número equivocado, sino una hora investigando un cambio que nunca ocurrió.