Avisar de contenido inadecuado

Optimizacion en Pixelovers

Expand

Javascript y jQuery: Consejos y Buenas Practicas (Parte II)

Hace unas semanas iniciamos una serie de 2 posts para hablar de lo que consideramos que son unas buenas practicas para desarrollar codigo Javascript con la libreria jQuery.

http://stc.obolog.net/multimedia/fotos/309000/308801/308801-209198.jpg

Con este post cerramos la serie y profundizamos un poco más en el tema

En el primer post de esta serie comentamos algunas generalidades que nos pueden servir de base a la hora de desarrollar un código JS eficiente. En este segundo post hablaremos de como solucionar de forma eficiente problemas concretos que nos solemos encontrar en nuestros desarrollos.

Asi que, ahi vamos...

Expand

Javascript y jQuery: Consejos y Buenas Practicas (Parte I)

jQuery es una de las librerias mas utilizadas por los desarrolladores FrontEnd por su versatilidad y facilidad de uso. En Pixelovers somos autenticos fans de esta libreria.

http://stc.obolog.net/multimedia/fotos/309000/308801/308801-209198.jpg

Es por esto que queremos compartir con vosotros lo que consideramos que son unas buenas practicas a la hora de programar codigo Javascript ayudandonos de la libreria jQuery.

El objetivo de este compendio de buenas practicas es conseguir un codigo Javascript lo mas limpio, claro y eficiente posible.

Los tips que aqui incluimos estan sacados de nuestra propia experiencia y de conclusiones interesantes que hemos ido encontrando por la red y que hemos acoplado a nuestro repertorio.

Como son muchos los puntos tratados y para no cargar el post con demasiada informacion vamos a dividir este compendio en 2 partes.

En esta primera parte hablaremos de normas generales a seguir que te ayudaran a crear un codigo mas claro y eficiente. En un segundo post hablaremos de como solucionar de forma eficiente problemas concretos que nos solemos encontrar en nuestros desarrollos.

Y una vez dicho esto, vamos al lio...

Consideraciones Generales

  • Aprenderse bien la librería. Para utilizar siempre la solución mas optimizada posible. No está de mas tener a mano una chuleta de jQuery como comentabamos en otro post hace unas semanas o ir directamente a la documentacion oficial de jQuery
  • Utilizar librerias consolidadas, versatiles, con soporte y con proyecto de futuro. Por ejemplo jQuery como librería principal y jQuery Tools y jQuery UI como liberias adicionales de efectos
  • Trabajar en archivos separados. Mejor crear JS's diferentes para cada funcionalidad separable de nuestro site y luego utilizar algun sistema que junte todos estos JS's en uno final (comprimido y ofuscado)
  • Javascript no intrusivo. Nunca depender de JS en la medida de lo posible. Si está desactivado el javascript o falla, que la pagina muestre un aspecto normal. Javascript es una mejora, no un sistema de seguridad.
  • Optimiza el codigo haciendo pruebas de rendimiento. Con Firebug podemos medir el tiempo que tarda una funcion (o trozo de codigo) en ejecutarse:
    			
    	console.time('native');  
    	var l = array.length;
    		for (var i=0;i<l; i++) {
            array[i] = i;  
    	}  
    	console.timeEnd('native');  
    			 
    		
  • Comprimir el codigo al final. Al comprimir el codigo el archivo JS que tendrá que bajarse el usuario será de menor tamaño, aunque hay que valorar el rendimiento final ya que por el contrario el navegador tendrá que realizar el proceso adicional de descomprimir el codigo antes de ejecutarlo.Para comprimir el codigo disponemos de herramientas, tipo YUI Compressor aunque hay muchas mas
  • El marcado semantico y accesible viene primero. No adaptar el marcado para facilitar el JS sino que sea el JS el que se adapte al marcado. Con ID’s, herencia, y clases podemos acceder a cualquier elemento y asignarle funcionalidades

    Marcado horrible:

    			
    	<table>
    	    <tr>
    	    	<td onclick="doSomething();">First Option</td>
    	        <td>First option description</td>
    		</tr>
    		<tr>
    			<td onclick="doSomething();">Second Option</td>
    			<td>Second option description</td>
    		</tr>		
    	</table>
    			

    Marcado malo:

    	
            <dl>
    		<dt onclick="doSomething();">First Option</dt>
    		<dd>First option description</dd>
    		<dt onclick="doSomething();">Second Option</dt>
    		<dd>Second option description</dd>
    	</dl>
    		

    Buen marcado:

    			
    	<dl id="OptionList">
    	    <dt>First Option</dt>
    	    <dd>First option description</dd>
    	    <dt>Second Option</dt>
    	    <dd>Second option description</dd>
    	</dl>
    			
    
  • Encapsular lo maximo posible el codigo. Esto significa agrupar todas las funciones comunes dentro de una funcion padre, asi acotamos el contexto de cada funcionalidad (objeto si hace falta)

    Ejemplo:

    			
    	var mySite = new Object();
    	
    	mySite = {
    		
    		var1 : 1,
    		var2 : 2,
    		valorCalculado,
    		
    		init : function() {
    			// aqui hago varias cosas
    			this.valorCalculado = "hola";
    			this.funcionalidad1();
    		},
    		
    		funcionalidad1 : function() {
    			// aqui desarrollo una funcionalidad concreta
    		
    		}
    	}
    	
    	// desde fuera (o desde otro objeto) puedo llamar a las funciones de este objecto
    	mySite.funcionalidad1();
    					
    
  • Elimina consultas innecesarias. Podemos ahorrarnos la llamada al $(document).ready() lanzando el <script> justo antes de cerrar el tag </body> lo que nos asegura que todos los elementos que podemos necesitar están ya cargados en el árbol DOM.

    Menos eficiente:

    			
    	$(document).ready(function(){
    		mylib.article.init();
    	});
    			
    

    Mas eficiente:

    			
    		<script type="text/javascript>
            	  mylib.article.init();
    		</script>
    	</body>
    			
    
  • “Eval is evil” Evitar el uso de eval. Problemas de seguridad. Mas info de por qué puede ser un problema aqui. Una posible alternativa al uso de EVAL puede ser JSON.parse o JSONP

