uda-desarrollo rup. consejos y buenas prácticas

UDA – Utilidades de desarrollo de aplicaciones by EJIE is licensed under a Creative Commons Reconocimiento-NoComercial-CompartirIgual 3.0 Unported License.

UDA - Utilidades de desarrollo de aplicaciones

Desarrollo RUP - Consejos y buenas prácticas

Fecha: 23/12/2011 Referencia:

EJIE S.A.

Mediterráneo, 14

Tel. 945 01 73 00*

Fax. 945 01 73 01

01010 Vitoria-Gasteiz

Posta-kutxatila / Apartado: 809

01080 Vitoria-Gasteiz

www.ejie.es

Desarrollo RUP – Consejos y buenas prácticas ii/44

Control de documentación

Título de documento: Desarrollo RUP – Consejos y Buenas Prácticas

Histórico de versiones

Código: Versión: Fecha: Resumen de cambios:

1.0.0 23/12/2011 Primera versión.

Cambios producidos desde la última versión

Control de difusión

Responsable: Ander Martínez

Aprobado por:

Firma: Fecha:

Distribución:

Referencias de archivo

Autor:

Nombre archivo:

Localización:

Desarrollo RUP – Consejos y buenas prácticas iii/44

Contenido

Capítulo/sección Página

1. Introducción 7

2. Buenas prácticas de diseño 8

2.1. Introducción 8

2.2. Volumen de las JSP 8

2.3. Flujo de navegación 9

3. Plugins en jQuery 10

3.1. Introducción a jQuery 10

3.2. Diseño de plugins en jQuery 10

3.2.1. Estructura general 11

3.2.2. Único nombre en el namespace 11

3.2.3. Opciones como argumento 11

3.2.4. Cambio de ajustes por defecto 12

3.2.5. Funciones secundarias 12

3.2.6. Protección de funciones privadas 12

4. Gestión del contenido estático 14


4.2. Servir el contenido estático 14

4.2.1. Ubicación 14

4.2.2. Minimización 15

4.2.3. Compresión 15

4.3. Carga de imágenes mediante sprites 15

4.3.1. Herramienta para la generación de sprites 16

5. Normativa de estilos (CSS) 18

Desarrollo RUP – Consejos y buenas prácticas iv/44


5.2. Validación de CSS (W3C) 18

5.3. jQuery UI ThemeRoller 18

5.4. Aplicación de estilos sobre diferentes navegadores (Hack’s) 20

5.4.1. Comentarios condicionales en Html 20

5.4.2. Hack’s 22

6. Herramientas de ayuda al desarrollo 25


6.2. Firebug 25

6.2.1. Consola 25

6.2.1.1. Objeto console 26

6.2.2. HTML 27

6.2.3. CSS 27

6.2.4. Script 28

6.2.5. Red 29

6.2.6. DOM 30

6.3. Firebug (Lite) 31

6.4. IE Developer Toolbar 31

6.5. jslog 32

6.6. YSlow 34

6.6.1. Contenido 34

6.6.1.1. Minimizar las peticiones http 34

6.6.1.2. Reducir los DNS Lookup 35

6.6.1.3. Evitar redireccionamientos 35

6.6.1.4. Habilitar el cacheo de Ajax 36

6.6.1.5. Postcarga de componentes 36

6.6.1.6. Precarga de componentes 36

Desarrollo RUP – Consejos y buenas prácticas v/44

6.6.1.7. Reducir el número de elementos DOM 36

6.6.1.8. Repartir componentes en dominios 37

6.6.1.9. Reducir el número de iframes 37

6.6.1.10. Evitar los errores 404 37

6.6.2. Servidor 38

6.6.2.1. Utilizar una red de distribución de contenido (CDN) 38

6.6.2.2. Añadir cabeceras de expiración o de control de la cache 38

6.6.2.3. Compresión de componentes (GZIP) 38

6.6.2.4. Configurar ETags 38

6.6.2.5. Facilitar el renderizado 39

6.6.2.6. Usar método GET para peticiones Ajax 39

6.6.2.7. Evitar dejar vacío el atributo src de las imágenes 39

6.6.3. Cookie 40

6.6.3.1. Reducir el tamaño de las cookies 40

6.6.3.2. Usar dominios libres de cookies para componentes 40

6.6.4. CSS 40

6.6.4.1. Colocar las hojas de estilo al inicio 40

6.6.4.2. Evitar las expresiones CSS 40

6.6.4.3. Optar por <link> en lugar de @import 40

6.6.4.4. Evitar los filtros 41

6.6.5. JavaScript 41

6.6.5.1. Colocar los scripts al final 41

6.6.5.2. Externalizar CSS y Javascript 41

6.6.5.3. Minimizar CSS y Javascript 41

6.6.5.4. Eliminar scripts duplicados 41

6.6.5.5. Minimizar el acceso DOM 42

6.6.5.6. Desarrollar controladores de eventos inteligentes 42

Desarrollo RUP – Consejos y buenas prácticas vi/44

6.6.6. Imágenes 42

6.6.6.1. Optimizar las imágenes 42

6.6.6.2. Optimizar los CSS sprites 43

6.6.6.3. No escalar las imágenes en HTML 43

6.6.6.4. Hacer el favicon.ico pequeño y cacheable 43

6.6.6.5. Móviles 43

6.7. HttpWatch 43

Desarrollo RUP – Consejos y buenas prácticas 7/44

1. Introducción

El presente documento quiere servir de guía orientativa para los desarrolladores que integren o utilicen los patrones de RUP en una aplicación. A lo largo del mismo se darán una serie de pautas, consejos y recomendaciones que buscan facilitar y agilizar el desarrollo y futuro mantenimiento de las aplicaciones.

Se han definido diferentes apartados, agrupados según temática, para tratar diferentes aspectos del desarrollo de la capa de presentación con RUP (buenas prácticas, gestión del contenido estático, estilos, herramientas de ayuda al desarrollo…). Cada apartado no es completamente independiente y puede estar ligado, en mayor o menor medida, a alguno de los otros. Así, en la medida de lo posible, se ha procurado introducir y presentar los conceptos de forma previa (incluso en apartados anteriores) al desarrollo de los mismos, pero es posible que el lector se encuentre con alguna excepción insalvable.

El objetivo principal de este documento es hacer de repositorio del conocimiento y experiencias recopilada a la hora de desarrollar, integrar y utilizar RUP. Esta información se puede extrapolar a nuevos desarrollos, por lo que es interesante tenerlo en cuenta para no incurrir en errores o malas prácticas detectadas y para tener conocimiento de herramientas que puedan facilitar y agilizar el desarrollo.


2. Buenas prácticas de diseño

2.1. Introducción

El apartado actual es un compendio de Buenas Prácticas a la hora de diseñar una aplicación. Mediante el uso y aplicación de dichas prácticas se conseguirá una aplicación más mantenible y que gestione mejor los recursos disponibles, además de mejorar la experiencia del usuario a la hora de interactuar con ella.

2.2. Volumen de las JSP

A la hora de servir una página (jsp), el tiempo de descarga y presentación depende directamente del tamaño y complejidad de la misma. En muchos casos, la complejidad de una página es inevitable, por cuestiones de negocio, pero el tamaño excesivo o innecesario puede acarrear penalizaciones que pueden paliarse u optimizarse.

Una práctica muy habitual a la hora de diseñar una página (jsp) es incluir elementos que el usuario no va a tener que visualizar o utilizar hasta que ocurra una determinada circunstancia, se realice alguna petición al servidor o se aporte cierta información. Esta información, que no va a ser usada o visualizada de forma directa, se va descargar con el grueso de la página y va a aumentar el tamaño de información descargado. Como consecuencia directa de esta circunstancia, se van a incrementar los tiempos de descarga de las páginas y la experiencia de usuario se verá perjudicada por la sensación de pesadez y lentitud.

El código innecesario de las páginas, unido a un posible exceso de complejidad, a una inexistente ordenación y a una falta de modularidad, va a penalizar la legibilidad y manejo de las páginas en las fases de desarrollo y va a mermar su rendimiento a nivel productivo. El uso arbitrario de este tipo de páginas va a provocar un aumento de costes y una posible pérdida de calidad.

Para no incurrir en este tipo de “mala praxis”, existen un conjunto de buenas prácticas que mejoran la organización, favorecen la legibilidad y permiten modular las páginas para su descarga distribuida:

• Extraer el contenido estático de la página: Tanto los estilos como el código JavaScript

pueden extraerse de la jsp y ubicarse en sendos ficheros css y js. Este tipo de práctica, además de reorganizar y hacer más legible la jsp, permite la descarga de los ficheros desde el servidor Web con lo que la descarga de la página se agiliza (menos datos que enviar desde el servidor de aplicaciones).

• Dividir la página en fragmentos mediante includes: Toda jsp puede ser fragmentada en

