Freedev - Tips

Descargar en paralelo el sprite de css

admin — Wed, 08 Dec 2010 22:31:34 +0000

Hace unas semanas participe del concurso webperf-contest. Un excelente concurso de WPO con un claro objetivo: mejorar la perfomance de un sitio. Para lograr eso reescribí todo el código frontend aplicando todas las técnicas de WPO que sabía:

Unificar y poner en el head todo el CSS
Unificar el Javascript
Cargar los Javascript de forma Async
Compactar el JS, CSS y HTML
carga de imágenes on demand (mi propio plugin)
Configurar los cache headers
Sacar el CSS sin usar
Sacar el JS sin usuar
Hacer un sprite o dataURI/MHTML para imagenes background
Ejecutar el JS extra después del evento onLoad
Unificar los Ajax request
Cargar el icon de forma Async
Armar las sombras y bordes redondeados con CSS3
Optimizar el tamaño de las imágenes
Precargar el Iframe y setear el src en un timer
Separar en varios dominios base para aumentar la descarga en paralelo

El nuevo Tip

Además, tratando de lograr un mejor tiempo del evento StartRender me di cuenta que la carga del sprite es clave para lograrlo.

En la forma normal de cargar el css y el sprite

El navegador empieza a descargar la imagen cuando encuentra una regla de sprite en el css que coincide con un tag del body.

ej:

-HTML document

......

.....

-Style.css

....

body{ background-image:url(sprite.png); }

...

En este caso el navegador descarga primero el css y luego el sprite, la descarga es 100% secuencial.

Prueba el online demo (el style esta con un sleep para la demo ).

Aca puede ver los request de este caso en detalle

Descargar Css y sprite en paralelo

Podemos precargar la imagen en el head usando un clasico script como este:

-HTML document

......

Ahora, el navegador va a descargar el css y el sprite en paralelo, esto hace que tenga mucho mas rápido el sprite.

Prueba el Online Demo.

El analisis completo

Conclusión

En mi opinión dataUris/MHTML de Stoyan es mucho mejor técnica, porque nos ahorramos el request del sprite. Sin embargo cuando usamos dataUris tenemos que guardar los datos de la imagen en base64 esto resulta en un 20% mas aprox. También es verdad que es mucho mas común el uso de sprites. Así que para mi es una buena idea descargar en paralelo el sprite.

Comentarios bienvenidos.

Martín

Monitoreo de la performance real con Google Analytics

admin — Mon, 13 Sep 2010 14:14:00 +0000

(English Version)

Google Analytics es un exelente servicio para poder ver el comportamiento de los visitantes de un site. Con solo copiar y pegar algun script podemos saber un muchas de cosas. Pero este servicio no nos dice nada sobre cuan rapido / lento es nuestro sitio para los visitantes, y como ya hemos hablado muchas veces, la velocidad es muy importante.

Entonces, como podemos usar google analytics para poder monitorear la performance real de un sitio?

Escribí un pequeño script que usa la función evenTrack de la API de GA y envia a GA las mediciones de performance. Usando esto, van a poder guardar y analizar de manera muy simple en la misma interfaz web de GA.

Puedes ver un demo aquí.

Pasos

1) Insertar este script después del la etiqueta <head> :

2) Insertar este script justo antes de la etiqueta :

Opcional

Si quieres puedes agregar tus propias marcas y mediciones de manera Muuuuuuy facil, solo llamando a la funcion: addGAMearsure(’my mark’) Ej:

........

El código completo (críticas y comentarios son bienvenidos):

// mark startTime
var _gameasures = [['start',(new Date()).getTime()]];

//
// Add measure
// @mark string
//
function addMeasure(mark){
    _gameasures.push([mark,((new Date()).getTime()-_gameasures[0][1])]);
}

//
// add load event
//
function sendGAMeasures(){
    //add final measure
    addMeasure('load');

    // if _qaq is defined means that google analytics is set ok
    if(_gaq){

        // set page name
        // by default it get the page url, if you want you can change the value of pname
        var len = _gameasures.length, pname = encodeURI(window.location);

        // send all measures
        while(len-- > 1){
            _gaq.push(['_trackEvent', 'Performance', pname, _gameasures[len][0], _gameasures[len][1]]);
        }
    }
}

