Tags » ‘Performance’

Un caché es básicamente una entidad que almacena información de manera transparente con el objetivo de reducir los costos de cómputos de operaciones futuras.

En el ámbito web el uso de caché es conocido en cuanto al servicio de contenido, que suele ser cacheado a fines de agilizar futuros requerimientos del mismo.

En general el uso de caché permite agilizar los procesos así como también reducir los costos operativos, lo cual decanta en una mejor experiencia de usuario.

Utilizando un cache básico

Suponiendo que tenemos una implementación bastante básica de caché con la siguiente interfaz:

cache.set(key, value)
cache.get(key)

Podemos modificar nuestro código para reducir las llamadas a operaciones costosas, reduciendo virtualmente en un 100% el trabajo requerido para las solicitudes adicionales. Caso de uso típico:

// Sin cache, se realiza siempre la
// operacion costosa
data = expensiveOperation();

// Con cache
data = cache.get('data');

// La operacion costosa solo se realiza en
// caso de que no exista la informacion en
// cache
if(!data) {
	data = expensiveOperation();
	cache.set('data', data);
}

Un ejemplo más concreto se puede dar con las consultas ajax. Suponiendo que nuestra aplicación realiza numerosos requests, podríamos generar un proxy para nuestros métodos ajax a fines de no realizar requests repetidos (algo bastante común en cualquier aplicación web).

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

Considerando a las paginas y aplicaciones web como servicios para los usuarios, es lógico considerar la calidad del mismo evaluando el contenido y presentación que ofrecen.
En estos aspectos es donde puede verse que el desarrollo e inversión tienen mayor enfásis, sin embargo, un factor no menos importante son el rendimiento y experiencia que ofrecen, tanto por la experiencia del usuario como por la carga que generan las peticiones sobre el servidor.

La experiencia de usuario es el conjunto de factores y elementos relativos a la interacción del usuario, con un entorno o dispositivo concretos, cuyo resultado es la generación de una percepción positiva o negativa de dicho servicio, producto o dispositivo.*

*Wikipedia: Experiencia de usuario.

Los sospechosos

Existen diversos factores que afectan en mayor o menor medida el rendimiento de los sitios, los mismos abarcan el ciclo de vida completo del request así como también el tiempo de ejecución, siendo cada etapa muy específica en cuanto a problematicas.

1. Servicio de contenidos

Cantidad y peso

Bytes, bytes y más bytes.

lanacion.com es cosa seria.

La cantidad y peso de los recursos cargan con gran protagonismo en la optimización de websites. Obviamente, a mayor cantidad de información a descargar, mayor será la demora, lo mismo ocurre con la cantidad de recursos solicitados, donde el cuello de botella se encuentra en la cantidad de descargas en simultaneo que puede realizar el browser.
Además hay que considerar que el browser no realizará el renderizado hasta completar la descarga secuencial de recursos bloqueantes.

Recursos externos

El uso de APIs externas o librerías hosteadas (CDN) puede bloquear las descargas de archivos del sitio con su consecuente “blank page” o sitio a medio renderizar.


API Facebook congelando el sitio

Ouuu no! (I)

Particularmente, esto puede verse bastante seguido con los scripts sociales (Facebook Connect, Addthis, Twitter API) así tambien como con Google Analytics, donde básicamente se confía en la capacidad de respuesta (muchas veces pésima) de un servidor remoto.

2. Renderizado de contenidos y setup de scripts

A la hora de renderizar un sitio suele ser bastante problematico tener un HTML complejo (principalmente en el anidamiento), ya que impacta directamente en la performance inicial del sitio.

Al cargar un sitio, se produce un renderizado completo, lo cual implica generar la estructura en memoria (render) y posteriormente calcular el su layout (flow) y dibujarla en pantalla (draw). Además del mencionado problema de niveles de anidamiento, otros factores que suelen impactar en esta etapa son selectores css poco eficientes, imagenes sin tamaño explícito, falta de especificación de charset, etc.

De igual manera, la inicialización de scripts puede bloquear o alentar la navegación inicial de la web.

3. Ejecucion

JavaScript cuelga el browser

Ouuu no! (II)

Finalmente, una vez alcanzada la etapa de de ejecución, la problematica se vuelca mayormente a los scripts, situación que se hace evidente en algunas aplicaciones web (GMail, Facebook) sobre todo cuando las condiciones de ejecución no son optimas (pc y browsers anticuados).

En esta etapa, es donde hay que tener muy en cuenta que el browser usa un mismo thread para la ejecución de scripts y renderizado, con lo cual las situaciones de mucha carga en scripts se hace excesivamente evidente en la experiencia de usuario.

En este ejemplo puede comprobarse la dificultad de navegación cuando el browser esta ejecutando código.


En la próxima entrada del tema, vamos a investigar sobre las distintas herramientas que permiten identificar y mesurar los problemas relacionados con la performance para posteriormente centrarnos en las soluciones a los problemas más comunes.

Shortlink: http://goo.gl/cXnWu

 

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

DOM Monster, el bookmarklet desarrollado inicialmente por Thomas Fusch (anteriormente mencionado por Zepto) es ahora open source, con licencia MIT y repositorio en GitHub de libre acceso.

DOM Monster es una herramienta que sirve para analizar los distintos aspectos que influyen en la performance de un sitio web, destacandose principalmente el exaustivo analísis que realiza sobre el arbol DOM en memoria (no el markup inicial) lo cual permite mesurar tamaño, profundidad y otros aspectos en distintos momentos del ciclo de vida de la aplicación.

En definitiva, es una interesante herramienta para combinar con PageSpeed e YSlow a fines de afinar los aspectos más críticos en todo el espectro de posibilidades (desde la carga inicial hasta el manejo de nodos).

En el sitio se ofrece mayor información (en inglés) y un video (por supuesto también en inglés).

  • 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