distintos ficheros. Dichos ficheros (jsp) se asocian a la página original mediante directivas include. Este tipo de práctica es muy habitual para estructurar páginas muy grandes en fragmentos más manejables y entendibles. Los criterios para dividir las páginas son numerosos pero la opción mas acertada, en la mayoría de los casos, es dividir la página en fragmentos funcionalmente lógicos.

Dependiendo del tipo fichero usado para cada fragmento de la jsp, las directivas usadas deberían ser las siguientes:

si los fragmentos son includes (.inc):


<%@include file="nombreFile.inc"%> si los fragmentos son otras jsps (.jsp): <jsp:include page="nombrePage.jsp"></jsp:include>

• Inclusión de contenidos comunes mediante un include: Una buena práctica para ordenar y

volver más legibles las páginas (jsp) es agrupar los elementos comunes (p.e., carga de estáticos) de varias páginas en una página externa e incluirla en las jsps que tengan estos componentes en común. Con esta medida se evita repetir código (el mismo conjunto de sentencias se extrae a un punto común) y se facilita el entendimiento de las páginas (en las páginas que hacen uso del código extraído solo será necesaria la directiva de inclusión).

• Carga de contenido vía ajax: La presencia de componentes que se cargan o ejecutan en

función de otros es muy habitual y en muchos casos enriquece las funcionalidades de las páginas, pero conlleva un aumento del peso de las páginas presentadas. Bajo ciertas circunstancias una alternativa, a la carga inicial de toda la información involucrada en una jsp, es utilizar la tecnología ajax y descargar, según demanda o en modo desatendido (sin que el usuario lo perciba) la información que se precise. Este modelo de diseño no es aplicable a todos los casos, por lo que es cuestión de los desarrolladores el valorar, incluir y optimizar su uso. Esta buena práctica tiene como contrapartida que siempre habrá que tener en cuenta la saturación del servidor por excesivas llamadas ajax.

2.3. Flujo de navegación

Los aspectos funcionales y las decisiones, que en las fases iniciales del proyecto se toman, son determinantes a la hora de marcar la evolución y complejidad del desarrollo posterior. Uno de los aspectos que, a veces, se toma más a la ligera y que puede ser muy importante en un desarrollo es el “flujo de navegación”. Una buena definición del flujo de navegación y un buen uso de los distintos componentes (respetando la naturaleza de los mismos), puede favorecer la experiencia de los usuarios o convertirla en un guirigay incomprensible.

En torno a esta idea, se ha detectado un uso incorrecto del patrón pestañas. El patrón no debe estar involucrado, de forma directa, en el flujo de navegación de las aplicaciones, sino en la gestión y presentación de datos. El uso de las pestañas se recomienda para contener, separar y agrupar datos interrelacionados de distinta naturaleza, y nunca para simular la navegación a páginas consecutivas o relacionadas funcionalmente.

Este uso incorrecto del patrón, responde a la necesidad de estructurar y separar el flujo de navegación, en diferentes pasos o etapas, funcionalidad ya cubierta por el patrón Wizard. Este patrón, facilita, el diseño e implementación de flujos de páginas y aporta mecanismos para que los usuarios tengan control de las acciones que hacen y del punto en el que se encuentran.


3. Plugins en jQuery

3.1. Introducción a jQuery

