Tip 4 – Compactar Javascript, Css y porque no el HTML

By admin | Published: 2009/03/08

Para los ansiosos, el tip: Compactar el CSS y Javascript la página.

La explicación:

Si pensamos que nuestro objetivo es disminuir el tiempo de carga de un nuevo usuario en nuestra web site o webapp.  Debemos entender que el peso de los archivos que se transmiten entre el servidor web y el browser importa en el tiempo final. Ya que los archivos de CSS y Javascript son código que interpretará el browser, podemos de manera muy simple compactarlo, utilizando alguna de las varias herramientas online que aplican algoritmos de simplificado y minimizado del código. Esto reduce el código sin afectar la capasidad del browser de interpretarlo.

Tipicamente estos algoritmos eliminan los comentarios, remplazan el nombre de variables por letras, eliminan los “enter” y otras cosas. Con esto podemos ganar hasta un 60% o mas de reducción en los archivos y disminuir así el tiempo de transferencia.

Para los mas exigentes, también es posible compactar el HTML, eliminando “enter” y comentarios. Y aunque no se consigue el mismo porcentaje de compresión, todo suma ;) .

Algunas herramientas online:

Para CSS:

  • http://www.csscompressor.com/

Para JS:

  • http://javascriptcompressor.com/
  • http://developer.yahoo.com/yui/compressor/

Consejo:

Es importante tener en cuenta que el código compactado es muy complejo de analizar, por lo que no conviene compactarlo hasta que no implementemos los cambios en el ambiente de producción. O sea, no lo compacten mientras desarrollan.

Adicionalmente, y pensando en otra de las reglas que nos dice que debemos “minimizar la cantidad de componentes(archivos)”, podemos implementar, de manera muy simple un script (en PHP o Python o ASP, etc) que compacte todos los JS y CSS que utiliza nuestra web y los deje en uno solo CSS y un solo JS compactado y minificado.  Con esto matamos dos pajaros de un tiro ;) .

Suerte

Posted in performance, webapps | Tagged , , , , , , | 1 Comment

Tip 3 – Los CSS arriba!

By martin | Published: 2009/03/05

Para los ansiosos, el Tip: siempre incluir todos los CSS con el tag LINK dentro del HEAD

Para los que quieran leer, va la explicación:

Los navegadores (browser para los amigos) como IE, FireFox, Opera, Safari, Crome, etc utilizan un sistema que se encarga de “dibujar” el HTML(markup) y todos los elementos de la página. Este sistema es conocido como “Layout Engine“, y los mas conocidos obviamente son Gecko, Webkit y Trident, de FireFox, Crome, Safari e IE respectivamente. Estos mecanismos ponen especial atención en dibujar lo antes posible nuestra página y bien va obteniendo los elementos que la conforman.

Se ha comprobado que todos los layout engine muestran progresivamente el contenido, si ponemos los CSS en el HEAD de nuestra página. Esto permite que personas con conexión lenta, puedan empezar a ver la página antes que se obtengan todos los elementos, algo muy útil en dispositivos móviles.

En cambio si incluímos el CSS en el final del HTML varios browsers bloquean la muestra progresiva de la misma hasta cargar la hoja de estilos.

En resumen, si queremos colaborar con la performance de nuestra webapp o web site,no olvidemos esto que es muy simple: los CSS van en el HEAD

Suerte

Posted in performance, webapps | Tagged , , , | Leave a comment

Tip 2 – Javascript al final

By martin | Published: 2009/03/04

Para los ansioso, el tip: Poner todos los javascript al final de la página antes del tag </body>

La explicación:

Parece muy simple, pero la mayoría de los desarrolladores web, cuando programamos un web site, tenemos por costumbre poner los javascript dentro del HEAD.  Sin saber que esto afecta notablemente el tiempo de carga de nuestro página, ya que los browsers trabajan de la siguiente manera:

  1. Cargan siempre primero el HTML,
  2. Luego interpretan las instrucciones del mismo
  3. Si encuentran algun componente externo (CSS, Javascript, IMG, etc) lo descargan.
  4. Pero el tag SCRIPT tiene un comportamiento especial, hace que el browser detenga la ejecución, ya que el mismo podría tener una instrucción que modifique la ventana o documente, como por ejemplo document.write

Es por eso que si ponemos los scripts al principio el browser no ejecutara ni mostrara nada hasta que no descargue los scripts que le indiquemos. Y generalmente se pueden poner sin mayores problemas al final de la página.

Hay algunos casos donde no es posible mover hacia el final a los scripts, ya que los mismos realizan modificaciones en el contexto, clásico ejemplo los ads. Esto nos quita mucha performance en nuestro web site o webapp, y antes podíamos solucionarlo poniendo el atributo DEFER en el script. Pero lamentablemente esto no funciona en FireFox y otros. Un excelente ejemplo de esto y algunos comentarios de como solucionarlo según el browser lo podemos encontrar en la página de Steve Souders.

Dentro de poco les voy a pasar un tip de como solucionar la carga de ads, sin perder la performance de nuestra web

Saludos

Posted in performance, webapps | Tagged , , , , , | 1 Comment

Tip 1 – Respuesta de Http compactada

By martin | Published: 2009/03/02

Para los ansiosos el Tip:

  1. Verificar que esté instalado el mod_deflate
  2. En el archivo .htaccess de la carpeta root del site debemos poner: 
    SetOutputFilter DEFLATE
  3. Si sólo queremos compactar algunos tipos de salida según su tipo MIME podemos hacerlo con: 
    AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
  4. Eso es todo ;)

