Tags » ‘CSS’

En la entrada anterior hicimos un repaso general de las problematicas que suelen afectar el rendimiento y experiencia de usuario en aplicaciones web.

Algunas de estas problematicas son facilmente detectables, mientras que otras requieren un poco de trabajo y un correcto uso de las herramientas disponibles.

En conjunto, estas herramientas abarcan todo el ciclo de vida de la aplicación además de presentarse en diversas formas (plugins, aplicaciones web, bookmarklets, etc).

Pagespeed

Page SpeedEsta herramienta desarrollada por Google, comenzo como plugin de Firefox (y del Firebug) para luego extenderse a sitios y a las herramientas de desarrollador que ofrece esta misma compañia.
Básicamente ofrece una reseña sobre los aspectos que afectan el rendimiento del sitio con tips y soluciones para los mismos.
Es importante destacar que la reseña en cuestión es de muy alta calidad y precisión con respecto a la información que ofrece, indicando detalles como selectores ineficientes o archivos sin el caché recomendado.
De las soluciones provistas, es sin duda la que más me sorprendió la generación de imágenes optimizadas

Page Speed

Yslow

Herramienta de Yahoo, bastante similar a PageSpeed y mantenida (entre otros) por Stoyan Stefanov, cuyo blog es prácticamente una lectura obligada para aquellos desarrolladores que primen la performance.
Al igual que PageSpeed, Yslow presenta las distintas metricas relacionadas a la performance en conjunto de un puntaje y tips para mejorarlos. Incluye tambien unos bonitos gráficos estadisticos y la posibilidad de modificar el ruleset que compondrá el test.

Yslow

Yslow: Graficas

En el blog de Stoyan, vamos a encontrar bastante información sobre el uso y el hacking de esta herramienta.

yottaa.com

Este sitio web brinda distintas metricas de rendimiento (al igual que PageSpeed e Yslow) permitiendo además realizar un seguimiento en el tiempo de las mismas.

Yotta.com

Si bien actualmente se encuentra en etapa beta, no deja de ser una gran herramienta para llevar apunte del progreso de las metricas relacionadas.

Firebug

Dentro del ya super conocido Firebug, tenemos la posibilidad de analizar el desarrollo de la página/aplicación desde las peticiones realizadas hasta la ejecución de scripts.
Dentro del tab ‘Red’ (o ‘Net’ en caso de que usemos el Firebug en inglés) se pueden observar las peticiones realizadas, sus headers e inclusive el detalle del tiempo que consumieron en sus distintas etapas (resolver el dns, conectar, esperar, recibir, etc).

Firebug

Twitter, Twitter, Twitter...

En cuanto a los scripts, Firebug nos ayuda con un Profiler, que permite visualizar las llamadas javascript que se realizan con metricas específicas como ser la duración de las mismas.

Profiler

Firebug Profiler

DOM Monster

Bookmarklet inicialmente desarrollado por Thomas Fuschs, del cual se habló anteriormente en este blog. Al igual que otras herramientas, presenta metricas y tips sobre la performance, en este caso, focalizado principalmente sobre el DOM.
En su repositorio en GitHub está disponible su versión actualizada.

Experiencia de Usuario

Por último (pero no por ello menos importante), es de suma utilidad comprobar la usabilidad del sitio/aplicación en entornos no óptimos. Generalmente, los tests de usabilidad que se realizan, no contemplan el hecho de que no todos los usuarios disponen de computadoras (o dispositivos) actuales, así como tambien ignoran la calidad de servicio de red que puedan tener. Por ello es importante comprobar como puede comportarse la aplicación frente a factores variables (que exceden al browser) como ser: resolución, ancho de banda, velocidad de procesamiento, etc.


Shortlink: http://goo.gl/nAoju

Reciementeme me tope con un artículo que resume el funcionamiento de los selectores css a la hora de renderizar el html. Al procesar el CSS, los browsers leen las reglas secuencialmente, desde arriba hacia a abajo (predecible) y de derecha a izquierda (sorpresa aquí).