jQuery (http://docs.jquery.com/) es una biblioteca o framework de Javascript, creada inicialmente por John Resig, que permite simplificar la manera de interactuar con los documentos HTML, manipular el árbol DOM, manejar eventos, desarrollar animaciones y agregar interacción con la tecnología ajax a páginas web. Se conforma de un único fichero Javascript que contiene las funcionalidades comunes de DOM, eventos, efectos y ajax.

La característica principal de la biblioteca es que mediante la manipulación del árbol DOM y peticiones ajax, permite cambiar el contenido de una página web sin necesidad de recargarla.

Otras características reseñables:

• Selección de elementos DOM.

• Interactividad y modificaciones del árbol DOM.

• Eventos.

• Manipulación de la hoja de estilos css.

• Efectos y animaciones.

• Llamadas ajax.

• Soporta extensiones (plugins).

En la web http://visualjquery.com/ puede encontrarse una API no actualizada (v.1.2.6) pero muy intuitiva.

3.2. Diseño de plugins en jQuery

Una de las características más valorada de jQuery es su capacidad de extensibilidad a base de funciones y plugins. Esta capacidad de extensibilidad permite la adaptación de la librería, y los componentes derivados de ella, a las necesidades de la aplicación que la utilice.

Este modelo de extensibilidad, está tan integrado con el propio jQuery que la mayoría de métodos y funciones incluidas en el paquete por defecto están escritos usando el modelo de construcción y extensibilidad de jQuery. Si se desea más información al respecto, se puede encontrar en: http://docs.jquery.com/Plugins/Authoring

A la hora de crear o extender nuevas funciones o plugins, las distintos enfoques o estructuras usadas pueden diferir en distintos aspectos, por ejemplo RUP dispone de su propio modelo (ver: Desarrollo RUP – Estructura Base y Extensibilidad), pero todas se basan en las pautas marcadas por jQuery.


3.2.1. Estructura general

La estructura tipo a seguir tendría el siguiente aspecto:

jQuery.fn.nombreFuncion = function (properties) { return this .each( function () { alert( this ); } ); };

La invocación de estas nuevas funcionalidades o plugins, se realiza mediante la identificación a través de un selector del objeto al que se le va a aplicar y el nombre de la función o plugin invocado:

$( ”div a” ).nombreFuncion();

3.2.2. Único nombre en el namespace

Se recomienda el registro de un solo nombre en el namespace de jQuery, lo que implica un script con un único plugin. Se podrían definir varios nombres diferentes en el mismo fichero en caso de ser necesario.

Definición:

$.fn.hilight = function () { //... } ;

Invocación:

$( '#myDiv' ).hilight();

3.2.3. Opciones como argumento

Se recomienda el paso de un argumento que defina las diferentes configuraciones del plugin.

Definición:

$.fn.hilight = function ( options) { var defaults = { foreground: 'red' , background: 'yellow' } ; var opts = $.extend(defaults, options); //... } ;

Invocación:

$( '#myDiv' ).hilight ( { foreground: 'blue' } );


3.2.4. Cambio de ajustes por defecto

Mediante la exposición de los ajustes por defecto del plugin se facilita la modificación de estos parámetros directamente por parte del usuario.

Definición:

$.fn.hilight = function (options) { var opts = $.extend( {} , $.fn.hilight.defaults, options); //... } ; $.fn.hilight.defaults = { foreground: 'red' , background: 'yellow' };

Invocación:

$.fn.hilight.defaults.foreground = 'blue' ; $( '#myDiv' ).hilight();

3.2.5. Funciones secundarias

Una manera interesante de extender el plugin es mediante la definición y acceso a funciones secundarias. Al exponer la función format se da la opción de que esta sea redefinida, por lo que terceros podrían implementar sus propias reescrituras de la función.

Definición:

$.fn.hilight = function (options) { return this .each( function () { var $this = $( this ); var markup = $this.html(); markup = $.fn.hilight.format(markup); $this.html(markup); } ); } ; $.fn.hilight.format = function (txt) { return '<strong>' + txt + '</strong>' ; } ;

Invocación:

$.fn.hilight.defaults.foreground = 'blue' ; $( '#myDiv' ).hilight();

3.2.6. Protección de funciones privadas

Se deben proteger aquellas funciones a las que no se quiera permitir el acceso para evitar posibles reescrituras por parte de terceros.


Definición:

(function($) { $.fn.hilight = function (options) { debug( this ); // ... } ; function debug($obj) { if (window.console && window.console.log) window.console.log( 'selection count: ' + $obj.size()); } ; })(jQuery);

A continuación se muestra un plugin de ejemplo en el que aparecen resaltadas las partes del código referente a las recomendaciones:

(function($) { var settings = {} ; $.fn.jq_ejie_fecha = function ( properties ) { settings = $.extend( {} , $.fn.jq_ejie_fecha.defaults, properties); } ; $.fn.jq_ejie_calendario.habilitar = function (id, parentForm) { return $( '#' + id).datepicker( 'enable' ); } ; $.fn.jq_ejie_calendario.defaults = { ... } ; })(jQuery); function validarFecha(dia, mes, anio) { ... }


4. Gestión del contenido estático

4.1. Introducción

El presente capítulo tiene como objeto analizar y profundizar los principales aspectos que rodean la gestión de los contenidos estáticos.

En la actualidad, prácticamente toda aplicación web tiene una parte de contenido estático que puede ser de mayor o menor volumen. En función de cómo se diseñan y gestionan estos contenidos puede verse afectado el rendimiento y la respuesta de la aplicación. Los problemas puede deberse a exceso en el tamaño de los recursos, por un innecesario y desmedido número de peticiones de descarga o por errores en la composición del javaScript de las páginas (clases duplicadas, descargas de contenidos inexistentes, ubicación inapropiada en la pagina,…).

En los siguientes apartados, se tratará en profundidad una serie de recomendaciones y buenas prácticas asociadas a la manipulación del contenido estático.

4.2. Servir el contenido estático

A la hora de servir el contenido estático, más concretamente los ficheros de estilos (.css ) y de scripts (.js ), es recomendable que éstos sean correctamente ubicados, previamente minimizados y servidos en una única petición comprimida (fichero GZIP).

4.2.1. Ubicación

La ubicación utilizada para colocar los tags de inclusión de los css’s y js’s, al contrario de lo que se podría pensar, afecta a los tiempos de carga y visualización de las paginas.

Por un lado, los tags asociados a la carga de css’s se deben incluir en el <head> del html que compone la página. Esto se debe a que los css’s determinan el aspecto y forma de los distintos objetos incluidos dentro de una pagina. Si la carga de los mismos se incluye en la cabecera (HEAD) de las páginas, éstas se irán cargando progresivamente en el navegador. En caso contrario, si un navegador detecta la carga de hoja de estilos posterior a la creación de un objeto html aquél detendrá la visualización de la pagina (manteniéndola en blanco) para no cambiar el aspecto repetidas veces hasta descargar todos los css’s. Con esta medida, se consigue que las páginas se carguen más rápido, al no tener tiempos de espera innecesarios, y que se visualicen progresivamente (favoreciendo el manejo y la sensación de respuesta a los usuarios).

En el caso de los tags de invocación de los js’s, la ubicación adecuada sería en la parte inferior de las paginas (poco antes del fin del código de la página </html>). Esta recomendación se fundamenta en el comportamiento de los navegadores con este tipo de ficheros. Por la capacidad de modificación de los ficheros js’s sobre la disposición y aspecto de la pantallas, los navegadores bloquean cualquier otra acción (descarga, ejecución,…) hasta que termina el tratamiento de un js. En otras palabras, los navegadores detienen el procesado de una página, perdiéndose la capacidad de descarga en paralelo de la que disponen, hasta que terminan de tratar un js. Además, mediante esta estrategia, se minimizan los riesgos de ejecución de los js’s sobre objetos todavía no cargados en la pagina.


4.2.2. Minimización

La minimización consiste en reducir el tamaño de los ficheros. Para ello se emplean diversas técnicas como pueden ser eliminar los saltos de línea y espacios, tan necesarios en la legibilidad del código pero que aumentan el tamaño de los ficheros y por tanto el tiempo que tarda en procesarse su petición al servidor. Adicionalmente se puede ofuscar el código para evitar que terceros puedan acceder a él.

Por tanto mediante la minimización de los contenidos se logra reducir el volumen de datos que se transmite en cada petición con lo que la aplicación tendrá mejor tiempo de respuesta, se obtendrá una navegación más fluida y un rendimiento mayor.

Para la minimización del contenido, se recomienda utilizar la librería YUI Compressor (http://yuilibrary.com/projects/yuicompressor/). Esta librería se distribuye como fichero JAR y puede ser invocada desde una consola directamente o a través de una tarea ANT.

4.2.3. Compresión

Otro punto a tener en cuenta a la hora de servir el contenido estático, es la posibilidad de servir los ficheros de estilos y de scripts comprimidos todos ellos en un único fichero con formato GZIP y que este sea cacheado. De esta manera, el contenido estático se sirve una única vez y de manera rápida (al ser un fichero comprimido) con lo que se evitan continúas peticiones al servidor.

4.3. Carga de imágenes mediante sprites

Las imágenes son un recurso muy habitual en las aplicaciones web, ya que enriquecen la presentación de las mismas y las pueden hacer más atractivas al usuario. Pero el uso de imágenes puede representar un problema debido a la necesidad de realizar múltiples peticiones al servidor para recuperarlas penalizando el tiempo de respuesta. Para solventar esta problemática se recomienda el uso de sprites. Esta técnica puede ser muy eficaz para mejorar el rendimiento sobre todo en situaciones en las que se incluyen muchas imágenes pequeñas, tales como iconos de menú. Por ejemplo la página de Yahoo (Yahoo! home page) utiliza esta técnica.

Un sprite es una serie de imágenes ordenadas en forma de matriz formando una imagen mayor. Un ejemplo de sprite (icons.png ):


Mediante el uso de sprites, se consigue que en una única petición se obtengan todas las imágenes que una página está mostrando. De esta forma se reduce el número de invocaciones a servidor y por tanto se mejora el tiempo de respuesta de las páginas y el rendimiento del servidor.

Además de disminuir el número de peticiones a una sola, también se reduce el tamaño de los recursos enviados puesto que el tamaño de la imagen que forma el sprite será menor a la suma de los tamaños de todas las imágenes necesarias por separado.

A la hora de de trabajar con una imagen concreta de la matriz de imágenes, bastará con identificar su posición, dentro del sprite, mediante el atributo “background-position”. Este atributo indica la posición exacta donde se encuentra la imagen a cargar. A continuación se muestra un ejemplo de uso:

Estilo:

.imagen { background-image : url(xxx/images/icons.png) ; background-position : -96px -128px ; }

Imagen que se mostraría:

En la siguiente URL http://websitetips.com/articles/css/sprites/ , hay un tutorial sobre cómo generar un sprite propio y cómo configurar el fichero de estilos para que localice las imágenes. Dado que esta labor puede resultar repetitiva y tediosa, a continuación, se propone una herramienta OpenSource para facilitar el proceso de generación de sprites a partir de un conjunto de imágenes.

4.3.1. Herramienta para la generación de sprites

Existen múltiples herramientas para la generación de sprites, pero se recomienda el uso de “css Sprite Generator”.

Se trata de un proyecto OpenSource en el que partiendo de una serie de imágenes de origen se genera una sola imagen (sprite) que contiene todas las imágenes origen y los estilos css asignados a cada imagen.

Al tratarse de un proyecto abierto, permite la descarga del código fuente de la aplicación que realiza la conversión, programada en PHP, desde la página del proyecto.

• CSS Sprite Generador: https://launchpad.net/css-sprite-generator

Otra alternativa es el uso de la aplicación directamente desplegada en Internet:

• Aplicación online: http://es.spritegen.website-performance.org/

La aplicación online recibe un fichero comprimido (ZIP) con las imágenes a agrupar y genera: un texto con los estilos necesarios de cada imagen del sprite y un fichero que forma el sprite de imágenes. Se permite la configuración de múltiples opciones:


o Omisión de imágenes repetidas

o Redimensionado de imágenes

o Dirección del sprite (Vertical-Horizontal)

o Formato del sprite (PNG, GIF, JPG)

o Personalización del código CSS generado:

� Definición de un prefijo

� Definición de un sufijo


5. Normativa de estilos (CSS)

5.1. Introducción

El presente capítulo tiene como objeto el profundizar en los aspectos relativos a los ficheros de estilos. Si bien es cierto que toda aplicación web debe tener unos estilos jerarquizados y estructurados de una manera concreta y determinada, a la hora de la verdad en muchos casos esto suele resultar imposible o no se cumple en gran medida. Por ello se destacan aquí ciertas recomendaciones a la hora de gestionar los estilos del sitio web que se está desarrollando.

Por una parte se debe definir una nomenclatura y jerarquía en la implementación de estilos mediante la incorporación de namespaces. También debe asegurarse que los estilos cumplen (en la medida de lo posible) con los estándares definidos por el “World Wide Web Consortium” [W3C] (http://www.w3c.es/).

En un intento de facilitar la manipulación y el cambio de los distintos estilos aplicados a una aplicación, los componentes de RUP han sido desarrollados “ThemeRoller-like”. Para hondar en los distintos aspectos que influyen en dicha estrategia de generación de estilos, se procederá a explican las claves y las implicaciones asociadas al desarrollo mediante el “jQuery UI Theme Manager”.

Cada navegador, tomando como fundamento el cumplimiento del estándar de estilos de “World Wide Web Consortium” [W3C], procesa las hojas de estilo de manera diferente. Esta circunstancia provoca que las páginas no se visualicen igual en los diferentes navegadores (Internet Explorer, Firefox, Chrome, Safari,…). Para intentar corregir este tipo de anomalías visuales se van a enumerar ciertas claves asociadas a cada navegador.

5.2. Validación de CSS (W3C)

Una buena práctica, a la hora de implementar las hojas de estilo de una aplicación es ir validándolas mediante los validadores que proporciona el “World Wide Web Consortium” [W3C].

Si bien es cierto que, estas validaciones pueden mejorar la interpretación de los elementos por parte de los navegadores, en absoluto garantiza que dichos estilos se visualicen de la misma manera en los diferentes navegadores. Esto se debe a que cada navegador implementa de manera específica el procesamiento de los estilos.

A través de su página, http://jigsaw.w3.org/css-validator/, el “World Wide Web Consortium” [W3C] ofrece un validador de css’s capaz de validar los ficheros css indicando su URL (si están accesibles en Internet), mediante la subida directa de los mismos (a partir de una ruta local) o mediante la escritura directa de su contenido en la propia página de la herramienta.

5.3. jQuery UI ThemeRoller

Los componentes diseñados para RUP, como cualquier componente web, tienen unos estilos propios asociados a cada uno de los componentes. Para una presentación y manejo aséptico de los mismos, por defecto, se distribuyen en tonalidades de grises. Este modus operandi responde a una política de independencia total con cualquier portal o aplicación ya creada.


Los desarrolladores pueden modificar dichos estilos para adaptarlos a los colores corporativos de la aplicación donde vayan a integrarse los componentes de RUP. De cara a facilitar la modificación de los distintos estilos aplicados, los componentes RUP se han desarrollado como “ThemeRoller-like”. Este modelo de desarrollo permite alinear la jerarquía de los estilos de los componentes RUP con los estilos de “jQuery-UI” de forma que sea posible utilizar la herramienta “jQuery UI ThemeRoller” (http://jqueryui.com/themeroller/) para el diseño y gestión de estilos.

“jQuery UI ThemeRoller” permite diseñar temas de “jQuery-UI” a medida para una integración directa con las aplicaciones. La creación de un tema personalizado, es tan sencillo como seleccionar la pestaña “Roll your own” y ajustar la configuración. A medida que se cambian los parámetros del tema, los componentes de la interfaz de usuario se actualizarán automáticamente para reflejar los cambios de diseño realizados. Una vez acabada la configuración del mismo, se puede descargar el tema creado pinchando en “Download theme”. A la hora de la descarga se deberá especificar que componentes del tema se desean descargar, ya que se estructuran en paquetes según su funcionalidad: Core, Interacciones, Widgets y Efectos.

Existe la posibilidad de utilizar un tema prediseñado o cargarlo para realizar las modificaciones sobre éste. Accediendo a la pestaña “Gallery” se podrán visualizan todos los temas prediseñados y trabajar con ellos.

A continuación se muestra una captura de cómo se muestra la herramienta:

Además de trabajar sobre las paginas de diseño creadas por los desarrolladores de “jQuery-UI” es posible utilizar el “jQuery UI ThemeRoller” sobre las paginas de cualquier aplicación que se esté desarrollando. Para ello, en la página a tratar, se deberá ejecutar el siguiente código JavaScript:

javascript:(function(){if (!/Firefox[\/\s](\d+\.\d+)/.test(navigator.userAgen t)){alert('Sorry, due to security restrictions, this tool only works in F irefox'); return false; }; if(window.jquitr){ jquitr.addThemeRoller(); } el se{ jquitr = {};

jquitr.s = document.createElement('script'); jquitr .s.src = 'http://jqueryui.com/themeroller/developertool/deve lopertool.js.php'; document.getElementsByTagName('head')[0].appendChil d(jquitr.s);} })();

Hay que destacar que gracias al desarrollo “ThemeRoller-like” de los componentes de RUP, la personalización de los estilos se puede hacer de forma rápida y sencilla. En tres pasos se puede cambiar el aspecto general de toda la aplicación:

1. Mediante el “jQuery UI ThemeRoller” personalizar el aspecto de los componentes.

2. Descargar el tema.

3. Descomprimir el zip y sustituir el antiguo “custom-theme” por el nuevo dentro del proyecto que gestiona los recursos estáticos de la aplicación.

Para más información consultar el documento “Patrones RUP - Estructura Base y Extensibilidad.doc ”.

5.4. Aplicación de estilos sobre diferentes navegad ores (Hack’s)

Los estilos y el modo en que los distintos navegadores los gestionan es un problema que siempre ha estado presente a la hora de desarrollar cualquier aplicación web para varios navegadores. En muchos casos, la forma de afrontar este problema pasaba por desarrollar o adaptar, por separado, los estilos de la aplicación para cada uno de los navegadores donde se visualizara.

Con la proliferación de numerosos navegadores, el diseño de estilos de aplicación en función del navegador, a parte de ser un derroche de recursos excesivo, se convierte en un modelo de trabajo engorroso e inasumible. Ante esta perspectiva, ningún desarrollo asumiría la implementación de una aplicación para más de dos navegadores distintos. Por suerte, existen algunas alternativas para el desarrollo de los estilos que pueden facilitar la visualización de una aplicación en un entorno multinavegador. Entre las alternativas posibles, se encuentran los comentarios condicionales y los hack ’s.

5.4.1. Comentarios condicionales en Html

El uso de los comentarios condicionales se basa en la idea de añadir una sentencia selectiva en el html para que cargue un css u otro dependiendo del navegador que este utilizando el usuario.

En una primera aproximación, esta técnica permitiría tener un único fichero css por navegador y cargar uno u otro según fuera necesario. Pero yendo más allá, se podría crear un fichero css general, con los estilos aceptados por todos los navegadores, y otros ficheros css con las especificidades de cada navegador.

El código que implementa los comentarios condicionales tiene el siguiente esquema:

  <link rel ="stylesheet" href ="ejie-ie.css" mce_href =" ejie-ie.css" type ="text/css" / > <!—Fin sentencia condicional--> <! [ endif ] -- >

Como se puede observar, el código es una sentencia condicional que hace posible la ejecución de distinto código (cuerpo de la condición) según la condición, concretamente el tipo de navegador.

El código utilizado para ilustrar el esquema de uso cargará la hoja de estilo “ejie-ie.css” solo si el navegador utilizado es Internet Explorer (en cualquiera de sus versiones).

A continuación se enumeran los posibles selectores a utilizar en las sentencias condicionales:

Elemento Ejemplo Comentario

! [if !IE] El operador NOT. Se pone delante para invertir el valor booleano de la expresión.

lt [if lt IE 5.5] El operador menor que. Este ejemplo devuelve verdad si nos encontramos una versión anterior a IE 5.5.

lte [if lte IE 6] El operador igual o menor que. Este ejemplo devuelve verdad si esta versión es la 6 o más antigua.

gt [if gt IE 5] Operador mayor que. El ejemplo devuelve verdad si la versión es superior que la 5.

gte [if gte IE 7] El operador igual o mayor que. El ejemplo devuelve verdad si la versión es IE 7 o mayor.

( ) [if !(IE 7)] Operador para sub-expresiones. Usado en conjunto con operadores booleanos para crear expresiones más complejas.

& [if (gt IE 5)&(lt IE 7)] Operador AND. Devuelve verdad si todas las sub-expresiones son verdad.

| [if (IE 6)|(IE 7)] Operador OR. Devuelve verdad si cualquiera de las sub-expresiones son ciertas.

Algunos ejemplos más de uso de los comentarios condicionales serían los siguientes:

 <p>Usted no está usando un navegador Internet Exp lorer</p> <! [ endif ] -- >

<link rel ="stylesheet" href ="ejie-estilosGenerales.css" type ="text/css" media ="screen" /> <!-- [ if IE 7 ]> <link href ="estilo_ie7.css" rel ="stylesheet" type ="text/css" media ="screen" /> <! [ endif ] -- > <!-- [ if lt IE 7 ]> <link href ="estilo_ie.css" rel ="stylesheet" type ="text/css" media ="screen" />


<! [ endif ] -- >

5.4.2. Hack’s

Una manera menos sutil pero igual de efectiva que los comentarios condicionales, a la hora de resolver los problemas de estilos entre navegadores, es emplear hack’s en las hojas de estilos. El funcionamiento de los hack’s consiste en utilizar el conjunto de caracteres especiales que no son interpretables o que solo ciertos navegadores reconocen. Gracias a estas diferencias de interpretación entre los distintos navegadores, se pueden crear estilos que solo un tipo (o familia) de navegadores puede procesar.

El uso de hack’s es sencillo: para los estilos que se ven distintos de un navegador a otro, se pueden crear estilos específicos o versiones del mismo estilo que solo se apliquen al navegador que da problemas. Por ejemplo:

.caja { margin-left : 5px ; * margin-left : 2px ;}

El estilo caja, según el navegador utilizado, será interpretado de dos formas distintas:

Para cualquier navegador, a excepción del Internet Explorer 6, tendrá como valor de margen izquierdo “5 pixeles”. En caso de ser usado por un Internet Explorer 6, ya que es el único que acepta el carácter especial “*” al inicio de una palabra clave de un CSS, el valor del margen izquierdo tendrá un valor de “2 pixeles”.

Dentro de los hack’s existentes cabe destacar que muchos que se pueden encontrar en Internet no son fiables o no funcionan (por inconsistencias o por errores tipográficos). Por esta razón, a continuación se muestran dos grupos: hack’s validados (contrastados) y hack’s existentes.

-.Hack’s validados:

Partiendo de la especificación de un color rojo (red) para los css y un color azul (blue) para los atributos, se especifican la aplicación de los distintos hack’s para los distintos navegadores o familias de navegadores.

/***** Hack en CSS ******/

/* Solo IE6 */ * html .ejie-ejemplo{ color: red; } /* FF & Chrome */ html>/**/body .ejie-ejemplo { color: red; } /* IE 7-8 && FF && Chrome*/ html>body .ejie-ejemplo { color: red;


}

-.Hack’s existentes:

Partiendo de la especificación de un color rojo (red) para los css y un color azul (blue) para los atributos, se especifican la aplicación de los distintos hack’s para los distintos navegadores o familias de navegadores.

/***** Hack en CSS ******/

/* IE 6 y más antiguos */ * html #uno { color: red } /* IE 7 y más antiguos */ *:first-child+html #dos { color: red } /* IE 7 y navegadores modernos */ html>body #tres { color: red } /* Navegadores modernos (no el IE 7) */ html>/**/body #cuatro { color: red } /* Opera 9.27 y más antiguo */ html:first-child #cinco { color: red } /* Safari */ html[xmlns*=""] body:last-child #seis { color: red } /*safari 3+, chrome 1+, opera9+, ff 3.5+ */ body:nth-of-type(1) #siete { color: red } /* safari 3+, chrome 1+, opera9+, ff 3.5+ */ body:first-of-type #ocho { color: red } /* saf3, chrome1+ */ @media screen and (-webkit-min-device-pixel-ratio:0 ) { #diez { background: #FFDECE; border: 2px solid #f f0000 } } /* iPhone / mobile webkit */ @media screen and (max-device-width: 480px) { #veintiseis { color: red } } /* Safari 2 - 3.1 */ html[xmlns*=""]:root #trece { color: red } /* Safari 2 - 3.1, Opera 9.25 */ *|html[xmlns*=""] #catorce { color: red } /* Todos menos IE6-8 */ :root *> #quince { color: red } /* IE7 */ *+html #dieciocho { color: red }


/* Solo Firefox. 1+ */ #veinticuatro, x:-moz-any-link { color: red } /* Firefox 3.0+ */ #veinticinco, x:-moz-any-link, x:default { color: red } /***** Hack por atributos ******/

/* ie6 y más antiguos */ #once { _color:blue } /* ie7 y más antiguos */ #doce { *color: blue } /* or #color:blue */ /* Todos los navegadores menos IE6 */ #diecisiete { color/**/: blue } /* IE6, IE7, IE8 */ #diecinueve { color: blue\9; } /* IE7, IE8 */ #veinte { color/*\**/: blue\9; } /* IE6, IE7 – actua como un !important */ #veintesiete { color: blue !ie; }


6. Herramientas de ayuda al desarrollo

6.1. Introducción

El presente apartado tiene como objeto el presentar diferentes herramientas que pueden ayudar a desarrollador a la hora de implementar una aplicación. Estas herramientas tendrán ámbitos tan dispares como la manipulación y gestión de estilos o el trazado mediante sentencias javaScript.

El uso de las herramientas es recomendable ya que gracias a ellas se pueden solventar muchos de los problemas más comunes encontrados en la creación de una aplicación web.

6.2. Firebug

Firebug (http://getfirebug.com) es una extensión para Mozilla Firefox que contiene una serie de funcionalidades indispensables para el desarrollo de cualquier sitio web. Entre sus opciones se destacan:

• Edición de HTML en tiempo real

• Edición online de hojas de estilos

• Monitorización del tiempo de carga de las páginas

• Depurador de Javascript

• Gestor de errores en Javascript, CSS y XML

• Explorador del árbol DOM

Para gestionar todas estas funcionalidades Firebug contiene una ventana que se divide en diferentes pestañas que se detallan a continuación.

6.2.1. Consola

La consola muestra las peticiones ajax (get o post) que realiza la página, las cabeceras, las variables enviadas y la respuesta del servidor. También muestra los errores javaScript que se producen en la página junto a un enlace donde se puede ver la línea de código exacta que produce el error.

Esta consola puede ser una gran ayuda a la hora de desarrollar y de probar los componentes ya que permite ejecutar código javaScript. Por tanto se puede incluir el código que se está desarrollando y ejecutarlo directamente en la página sin tener que realizar cambios en la JSP continuamente.

A continuación se muestra un ejemplo que ejecuta el código javaScript necesario para lanzar el componente diálogo. El código se introduce en la parte inferior derecha y tras pulsar el botón “Ejecutar” se ejecuta. En la parte inferior izquierda se ve como se ha ejecutado la sentencia y aparece la ventana de diálogo:


6.2.1.1. Objeto console

A nivel de javaScript, existe un objeto console que representa la salida estándar de consola. Este objeto interacciona directamente con la consola de Firebug o cualquier otra que posea el navegador (por ejemplo, el chrome dispone de la suya propia).

Este objeto contiene varias funcionalidades que permiten mostrar información en la consola sin necesidad de recurrir a los molestos “alert()” y sus paradas de ejecución.

La forma más sencilla de escribir en la consola es utilizar el metodo log: console.log ("hello world"). Dicho método, acepta un numero ilimitado de argumentos: console.log (2,4,6,8,"foo",bar). Los objetos pasados como parámetros se mostrarán como enlaces y pinchando en cada uno de ellos se navegará a su detalle. Existe la posibilidad de que el objeto se muestre desglosado mediante el uso de la sentencia dir: console.dir (object).

El objeto console es capaz de trabajar con diferentes niveles de traza. En función de éstos, en la consola, aparecerán los datos resaltados de diferente manera. Los niveles de traza existentes son:

• console.debug()

• console.info()

• console.warn()

• console.error()

Las funcionalidades descritas son las más importantes pero no las únicas. Se puede encontrar más información en: http://getfirebug.com/logging


6.2.2. HTML

Mediante esta pestaña Firebug permite editar el html en tiempo real. Especialmente interesante es el “Inspector de html” que permite detectar los elementos pasando el ratón por encima. Una vez localizado el elemento deseado se podrá editar en tiempo real.

Las funcionalidades, más destacadas, que aporta esta pestaña son:

• Ver código fuente generado

• Resaltar cambios

• Editar html en tiempo real

• Encontrar elementos con el ratón

• Inspeccionar un elemento y recargarlo sin perderlo

• Copiar el html

A continuación se muestra un ejemplo de la pestaña html inspeccionado un elemento. Para cambiar los estilos aplicados, se puede pinchar en la ventana inferior derecha y deshabilitar determinados estilos o se puede editar directamente el código pulsando el botón Editar de la ventana izquierda.

6.2.3. CSS

Mediante esta pestaña se accede fácilmente a la edición de estilos de la página en tiempo real. Como ya se ha comentado anteriormente, la apariencia de las aplicaciones puede variar entre


navegadores. Mediante esta herramienta se facilita el famoso método de “Prueba y Error” para la encontrar los estilos correctos y deseados.


• Previsualizar colores e imágenes

• Inspeccionar la hoja de estilos

• Editar estilos y ver los cambios en tiempo real

• Ayuda en línea y corrector de errores tipográficos

Se puede seleccionar el fichero de estilos aplicado en la página como se muestra en el ejemplo de la pestaña CSS para su manipulación:

6.2.4. Script

El debugger de javaScript incorporado permite controlar la ejecución de los códigos javaScript para conseguir localizar posibles fuentes de error, así como mejorar el rendimiento del código.


• Encuentra cualquier script fácilmente

• Ejecución paso a paso

• Detección de errores y puntos de ruptura

• Ver el valor de las variables en tiempo real

• Saltos fáciles a cualquier línea del código


• Modo “Profile” que muestra un completo análisis de los tiempos de carga y ejecución que ha provocado la navegación por la página.

A continuación se presenta una captura del depurador del código javacript. En la línea 165 se puede observar un punto granate mostrando un punto de ruptura (BreakPoint), y en la línea 170 una flecha amarilla que indica cuál es la siguiente sentencia a ejecutar. La ejecución paso a paso se controla mediante los botones de la parte superior.

6.2.5. Red

La pestaña Red ofrece la posibilidad de controlar las peticiones que realiza la aplicación tanto para la descarga de contenido estático (js, css o imágenes) así como peticiones ajax, para poder controlar los tiempos de respuesta así como los parámetros de envío y de respuesta. Permite realizar un filtrado según el tipo de petición: todo, html, css, js, xhr (peticiones ajax ), imágenes, flash.


• Línea de tiempo

• Filtros por tipos de archivos

• Ver qué datos se sirven de cache

• Examen de cabeceras

• Monitorización del XMLHttpRequest

La siguiente captura muestra los elementos pedidos al servidor y el tiempo que estos han tardado en servirse. En caso de no encontrar algún recurso este aparecerá en color rojo.


Desplegando cada uno de los recursos podrá verse el detalle de la petición: cabeceras, respuesta…

6.2.6. DOM

La manipulación de objetos DOM se puede realizar desde esta pestaña de una manera relativamente sencilla.


• Resumen de objetos

• Muestra el árbol DOM de la página

• Edición en tiempo real

• Navegación por el código javaScript

Una captura de ejemplo del árbol DOM mostrado por Firebug :


6.3. Firebug (Lite)

Firebug Lite (http://getfirebug.com/firebuglite) se trata de una versión reducida de la extensión Firebug que permite ser ejecutada desde navegadores diferentes a Firefox, ya que la herramienta se incluye a través del código de la aplicación mediante la invocación a un fichero js alojado en Internet.

Para su uso simplemente debe incluirse el siguiente código en la cabecera de la página:

<script src=" https://getfirebug.com/firebug-lite.j s" type="text/Javascript"></script>

6.4. IE Developer Toolbar

Internet Explorer Developer Toolbar , es una extensión para Internet Explorer 6 e Internet Explorer 7 que tiene como objetivo ayudar en el diseño y la depuración de páginas web.

http://www.microsoft.com/downloads/details.aspx?familyid=e59c3964-672d-4511-bb3e-2d5e1db91038&displaylang=en

Sus funcionalidades más características son:

• Validación de HTML y CSS

• Vista previa de diseño de página en varias resoluciones

• Utilidad (que mide en píxeles) para ayudar en el posicionamiento de los elementos

• Inspeccionar los objetos DOM y los selectores css que se aplican a cada elemento

• Inspeccionar las propiedades y estilos de los distintos elementos

La barra de herramientas incluye un panel de expandible en la parte inferior de la ventana. El panel muestra la estructura de la página web, y a partir de ella, las propiedades y estilos de los distintos objetos. Expone sus características a través de una jerarquía de menús, y también incluye botones de la barra de acceso rápido a funciones tales como borrar la cache del navegador y permitir la selección de elementos haciendo clic en la página final en lugar de navegar a través de la representación visual del árbol DOM.


En la siguiente captura se muestra la apariencia del IE Developer Toolbar :

Internet Explorer 8 incluye las características de Internet Explorer Developer Toolbar integradas, en lugar de un producto distinto, como una herramienta de desarrollo. Se puede acceder desde el menú Herramientas del navegador o pulsando F12. Esta toolbar integrada se asemeja más a Firebug y ofrece más funcionalidades que el IE Developer Toolbar basado en IE6 e IE7.

6.5. jslog

En los desarrollos que basan gran parte de su funcionalidad en código javaScript , es una ayuda indispensable el contar con una herramienta que facilite la depuración de código y el desarrollo del mismo. En el caso de estar desarrollando con un navegador Firefox, se recomienda el uso del objeto console; pero en Internet Explorer, la herramienta IE Developer Toolbar no tiene ningún objeto similar.

jslog es una librería javaScript que facilita la obtención de trazas sin tener que recurrir a los incómodos alert propios de javaScript. Entre los inconvenientes más típicos del método alert, destacan los siguientes:

• Se debe reconocer cada mensaje por algún indicativo.

• Se deben buscar y eliminar todas las invocaciones de la función de cara a la implantación de la aplicación en un entorno productivo.

• Las notificaciones son intrusivas y paran la ejecución del código por lo que no pueden procesarse correctamente peticiones asíncronas y/o concurrentes.

Mediante el uso de jslog , se consigue la posibilidad de usar cuatro niveles diferentes de traza asociados a un determinado color: debug (azul), info (verde), warning (amarillo), error (rojo).

Su integración en la aplicación es trivial ya que basta con copiar el fichero “jslog.js ” dentro de la aplicación y cargarlo en las páginas mediante la sentencia:

< script src =" /xxx/jslog.js " type ="text/Javascript" ></ script >

Para usar las facilidades de traza basta con invocar a la función correspondiente al nivel deseado pasando como parámetro el texto a mostrar:

• jslog.debug()

• jslog.info()

• jslog.warning()


• jslog.error()

Una vez cargada la página que hace uso de la librería, en pantalla se mostrará la siguiente imagen:

El número que aparece indica el número de líneas de traza escritas hasta el momento. Con un doble-click sobre la imagen se mostrará una ventana que contendrá las trazas y volviendo a pulsar en la misma desaparecerá. A continuación se muestra un ejemplo de la ventana de trazas:

El fichero “jslog.js ”, contiene una entrada (primera línea de código) que permite habilitar o deshabilitar el componente. De esta manera se consigue ocultar el uso de jslog sin necesidad de ir página a página buscando y eliminando todas las llamadas al componente.

var config_enabled= true ; � Habilita el componente

var config_enabled= false ; � Deshabilita el componente

La posición de la ventana en pantalla también es configurable. Por defecto aparece en la posición 2,2 (píxeles), pero puede modificarse cambiando las variables del fichero:

var _26=2; � Posición Vertical

var _27=2; � Posición Horizontal

Más información y descarga de la librería en: http://earthcode.com/blog/tools/jslog/contents.html

Descarga de la librería: http://earthcode.com/downloads/jslog.js


NOTA IMPORTANTE: Se recomienda la inclusión de este script dentro del cuerpo de la página debido a que manipula el objeto <body> y, tal como ya se ha dicho, a que es donde debe ir el código javaScript.

6.6. YSlow

YSlow (http://developer.yahoo.com/yslow/) analiza las páginas web y sugiere formas para mejorar su rendimiento basándose en un conjunto de reglas específicas que mejoran el rendimiento de las páginas web. Se trata de un complemento de Firefox integrado bajo la herramienta de desarrollo web Firebug. YSlow califica una página web en función de un conjunto de reglas predefinidas (existen tres ruleset creados por defecto) o de un conjunto de reglas definidas por el usuario (se puede definir un ruleset basándose en alguno de los creados o uno completamente nuevo con las opciones que se deseen).

Entre sus funcionalidades se destacan:

• Ofrece sugerencias para mejorar el rendimiento de la página.

• Un resumen de los componentes de la página.

• Muestra las estadísticas sobre la página.

• Proporciona herramientas para el análisis de rendimiento, como Smush.it y JSLint .

Principalmente, los ámbitos que analizan las reglas que aplica YSlow se centran en los contenidos, las cookies, los css’s, las imágenes, el javaScript y el server.

Analizando las reglas con más detenimiento los aspectos a los que afectan serían los siguientes:

6.6.1. Contenido

6.6.1.1. Minimizar las peticiones http

Reducir el número de peticiones http es una de las prácticas más recomendable y por la que se debe empezar a la hora de optimizar una aplicación web.

El 80% del tiempo de respuesta del usuario final se gasta en el “front-end” y la mayoría de este tiempo es invertido en la descarga de todos los componentes de la página: imágenes, hojas de estilo, scripts, flash, etc. Por tanto la reducción del número de componentes de una página, reduce a su vez el número de peticiones http

A continuación se detallan algunas técnicas para reducir el número de solicitudes http:

• Combinación de archivos: combinar todos los ficheros de scripts (.js) en una única secuencia de comandos (un único fichero). Del mismo modo se pueden combinar todos los estilos en una hoja de estilo css única. Esta solución es difícil de aplicar cuando los scripts y hojas de estilo varían de una página a otra.

• Sprites css: juntar todas las imágenes en una única imagen (sprite) obteniendo la imagen deseada a través de atributos (fondo-posición) aplicados en el fichero css. Es la


mejor solución para reducir las peticiones de imágenes al servidor. Esta práctica se detalla en este documento en el apartado relativo al contenido estático.

• Mapas de imágenes: se trata de unir imágenes que aparecen contiguas en la página (por ejemplo una barra de menú) para que todas puedan ser cargadas mediante una única petición http. La zona activa de cada imagen se define mediante el tag <map> de html lo que puede ser tedioso y provocar diversos errores. Se debe tener en cuenta que el uso de mapas de imágenes para la navegación no es accesible.

• Imágenes en línea: consiste en integrar la imagen en la página mediante el uso de data: URL écheme (http://tools.ietf.org/html/rfc2397), por lo que puede aumentar el tamaño de su documento html. La combinación de imágenes en línea con las hojas de estilo (cacheadas) es una manera de reducir las peticiones http y evitar el aumento del tamaño de las páginas. Esta alternativa aún no está disponible en todos los navegadores.

6.6.1.2. Reducir los DNS Lookup

La mayoría de los navegadores tienen un sistema de cache propio independiente de la cache del sistema operativo. Mientras que el navegador guarda un registro de DNS en su propia cache (tras atender la petición de un recurso), no se molesta al sistema operativo con una solicitud para el registro.

Cuando la cache DNS del cliente está vacía (tanto para el navegador y el sistema operativo), el número de búsquedas de DNS es igual al número de host’s diferentes en la página web. Esto incluye los nombres de host utilizados en la url de la página, imágenes, archivos de script, hojas de estilo, objetos flash, etc. Reducir el número de nombres de host diferentes, reduce el número de búsquedas de DNS y en consecuencia el tiempo de carga de la pagina.

Esta estrategia de diseño, reduce el número de nombres de host pero también reduce la cantidad de descargas paralelas que se realizan en la página. Evitar las búsquedas de DNS reduce los plazos de respuesta, pero la reducción de descargas simultáneas puede aumentar los tiempos de respuesta. Por tanto las buenas prácticas recomiendan dividir estos componentes en: al menos dos, pero no más de cuatro host’s diferentes. Lo que supone un buen compromiso entre la reducción de las búsquedas de DNS y un alto grado de descargas simultáneas.

6.6.1.3. Evitar redireccionamientos

Los redireccionamientos ralentizan la experiencia del usuario por lo que son elementos a evitar aunque en algunos casos puede suponer una reducción considerable en el desarrollo de la aplicación.

Uno de los redireccionamientos que sucede con mas frecuencia, y que más tiempo de carga conlleva, se produce cuando las url’s no están finalizadas por una barra diagonal (/). Por ejemplo una petición http://astrology.yahoo.com/astrology devuelve una respuesta 301 (re-direccionamiento) a la dirección, http://astrology.yahoo.com/astrology/


6.6.1.4. Habilitar el cacheo de Ajax

Uno de los grandes beneficios del uso de ajax es que proporciona una respuesta al usuario de forma asincróna desde el servidor. Sin embargo, el uso de ajax no garantiza la no espera por parte del usuario mientras recibe las respuestas javaScript asíncronas y XML. En muchas aplicaciones esta espera depende de cómo se utiliza la tecnología ajax. Por ejemplo, en un cliente de correo electrónico basado en web, el usuario se mantendrá en estado de espera mientras una petición ajax encuentra todos los mensajes de correo electrónico asociados al usuario. Es importante recordar que "asíncrono" no implica "instantáneo".

Para mejorar el rendimiento es importante optimizar estas respuestas ajax y la mejor manera es hacer que las respuestas puedan ser cacheadas.

6.6.1.5. Postcarga de componentes

En toda página web existen componentes que no necesitan que sean cargados al cargar la página ya que el usuario no interactúa con estos hasta después de realizar ciertas interacciones con la aplicación. Por tanto puede que ese componente no requiera ser cargado en primera instancia.

El código javaScript es un candidato ideal para dividir el proceso de carga en distintas partes. Por ejemplo, si se incluye código javaScript para efectos de arrastrar y soltar así como de animación, éstos pueden ser excluidos de la carga inicial y relegarlos a una carga asociada a su uso. Otros candidatos para la post-carga son los contenidos ocultos o en segundo plano.

6.6.1.6. Precarga de componentes

La pre-carga puede parecer lo contrario de la post-carga, pero en realidad tiene una meta diferente. Mediante la pre-carga componentes se puede aprovechar el tiempo que el navegador está inactivo para solicitar los componentes (imágenes, estilos y scripts) que se necesitarán en el futuro. De esta manera cuando el usuario visita la página siguiente, la mayoría de los componentes ya están en la cache y la página se carga mucho más rápido para el usuario.

Existen varios tipos de precarga:

• Precarga incondicional: tan pronto como se ejecuta el evento onload se obtienen algunos componentes adicionales.

• Precarga condicional: se cargan los elementos basándose en la suposición de lo que va a necesitar el usuario aventurando hacia donde se va a dirigir en la aplicación.

6.6.1.7. Reducir el número de elementos DOM

Un gran número de elementos DOM en una página tiene varias connotaciones negativas: más flujo de datos en descarga, acceso más lento en javaScript y puede ser un síntoma de que hay algo que debe ser mejorado. Ejemplos concretos de esta mala práctica pueden ser el uso de tablas anidadas para maquetación o el uso excesivo de capas para corregir problemas de diseño.


El número de elementos DOM se puede comprobar mediante la consola de Firebug:

document.getElementsByTagName('*').length

Por ejemplo la página “Yahoo! Home Page” es una página con gran funcionalidad que contiene menos de 700 elementos.

6.6.1.8. Repartir componentes en dominios

La división de componentes permite maximizar descargas simultáneas. Un número adecuado de dominios podría ser entre dos y cuatro ya que un excesivo uso podría penalizar la búsqueda de DNS.

Por ejemplo, se puede alojar un contenido html y sus páginas dinámicas en www.example.org y dividir los componentes estáticos entre static1.example.org y static2.example.org.

6.6.1.9. Reducir el número de iframes

Los <iframe> permiten que en un documento html se incluya a su vez en otro documento principal. Es importante entender cómo funcionan los iframes para que sean utilizados con eficacia.

Ventajas:

• Ayuda con la carga lenta de elementos de terceros tales como anuncios.

• Security sandbox

• Descarga de scripts en paralelo

Desventajas:

• Costoso (bajo rendimiento) incluso estando en blanco.

• Bloquea la página en el evento onload

• Non-semantic

6.6.1.10. Evitar los errores 404

Las peticiones http son costosas, por lo que si de una petición http se obtiene una respuesta inútil (es decir, 404 Not Found) ésta se convierte en totalmente innecesaria y además disminuye la experiencia del usuario sin ningún tipo de beneficio.

Especialmente problemático es la petición que descarga un javaScript externo que está mal y cuyo resultado es un 404. En primer lugar, esta descarga bloqueará descargas simultáneas. Y además, el navegador puede tratar de analizar la respuesta del cuerpo 404 como si fuera código javaScript, tratando de encontrar algo útil en él.


6.6.2. Servidor

6.6.2.1. Utilizar una red de distribución de conten ido (CDN)

Una red de distribución de contenidos (CDN) es una colección de servidores web distribuidos en varias ubicaciones para entregar el contenido de la manera más eficiente a los usuarios. El servidor seleccionado para entregar información a un usuario específico, se basa típicamente en una medida de la proximidad de la red. Por ejemplo, el servidor con el menor número de saltos de red o el servidor con el mejor tiempo de respuesta es el elegido.

6.6.2.2. Añadir cabeceras de expiración o de contro l de la cache

Existen dos alternativas en esta regla:

• Componentes estáticos: implementar la política “Nunca expira” mediante el establecimiento de la cabecera de expiración a un futuro lejano.

• Componentes dinámicos: usar la cabecera apropiada Cache-Control para ayudar al navegador con las peticiones condicionales.

6.6.2.3. Compresión de componentes (GZIP)

La compresión de los componentes reduce los tiempos de respuesta al reducir el tamaño de la respuesta http.

A partir de HTTP/1.1, los clientes web soportan la compresión a través de la cabecera Accept-Encoding en la petición http.

Accept-Encoding: gzip, deflate

Si el servidor web ve esta cabecera en la solicitud, puede comprimir la respuesta mediante uno de los métodos enumerados por el cliente. El servidor web se lo notifica al cliente a través de la cabecera Content-Encoding en la respuesta.

Content-Encoding: gzip

Gzip es el método de compresión más popular y más eficaz en este momento. Fue desarrollado por el proyecto GNU y estandarizado por el RFC 1952.

Comprimir tantos tipos de ficheros como sea posible es una manera fácil de reducir el peso de las páginas y de mejorar la experiencia del usuario.

6.6.2.4. Configurar ETags

Las etiquetas entidad (ETag) son un mecanismo que los servidores web y navegadores utilizan para determinar si el componente en la cache del navegador coincide con el que existe en el servidor.

Los ETags se agregaron para proporcionar un mecanismo de validación de las entidades más flexible que la fecha de la última modificación. Un ETag es una cadena que identifica


de forma exclusiva una versión específica de un componente. Las restricciones de formato es que el string debe ir entrecomillado. El servidor especifica el ETag del componente que utiliza mediante la cabecera ETag en la respuesta. Ejemplo de un ETag:

HTTP/1.1 200 OK Last-Modified: Tue, 12 Dec 2006 03:03:59 GMT ETag: "10c24bc-4ab-457e1c1f" Content-Length: 12195

6.6.2.5. Facilitar el renderizado

Cuando los usuarios solicitan una página, el servidor de backend puede tardar de 200 ms a 500 ms para unir la página html. Durante este tiempo, el navegador está parado mientras espera a que los datos lleguen. En lenguajes como php existe la función flush() que permite enviar la respuesta html parcialmente lista al navegador para que este pueda comenzar a procesarla mientras se sigue enviando el resto.

6.6.2.6. Usar método GET para peticiones Ajax

Cuando se utiliza el objeto HttpRequest para el envío de peticiones asíncronas mediante el método post, éste se ejecuta en los navegadores como un proceso de dos pasos: primero, el envío de los encabezados y, después, el envío de los datos. En consecuencia, es preferible usar get, que solo toma un paquete TCP para el envío (a menos que haya muchas cookies). La longitud máxima de url en Internet Explorer es 2K, por lo que si se envían menos de 2K datos se podría usar el método get.

6.6.2.7. Evitar dejar vacío el atributo src de las imágenes

Este error puede darse en dos versiones:

• <img src="">

• var img = new Image(); img.src = "";

Ambas opciones crean una petición extra al servidor ocasionando:

1. Duplicar el tráfico del servidor, sobre todo en aquellas aplicaciones que tienen múltiples usuarios.

2. Malgastar tiempo del servidor generando un recurso que no va a ser visionado.

3. Posibilidad de corromper información del usuario.

Por tanto deberá evitarse dejar vacío el atributo src para no ocasionar problemas.


6.6.3. Cookie

6.6.3.1. Reducir el tamaño de las cookies

Las cookies sirven para llevar el control de usuarios. Cuando un usuario introduce su nombre de usuario y contraseña, se almacena una cookie para que no tenga que estar introduciéndolas para cada página del servidor. Sin embargo, una cookie no identifica a una persona, sino a una combinación de computador-navegador-usuario.

La información de las cookies se intercambia en las cabeceras http entre servidores web y navegadores por lo que es importante mantener el tamaño de las cookies lo más bajo posible para reducir al mínimo el impacto en el tiempo de respuesta del usuario.

6.6.3.2. Usar dominios libres de cookies para compo nentes

Cuando el navegador hace una petición de una imagen estática y envía cookies junto con la solicitud, el servidor no realiza ninguna función con las cookies por lo que únicamente generan tráfico de red sin razón. Deben asegurarse peticiones de componente estáticos sin cookies de por medio. Una alternativa puede ser la creación de un sub-dominio para dichos componentes.

6.6.4. CSS

6.6.4.1. Colocar las hojas de estilo al inicio

La colocación de las hojas de estilo en la cabecera (HEAD) en lugar del cuerpo (BODY) acelera la carga de éstas ya que la renderización de la página se realiza progresivamente.

6.6.4.2. Evitar las expresiones CSS

Las expresiones css son una poderosa (y a la vez peligrosa) manera de establecer las propiedades css de forma dinámica. Contaron con el apoyo de Internet Explorer desde la versión 5, pero fueron desaprobadas a partir del IE8. Un ejemplo de expresiones css:

background-color: expression((new Date()).getHours( )? "#B8D4FF":"#F08A00");

Estas expresiones son evaluadas en múltiples casos. No solo cuando se renderiza la página o cuando se redimensiona, sino también cuando en la página se hace scroll o cuando el usuario mueve el ratón sobre la página.

6.6.4.3. Optar por <link> en lugar de @import

En IE la directiva @import se comporta de la misma manera que <link> pero en la parte inferior de la página, así que es mejor no usarlo. Ya que, como se ha comentado anteriormente, una buena práctica es cargar las hojas de estilo en la parte superior (HEAD).


6.6.4.4. Evitar los filtros

Evitar el uso de AlphaImageLoader completamente y usar el degradado PNG8 en su lugar. En el caso de necesitar usar el AlphaImageLoader obligatoriamente, se recomienda el uso del hack_filter _ para no penalizar a los usuarios de IE7 o superior.

6.6.5. JavaScript

6.6.5.1. Colocar los scripts al final

El problema que originan las secuencias de comandos es que bloquean descargas simultáneas. Por lo que se recomienda su inclusión al final de las páginas.

Otra alternativa podría ser la carga de elementos en modo diferido pero Firefox no es compatible con ello.

6.6.5.2. Externalizar CSS y Javascript

El uso de archivos externos provoca que las páginas se carguen más rápidamente porque el código javaScript y css se almacenan en la cache por el navegador.

Cuando los ficheros javaScript y css se cargan "inline" en los documentos html, éstos se descargan cada vez que el documento html los solicita lo que reduce el número de peticiones htttp necesarias, pero aumenta el tamaño del documento html.

En cambio si el código javaScript y css se externaliza, el tamaño del documento html se reduce sin aumentar el número de peticiones http.

6.6.5.3. Minimizar CSS y Javascript

Minimizando los ficheros css y javaScript se eliminan los caracteres innecesarios de estos ficheros con lo que se reduce el tamaño de los mismos. Entre otros se eliminan los comentarios, los espacios en blanco y los saltos de línea. Adicionalmente se puede optar por la ofuscación de código.

Este documento incluye un apartado en el que se detalla la minimización de los ficheros css y javaScript.

6.6.5.4. Eliminar scripts duplicados

En caso de incluir los mismos scripts en la página, éstos se descargarán dos veces innecesariamente, al menos en Internet Explorer, no así en Firefox. Se recomienda que se intenten controlar las peticiones de los scripts para que éstos sean incluidos una única vez para que la aplicación funcione correctamente en cualquier navegador.


6.6.5.5. Minimizar el acceso DOM

El acceso a DOM mediante javaScript es lento por lo que se recomienda evitar su uso y seguir las siguientes recomendaciones:

• Cachear las referencias a los elementos accedidos.

• Cambiar los nodos en modo “offline” y luego añadirlos al árbol.

• Evitar fijar el layout mediante javaScript.

6.6.5.6. Desarrollar controladores de eventos intel igentes

En ocasiones las páginas resultan menos sensibles debido a que tienen demasiados controladores de eventos asociados a diferentes elementos del árbol DOM, que son ejecutados a menudo. Por ejemplo en el caso de tener una capa con 10 botones, sería recomendable asociar un evento a la capa que un evento por cada botón.

Adicionalmente no se debe esperar al evento onload para empezar a manipular objetos del árbol DOM. Solo se necesita que el elemento a manipular esté disponible en el árbol.

6.6.6. Imágenes

6.6.6.1. Optimizar las imágenes

Existen ciertas maneras de optimizar las imágenes:

• Comprobar que las imágenes con extensión gif utilizan un tamaño de la paleta correspondiente al número de colores en la imagen. Si una imagen usa 4 colores y 256 slots en la paleta, se puede mejorar con imagemagick (http://www.imagemagick.org) y el siguiente comando:

identify -verbose image.gif

• Tratar de convertir las extensiones gif a png y comprobar si se produce un ahorro en cuanto al tamaño. Cualquier imagen representada en gif puede ser representada en png (excepto las animaciones). Para ello existe un comando de imagemagick:

convert image.gif image.png

• Ejecutar pngcrush (http://pmt.sourceforge.net/pngcrush/) o cualquier optimizador de imágenes png:

pngcrush image.png -rem alla -reduce -brute result.png

• Ejecutar jpegtran (http://jpegclub.org/jpegtran/) sobre aquellas imágenes de tipo jpeg. Esta herramienta realiza diferentes operaciones como rotar, optimizar y eliminar comentarios y otros datos inútiles (como la información exif) de las imágenes:

jpegtran -copy none -optimize -perfect src.jpg dest.jpg


6.6.6.2. Optimizar los CSS sprites

Cuando se utilizan sprites de imágenes mediante css para reducir el número de peticiones de recursos se pueden aplicar ciertas recomendaciones para mejorar el rendimiento:

• Organizar las imágenes horizontalmente y no verticalmente reduciendo el tamaño de la imagen.

• Combinar colores y tonalidades diferentes para mantener un número bajo de colores (ideal que sea inferior a 256 para que se ajuste a PNG8).

• No dejar grandes espacios entre las imágenes. Esto no afecta al tamaño de la imagen pero mejora los tiempos de respuesta a la hora de descomprimir la imagen en mapas de bits.

6.6.6.3. No escalar las imágenes en HTML

No utilizar imágenes más grandes de lo necesario porque puedan establecerse la altura y anchura mediante html. Diseñar las imágenes con el tamaño necesario para no tener que escalarlas ya sea para agrandarlas o para reducirlas.

6.6.6.4. Hacer el favicon.ico pequeño y cacheable

El favicon.ico es una imagen que permanece en la raíz de su servidor. A pesar de que no se defina, el navegador realizará la petición de acceso al mismo. Por tanto para mitigar los posibles problemas en el uso del favicon.ico se recomienda:

• Tamaño inferior a 1KB.

• Establecer la cabecera Expires

6.6.6.5. Móviles

Existen algunas recomendaciones en cuanto al desarrollo de aplicaciones web para móviles pero que no se comentan por no ser un ámbito relacionado con el presente documento.

6.7. HttpWatch

HttpWatch (http://www.httpwatch.com/) es un visor de http que se integra tanto con Internet Explorer como con Firefox. Dicho visor permite realizar un seguimiento de las peticiones http y https sin salir de la ventana del propio navegador.

Entre sus funcionalidades más destacadas se encuentran:

• Descifrar el tráfico https

• Agrupación de las solicitudes por página

• Detección de problemas potenciales

• Exportación de datos a csv, xml


A continuación se muestra una captura del programa integrado en Internet Explorer

uda-desarrollo rup. consejos y buenas prácticas

Technology