Gzip versus minify

Tuve un debate animado el otro día sobre la minimización de Javascript y CSS frente a alguien que prefiere usar Gzip.

Llamaré a esta persona X.

X dijo que Gzip ya minimiza el código, ya que comprime tus archivos.

Estoy en desacuerdo. Zip es un método sin pérdidas para reducir el tamaño del archivo. Sin pérdida significa que el original debe restaurarse perfectamente, lo que significa que la información debe almacenarse para poder restaurar los espacios, los caracteres innecesarios, el código comentado y todo lo demás. Eso ocupa más espacio, ya que se debe comprimir más.

No tengo ningún método de prueba, pero creo que el Gzip de este código:

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

Todavía será más grande que el Gzip de este código:

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

¿Hay alguien que pueda probar que esto está bien o mal?
Y por favor no vengas diciendo “Está bien porque eso es lo que siempre he usado”.

Estoy pidiendo pruebas científicas aquí.

Muy simple de probar. Cogí tu js, los puse en diferentes archivos y ejecuté gzip -9 en ellos. Este es el resultado. Esto se hizo en una máquina WinXP que ejecuta Cygwin y gzip 1.3.12.

 -rwx------ 1 xxxxxxxx mkgroup-ld 88 Apr 30 09:17 expanded.js.gz -rwx------ 1 xxxxxxxx mkgroup-ld 81 Apr 30 09:18 minified.js.gz 

Aquí hay otra prueba usando un ejemplo de JS del mundo real. El archivo fuente es “common.js” El tamaño del archivo original es 73134 bytes. Minificado, llegó a 26232 bytes.

Archivo original:

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

Archivo Minificado:

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

El archivo original tiene gzip con la opción -9 (la misma versión anterior):

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

Archivo modificado gzip con la opción -9 (misma versión que la anterior):

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

Como puede ver, hay una diferencia definitiva entre los diversos métodos. La mejor apuesta es tanto minimizar como gzip.

Aquí están los resultados de una prueba que hice hace un tiempo, usando un archivo CSS de “vida real” de mi sitio web. CSS Optimiser se usa para la minificación. La aplicación de archivo estándar de Linux que viene con Ubuntu se usó para Gzipping.

Original: 28,781 bytes
Minificado: 22,242 bytes
Gzipped: 6,969 bytes
Min + Gzip: 5,990 bytes

Mi opinión personal es ir primero a Gzipping, ya que obviamente hace la mayor diferencia. En cuanto a la minificación, depende de cómo trabajas. Tendría que conservar el archivo CSS original para poder realizar ediciones más adelante. Si no te molesta minimizarlo después de cada cambio, entonces hazlo.

(Nota: hay otras soluciones, como ejecutarlo a través de un minificador “a pedido” cuando se sirve el archivo, y almacenarlo en caché en el sistema de archivos).

Tenga cuidado al probar esto: esos dos fragmentos de CSS son trivialmente pequeños, por lo que no se benefician de la compresión GZIP; la adición del encabezado pequeño de GZIP solo perderá las ganancias obtenidas. En realidad, no tendría un archivo CSS tan pequeño y le preocuparía comprimirlo.

minify + gzip comprime más que solo gzip

La respuesta a la pregunta original es, sí, minify + gzip obtendrá una cantidad significativamente mayor de compresión que solo gzip. Esto es cierto para cualquier ejemplo no trivial (es decir, cualquier código JS o CSS útil que tenga más de unos cientos de bytes).

Para ver ejemplos de esto en efecto, tome el código fuente de Jquery que está disponible minimizado y sin comprimir, comprímalos con gzip y échale un vistazo.

Vale la pena señalar que Javascript se beneficia mucho más de la minificación que CSS bien optimizado, pero todavía hay un beneficio.

Razonamiento:

La compresión GZIP no tiene pérdidas. Esto significa que tiene que almacenar todo el texto, incluidos el espacio en blanco exacto, los comentarios, los nombres largos de las variables, etc. para que puedan reproducirse perfectamente más adelante. Por otro lado, la minificación es con pérdida. Si minimizas tu código, estás eliminando gran parte de esta información de tu código, dejando menos que GZIP necesite preservar.

  • La minimización descarta innecesariamente el espacio en blanco, dejando espacios solo donde sea necesario por razones sintácticas.
  • La minificación elimina los comentarios.
  • La minificación de código puede reemplazar los nombres de los identificadores con nombres más cortos donde no habría efectos secundarios.
  • La minificación de código puede hacer ‘optimizaciones de comstackdor’ triviales para el código que solo son posibles al analizar realmente el código
  • La minificación de CSS puede eliminar reglas redundantes o combinar reglas que tienen el mismo selector.

Tienes razón.

No es lo mismo minificar que gzipping (se llamarían igual si ese fuera el caso). Por ejemplo, no es lo mismo hacer gzip esto:

 var myIncrediblyLongNameForThisVariableThatDoesNothingButTakeUpSpace = null; 

Que minify para terminar con algo como:

 var a = null; 

Por supuesto, diría que el mejor enfoque en la mayoría de los casos es ministrar PRIMERO luego Gzip, que solo minificar o gzip, aunque dependiendo del código a veces solo minifying o gzipping le dará mejores resultados que haciendo ambos.