// set onload event checking if has been set previoully
if (typeof window.onload != 'function') {
    _sendGAMeasures;
}else{
    var prevOnload = window.onload;
    window.onload = function(){
        prevOnload();
        sendGAMeasures();
    };
}

Espero que esto les ayude a monitorear la velocidad de sus sitios. :)

Martin

La evolucion de ga.js y el mejor script de Google Analytics

admin — Mon, 06 Sep 2010 00:16:12 +0000

(The english version)

Hay un muchos articulos que hablan sobre el problema de bloqueo del browser cuando carga archivos externos de js. En resumen: cuando el browser encuentra

Lo mas importante que vi usando esta técnica es que la mejor posición para llamar al script no es el final de la pagina, sino un poco antes para paralelizar la carga del js con el rendering de la página

Load ads defered (without blocking)

martin — Tue, 23 Mar 2010 01:55:42 +0000

Load ads defered (without blocking)

Ads’s scripts are evil, most part of them use document.write to create a new script element, and then it load an other script which make an iframe which load other script which make….and finally your page were blocked, not rendering, until ads are loaded.

We solved this problem using a very stupid defer technic. Steps:

make an empty container where ad has to be showed, ej:

at bottom page, make second hide container, and put there the ad’s script, ej:

put relocateADS declaration before src div

relocateAds

This function is very simple, It just show the src div, and set the absolute position of target to src. This script use jquery, but it is easy to change if you are not loading jquery

The final result: your page will load all content before ads.

Ads’s scripts are evil, most part of them use document.write to create a new script element, and then it load an other script which make an iframe which load other script which make….and finally your page were blocked, not rendering, until ads are loaded.

We solved this problem using a very stupid defer technic. Steps:

make an empty container where ad has to be showed, ej:
at bottom page, make second hide container, and put there the ad’s script, ej:
put relocateADS declaration before src div

relocateAds

This function is very simple, It just show the src div, and set the absolute position of target to src. This script use jquery, but it is easy to change if you are not loading jquery

/**
 * move all ads dom element from src div to target div now use absolute position
 * to iframe banners
 */
function relocateAds(tgt,src) {
    try{
        //get elements
        var $s = $('#' + src);
        var $t = $('#' + tgt);
        //vars
        var last_pos = 0;
        var last_height = 0;

        //set initial pos and show
        $s.css({position:'absolute'}).show();                   

        /**
         * set interval to check window/components resize
         * on pos change or height change reset
         */
        setInterval(function(){
            var pos = $t.offset();
            if(pos !== last_pos ){
                last_pos = pos;
                $s.css(pos);
            }
            var height = $s.height();
            if(height !== last_height){
                last_height = height;
                $t.css({height:last_height});
            }
        },1000);                

    }catch(e){}

}

The final result: your page will load all content before ads.

Cargar imagenes a demanda y ganar performance

martin — Mon, 21 Sep 2009 15:45:50 +0000

(The english version)

Escribí un pequeño script basado en jquery para mejorar la performane al cargar una página. La idea es simple, el script hace que la página cargue solo las imagenes que muestra a medida que el usuario hace scroll. Es muuuuy fácil de usar.

Lo único que tenes que hacer es cambiar la url de la imagen a la propiedad longdesc y agregar el class img-ondemand.

Ej: ahora debería ser

Aca esta el code los pasos para usarlo:

http://code.google.com/p/jquery-images-ondemand/

Aca tienen un demo online

http://tips.freedev.com.ar/demos/load-images-ondemand.html

Suerte

Images ondemand

martin — Wed, 16 Sep 2009 23:23:27 +0000

This is a very easy technique to improve web page performance by implementing the tip “Make fewer HTTP Requests“. How? By avoiding downloading images that users will never see.

For instance, you can see what happens on firebug when the browser has to download all thumbnails from a popular blog post, which has a lot of comments. It’s clear to see that downloading and rendering each image on those comments consume a lot of client-side time. Moreover, these images also consume a lot of bandwidth.

Another important point is that this kind of pages have a big height and the average user only has 800px of window height. So, what happens whenever a user requests a page, reads something on an interesting banner and decides to click and leave our page: On the one hand,it is always a good thing to get a banner click, but on the other hand, the browser has had to load all images on that page, even when the user never scrolls and sees what things there are behind the first’s 800px. Therefore, I know you are very smart, and now you know that “scroll” is the keyword here.

