Converter MiB para kB

Um mebibyte são 1.024 kibibytes, ou seja 1.048.576 bytes. As ferramentas do Linux e os números de memória quase sempre se referem a isto, mesmo escrevendo «MB».

Um kilobyte são 1.000 bytes quando quem define é um órgão de normalização e 1.024 quando quem define é um sistema operacional. Esta página calcula com 1.000; a unidade de 1.024 se chama kibibyte.

O fator é 1048,576, e quase ninguém carrega isso na cabeça. Arredondado para 1050 ele erra 0,14 % — invisível em números pequenos, e já uma unidade inteira por volta de 1.000 MiB.

É esse o número que interessa antes de arredondar: não o erro em si, mas a partir de onde ele deixa de ser desprezível. Abaixo disso o fator curto é o sensato; acima, use o campo lá em cima, que só arredonda na hora de escrever.

Um MiB são 1.024 da unidade de baixo; um MB, 1.000. Nesta página isso é a diferença entre 1048,576 kB e 1000 kB — 4,9 % — e a distância cresce a cada degrau: por isso é arredondamento desprezível numa foto e um pedaço visível de um HD.

O mistério do espaço que some é inteiro isso. Um disco vendido como um terabyte tem exatamente o que diz em unidades decimais; o Windows reconta em unidades binárias e mantém o nome decimal, então o número encolhe sem que nada tenha se perdido. O macOS conta em unidades decimais desde o 10.6, e é por isso que o mesmo disco pode aparecer com dois tamanhos em dois computadores.

Ferramentas de build contam em unidades binárias porque estão descrevendo o que o sistema de arquivos guarda, e um empacotador que imprime KiB e MiB está sendo honesto. Orçamentos de desempenho são escritos em kilobytes decimais porque descrevem bytes atravessando uma rede, onde potências de dez são a convenção desde muito antes de qualquer site enviar um megabyte inteiro de JavaScript. Os dois são internamente consistentes e não concordam entre si.

A conversão é uma multiplicação por 1.048,576. Um pacote relatado como 1,5 MiB são 1.572,9 kB, não 1.536 e não 1.500. Contra um orçamento de 1.500 kB, ele está 4,9% acima, e a conversão redonda de cabeça é exatamente o que esconde isso — "1,5 MiB" soa como "cerca de um megabyte e meio", o que soa como algo que cabe.

Antes de se preocupar com os 4,9%, confira se o número está medindo a coisa certa. Uma ferramenta de build relata o tamanho do arquivo que escreveu; um usuário espera pelos bytes comprimidos que atravessaram a conexão. Arquivos de texto costumam comprimir para algo entre um quinto e um quarto do tamanho bruto, então um pacote de 1,5 MiB pode virar 350 kB na rede, e um orçamento escrito contra o valor bruto está errado por um fator, não por uma porcentagem.

Isso não torna a conversão de unidade desnecessária — o valor comprimido também precisa ser expresso em alguma unidade, e o mesmo 2,4% se aplica a ele. Torna a ordem das operações clara: primeiro estabeleça em que etapa do pipeline o número está, depois converta a unidade.

Um erro de medição aleatório se cancela ao longo de muitos ativos; um erro de unidade não, porque é a mesma multiplicação toda vez e sempre na mesma direção. Cada ativo parece um pouco menor do que é, o total parece menor do que é, e toda comparação com o orçamento fica levemente otimista.

A composição é o que transforma isso de pedantismo em lacuna real. Uma página montada de vinte ativos, cada um convertido com o fator redondo, fica curta em 2,4% no total — talvez trinta ou quarenta kilobytes numa página moderada. É aproximadamente o tamanho de uma biblioteca pequena inteira, o tipo de coisa em que times gastam uma tarde inteira tentando remover.

Os dois raramente vão mostrar o mesmo número para o mesmo ativo. O relatório de build mostra bytes brutos em unidade binária; o painel de rede mostra bytes transferidos, comprimidos, em unidade decimal, e pode ou não incluir cabeçalhos de resposta. Qualquer uma dessas diferenças basta para fazer os valores discordarem em dezenas de por cento.

O jeito de compará-los é reduzir os dois a uma contagem de bytes da mesma grandeza. Pegue o artefato comprimido, leia o tamanho exato, e compare contra o tamanho transferido que o navegador relata; o que sobrar deveria ser pequeno e atribuível à sobrecarga de protocolo. Depois que os dois baterem, as unidades amigáveis de cada ferramenta podem ser o que preferirem.

Nem tudo. Os bytes que mais importam são os que bloqueiam a primeira renderização — o CSS crítico, os scripts que têm que executar antes de qualquer conteúdo aparecer, as fontes que seguram texto. Cinquenta kilobytes ali valem mais do que quinhentos em algo carregado sob demanda depois que a página já está usável.

É também onde a questão de unidade deixa de ser acadêmica, porque orçamentos de caminho crítico são os mais apertados. Uma meta de 150 kB de JavaScript bloqueante quase não tem folga; converter um valor de 0,15 MiB como se fossem 150 kB em vez de 157,3 kB já gastou cinco por cento do orçamento em aritmética.

Multiplique por mil e some cinco por cento. 2,4 MiB ficam perto de 2.400 mais 120, então cerca de 2.520 kB contra 2.516,6 exatos. É preciso o bastante para uma conversa e para pegar um erro de ordem de grandeza, que é para isso que serve aritmética mental. Não é preciso o bastante para nada que vá entrar num arquivo de configuração e ser aplicado.

O critério para fazer com exatidão é se o número vai ser comparado contra outro número. Um valor citado numa conversa pode ser aproximado; um valor que uma ferramenta vai conferir, ou que vai sentar numa tabela ao lado de uma medição de outro lugar, precisa da multiplicação exata, porque uma discrepância de alguns kilobytes numa comparação é indistinguível de uma regressão real.