Y hasta aqui la primera parte del asunto...

¿Que te han parecido los puntos aqui comentados? ¿Estas de acuerdo? ¿Algun punto que creas que falta en esta lista?

Enlaces y más

Expand

The Smashing Book

Libro de Smashing MagazineYa por fin ha salido a la venta el libro de Smashing, en el que encontrarás las mejores prácticas en diseño Web moderno. Sus 313 páginas están llenas de consejos técnicos y buenas prácticas de codificación, usabilidad y optimización, adnás podrás aprender a como crear interfaces de usuario con éxito y aplicar los principios de marketing para aumentar las tasas de conversión. Todo esto no sería posible sin mostarte cómo obtener el máximo provecho de la tipografía, color y marca.

Un libro muy recomendable para los diseñadores web y desarrolladores de interfaces, que espero tener en mis manos muy pronto para poder contar de primera mano mis impresiones.

Expand

CDN (Content Delivery Network) gratis con Google App Engine

Google App EngineAyer me comentaba un compañero de trabajo que estaba buscando un hosting donde alojar la web de su grupo: muchas imágenes, sonido, vídeo... mucho archivo estático. El problema que se encontraba muchas veces es que los planes que se adecuaban a su proyecto, en CPU, memoria y espacio en disco, se quedaban cortos en transferencia mensual y velocidad de la conexión, y viceversa: los que encajaban en cuanto a transferencia se excedían en todo lo demás (también en el precio). A raíz de esto, me acordé de un artículo que leí hace poco en Maestros del Web: 10 pasos fáciles para usar Google App Engine como tu propia red de distribución de contenido.

Una red de distribución de contenido (CDN) es lo que suelen usar las webs grandes para agilizar la distribución de archivos estáticos (imágenes, hojas de estilo, javascripts, multimedia...). Las CDNs permiten tener nuestros contenidos replicados en múltiples servidores por todo el mundo, acelerando la descarga de los mismos de cara a los clientes, puesto que éstos siempre se sirven desde la ubicación más cercana al usuario. Suelen ser sistemas demasiado caros para que pequeños proyectos o particulares se planteen siquiera su uso.

Content Distribution NetworkLo que propone Andreas Kohn en el artículo es utilizar la Google App Engine para montar nuestro propio CDN gratis, o a bajo coste (cobran a partir de 500MB de alojamiento o por encima de los 5 millones de PV. A pesar de esto, los precios son muy muy bajos).

No lo he probado, pero parece muy sencillo de desarrollar. Disponer de la infraestructura de servidores de Google a nuestra disposición bien merece el esfuerzo, no? Está por ver, sin embargo, si el rendimiento vale la pena. En experiencias similares que otros han tenido tratando de utilizar Amazon S3 (el equivalente de Amazon en cuanto a alojamiento) con los mismos fines, los resultados no fueron muy buenos.