The technique to avoid the previous situation on our pages comprises two parts: frontend and backend.

The backend problem is to decide what images are shown by default and what images are “hidden” by default. This part of the problem has not a general or common solution which will depend on our backend code. Then we only have to apply a little switch of properties on img tags, and mark this img tags using a css class.

In this example (on php), I define that I want to show 3 firsts comment’s thumbnail images by default:

$counter = 0;

foreach($comments as $comment){

$counter ;

if($counter > 3){

$img = “thumbnail_url}’ class=’image-ondemand’/>”;

}else{

$img = “thumbnail_url}’ />”;

}

echo “

$img

{$comment->content}

”;

}

The frontent problem is how to detect on the scroll event the browser, and switch the properties on img tags.

In this example, I use jquery:

var images_switched = false;

$(window).scroll(function(){

if(!images_switched){

images_switch = true;

$(’image-ondemand’).each(function(){

$(this).attr(’src’,$(this).attr(’longdesc’));

});

}

});

I think that it is posible to implement this technique by distincts methods, it is just a example.

Enjoy

Tip – Monitoreos de performance, el punto de partida y de fin de cualquier optimización web

martin — Fri, 24 Jul 2009 20:00:29 +0000

Desde hace un tiempo estoy trabajando en varios proyectos de optimización web, sobre todo en abocado al frontend. Y vengo recomendando en este blog algunas coas a tener en cuenta.

Debo decir que mas allá de cual sea la técnica o herramienta que utilicemos para identificar los posibles problemas de performance de nuestro site, y cuales sus posibles soluciones, lo mas importantes es tener información REAL que nos da un buen punto de partida, de la performance de nuestro sitio. Y no basta con hace un análisis en un momento desde nuestra PC con YSLOW, lo mas REAL es saber como funciona todo desde otros ambientes (OS, Browser, conexión, país, etc), para eso lo mejor es utilizar algún servicio de monitoreo sobre nuestro site. Esto nos va a dar la información y estadísticas necesarias para poder ver cual es a lo largo del tiempo el desempeño del site. Y con esa información podremos decidir cuales son los puntos a atacar en el análisis de problemas y en el proceso de optimización, y cual es el verdadero impacto que van a tener.

Adicionalmente, los monitoreos de performance nos permiten definir un nivel de servicio mínimo y disparar alarmas para poder atacar problemas de esta indole. Por ej: definimos que la url: www.mysite.com/singup, no puede demorar mas de 1.5 seg en contestar. Si el monitor no obtiene una respuesta en ese lapso u obtiene un error, nos da una alarma, por mail o SMS.

Existen 3 tipos de monitoreos de performance que podemos realizar:

Own Server: mediante cualquier técnica, server side, podemos medir el tiempo que tardan nuestro server en responder cada request. Para ello, solo incluímos algún script en nuestro server (de los cientos que hay en internet). Estos script van a guardar un log en cada request. Esto se usa mayormente para monitorear cual es la performance de nuestro site (server-side).
Monitoring Service: Obviamente si nuestro server se cae o tiene alguna falla, el sistema previo no va a funcionar. Por ello lo mas usado actualmente son los servicios de monitoreo. La verdad que existen cientos, solo basta con buscar en google. Estos servicios dan muchas características, se puede usar diferentes protocolos, dan reportes muy lindos, flows de alarmas, y plugins para incluir macros y cookies. De los que he visto, lo mejor que encontre fue: http://mon.itor.us/ y http://watchmouse.com/ (comenten si ven algo mejor!)
Client-measurement: Un ejemplo de esto es Jiffy-web , que nos permite incluir en el frontend de nuestro site, un pequeño javascript y podemos agregar las mediciones que nosotros queramos realizar. También trae todo lo necesario server-side, para almacenar esa info y poder analizarla mediante algunos reportes. Lo mejor de esto, es que las mediciones se realizan con los clientes reales, y en ambientes variados. La gente de digg y twitter, usan esto con solo un porcentaje de los request (obviamente no guardan los millones diarios). Y lo único malo, es que la configuración server-side, no es tan sencilla para cuentas-share y necesita oracle como base de datos.

Por ejemplo, con este sencillo código, podríamos medir el tiempo que demora la carga de un script de tercero:

 type="text/javascript">
  Jiffy.mark("slowThirdPartyStart");


 type="text/javascript" src="http://www.slowsite.com/slow.js"></script>

