Como reducir el tamaño de nuestras páginas al enviarlas mediante el protocolo HTTP, reduciendo el tiempo de transferencia y el ancho de banda.
Introducción
Para reducir el tamaño de las páginas enviadas con HTTP, cuando nace el protocolo HTTP1.1, se le añade una opción de compresión de página, de esta manera, cuando el navegador hace una llamada al servidor, le indica que puede recibir contenido comprimido de la siguiente manera:
Accept-Encoding: gzip
Esto significa que el navegador es capaz de descomprimir los contenidos que se le envíen comprimidos con gzip, entonces si el servidor está preparado para hacerlo envía el siguiente encabezado seguido del contenido de la página comprimido.
Content-Encoding: gzip
Es evidente que el uso de compresión en una transferencia gzip, aparte de reducir el tiempo necesario para realizar la transferencia, aporta beneficios para el servidor y el cliente reduciendo el ancho de banda consumido para ambos, sin embargo, la implantación de este tipo de compresión es todavía muy bajo.
Según un estudio realizado por programacionweb.net con nuestro robot experimental realizado sobre mas de 10000 páginas, solo un 9,4% de las páginas consultadas respondieron a nuestra peticion de transferéncia comprimida con gzip o deflate y esto supone un porcentaje realmente bajo.
¿como comprimo mis páginas?
En la mayoría de servidores la compresión HTTP1.1 es una opción que hay que activar (como en el caso de IIS) o un módulo (como en el caso de apache), por lo que solo tendremos que activarlo siguiendo el manual de nuestro servidor para empezar a reducir hasta un 70% la transferencia utilizada por nuestro servidor.
Y si no tenemos acceso a la configuración del servidor, además de pedir a nuestro ISP que active la compresión, podemos comprimir nuestros envíos utilizando lenguajes de servidor, como ejemplo, podéis leer en cómo comprimir la salida en gzip usando PHP.
¿Y los navegadores antiguos y robots?
Un 99% de los accesos de usuarios a ProgramacionWeb, son accesos de usuarios con un navegador capaz de leer páginas comprimidas, otro tema aparte son los robots de los buscadores ya que hoy en día, lamentablemente, solo una nueva versión del GoogleBot es capaz de descomprimir las páginas recibidas.
Este hecho es realmente desconcertante, pues al robot PWeBot solo tuve que añadirle unas líneas para la descompresión tanto en gzip cómo en deflate:
<?
if($gz=='gzip')$datos=@gzinflate(substr($datos,10));
if($gz=='deflate')$datos=@gzinflate($datos);
?>
Pero incluso así, no hay que temer nada, porque en el caso de que el cliente (visitante o robot) no sea capaz de descodificar una transferencia comprimida, se realizará una transferencia de hipertexto normal ya que el cliente no indicará un Accept-Encoding y el servidor no comprimirá el contenido.
Conclusiones
Teniendo en cuenta los beneficios de la compresión en las transferencias de HiperTexto y la facilidad de realizar una transferencia comprimida, y sabiendo que no hay ningún contra, el hecho de que solo un porcentaje tan bajo de los servidores tenga habilitada esta opción es por simple desconocimiento, así que animo a todo el que tenga una página publicada en Internet a que empiece a ahorrar ancho de banda tanto a su servidor como a sus usuarios como estoy realizando desde finales de 2003 en ProgramacionWeb.
Para reducir el tamaño de las páginas enviadas con HTTP, cuando nace el protocolo HTTP1.1, se le añade una opción de compresión de página, de esta manera, cuando el navegador hace una llamada al servidor, le indica que puede recibir contenido comprimido de la siguiente manera:
Accept-Encoding: gzip
Esto significa que el navegador es capaz de descomprimir los contenidos que se le envíen comprimidos con gzip, entonces si el servidor está preparado para hacerlo envía el siguiente encabezado seguido del contenido de la página comprimido.
Content-Encoding: gzip
Es evidente que el uso de compresión en una transferencia gzip, aparte de reducir el tiempo necesario para realizar la transferencia, aporta beneficios para el servidor y el cliente reduciendo el ancho de banda consumido para ambos, sin embargo, la implantación de este tipo de compresión es todavía muy bajo.
Según un estudio realizado por programacionweb.net con nuestro robot experimental realizado sobre mas de 10000 páginas, solo un 9,4% de las páginas consultadas respondieron a nuestra peticion de transferéncia comprimida con gzip o deflate y esto supone un porcentaje realmente bajo.
¿como comprimo mis páginas?
En la mayoría de servidores la compresión HTTP1.1 es una opción que hay que activar (como en el caso de IIS) o un módulo (como en el caso de apache), por lo que solo tendremos que activarlo siguiendo el manual de nuestro servidor para empezar a reducir hasta un 70% la transferencia utilizada por nuestro servidor.
Y si no tenemos acceso a la configuración del servidor, además de pedir a nuestro ISP que active la compresión, podemos comprimir nuestros envíos utilizando lenguajes de servidor, como ejemplo, podéis leer en cómo comprimir la salida en gzip usando PHP.
¿Y los navegadores antiguos y robots?
Un 99% de los accesos de usuarios a ProgramacionWeb, son accesos de usuarios con un navegador capaz de leer páginas comprimidas, otro tema aparte son los robots de los buscadores ya que hoy en día, lamentablemente, solo una nueva versión del GoogleBot es capaz de descomprimir las páginas recibidas.
Este hecho es realmente desconcertante, pues al robot PWeBot solo tuve que añadirle unas líneas para la descompresión tanto en gzip cómo en deflate:
<?
if($gz=='gzip')$datos=@gzinflate(substr($datos,10));
if($gz=='deflate')$datos=@gzinflate($datos);
?>
Pero incluso así, no hay que temer nada, porque en el caso de que el cliente (visitante o robot) no sea capaz de descodificar una transferencia comprimida, se realizará una transferencia de hipertexto normal ya que el cliente no indicará un Accept-Encoding y el servidor no comprimirá el contenido.
Conclusiones
Teniendo en cuenta los beneficios de la compresión en las transferencias de HiperTexto y la facilidad de realizar una transferencia comprimida, y sabiendo que no hay ningún contra, el hecho de que solo un porcentaje tan bajo de los servidores tenga habilitada esta opción es por simple desconocimiento, así que animo a todo el que tenga una página publicada en Internet a que empiece a ahorrar ancho de banda tanto a su servidor como a sus usuarios como estoy realizando desde finales de 2003 en ProgramacionWeb.
Eloi de San Martin Lagranje