Leí que debido a que las páginas aspx no son archivos estáticos, IIS no las almacenará en caché y, por lo tanto, comprimirá la página en cada solicitud ...
Paulo
23
... y eso es un problema? A menos que su servidor ya tenga un 99,9% de CPU, probablemente no. gzip es lo habitual y mucho más eficaz que cualquier 'minificación'.
Quizás pruebe HTML Compressor , aquí hay una tabla de antes y después que muestra lo que puede hacer (incluso para Stack Overflow):
Cuenta con muchas selecciones para optimizar sus páginas e incluir la minimización de scripts (ompressor, Google Closure Compiler, su propio compresor) donde sería seguro. El conjunto de opciones predeterminado es bastante conservador, por lo que puede comenzar con eso y experimentar habilitando opciones más agresivas.
El proyecto está muy bien documentado y respaldado.
No hagas esto . O más bien, si insiste en ello, hágalo después de que se hayan completado las optimizaciones más importantes del sitio. Es muy probable que el costo / beneficio de este esfuerzo sea insignificante, especialmente si planeaba usar manualmente herramientas en línea para manejar cada página.
Utilice YSlow o Page Speed para determinar lo que realmente necesita hacer para optimizar sus páginas. Supongo que reducir bytes de HTML no será el mayor problema de su sitio. Es mucho más probable que la compresión, la administración de caché, la optimización de imágenes, etc., hagan una mayor diferencia en el rendimiento general de su sitio. Esas herramientas le mostrarán cuáles son los problemas más grandes: si los ha tratado todos y aún encuentra que la minificación de HTML hace una diferencia significativa, hágalo.
(Si está seguro de que quiere hacerlo y usa Apache httpd, podría considerar usar mod_pagespeed y activar algunas de las opciones para reducir los espacios en blanco, etc., pero tenga en cuenta los riesgos ).
¿Qué hay de malo en la optimización si el código minificado es fácil de leer mediante el embellecimiento automático?
12
Probablemente no sea el mayor problema, pero si es un proceso trivial ejecutar el marcado a través de un conjunto de expresiones regulares reducidas al compilar de dev a qa o prod, ¿por qué no querría enviar documentos de marcado más pequeños?
Will Peavy
26
En realidad, no es una respuesta a la pregunta original :(
Chuck Le Butt
7
@Will, es casi seguro que no es un proceso trivial ejecutar HTML a través de la minimización de expresiones regulares, e incluso usar un analizador adecuado probablemente no sea trivial o rápido. Es más, a diferencia de la minificación JS / CSS, la minificación HTML no tendrá pérdidas: cualquier etiqueta puede tener un estilo white-space: pre, y la minificación destruiría el texto preformateado.
párpados
3
@eyelidlessness: actualmente tengo miles de páginas que se minimizan con expresiones regulares antes de que se publiquen. Esta función no es una parte compleja o cara del sistema. ... Por otro lado, si quisiera analizar el estilo calculado para evitar minificar elementos con estilo white-space:pre, entonces sí, minificar HTML sería más complejo. Sin embargo, no tengo claro por qué alguien querría usar espacios en blanco: pre en lugar de usar un elemento preo code.
Will Peavy
34
Aquí hay una breve respuesta a su pregunta: debe minimizar su HTML, CSS, JS . Existe una herramienta fácil de usar que se llama gruñido . Te permite automatizar muchas tareas. Entre ellos JS , CSS , minificación de HTML , concatenación de archivos y muchos otros .
Las respuestas escritas aquí están extremadamente desactualizadas o incluso a veces no tienen sentido. Muchas cosas cambiaron desde el antiguo 2009, así que intentaré responder a esto correctamente.
Respuesta corta: definitivamente deberías minimizar el HTML . Es trivial hoy y da aproximadamente un 5% de aceleración . Para una respuesta más larga, lea la respuesta completa.
En los viejos tiempos, la gente minimizaba manualmente css / js (ejecutándolo a través de alguna herramienta específica para minimizarlo). Fue un poco difícil automatizar el proceso y definitivamente requirió algunas habilidades. Sabiendo que muchos sitios de alto nivel, incluso ahora mismo, no están usando gzip (lo cual es trivial), es comprensible que la gente se mostrara reacia a minificar html.
Entonces, ¿por qué la gente estaba minimizando js, pero no html ? Cuando minimizas JS, haces las siguientes cosas:
eliminar comentarios
eliminar espacios en blanco (tabulaciones, espacios, nuevas líneas)
cambiar nombres largos a cortos ( var isUserLoggedIna var a)
Lo que dio una gran mejora incluso en los viejos tiempos. Pero en html no fue posible cambiar nombres largos por abreviados, además, no hubo casi nada que comentar durante ese tiempo. Entonces, lo único que quedó fue eliminar espacios y nuevas líneas. Lo que da solo una pequeña cantidad de mejora.
Un argumento incorrecto escrito aquí es que debido a que el contenido se sirve con gzip, la minificación no tiene sentido. Esto está totalmente mal. Sí, tiene sentido que gzip disminuya la mejora de la minificación, pero ¿por qué debería gzip comentarios, espacios en blanco si puede recortarlos correctamente y gzip solo una parte importante? Es lo mismo que si tiene una carpeta para archivar que tiene algunas porquerías que nunca usará y decide simplemente comprimirla en lugar de limpiarla y comprimirla.
Otro argumento por el que no tiene sentido hacer minificación es que es tedioso. Tal vez esto fuera cierto en 2009, pero después de este tiempo aparecieron nuevas herramientas. En este momento, no es necesario que minimice manualmente su marcado. Con cosas como Grunt , es trivial instalar grunt-contrib-htmlmin (se basa en HTMLMinifier de @kangax) y configurarlo para minificar su html. Todo lo que necesitas son como 2 horas para aprender a gruñir y configurar todo y luego todo se hace automáticamente en menos de un segundo. Parece que 1 segundo (que incluso puede automatizar para no hacer nada con grunt-contrib-watch ) no es tan malo para aproximadamente un 5% de mejora (incluso con gzip).
Un argumento más es que CSS y JS son estáticos , y el servidor genera HTML, por lo que no se puede minimizar. Esto también fue cierto en 2009, pero actualmente cada vez más sitios parecen una aplicación de una sola página, donde el servidor es delgado y el cliente está haciendo todo el enrutamiento, la creación de plantillas y otras lógicas. Entonces, el servidor solo le brinda JSON y el cliente lo representa. Aquí tienes mucho html para la página y diferentes plantillas.
Minfying HTML es absolutamente no triviales, como espacio en blanco es significativo en HTML y si cualquier espacio en blanco dado puede ser eliminado depende de CSS. Además, los clientes ligeros son terribles y, en mi opinión, no se pueden dar como un buen argumento contra los problemas de minimizar el HTML dinámico. (Una buena forma de hacerlo es elegir un motor de plantilla [Haml, Jade, etc.] que no incluya espacios en blanco innecesarios en su salida renderizada en primer lugar.)
Ry-
@minitech minificar HTML es trivial y también hay pocos problemas posibles con los espacios en blanco (como <span>). En primer lugar, siempre puede encontrar una manera de escribir HTML válido, lo que lo hace independiente de los espacios en blanco. También es posible que te sorprenda escuchar, pero el minificador JS / CSS también puede introducir un error, lo que no significa que no debas usarlo. Entonces, dos formas de resolver su problema: aprenda a escribir marcas independientes de espacios en blanco, pruebe su producto antes / después de la minificación (CSS / HTML / JS). Además, en Minifier puede especificar qué espacios en blanco desea conservar.
Salvador Dali
Los minificadores de JavaScript correctos en código que no sea demente (es decir, código que no se lee a sí mismo o hace trampa por tiempo) no puede introducir un error. Y no, no siempre hay una manera de escribir HTML independiente de los espacios en blanco, específicamente porque HTML, de nuevo, no es independiente de los espacios en blanco. En absoluto. Asegúrese de probar copiando y pegando esto si cree que los márgenes lo cortarán. Especificar qué espacios en blanco quiero preservar suena como una pérdida de tiempo (excepto para Google)…
Ry-
@minitech, ¿puedes mostrarme CSS que es imposible de escribir de manera independiente de los espacios en blanco? Estoy minimizando html durante mucho tiempo y no he visto problemas hasta ahora.
Salvador Dali
* { white-space: pre; }es obvio, pero si elimina todos los espacios en blanco y no solo los contrae (reemplazándolos con márgenes), el texto puede copiarse incorrectamente y causar estragos en los navegadores de texto y lectores de pantalla.
Las series de caracteres de espacio en blanco se convierten en caracteres de un solo espacio
Se eliminan los espacios en blanco innecesarios dentro de las etiquetas.
Se eliminan los espacios en blanco entre dos etiquetas donde una de estas dos etiquetas no es un singleton
Todo el contenido dentro de una styleetiqueta se presume que es CSS y se minimiza como tal
scriptSe presume que todo el contenido dentro de una etiqueta es JavaScript, a menos que se proporcione un tipo de medio diferente y luego se minimice como tal
La minificación de CSS y JavaScript utiliza una forma muy bifurcada de JSMin. Esta bifurcación se amplió para admitir CSS de forma nativa y también admitir la sintaxis SCSS. La inserción automática de punto y coma se admite para la minificación de JavaScript, sin embargo, la inserción automática de llaves aún no es compatible.
No es una herramienta en línea que ya esté disponible, pero al ser una simple inclusión de PHP, es bastante fácil que pueda ejecutarla usted mismo.
Sin embargo, no guardaría archivos comprimidos, haga esto dinámicamente si realmente es necesario, y siempre es una mejor idea habilitar la compresión del servidor Gzip. No sé qué tan involucrado está eso en IIS / .Net, pero en PHP es tan trivial como agregar una línea al archivo de inclusión global
HtmlCompressor es una biblioteca .NET pequeña, rápida y muy fácil de usar que minimiza la fuente HTML o XML dada al eliminar espacios en blanco adicionales, comentarios y otros caracteres innecesarios sin romper la estructura del contenido. Como resultado, las páginas se vuelven más pequeñas y se cargan más rápido. También está disponible una versión de línea de comandos del compresor.
Respuestas:
Quizás pruebe HTML Compressor , aquí hay una tabla de antes y después que muestra lo que puede hacer (incluso para Stack Overflow):
Cuenta con muchas selecciones para optimizar sus páginas e incluir la minimización de scripts (ompressor, Google Closure Compiler, su propio compresor) donde sería seguro. El conjunto de opciones predeterminado es bastante conservador, por lo que puede comenzar con eso y experimentar habilitando opciones más agresivas.
El proyecto está muy bien documentado y respaldado.
fuente
No hagas esto . O más bien, si insiste en ello, hágalo después de que se hayan completado las optimizaciones más importantes del sitio. Es muy probable que el costo / beneficio de este esfuerzo sea insignificante, especialmente si planeaba usar manualmente herramientas en línea para manejar cada página.
Utilice YSlow o Page Speed para determinar lo que realmente necesita hacer para optimizar sus páginas. Supongo que reducir bytes de HTML no será el mayor problema de su sitio. Es mucho más probable que la compresión, la administración de caché, la optimización de imágenes, etc., hagan una mayor diferencia en el rendimiento general de su sitio. Esas herramientas le mostrarán cuáles son los problemas más grandes: si los ha tratado todos y aún encuentra que la minificación de HTML hace una diferencia significativa, hágalo.
(Si está seguro de que quiere hacerlo y usa Apache httpd, podría considerar usar mod_pagespeed y activar algunas de las opciones para reducir los espacios en blanco, etc., pero tenga en cuenta los riesgos ).
fuente
white-space: pre, y la minificación destruiría el texto preformateado.white-space:pre, entonces sí, minificar HTML sería más complejo. Sin embargo, no tengo claro por qué alguien querría usar espacios en blanco: pre en lugar de usar un elementopreocode.Aquí hay una breve respuesta a su pregunta: debe minimizar su HTML, CSS, JS . Existe una herramienta fácil de usar que se llama gruñido . Te permite automatizar muchas tareas. Entre ellos JS , CSS , minificación de HTML , concatenación de archivos y muchos otros .
Las respuestas escritas aquí están extremadamente desactualizadas o incluso a veces no tienen sentido. Muchas cosas cambiaron desde el antiguo 2009, así que intentaré responder a esto correctamente.
Respuesta corta: definitivamente deberías minimizar el HTML . Es trivial hoy y da aproximadamente un 5% de aceleración . Para una respuesta más larga, lea la respuesta completa.
En los viejos tiempos, la gente minimizaba manualmente css / js (ejecutándolo a través de alguna herramienta específica para minimizarlo). Fue un poco difícil automatizar el proceso y definitivamente requirió algunas habilidades. Sabiendo que muchos sitios de alto nivel, incluso ahora mismo, no están usando gzip (lo cual es trivial), es comprensible que la gente se mostrara reacia a minificar html.
Entonces, ¿por qué la gente estaba minimizando js, pero no html ? Cuando minimizas JS, haces las siguientes cosas:
var isUserLoggedInavar a)Lo que dio una gran mejora incluso en los viejos tiempos. Pero en html no fue posible cambiar nombres largos por abreviados, además, no hubo casi nada que comentar durante ese tiempo. Entonces, lo único que quedó fue eliminar espacios y nuevas líneas. Lo que da solo una pequeña cantidad de mejora.
Un argumento incorrecto escrito aquí es que debido a que el contenido se sirve con gzip, la minificación no tiene sentido. Esto está totalmente mal. Sí, tiene sentido que gzip disminuya la mejora de la minificación, pero ¿por qué debería gzip comentarios, espacios en blanco si puede recortarlos correctamente y gzip solo una parte importante? Es lo mismo que si tiene una carpeta para archivar que tiene algunas porquerías que nunca usará y decide simplemente comprimirla en lugar de limpiarla y comprimirla.
Otro argumento por el que no tiene sentido hacer minificación es que es tedioso. Tal vez esto fuera cierto en 2009, pero después de este tiempo aparecieron nuevas herramientas. En este momento, no es necesario que minimice manualmente su marcado. Con cosas como Grunt , es trivial instalar grunt-contrib-htmlmin (se basa en HTMLMinifier de @kangax) y configurarlo para minificar su html. Todo lo que necesitas son como 2 horas para aprender a gruñir y configurar todo y luego todo se hace automáticamente en menos de un segundo. Parece que 1 segundo (que incluso puede automatizar para no hacer nada con grunt-contrib-watch ) no es tan malo para aproximadamente un 5% de mejora (incluso con gzip).
Un argumento más es que CSS y JS son estáticos , y el servidor genera HTML, por lo que no se puede minimizar. Esto también fue cierto en 2009, pero actualmente cada vez más sitios parecen una aplicación de una sola página, donde el servidor es delgado y el cliente está haciendo todo el enrutamiento, la creación de plantillas y otras lógicas. Entonces, el servidor solo le brinda JSON y el cliente lo representa. Aquí tienes mucho html para la página y diferentes plantillas.
Así que para terminar mis pensamientos:
fuente
<span>). En primer lugar, siempre puede encontrar una manera de escribir HTML válido, lo que lo hace independiente de los espacios en blanco. También es posible que te sorprenda escuchar, pero el minificador JS / CSS también puede introducir un error, lo que no significa que no debas usarlo. Entonces, dos formas de resolver su problema: aprenda a escribir marcas independientes de espacios en blanco, pruebe su producto antes / después de la minificación (CSS / HTML / JS). Además, en Minifier puede especificar qué espacios en blanco desea conservar.* { white-space: pre; }es obvio, pero si elimina todos los espacios en blanco y no solo los contrae (reemplazándolos con márgenes), el texto puede copiarse incorrectamente y causar estragos en los navegadores de texto y lectores de pantalla.Escribí una herramienta web para minimizar HTML. http://prettydiff.com/?m=minify&html
Esta herramienta opera usando estas reglas:
styleetiqueta se presume que es CSS y se minimiza como talscriptSe presume que todo el contenido dentro de una etiqueta es JavaScript, a menos que se proporcione un tipo de medio diferente y luego se minimice como talfuente
<!--[if IE 8.0]><link rel="stylesheet" href="css/ie8.css" type="text/css" /><![endif]-->Esto funcionó para mí:
http://minify.googlecode.com/git/min/lib/Minify/HTML.php
No es una herramienta en línea que ya esté disponible, pero al ser una simple inclusión de PHP, es bastante fácil que pueda ejecutarla usted mismo.
Sin embargo, no guardaría archivos comprimidos, haga esto dinámicamente si realmente es necesario, y siempre es una mejor idea habilitar la compresión del servidor Gzip. No sé qué tan involucrado está eso en IIS / .Net, pero en PHP es tan trivial como agregar una línea al archivo de inclusión global
fuente
CodeProject tiene un proyecto de muestra publicado ( http://www.codeproject.com/KB/aspnet/AspNetOptimizer.aspx?fid=1528916&df=90&mpp=25&noise=3&sort=Position&view=Quick&select=2794900 ) para manejar algunas de las siguientes situaciones. .
fuente
Para la plataforma Microsoft .NET existe una biblioteca llamada WebMarkupMin , que produce la minificación del código HTML.
Además, hay un módulo para la integración de esta biblioteca en ASP.NET MVC - WebMarkupMin.Mvc .
fuente
prueba http://code.mini-tips.com/html-minifier.html , esta es .NET Libary para Html Minifier
HtmlCompressor es una biblioteca .NET pequeña, rápida y muy fácil de usar que minimiza la fuente HTML o XML dada al eliminar espacios en blanco adicionales, comentarios y otros caracteres innecesarios sin romper la estructura del contenido. Como resultado, las páginas se vuelven más pequeñas y se cargan más rápido. También está disponible una versión de línea de comandos del compresor.
fuente