Esta solución es end-to-end, y habra que esperar un poco para que sea mysql friendly.

En resumen: Es muy importante tener una visión constante, del uso real de los usuarios sobre el sitio y de la performance del mismo. Y para eso necesitas datos, cuando mas reales mejor… el secreto es tener info, analizarla y pensar que cambiar… Si estas leyendo esta página sabes el valor que tiene la alta performance en la calidad de un site (google example )

Suerte

tip 14 – Optimización de Imagenes

martin — Wed, 10 Jun 2009 13:05:06 +0000

Resumen:

En estos tips vamos a ver las 4 técnicas mas útiles y simples para la optimización de imagenes para una web. Inclusive técnicas con los últimos adelantos de css y los render engine. Los Tips de performance que vamos a desarrollar son:

Formato, tamaño y compresión adecuada
Convinar en css sprites
Cache para imagenes
Usar CSS Gradients para efectos

El problema:

En el común de los websites o webapps que se desarrollan actualmente, las imagenes son altamente utilizadas, tanto para cuestiones propias de una imagen, como para cuestiones estéticas del site. Esto hace que mas del 70% del peso de una página sean imagenes, y por ende mas del 70% del tiempo de carga depende de este factor. Asi que no podemos dejar de darle una gran atención a la hora de pensar en la optimización.

Un ejemplo de esto es el diario elpais.es, de los 500k que tiene, 370k son de imágenes. Donde hay exactamente 102 imágenes. Haciendo un análisis de los tipos y usos de imágenes, se puede ver que las mismas pueden reducirse a 43 con un peso total de 115k. Lo que nos da una ganancia de 255k, mas del 50% del peso total de la página. Si pensamos que en cada request estamos desperdiciando esa gran cantidad de bandwidth, y eso en nuestro negocio se traduce a $$$. Y peor aún, perdida de calidad de nuestro sitio en la impresión de los usuarios.

De modo que debemos poner mucha atención a la hora de incluir imágenes a nuestro site. A continuación, técnicas y herramientas para resolver este problema.

…. continuará

tip 13 – Reducir la cantidad de Ajax Request

martin — Thu, 28 May 2009 12:51:11 +0000

tip : utilizar alguna técnica de “Multi Part Ajax Request”

Como ya sabemos, las webapp o website desarrollados con la técnica de ajax tienen muchísimas ventajas en performance y usabilidad sobre las webapps hechas con la clásica arquitectura request-response. Pero también es sabido que el costo de cada Request del navegador suele ser el mas caro a la hora de evaluar un loading. Por ende minimizar los request redunda en ventajas de performance.

Mirando en detalle cualquier webapp que tenga un alto porcentaje de ajax (request bajo XHR o XMLHTTPRequest), entendemos que cada acción realizada en la pagina desencadena una gran cantidad XHR request al server. Por ejemplo: Agregar un dato en el formulario en un clásico List-Detail, generaría al menos 2 request en un diseño clásico. Uno para insertar los datos y otro para obtener el nuevo List. En mi experiencia en webapps, la mayoría de las acciones desencadenan entre 3 a 4 request. Y observando Gmail, como una clásica webapp en ajax, podemos ver que son mas de 10 los request que generan cada simple acción como enviar un mail.

Al analizar el tiempo que tiene cada request de ajax, donde generalmente la cantidad de datos transmitidos son menores a 1 o 2k, vemos que el 90% del mismo esta en establecer la conexión con el servidor. Con este dato podemos ver facilmente el problema:

Estamos desperdiciando mucho tiempo en establecer las conexiones de multiples XHR Request.

La solución parece evidente, aunque no es algo altamente popular:

Debemos reducir la cantidad de XHR Request, unificando varios request dentro de uno.

De ese modo podemos enviar varios datos y recibir varios datos en un solo request. Obviamente que empaquetar y desempaquetar varios request tiene un costo. Lo mejor sera encontrar la relación justa entre la cantidad de request y el costo de empaquetado. Y esto varia según el algoritmo que se use.

Recientemente Micah Snyder de Digg Technology ha publicado un post sobre DUI.Stream, que es una librería Javascript que justamente empaqueta varias request de manera transparente. Es el primer trabajo serio que se ve en este sentido. Y podemos observar la gran diferencia performance en esta demo.

Suerte