Expand

CSS Sprites. Mejora el rendimiento de tu web (I)


Con este artículo empezaremos una serie de posts que tratarán de diversas técnicas y consejos que podemos seguir para mejorar el rendimiento y los tiempos de carga de nuestra página web. Y es que el rendimiento de una aplicación web no sólo depende de la programación del lado del servidor, si no también del marcado, el uso que hagamos de hojas de estilo, de imágenes, de nuestra programación javascript... Todos ellos campos que afectan directamente al desarrollador web en su faceta de maquetador/diseñador.

Hoy empezaremos desarrollando una técnica CSS muy sencilla y efectiva: Los CSS Sprites.

La problemática.

Una de nuestras máximas prioridades a la hora de optimizar nuestra aplicación web debe ser reducir las peticiones que ésta hará al servidor una vez el HTML se haya cargado en el navegador del cliente. Cada archivo de hoja de estilos, cada archivo Javascript, cada imagen... cada elemento externo en definitiva, se solicita de forma separada y aumenta por tanto la transferencia y el tiempo de carga, esto resulta obvio. Lo que no resulta tan evidente es que ese aumento no es proporcional a la suma del tamaño de los archivos externos, es decir, la carga de 10 elementos de 5 KB no es igual de rápida que la de un elemento de 50 KB.

Además de sumar los tiempos de transferencia para cada archivo, deberemos sumar por un lado el tiempo que tarda en realizarse la propia conexión+petición+respuesta y el tamaño correspondiente a las cabeceras del archivo. Recordemos, en relación a las cabecera, que éstas se adjuntan a cada petición al servidor y que si, además, nuestra aplicación usa cookies, éstas también se adjuntarán a cabeceras para cada archivo. Podría darse el caso, por ejemplo en un archivo de imagen pequeño, en qué el tamaño de las cabeceras + cookies ¡superara al tamaño del propio archivo!

La solución.

Este sería un claro ejemplo de una técnica antigua retomada para solucionar un problema moderno. Y es que para encontrar el origen de los CSS Sprites debemos mirar atrás hacia los antiguos juegos en 2D ( o los actuales juegos para móviles ), que usaban los "sprites" para las animaciones de sus personajes u otros elementos del juego. 

37249-34955.jpg

Como ves, los sprites no eran más que imágenes que contenían a su vez varias imágenes pequeñas, que en el caso de los videojuegos se utilizaban para recrear una animación. En nuestro caso, la solución a las múltiples peticiones para imágenes en nuestras hojas de estilo pasará por el uso de imágenes grandes que contengan a su vez varias imágenes más pequeñas. De esta forma, para mostrar diversos fondos o varios iconos, estaremos realizando una única petición al servidor, con el correspondiente ahorro en tiempo de carga y transferencia.

Implementación.

El "truco" en esta técnica está en el uso correcto del posicionamiento de backgrounds para mostrar sólo aquella parte de la imagen que nos interesa. Pongamos como ejemplo un menú, en el que queremos mostrar un icono diferente por cada opción.

Nuestro HTML podría ser algo parecido a:

<ul>
    <li class="option1">Opción 1</li>
    <li class="option2">Opción 2</li>
    <li class="option3">Opción 3</li>
</ul>

y para el CSS usaríamos

    .option1, .option2, .option3 { padding-left:20px; }
    .option1 { background:url(iconos.png) 0 0 no-repeat;
    .option2 { background:url(iconos.png) 0 -30px no-repeat;
    .option3 { background:url(iconos.png) 0 -60px no-repeat;

Como verás, hemos jugado con el posicionamiento vertical de la imagen para mostrar sólo aquella parte de la misma que nos interesa, la que contiene el icono en cuestión:

37249-34957.jpg               37249-34969.jpg

A partir de aquí podemos aplicar esta técnica de trabajo a muchos otros casos, ya no sólo iconos, sino fondos de imagen, pestañas, u otros elementos gráficos de interfaz.

Es fácil hacerse una idea del ahorro conexiones que podemos conseguir: una página con 20 iconos y 3 fondos de imagen diferentes para distintos contenedores pasaría de 23 peticiones de imágenes desde las CSS a sólo 2: una imagen conteniendo todos los iconos y otra conteniendo los fondos.

Más información.