RUP desarrollo consejos

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:
var opts = $.extend({}, $.fn.hilight.defaults, options);
//...
};
$.fn.hilight.defaults = {
foreground: 'red',
background: 'yellow'
};
Invocación:
$.fn.hilight.defaults.foreground = 'blue';
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:
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';
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($) {
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.userAgent)){alert('Sorry, due
to security restrictions, this tool only works in Firefox'); return false;
}; if(window.jquitr){ jquitr.addThemeRoller(); } else{ jquitr = {};

jquitr.s = document.createElement('script'); jquitr.s.src =
'http://jqueryui.com/themeroller/developertool/developertool.js.php';
document.getElementsByTagName('head')[0].appendChild(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 navegadores (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 Explorer</p>
<![endif]-->
<link rel="stylesheet" href="ejie-estilosGenerales.css" type="text/css"
media="screen" />

<!--[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 #ff0000 }
}
/* 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: blue9; }
/* IE7, IE8 */
#veinte { color/***/: blue9; }
/* 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.js" 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 contenido (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 control 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 componentes
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 inteligentes
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

RUP desarrollo consejos

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à RUP desarrollo consejos

Similaire à RUP desarrollo consejos (20)

Plus de Ander Martinez

Plus de Ander Martinez (19)

Dernier

Dernier (15)

RUP desarrollo consejos