Pueden chequear que funcione con Firebug como siempre mirando en el http header del response.

Los que quieran leer va las explicaciones…

Por qué compactar el contenido del mensaje http?

Si estás trabajando con Apache o Lighthttpd es muy sencillo poder compactar todos los datos que enviás desde tu server al browser.  Esto es posible si tienen los módulos mod_deflate o el mod_gzip (ya en desuso). Y permite lograr una compresión de hasta el 80% de los archivos que transmitimos.  Obviamente ésto redunda en mayor performance a la hora de que un browser haga el load de tu site y los elementos que tenga que cargar no se encuentren en cache.

A tener en cuenta

No todos los tipos de archivos logran igual compresión. Como se sabe los de contenido texto como HTML, XML, CSS, JavaScript y otros logran hasta el 80% o más de compresión, mientras los archivos binarios, como por ejemplo las imágenes casi no pueden ser comprimidas.  Adicionalmente, la compresión del módulo requiere utilizar el procesador del servidor antes de transmitir el archivo y procesador en el cliente para poder descomprimirlo. Por eso es importante que determinemos bien qué tipo de archivos nos convienen compactar a la hora de transmitir.

HTTP

Desde que se implemento el HTTP 1.1 existe en los browsers y servidores web la posibilidad de especificar que la transmisión de los datos se realizará en forma comprimida. Y esto lo implementan mediante una directiva en el head del request. Por ende sólo funcionará esta compresión, si tanto el browser como el servidor web tienen esa capacidad instalada. Pero a decir verdad, hoy en día la mayoría lo tiene.

Suerte

Posted in performance, webapps | Tagged , , , | Leave a comment

Tip 0 – Por qué el foco debe estar en el Frontend ?

By martin | Published: 2009/02/27

Es obvio que nuestros usuarios disfrutan y por ende usan mas un sitio que es rápido a uno que es lento. De hecho, según las estadísticas de Amazon y de Ebay cada segundo de demora en sus sitios representa el 1% perdida en las ventas.

Como ya lo ha demostrado Steve Souders con su equipo en Yahoo hace unos cuantos años, a la hora de mejorar la performance de site debemos poner foco  en el Frontend.

Esto se debe a que naturalmente los equipos de desarrollo invierten el 80% del tiempo tratando de mejorar los procesos del backend( apache, sql, php, etc) , que lamentablemente, solo repercute en el 20% del tiempo de respuesta al cliente.  Por ejemplo, si miramos la siguiente imagen que muestra el tiempo de carga de los elementos de yahoo.com con la cache vacia,  podemos ver solo el 10% del tiempo de loading es destinado a obtener el html y el 90% restante a los componentes de la página (imágenes, css, javascript, etc ).

loading yahoo.com

loading yahoo.com

Antes de este estudio los sitios clásicos como amazon, msn, google, youtube y otros, gastan entre el 62% y 95%  del tiempo de carga en los componentes adicionales.

Si pensamos que muchos de los usuarios todavía utilizan browsers que solo descargan dos componentes en paralelo, respetando lo que indica el HTTP 1.1 nos vemos mas perjudicados.

En resumen y como principal regla a la hora de desarrollar un sitio web o una webapp es: tratar de minimizar la cantidad de request (componentes que carga nuestro page).

Obviamente, que depende del tipo de desarrollo que estemos realizando, pero hay muchas técnicas para que los componentes adicionales (CSS, Javascript, imágenes) en nuestro site sean menos agresivas en el tiempo de carga (loading time). Estas técnicas las veremos en los próximos Tips.

Suerte

Posted in performance, webapps | Tagged , , , , | Leave a comment

Porque webapps de alta performance?

By martin | Published: 2009/02/26

Todos los que nos encontramos en el mundo de la informática desde antes del 2000, hemos podido vivir el proceso de crecimiento de Internet en todo sentido.  No hace falta detallar su evolución, estado actual o evidente crecimiento. Pero si es importante notar que la accesibilidad y las ventajas que presenta es cada ves mayor.

En este contexto, los desarrolladores  de aplicaciones de gestión sabemos las múltiples desventajas que conlleva el desarrollo, la implementación y el mantenimiento de aplicaciones en la clásica arquitectura de escritorio, frente a la nueva y mejorada día a día arquitectura web. Quiero dejar en claro que esto es independiente de las técnicas, herramientas, lenguajes y sistemas operativos que utilicemos.

Es por ello que estoy convencido que las aplicaciones de escritorio migrarán a aplicaciones web o webapps,  gracias a la mejora constante de los navegadores, como por ejemplo la arquitectura de Tab-Thread del Chrome, las mejoras en los motores de render, en las maquinas virtuales de JavaScript como V8 o SpiderMonkey, y adicionalmente las mejoradas técnicas como Ajax, web ofline (Google Gears), y otras.

De esta forma nos encontramos en una situación donde el mercado necesita migrar su software de gestion a la web. Y en esta tarea es imprescindible mantener la usabilidad y desempeño anterior, en una arquitectura que fue diseñada originalmente para transportar y compartir solo texto.

Por estas razones, voy a compartir con ustedes mis experiencias en breves tips, a fin de lograr mejores aplicaciones web.

Posted in webapps | Tagged | Leave a comment