Optimización AJAX 2: compresión GZIP

Habilitar la compresión de la respuesta puede reducir la cantidad de datos enviados alrededor de un 70%. La mayoría de los navegadores soporta recibir contenidos, e informan de esta capacidad al servidor al realizar una petición.

Es posible agregar la indicación de comprimir la respuesta del servidor en su configuración de acuerdo al mime-type de la respuesta: text/html, text/plain, application/json, application/xml (y en general, es conveniente activarlo para cualquier lenguaje basado en texto, como text/html, text/css, application/javascript, application/json).

Habilitar compresión en Apache y nginx

En Apache puedes habilitar la compresión gzip añadiendo las siguientes líneas a la configuración del servidor o el archivo .htaccess relevante:

<ifModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file .(html?|txt|css|js|php|pl)$
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include mime ^text/.*
mod_gzip_item_include mime ^application/x-javascript.*
mod_gzip_item_exclude mime ^image/.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</ifModule>

En el caso de nginx puedes activarlo dentro del bloque http de la configuración de modo que quede disponible para todos los virtual hosts configurados o bien por bloques server o incluso location.

En Ubuntu estos parámetros suelen venir en la configuración por defecto pero comentados.

gzip on;
# deshabilitar para IE 4 a IE6
gzip_disable "msie6";

gzip_vary on;
# des/habilitar compresión para respuestas de las nginx hace de proxy
gzip_proxied any;
# nivel de compresión, de 1 a 9
gzip_comp_level 4;
gzip_buffers 16 8k;
gzip_http_version 1.1;
# los tipos de respuesta que se enviarán comprimidos. siempre incluye text/html
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

Habilitar compresión desde PHP

También es posible activar la compresión de la respuesta en la misma aplicación; por ejemplo en PHP esto se puede lograr de forma muy sencilla con ob_gzhandler:

/**
 * Si el navegador no soporta Gzip,
 * la condición retorna falso y se abre un buffer normal
 */
if ( ! ob_start('ob_gzhandler') ) ob_start();
echo $out;
ob_end_flush();
exit;

Cómo comprobar si la respuesta fue comprimida

Puedes comprobar si la respuesta se está enviando efectivamente comprimida con las herramientas de desarrollo de Chrome (debes habilitar la opción use large request rows, junto a la opción para mostra los filtros de contenido).

2b90b5d301En la columna Size, puedes ver dos cifras: la primera corresponde al tamaño del cuerpo de la respuesta, mientras que la segunda a los datos transferidos. Si la cantidad de datos transferidos es menor al tamaño de la respuesta, significa que la compresión está funcionando.

Optimización AJAX 1: elección del método HTTP

Si bien las interacciones en AJAX nos permiten obtener información de forma dinámica desde el servidor de un sitio web o aplicación, existen varias formas de aumentar la velocidad de estas respuestas para mejorar la experiencia de nuestros usuarios al cargar información bajo demanda, obtener datos de búsquedas u otras interacciones.

Más allá de la parafernalia tecnológica que supone la implementación de una respuesta AJAX (por supuesto, reducida al mínimo con el uso de un framework adecuado), ésta sigue siendo una respuesta HTTP, por lo que se pueden aplicar los mismos principios para mejorar su performance.

En éste y los siguientes posts intentaré revisar la teoría y práctica de las técnicas fundamentales para mejorar la performance de respuestas AJAX y la experiencia de tus usuarios.

Continue reading “Optimización AJAX 1: elección del método HTTP”

Sitios web aún más rápidos

A propósito del post sobre la “sensación” de velocidad y los selectores eficientes que publicó recientemente Armonth en su blog, recordé una de las presentaciones de la Web 2.0 Expo en San Francisco de la que había visto sus diapositivas, y que hablaba más o menos del mismo tema.

La presentación estuvo a cargo de Steve Souders, quien trabaja en Google en iniciativas de código abierto y alta performance, es el creador de YSlow — una herramienta (plugin para Firebug) desarrollada por Yahoo! para medir la performance de un sitio — y especialista en sitios de alta performance.

Pueden ver la presentación en Slideshare o bien descargar la original desde la ficha técnica de su charla.

CDN para frameworks javascript

Ahorra ancho de banda y mejora la experiencia de tus usuarios utilizando la infraestructura de Google para servir tu framework javascript.

¿No sería genial que en lugar de tener que descargar una y otra vez los archivos de jQuery, mootools, prototype… estos estuvieran distribuidos de forma de ahorrarte en transferencia y aumentando la velocidad con que tus usuarios ven tu sitio?

Tras esta larga y rebuscada pregunta lo que se esconde es un servicio de Google del que no sabía hasta hace poco, pero que demuestra que a veces una pequeña idea puede traer grandes beneficios: se trata de AJAX Libraries API, una red de distribución de contenidos (Content Distribution Network, o CDN, para los amigos) y “arquitectura de carga” para algunas de los frameworks javascript más populares.

En pocas palabras, AJAX Libraries API permite que tus usuarios descarguen la librería javascript de tu elección desde la red de servidores de Google, para lo cual tienes dos opciones: hacerlo a través de google.load() (un método desarrollado por Google para facilitar la carga de acuerdo a dos parámetros, que especifican el framework y la versión que quieres) o bien directamente desde <script />. Por ejemplo:

Con google.load():

<script src="http://www.google.com/jsapi"></script>
<script>
	// Load jQuery
	google.load("jquery", "1");
</script>


...o directamente:
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js"></script>

Continue reading “CDN para frameworks javascript”

¿VTR (Chile) aumenta velocidades de subida?

Al parecer, los ISP chilenos han decidido aumentar las velocidades de subida de sus clientes… a compartir contenidos se ha dicho

Hace poco leí en FayerWayer que Telefónica aumentaba las velocidades de subida a alrededor de 500 kb/s… siendo cliente de VTR, esperaba que pronto se replicara la medida y al parecer así será: acabo de hacer un test de velocidad y me arroja 507 kb/s de subida (tengo un plan de “1 Mega” de bajada, normalmente la subida era de 128 kb/s o algo así)…

Acá hay una copia del resultado:

Test de velocidad

Y una captura de pantalla del gráfico de velocidades en Deluge:

Gráfico de velocidades en Deluge

WordPress y uso de CPU: algunas lecciones

El pedido de auxilio para solucionar el problema de sobrecarga de CPU que hizo Boja provocó que mucha gente reaccionara y comenzara a dar sugerencias para solucionarlo, las que trato de recoger en este post.

Hace unos días escribía sobre el problema que Boja tenía con la sobrecarga de CPU que WordPress le estaba causando en su host. Desde su publicación, fueron muchos quienes aportaron con sus sugerencias para solucionar este problema, ya sea a través de comentarios o bien posts sobre el tema, y entre todos se ha creado una nueva base de conocimiento que antes no existía sobre la optimización del funcionamiento de WordPress en cuanto a su consumo de procesamiento, de la cual intentaré destacar algunos de sus puntos más importantes.
Continue reading “WordPress y uso de CPU: algunas lecciones”