Entonces, las reglas excesivamente verbose terminan perjudicando la performance del renderizado, como puede verse en el ejemplo dado en el artículo de css-101 en el que se ve claramente las verificaciones innecesarias que debe realizar el browser con su consecuente impacto en la performance.

/* Recordemos que los ids son unicos*/

/* Mal */
#nav li ul li a#active {
}

/* Bien */

#active {
}

A la hora de aplicar la primer regla, el browser se ve obligado a verificar la validez de la regla secuencialmente, empezando desde la derecha:

  • #nav li ul li a#active | OK
  • #nav li ul li a#active | OK
  • #nav li ul li a#active | OK
  • #nav li ul li a#active | OK
  • #nav li ul li a#active | OK
  • #nav li ul li a#active | OK

Por supuesto existen situaciones donde el uso de selectores complejos es una necesidad, pero para el resto de las situaciones aplicarse al principio KISS es una excelente idea.

Leer más

A propósito de lo tratado en el post anterior (CSS específico, lidiando con los browsers), adjunto una utilidad JavaScript para agregarle las clases correspondientes al browser del cliente.

El código original esta tomado de la librería ExtJS de Sencha, más específicamente del archivo ext-all-debug.js.

/*!
 * Ext JS Library 3.3.1
 * Copyright(c) 2006-2010 Sencha Inc.
 * licensing@sencha.com
 * http://www.sencha.com/license
 *
 * Modified by Valentin Starck
 * valentin.starck@gmail.com
 * http://blog.aijoona.com
 */
(function() {
	var
		t = {},
		ua = navigator.userAgent.toLowerCase(),
		DOC = document,
		docMode = DOC.documentMode,
		cls = "";

	function check(r) {
		return r.test(ua);
	}

	t.strict = DOC.compatMode == "CSS1Compat";
	t.opera = check(/opera/);
	t.chrome = check(/\bchrome\b/);
	t.webkit = check(/webkit/);
	t.safari = !t.chrome && check(/safari/);
	t.safari2 = t.safari && check(/applewebkit\/4/); // unique to safari 2
	t.safari3 = t.safari && check(/version\/3/);
	t.safari4 = t.safari && check(/version\/4/);
	t.ie = !t.opera && check(/msie/);
	t.ie7 = t.ie && (check(/msie 7/) || docMode == 7);
	t.ie8 = t.ie && (check(/msie 8/) && docMode != 7);
	t.ie6 = t.ie && !t.ie7 && !t.ie8;
	t.gecko = !t.webkit && check(/gecko/);
	t.gecko2 = t.gecko && check(/rv:1\.8/);
	t.gecko3 = t.gecko && check(/rv:1\.9/);
	t.borderbox = t.ie && !t.strict;
	t.windows = check(/windows|win32/);
	t.mac = check(/macintosh|mac os x/);
	t.air = check(/adobeair/);
	t.linux = check(/linux/);

	for(var p in t) {
		if(t.hasOwnProperty(p) && t[p]) {
			cls +=" "+p;
		}
	}

	try {
		document.getElementsByTagName("body")[0].className += cls;
	} catch(e) {}

	return t;
})();

Ya con solo incluirlo, el script adjunta al body la definición del browser como clases:

Browser sniffingActualización

Del blog de aNieto2K, rescato el link a una librería que hace lo propuesto en esta entrada de manera más completa: CssUserAgent.

El problema

Desde tiempos ancestrales los browsers hicieron del maquetado web una tortura de proporciones biblicas. Desde entonces, el arsenal de los maquetadores se fue acrecentando con buenas prácticas y muchos, muchos hacks.

¿A qué me refieron con hacks? Al uso de sintaxis alterada y características non-standard. Obviamente, hay casos en los que no existe salida por derecha y el uso de hacks es prácticamente una obligación. Por otra parte, la aplicación condicional de reglas mediante el uso de sintaxis alterada es algo que se puede (y debería) evitar.

