Hace unos meses Microsoft publicó Visual Round Trip Analyzer (VRTA), una herramienta que permite visualizar y evaluar el rendimiento de un sitio web. Por su lado, Google presentó la semana pasada Page Speed, un complemento open-source para FireFox / FireBug con una funcionalidad muy similar a VRTA. Ambas herramientas realizan un análisis de rendimiento y ofrecen sugerencias para mejorar la utilización del ancho de banda, el tiempo del viaje de ida y vuelta al servidor y el tiempo de renderizado del navegador.

Esta entrada la voy a dedicar a una de las optimizaciones más fáciles de implementar y con la que podemos reducir al máximo la cantidad de información que se envía al cliente. Esta optimización consiste en eliminar del código HTML los espacios, saltos de línea y tabuladores que normalmente utilizamos para facilitar la lectura, pero que son innecesarios para que el navegador genere la página correctamente. Según algunos estudios —que omito por ser parte interesada—, la media de espacios en blanco en una página Web está entre el 20 y el 30%. Y según las herramientas de Google y Microsoft, una cantidad por encima del 10% de espacios en blanco es un aspecto a corregir ya que, aunque no parezca mucho, al hacerlo se apreciará una mejora en el tiempo de carga de la página. En las siguientes líneas, vamos a intentar saber si este nivel de mejora se corresponde con la realidad, que ventajas se obtienen (si es que se obtienen) si se combina con la compresión HTTP, que consumo de CPU se requiere y si, en definitiva, es recomendable implementar esta optimización.

Para tener una referencia he comprobado cuanto mejoraría la transferencia de la página principal de diez sitios web que sigo habitualmente. Puede parecer que diez no es una muestra significativa, pero no pretendo hacer un estudio exhaustivo, sino simplemente quiero saber si el beneficio que se obtendría es similar al que los estudios afirman.

La prueba que he realizado ha sido entrar en cada una de las páginas, guardar el código HTML generado y quitar mediante expresiones regulares los espacios en blanco entre etiquetas y todos los saltos de línea. He utilizado el siguiente código, donde path es la ruta del archivo que contiene el código HTML de la página a optimizar:

StreamReader sr = new StreamReader(path); // Lee el fichero html string html = sr.ReadToEnd(); // y lo asignamos a la variable html

html = new Regex(@”>s+<”).Replace(html, “><”); // Reemplaza los espacios entre etiquetas html = new Regex(@”rn”).Replace(html, string.Empty); // Reemplaza los saltos de línea </pre>

En la siguiente tabla se muestra la comparación entre el tamaño de la página original y el tamaño de la página después de ser optimizada.

Comparación entre el tamaño del código HTML original y el optimizado sin espacios

Como podemos comprobar el índice de optimización se sitúa entre el 2 y el 16% del tamaño original. Sólo en el caso de «C# Corner» se obtiene un beneficio del 38%. Estos son unos resultados absolutos, esto significa que esta sería la mejora de transferencia si no se aplicase ninguna otra optimización. Pero lo cierto es que la mayoría de los sitios web que he consultado tienen habilitada la compresión HTTP y es de suponer que este beneficio será menor ya que los espacios en blanco ya se están comprimiendo. ¿Cuál es la mejora al eliminar los espacios en blanco en este caso? Lo vemos en la siguiente tabla:

Comparación utilizando compresión HTTP entre el tamaño del código HTML original y el optimizado sin espacios

Viendo estos resultados, está de más comentar que la compresión HTTP debe ser una característica que debe estar activada en cualquier sitio web si en algo nos preocupa, ya no sólo la experiencia de usuario sino también el uso que hacemos de nuestro ancho de banda, ya que mediante la compresión HTTP se obtiene desde un 73 hasta más de un 90% de reducción del código transferido. Sin embargo, el beneficio que obtenemos al eliminar los espacios en blanco es mucho menos espectacular, varia de un 1,5 hasta un poco más del 5,5%. Como era de esperar, en la página de «C# Corner» la mejora es sensiblemente mayor, de más de un 11%. Estos resultados indican que si se aplicase está optimización, se estarían ahorrando unos 110 Mb por cada gigabyte de transferencia, y en los casos no tan extremos se estarían ahorrando únicamente entre 15 y 55 Mb por gigabyte.

Entonces y resumiendo: ¿es aconsejable implementar esta optimización?

Es muy recomendable en los casos en los que la cantidad de espacios del código transferido supere el 10% (medido con la compresión HTTP deshabilitada), en el resto de situaciones no le daría la misma prioridad, aunque personalmente me obsesiona mucho la optimización, y creo que cualquier mejora en el rendimiento, por pequeña que sea, debe ser implementada a no ser que existan otros factores que lo desaconsejen, como puede ser un elevado coste de procesador o de desarrollo. El coste de CPU de esta optimización es mínimo y no tendrá impacto en el rendimiento general de la aplicación, pero si además tenemos la posibilidad de cachear las páginas, este coste lo podemos despreciar. En cuanto al desarrollo, creo que en la mayoría de casos se puede implementar está solución con muy poco impacto en el código.

No me resisto a poner un ejemplo de código para realizar optimización básica que he utilizado para hacer este análisis. El código es una clase base de la que heredarán todas las páginas de la aplicación. En esta clase únicamente se sobrecarga el método Render en el que se eliminan los espacios y saltos de línea, de la misma forma que he comentado antes.

using System.Web.UI;
using System.Text.RegularExpressions;

public class BasePage : System.Web.UI.Page
{
    protected override void Render(HtmlTextWriter writer) 
    {
        using (HtmlTextWriter htmlwriter = new HtmlTextWriter(new System.IO.StringWriter())) 
        { 
          base.Render(htmlwriter);
          string html = htmlwriter.InnerWriter.ToString();

          html = new Regex(@">s+<", RegexOptions.Compiled).Replace(html, "><");
          html = new Regex(@"rn", RegexOptions.Compiled).Replace(html, string.Empty);

          writer.Write(html.Trim()); 
        } 
    }
}

Esta propuesta es muy básica, pero da idea de lo que se puede conseguir con tan poco código. No obstante, aún se podría eliminar más información innecesaria como, por ejemplo, los comentarios (ya sean en JavaScript o en HTML), espacios en el código JavaScript y entre atributos, etc., consiguiendo así que viaje al cliente exclusivamente el código imprescindible. Por último, hay que tener en cuenta que este código no funcionará correctamente si tenemos código JavaScript con comentarios de una sola línea iniciados con la doble barra (//) o si existen líneas sin terminar en punto y coma (;).

Dejo para otra ocasión la explicación de cómo realizar esta misma optimización en los ficheros estáticos (JS, CSS y HTML), que aunque se basa en el mismo principio, se puede llevar a cabo a través de varios métodos.