Gzip versus minify

Outro dia, tive uma discussão animada sobre como reduzir o Javascript e o CSS contra alguém que prefere usar o Gzip.

Vou chamar essa pessoa de X.

X disse que o Gzip já reduz o código, pois ele fecha os arquivos.

Discordo. Zip é um método sem perdas de diminuir o tamanho do arquivo. Sem perdas significa que o original deve ser restaurado perfeitamente, o que significa que as informações devem ser armazenadas para poder restaurar os espaços, os caracteres desnecessários, o código comentado e tudo o mais. Isso ocupa mais espaço, já que mais deve ser compactado.

Não tenho método de teste, mas acredito que o Gzip deste código:

.a1 {
    background-color:#FFFFFF;
    padding: 40px 40px 40px 40px;
}

Ainda será maior que o Gzip deste código:

.a1{body:background-color:#FFF;padding:40px}

Existe alguém que possa provar isso certo ou errado.
E por favor, não venha dizendo "Está certo, porque é o que eu sempre usei".

Estou pedindo provas científicas aqui.

Muito simples de testar. Peguei seus js, coloquei-os em arquivos diferentes e executei o gzip -9 neles. Aqui está o resultado. Isso foi feito em uma máquina WinXP executando o Cygwin e o gzip 1.3.12.

-rwx------  1 xxxxxxxx mkgroup-l-d     88 Apr 30 09:17 expanded.js.gz

-rwx------  1 xxxxxxxx mkgroup-l-d     81 Apr 30 09:18 minified.js.gz

Aqui está mais um teste usando um exemplo de JS do mundo real. O arquivo de origem é "common.js" O tamanho do arquivo original é 73134 bytes. Minificado, chegou a 26232 bytes.

Arquivo original:

-rwxrwxrwx 1 xxxxxxxx mkgroup-l-d 73134 Apr 13 11:41 common.js

Arquivo Minificado:

-rwxr-xr-x 1 xxxxxxxx mkgroup-l-d 26232 Apr 30 10:39 common-min.js

Arquivo original compactado com a opção -9 (mesma versão que acima):

-rwxrwxrwx 1 xxxxxxxx mkgroup-l-d 12402 Apr 13 11:41 common.js.gz

Arquivo compactado compactado com g-zip com a opção -9 (mesma versão que a anterior):

-rwxr-xr-x 1 xxxxxxxx mkgroup-l-d  5608 Apr 30 10:39 common-min.js.gz

Como você pode ver, há uma diferença definida entre os vários métodos. A melhor aposta é minificá-los e compactá-los.

Aqui estão os resultados de um teste que fiz há algum tempo, usando um arquivo CSS da "vida real" do meu site. O CSS Optimizer é usado para minificação. O aplicativo de arquivamento Linux padrão que acompanha o Ubuntu foi usado para o Gzipping.

Original: 28.781 bytes
Minificado: 22.242 bytes
Gzipado: 6.969 bytes
Min + Gzip: 5.990 bytes

Minha opinião pessoal é ir primeiro ao Gzipping, pois isso obviamente faz a maior diferença. Quanto à minificação, depende de como você trabalha. Você precisaria manter o arquivo CSS original para fazer edições mais adiante. Se não incomodá-lo para reduzi-lo após cada alteração, faça isso.

(Nota: existem outras soluções, como executá-lo por meio de um minificador "sob demanda" ao servir o arquivo e armazená-lo em cache no sistema de arquivos.)

Cuidado ao testar isso: esses dois trechos de CSS são trivialmente pequenos, portanto não se beneficiam da compactação GZIP - a adição do cabeçalho e rodapé pequenos do GZIP (sobrecarga de cerca de 20 bytes) por si só perderá os ganhos obtidos. Na realidade, você não teria um arquivo CSS tão pequeno e estaria preocupado em compactá-lo.

O minify + gzip comprime mais do que apenas o gzip

A resposta para a pergunta original é que sim, minify + gzip ganhará uma quantidade significativa de compactação a mais do que apenas gzip. Isso é verdadeiro para qualquer exemplo não trivial (ou seja, qualquer código JS ou CSS útil com mais de algumas centenas de bytes).

Para exemplos disso, pegue o código fonte do Jquery, que está disponível minificado e descompactado, compacte-os com o gzip e dê uma olhada.

Vale a pena notar que o Javascript se beneficia muito mais com a minificação do que o CSS bem otimizado, mas ainda há um benefício.

Raciocínio:

A compactação GZIP é sem perdas. Isso significa que ele precisa armazenar todo o texto, incluindo o espaço em branco exato, comentários, nomes longos de variáveis ​​e assim por diante, para que possam ser perfeitamente reproduzidos posteriormente. Por outro lado, a minificação é com perdas. Se você minifica seu código, está removendo muitas dessas informações, deixando menos que o GZIP precisa preservar.

• A minificação descarta espaços em branco desnecessariamente, deixando espaços somente onde necessário por razões sintáticas.
• Minificação remove comentários.
• A minificação de código pode substituir nomes de identificadores por nomes mais curtos, onde não haveria efeitos colaterais.
• A minificação de código pode fazer 'otimizações de compilador' triviais para o código, que só são possíveis analisando o código
• A redução de CSS pode eliminar regras redundantes ou combinar regras que possuem o mesmo seletor.

Você está certo.

Não é o mesmo que minificar que compactar com gzip (eles seriam chamados da mesma maneira, se esse fosse o caso). Por exemplo, não é o mesmo que gzip:

var myIncrediblyLongNameForThisVariableThatDoesNothingButTakeUpSpace = null;

Than minify para acabar com algo como:

var a = null;

É claro que, na maioria dos casos, eu diria que a melhor abordagem é reduzir o PRIMEIRO e depois o Gzip, do que apenas minificar ou compactar com gzip, embora dependendo do código algumas vezes apenas minificar ou gzip fornecerá melhores resultados do que fazer as duas coisas.

Há um limite no qual a codificação gzip é vantajosa. A regra geral é: quanto maior o arquivo, melhor será a compactação e o gzip. Claro que você pode minificar primeiro e depois gzip depois.

Mas se estamos falando de gzip vs. minify em um pequeno pedaço de texto com mais de 100 bytes de comprimento, uma comparação "objetiva" não é confiável e até inútil - a menos que apresentemos um texto de base para estabelecer um meio padrão de comparação, como um tipo Lorem Ipsum, mas escrito em Javascript ou CSS.

Então, deixe-me propor comparar as versões mais recentes do jQuery e MooTools (as versões descompactadas) usando meu código PHP ( Fat-Free Minify ) (simplesmente removendo espaços em branco e comentários, sem encurtamento de variáveis, sem codificação baseX)

Aqui estão os resultados de minify vs. gzip (na compressão conservadora de nível 5) vs. minify + gzip:

MooTools-Core
-------------
Baseline 102,991 bytes
Minified 79,414 (77.1% of original)
Gzipped 27,406 (26.6%)
Minified+Gzipped 22,446 (21.8%)

jQuery
------
Baseline 170,095
Minified 99,735 (58.6% of original)
Gzipped 46,501 (27.3%)
Minified+Gzipped 27,938 (16.4%)

Antes que alguém salte a arma, essa não é uma batalha das bibliotecas JS.

Como você pode ver, minificar + gzipping oferece uma melhor compactação em arquivos grandes . O código de redução tem suas vantagens, mas o principal fator é a quantidade de espaço em branco e os comentários presentes no código original. Nesse caso, o jQuery possui mais, oferecendo melhor minificação (muito mais espaços em branco na documentação embutida). A força da compactação Gzip está em quanta repetição existe no conteúdo. Portanto, não se trata de minify vs. gzip. Eles fazem as coisas de maneira diferente. E você obtém o melhor dos dois mundos usando os dois.

Por que não usar os dois?

É fácil testar: basta colocar o texto do seu css em arquivos de texto e compactar os arquivos usando um arquivador como o gzip no linux.

Acabei de fazer isso, e acontece que, para o primeiro css, o tamanho é 184 bytes e para o segundo, 162 bytes.

Portanto, você está certo, o espaço em branco é importante mesmo para arquivos compactados com gzip, mas como se pode ver neste pequeno teste, para arquivos muito pequenos, o tamanho do arquivo compactado pode ser maior que o tamanho do arquivo original.

Isso se deve apenas ao tamanho muito pequeno do seu exemplo; para arquivos maiores, o gzipping gera arquivos menores.

Eu não vi ninguém mencionar Mangling, então estou postando meus resultados nisso.

Aqui estão algumas figuras que eu criei usando o UflifyJS para minificação e Gzip. Eu tinha cerca de 20 arquivos que concatenei juntos a cerca de 2,5 MB com comentários e tudo.

Arquivos Concat 2,5MB

uglify({
    mangle: false
})

Minificado sem confundir: 929kb

uglify({
    mangle: true
})

Minificado e mutilado: 617kb

Agora, se eu pegar esses arquivos e compactá-los, obterá 239kb e 190kb, respectivamente.

Existe um método muito simples de testar isso: Crie um arquivo que consiste apenas em espaço em branco e outro arquivo que esteja realmente vazio. Gzip ambos e compare seus tamanhos. O arquivo com o espaço em branco será obviamente maior.

É claro que a compactação com perdas "humana" que preserva o layout ou outras coisas importantes e remove qualquer lixo desnecessário (espaços em branco, comentários, coisas redundantes etc.) será melhor do que uma compactação gZip sem perdas.

Por exemplo, coisas como marcas ou nomes de funções provavelmente terão um certo comprimento para descrever o significado. Substituir isso por nomes com um caractere economiza muito espaço e não é possível com a compactação sem perdas.

A propósito, para CSS, existem ferramentas como o compressor CSS que farão o trabalho com perdas para você.

No entanto, você obterá os melhores resultados ao combinar "otimização com perdas" e compactação sem perdas.

é claro que você pode testar - escreva seu em um arquivo e gzip com zlib . Você também pode tentar com o programa utilitário "gzip".

de volta à sua pergunta - não há relação definida entre o comprimento da fonte e o resultado compactado. o ponto principal é a 'entropia' (quão diferentes são os elementos na fonte).

Então, isso depende de como é a sua fonte. por exemplo, muitos espaços contínuos (por exemplo,> 1000) podem ser compactados com o mesmo tamanho de poucos espaços (por exemplo, <10).

este é o resultado ao compactar os dois arquivos

bytes  File
45     min.txt
73     min.gz

72     normal.txt
81     normal.gz

Você está correto, minify + gzip resulta em menos bytes. Nenhuma prova científica embora.

Como é que você não tem método de teste?

Minimize seu código em um arquivo e deixe "não minificado" em outro. Faça o upload para um servidor Web capaz de compactar com gzip a saída (mod_deflate para Apache, por exemplo), instale a extensão Firebug para firefox, limpe seu cache e acesse os dois arquivos. A aba "NET" do Firebug conterá a quantidade exata de dados transferidos, compare-os e você terá uma prova "empírica".