p {
  /* Applies to all major browsers */
  background: red;
}

body[class|="page-body"] p {
  /* Applies to IE 7 and most modern browsers except Opera */
  background: green;
}

En el ejemplo (tomado de Css Hack), evidencia esta postura. Dentro del mismo sitio, se listan numerosas alternativas para diversas situaciones, siendo las más importantes la aplicación de reglas según el tipo de browser. Para horror de cualquier persona no demasiado interiorizada en el tema, se puede encontrar con algo parecido a lo siguiente.

/* Win IE7 */
*:first-child+html selector{property:value;} 

/* Win IE6 & Mac IE */
* html selector{property:value;}

/* Win IE6 */
/*\*/
* html selector{property:value;}
/**/

/* MacIE */
/*\*//*/
selector{property:value;}
/**/

Css validoComo se ve, además de invalidar el CSS (que no es un gran problema tampoco), vuelve las hojas de estilo algo complejo de leer (algo que se agrava con la falta de comentarios). No hay que olvidar, que si bien hoy las reglas pueden ser interpretadas por n browser, el día de mañana la situación puede ser distinta, con lo cual el hack pasa de utilidad a problema.

Dentro de lo que es Internet Explorer, existe otra herramienta (si es que se la puede llamar así) que permite cargar reglas u hojas de estilo de acuerdo a la versión del navegador (siempre dentro de la familia IE).

<!--[if lte IE 6]>
<link rel="stylesheet" type="text/css" href="ie_hacks.css" />
<![endif]-->

Para mayor información sobre esta “”"característica”"”: About Conditional Comments, Things You Might Not Know About Conditional Comments.

Si bien inicialmente los comentarios condicionales pueden parecer grandes aliados, si indagamos más en la web, podemos encontrarnos con grandes sorpresas, como ser que los comentarios condicionales bloquean las descargas (o en otras palabras, evitan la paralelización de descargas de hojas de estilo). En esta entrada Stoyan Stefanov, concluye el artículo con contundente consejo*:

if you worry about performance, don’t use conditional comments

*A modo de disclaimer, posteriormente actualiza con una forma de evitar el bloqueo. Pero aún así quedan claro los peligros de utilizar este tipo de hacks.

La solución menos mala

Más allá de las soluciones posible, queda en claro que el problema existe y seguirá existiendo en la medida que se maquete soportando browsers antiguos. ¿Cuál es la manera menos invasiva/macabra de solucionarlo?
Personalmente me inclino por realizar browser sniffing, ya sea desde el servidor o el cliente. Si bien no soy muy partidario del browser sniffing, es sin dudas una solución menos mala que el uso indiscriminado de hacks.

Si se opta por el servidor, la solución implica agregar a la página la hoja de estilo general y su correspondiente hoja de estilo puntual si es que existiera. O, puede generarse la hoja de estilo general de manera dinámica de acuerdo al browser solicitante.

Si es en cliente, basta con agregarle al body un class correspondiente al browser. Esta metodología es utilizada por ExtJS para renderizar de igual manera los widgets en cualquier browser.

Browser sniffing

Con lo cual podemos diferenciar las reglas sin hacer uso de hacks.

body.ext-ie #form {
  padding-left: 4px;
}
body.ext-webkit #form  {
  padding-top: 4px;
}

Conclusiones

Si bien tengo mis motivos para no utilizar hacks a la hora de maquetar, esto no siempre es posible, más que nada en el caso de los hacks no expuestos en este post. Para los casos puntuales de reglas específicas la técnica de browser sniffing termina siendo la menos invasiva y más recomendada.

  • Buscar

  • Ultimos Twits

  • Por fecha

    • 2012 (11)
    • 2011 (63)
    • 2010 (13)
  • Tags

  • Documentacion Javascript

    JavaScript Reference, JavaScript Guide, JavaScript API, JS API, JS Guide, JS Reference, Learn JS, JS Documentation