Hay un umbral en el que la encoding gzip es ventajosa. La regla general es: cuanto mayor sea el archivo, mejor será la compresión y gzip ganará sin problemas. Por supuesto, puedes minimizar primero y luego gzip después.

Pero si hablamos de gzip vs. minify en un pequeño trozo de texto de no más de 100 bytes de largo, una comparación “objetiva” no es confiable, incluso sin sentido, a menos que obtengamos un texto de referencia para establecer un estándar de benchmarking, como un tipo Lorem Ipsum pero escrito en Javascript o CSS.

Así que permítanme proponer comparar las últimas versiones de jQuery y MooTools (las versiones sin comprimir) usando mi código Fat-Free Minify (PHP) (simplemente eliminando espacios en blanco y comentarios, sin acortamiento de variables, sin encoding baseX)

Aquí están los resultados de minify vs. gzip (a nivel conservativo-5 compresión) 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 de que nadie salte el arma, esta no es una batalla de las bibliotecas de JS.

Como puede ver, minifying + gzipping le ofrece una mejor compresión en archivos grandes . La reducción del código tiene sus ventajas, pero el factor principal es cuánto espacio en blanco y comentarios están presentes en el código original. En este caso, jQuery tiene más, por lo que ofrece una mejor minificación (muchos más espacios en blanco en la documentación en línea). La fuerza de la compresión Gzip radica en la cantidad de repetición que hay en el contenido. Entonces no se trata de minify vs. gzip. Ellos hacen las cosas de manera diferente. Y obtienes lo mejor de ambos mundos usando ambos.

¿Por qué no usar ambos?

Es fácil de probar: simplemente coloque el texto de su CSS en archivos de texto y comprima los archivos usando un archivador como gzip on linux.

Acabo de hacer esto, y sucede que para la primera CSS, el tamaño es 184 bytes y para el segundo 162 bytes.

Entonces, tienes razón, el espacio en blanco es importante incluso para los archivos comprimidos, pero como se puede ver en esta pequeña prueba, para archivos realmente pequeños, el tamaño del archivo comprimido puede ser mayor que el tamaño del archivo original.

Esto se debe simplemente al pequeño tamaño de su ejemplo, para archivos más grandes, gzipping le proporcionará archivos más pequeños.

No vi a nadie mencionar Mangling, así que estoy publicando mis resultados sobre eso.

Aquí hay algunas figuras que se me ocurrieron usando UflifyJS para minificación y Gzip. Tenía alrededor de 20 archivos que concatené juntos a unos 2.5MB con comentarios y todo.

Archivos Concat 2.5MB

 uglify({ mangle: false }) 

Minificado sin arruinar: 929kb

 uglify({ mangle: true }) 

Minificado y destrozado: 617kb

Ahora si tomo esos archivos y los gzip obtendré 239kb y 190kb respectivamente.

Hay un método muy simple para probar esto: crear un archivo que conste solo de espacios en blanco y otro archivo que esté realmente vacío. Luego, comprueba Gzip y compara sus tamaños. El archivo con espacios en blanco será, por supuesto, más grande.

Por supuesto, la compresión con pérdida “humana” que conserva el diseño u otras cosas importantes y elimina cualquier basura no necesaria (espacios en blanco, comentarios, cosas redundantes, etc.) será mejor que una compresión gZip sin pérdida.

Por ejemplo, cosas como marcas o nombres de funciones probablemente tendrán cierta longitud para describir el significado. Reemplazar esto por los nombres de un carácter de largo ahorrará mucho espacio y no es posible con la compresión sin pérdida.

Por cierto, para CSS hay herramientas como el compresor CSS que harán el trabajo con pérdidas para ti.

Sin embargo, obtendrá los mejores resultados cuando combine la “optimización con pérdida” y la compresión sin pérdida.

por supuesto, puedes probar: escribir en un archivo y descomprimirlo con zlib . También puedes probar con el progtwig de utilidad “gzip”.

volviendo a su pregunta: no existe una relación definida entre la longitud de la fuente y el resultado comprimido. el punto clave es la ‘entropía’ (qué tan diferentes son cada elemento en la fuente).

entonces, eso depende de cómo sea tu fuente. por ejemplo, muchos espacios continuos (por ejemplo,> 1000) pueden comprimirse del mismo tamaño que algunos espacios (por ejemplo, <10).

este es el resultado cuando gziping los dos archivos

 bytes File 45 min.txt 73 min.gz 72 normal.txt 81 normal.gz 

Estás en lo correcto, minify + gzip resultados en menos bytes. Sin embargo, ninguna prueba científica.

¿Cómo es que no tienes un método de prueba?

Minifique su código en un archivo y déjelo “sin minificar” en otro. Suba a un servidor web capaz de actualizar el resultado (mod_deflate para Apache, por ejemplo), instale la extensión Firebug para Firefox, borre su caché y acceda a ambos archivos. La pestaña “NET” de Firebug contendrá la cantidad exacta de datos transferidos, los comparará y tendrá una prueba “empírica”.