Muchos de los tips de optimización para JavaScript involucran cosas que se ven más típicamente en otros sitios, como por ejemplo minimizar la cantidad de modificaciones al DOM. Pero en este caso es un poco diferente, ya que era el script por sí mismo era quien debía correr más rápido – No trabaja con el DOM ni nada, solo procesa muchos datos.

Encontrando la raíz del problema

Antes de iniciar cualquier optimización, el código debe ser perfilado para saber qué parte es la que está corriendo despacio. La mejor herramienta para lograr esto, es definitivamente el Profiler de Firebug. Sin este probablemente hubiese tenido muchas más dificultades para encontrar problemas y probar cómo las cosas que cambiaba afectaban la velocidad.

El Profiler lo encontrás en la consola del Firebug. Solo dale clic en el botón ‘profiler’ una vez para iniciar el perfilamiento (si es que existe la palabra) y clicás de nuevo para detenerlo. Después de detenerlo vas a recibir una lista informativa de las funciones que han sido llamadas y cuanto tiempo tomó cada una en ejecutarse.

Problema 1: Iteraciones, cantidad de datos

El primer problema que me abofeteó fué la enorme cantidad de datos que se debían de guardar. Un mapa de 128×128 requiere 16,384 iteraciones para ser completamente procesado. A primer vista no parece tanto, pero solamente iterar la data, sin hacer nada más, causaba un golpe mucho mayor del que pasaría en muchos otros lenguajes. Por extraño que pueda parecer, podés usar un do-while invertido para acelerar las iteraciones, o sea en lugar de usar un ciclo con for y contar sumando, usás un ciclo con do-while y contás restando.

			var i = data.length;
			do {
			 /* algo que hacer */
			} while(--i);

Por qué es más rápido? Aparentemente el simple hecho de remover la condicion usada para comprobar cuando el loop termine hace gran parte de la diferencia. Hacer -i en vez de i- también ayuda un poco.

El problema con este enfoque es que no siempre es aplicable.

Problema 2: Llamar funciones

Fué curioso encontrar que el simple hecho de llamar una función agrega un overhead significativo. Así que llamar una función dentro de uno de esos ciclos grandes en los for puede agregar mucho tiempo de procesamiento.

Como resolverlo? Colocando el código de la función dentro del loop.

Sí, raro. Pero si mueves el código de la función y lo colocas dentro del loop en lugar de llamar la función vas a tener una mejora significativa. Tiene como gran desventaja que reduce la legibilidad del código, además de que le abre las puertas a la duplicación de código si la función se usa en más de un lugar.

Por raro que sea, esto fué uno de los propulsores más grandes de performance, que en este caso particular, era más importante que un código legible.

Problema 3: Limitaciones de la memoria

Dado al bajo monto de memoria disponible en el dispositivo al que va dirigido el juego. La aplicación se quedó sin memoria en varias ocasiones.

Primero, el tamaño del mapa era de 300×300, lo que hacía que el teléfono se quedara sin memoria casi de inmediato. Para esto no hubo más remedio que reducir el tamaño a un 128×128. Usar 300×300 pudo también tener otras repercusiones con el performance, porque la cantidad de data hubiese sido mucho mayor para dibujarlo.

Segundo, cuando implementé la funcionalidad para cargar y salvar el juego, el app de nuevo se quedaba sin memoria. Esto probablemente causado porque el data del mapa era serializado a JSON.

La idea que resolvió esto: Cortar el data en pedazitos pequeños.

Entonces, en lugar de guardar todo el array del mapa de 128×128 de una sola vez, el código lo hace en 8 partes. De este modo el tamaño del JSON serializado se mantiene pequeño y la aplicación no se queda sin memoria.

Lo mismo se hace cuando carga, Como el JSON es guardado en 8 bloques separados, al cargar se meten dentro del array uno por uno.

Más optimizaciones: Dividir y Flood numbers

Como parte de la lógica del juego también eran necesario dividir algunos numeros y asegurarme de que los valores eran números enteros.

Típicamente esto requeriría dividir primero y luego aplicar Math.floor. Como mencioné hace un rato. Llamar funciones puede salir caro.

Hay un truco ‘limpio’ para esto. Y limpio entre comillas porque para algunas personas puede ser confuso si no están familiarizadas con la sintáxis, y esto, pues hace el código un poco dificil de leer.

El truco consiste en usar un bit-shift (no conozco el término en español…):

				var foo = 10;
				//la mayoría de veces, esto es lo mismo que hacer Math.floor(foo / 4)
				var result = foo >> 2;

Hacer >> 2 es, como menciona el comentario, practicamente lo mismo que dividir por 4 y despues llamar un Math.floor. Pero en lugar de dos operaciones, tenés solamente una, por lo tanto puede ser un poco más rápido.

Si no entendés de matemática binaria los bitshifts pueden ser un poco enredados. En palabras simples, si hacés >> con 1, es lo mismo que dividir por 2, 2 es dividir entre 4, 3 es dividir entre 8, y 4 es dividir entre 16 y ahí sigue la idea…

Como es costumbre, hay un buen articulo en Wikipedia sobre esto, el cual es un buen recurso si querés leer más información al respecto.

Más?: Mete el código en funciones anónimas

Esta es una sugerencia vieja vieja vieja, pero buena buena buena… Mete el código en funciones anónimas incluso si no son o usan globales.

Por alguna razón que no podría explicar apropiadamente, esto afecta también la velocidad de ejecución de los scripts.

Así que cuando sea que tengas código en JS en un archivo, recuerda envolverla en una función anónima auto ejecutable como esta:

(function(window) {
  /* todo el código va acá!!*/
})(window);
			

También podés hacer que la función reciba el objeto window como un argumento para una posible pequeña mejora.

Por último: Reducí el scope

Esta amarra con la anterior, agregá variables locales dentro de la función anónima para funciones que se usan normalmente, como Math.round or Math.random

(function(window) {
  var round = Math.round;
  var random = Math.random;
  /* todo el código va acá!!*/
})(window);

Conclusión

Solo porque ya se me hizo costumbre hacer conclusión…. En fín. La idea detrás de todo esto es mostrar que hay formas de mejorar la velocidad del JavaScript, incluso cuando no tenga nada que ver con el DOM, pero si de igual modo trabajas con el, no está de más agregar unos tips a lo que ya conoces.

Agregando una cosa más a lo anterior. Hay una cosa más que intenté: Probar si había alguna diferencia entre llamar una función objeto vs una función instancia:

				var x = new Foo();
				x.someFunc();
				//or
				bar.someFunc();

Yo no ví diferencia alguna, pero si estás usando las clasicas intancias de POO en lugar de funciones estáticas. Puede que te sirva.

Solo recordá que debes perfilar el código siempre antes y después de una optimización. Para ver donde están las partes que realmente necesitan optimizarse y su hubieron mejoras después de algún cambio.

También considerá que muchas optimizaciones pueden hacer que el código sea dificil de mantener. Así que puedes poner en una balanza que tanto necesitas mejorar el performance. Si no es tanto, a veces es mejor no hacerlo.

Espero que te sirva de algo.

Algo así es como podés hacerlo:

// Definimos algunas variables
var foo = "Hola";
var bar = "Mundo";
var nombre_funcion = "decir_" + foo + bar;

/*  Dado que estamos generandolo dinámicamente,
* siempre hay que asegurarse de que la función
* exista en realidad. */

if (typeof(window[nombre_funcion]) === "function")
{
	window[nombre_funcion](" Mundo!");
}
else
{
	throw("Error.  La función " + nombre_funcion + " no existe...duh!");
}

function decir_holaMundo(la_palabra)
{
	alert("Hola " + la_palabra);
}

// Browser va a alertar un trilladísimo "Hola Mundo!"

Cuando lo pensás un rato, tiene mucho sentido considerando que todos los objetos globales en JavasScript son en realidad propiedades del objeto “window”. Fijate en este ejemplo de manzanas y naranjas para entender un poco mejor el concepto.

var foo = "manzana";

function foobar()
{
	var foo = "naranja";
	alert(window["foo"]); // alerta "manzana"
	alert(foo); // alert "naranja"
	alert(window["foobar"]); // alerta la función foobar
}

foobar();

Acá hay otro ejemplo de cuando usar strings para llamar una función puede ser útil. Esta vez llamamos la propiedad de un objeto que hemos creado.

function Persona()
{
	this.mensaje = "Hola Mundo!";
	this.decir_hola = function(a)
	{
		alert(this.mensaje);
	}
}

var Yeco = new Persona();
nombre_funcion = "decir_hola";
Yeco[nombre_funcion]();

Ves como es casi lo mismo que el método de arriba usando una función global?

Espero que te sirva en algún momento.

Y bien, ya que la usamos seguido, o pensamos aprenderla, no nos queda de más conocer unos cuantos tips que nos sirvan para que funcione de un modo más adecuado.

Andando por ahí me encontré un post de Giulio Bai que aborda este tema en específico y nos dá unas buenas sugerencias al respecto:

1. $(document).ready (); Siempre

Todo lo que contenga será ejecutado tan pronto el DOM sea cargado y antes de que los contenidos sean llenados. Te permite agregar eventos a cualquier elemento en la página sin interferir directamente con el markup; todos esos metiches de onload, onclick y onLoQueSea ya no son necesarios, solo escribílos encapsulados ahí.

Un pequeño ejemplo podría ser:

$(document).ready(function()
 {
    $(".dummy").click(function()
    {
        $(this).css('color', '#000000');
    });
});

2. Usá $(window).load ()

Aunque la vasta mayoría de ejemplos vienen usando el método descrito anteriormente, a veces es mejor evitar poner todo ahí.

$(document).ready () es increíblemente útil, pero ocurre durante el rendering de la página, cuando los objetos aún se están descargando. Por eso las funcionalidades supérfluas como scrollings, arrastrar y soltar, podrían ponerse dentro de una función $(window).load () ya que esta ejecuta después de que todos los hayan sido descargados y evita que algo se rompa mientras carga la página.

La sintáxis es casi la misma que la de $(document).ready ():

$(window).load (function () {
// métodos de scrolling
});

3. Carga sólo lo que realmente necesitas

Todos han sido tentados a escribir JavaScript que va a ser usado en una sola página de un sitio y luego cargarlo por todas partes, aunque no se use. jQuery se toma el tiempo de revisar todos y cada uno de los elementos que se le dan, y eso pone las cosas un poco lentas.

Hay dos formas que se sugieren para evitar este problema. El más sencillo sería simplemente agregar una clase en el body del html que sea identificador para correr ahí solamente el código necesario.

$(document).ready(function()
 {
    if ('body').hasClass('home')
    {
        // home page code
        }
    else if ('body').hasClass('blog')
    {
        // blog code
        }
    // Y así sucesivamente
});

El otro método, un poco más enredado, sería construir una biblioteca para llamar el código que se necesite desde cada página:

var jslib =
{
    home:
    {
        init: function() {
            // home page code
            }
    },

    blog:
    {
        init: function() {
            // blog code
            }
    }

    // Y así sucesivamente
}

4. Aprende qué es el método ‘Data’ y usálo

Esto es algo muy común, la gente no piensa en ello y siempre escriben cosas como:

$('.selector').attr ('alt', 'naranja');

para guardar y asociar datos misceláneos en el DOM. Esto, es técnicamente incorrecto, además de que es fácil confundirse, sobre todo para las personas que entren al proyecto después.

jQuery ya tiene un método que sirve para guardar datos en el DOM llamado ‘data’. El ejemplo de arriba vendría siendo algo como esto:

$('.selector').data ('miColor', 'azul');
// que puede ser pedido con
$('.selector').data ('miColor');

Este método te permite asociar y guardar datos en cualquier elemento de la página y tener un nombre de referencia.

5. Usá los selectores personalizados

Estar familiarizado con los selectores de CSS es util cuando se trata de jQuery. Pero conocer los selectores que trae la biblioteca es de verdad un empujón increíble. Date una vuelta por http://docs.jquery.com/Selectors para conocer más de ellos.

Por ejemplo, podrías usar:

$("div:contains('hola')").css ('background-color', '#cc0000');

para pintar de rojo todos los div que contengan la palabra “hola” ó

$('input:password')

para obtener todos los campos que sean para password.

6. Indicadores con clases

Podés usar indicadores ó flags para monitorear lo que el usuario está haciendo o bien revisar si algo en particular se efectuó o no. El método addClass es bastante útil en este caso ya que provee una forma fácil de agregar una nueva clase css a un elemento. Así que podés chequear la existencia de la clase con la función hasClass.

Un uso muy común de los indicadores se da cuando a aplicación tiene uno o más modos de trabajo; al entrar en el segundo modo, el indicador se fija a un elemento predeterminado y, cuando se necesite, el método hasClass es usado para revisar el modo de trabajo actual. Sencillo no?

function editModeOn ()
{
// Inicializa el modo de edición y fija un indicador
$('#flags').addClass ("editModeOn");
// hacer otras cosas
}

function saveData ()
{
// guarda los datos pero primero sale del modo de edición (si está ahí)
if ($('#flags').hasClass ('editModeOn')) {
exitEditMode ();
$('#flags').removeClass ('editModeOn');
}

save ();
}

7. No llamés el mismo selector cientos de veces

De verdad, no lo hagas. Perfectamente en lugar de hacer algo como:

$('p.hola').css ('color', '#000000');
$('p.hola').text ('hoola');
$('p.hola').addClass ('parrafo');
$('p.hola').fadeTo (1000, 1);

Podés hacer algo como:

var $p = $('p.hola');
$p.css ('color', '#000000');
$p.text ('hola');
$p.addClass ('parrafo');
$p.fadeTo (1000, 1);

Eso va a mantener la información del selector lista para ser reutilizada.

8. Encadenando (Casi) todo

El encadenado, o chaining de jQuery es muy útil.
El código anterior podría ser reescrito como:

$('p.hola').css ('color', '#000000').text ('hola').addClass ('parrafo').fadeTo (1000, 1);

Eso sí, sin exagerar, es sabido que este patrón puede ser un poco lento.

9. La utilidad toggleClass

Podés encender y apagar la clase de un elemento para variar su comportamiento sin mucho esfuerzo. Digamos que tenés una clase .hidden que esconde los elementos que la usen. Fácilmente podrías mostrar los elementos de nuevo usando:

$('p.hidden').toggleClass ();

Otro punto de toggleClass es que, con el nuevo release de jQuery 1.3.3, el método .toggleClass() va a tener nuevas formas de operar. Va a ser capaz de cambiar multiples clases, además de que podrá quitar y poner todas las clases.

Estás son las formas en que vas a poder usar toggleClass:

// Con un elemento dado

	// Cambiar todas las Clases
	$('div').toggleClass(); //
	<div>
	$('div').toggleClass(); //
	<div class="a b c">
	$('div').toggleClass( false ); //
	<div>
	$('div').toggleClass( true ); //
	<div class="a b c">

	// Cambiar múltiples clases
	$('div').toggleClass( "a b" ); //
	<div class="c">
	$('div').toggleClass( "a c" ); //
	<div class="a">
	$('div').toggleClass( "a b c", false ); //
	<div>
	$('div').toggleClass( "a b c", true ); //</div>
	</div>
	</div>
	</div>
	</div>
	</div>
	</div>

10. Guardá los resultados de jQuery

Cuando se trata de funciones, podrías querer tener algunos resultados disponibles en otros lugares. Acá hay dos posibilidades.

Una posible solución sería guardar los resultados dentro de objetos dentro de una variable global, así se pueden usar después:

// usamos el objeto Window
	window.$resultados = {
	uno : 0,
	dos : 0
	};

	// esta es la función que podria corre más de una vez
	function getResults (first, second)
	{
	$resultados.uno = first;
	$resultados.dos = second;
	}

	// corre la funcion
	getResults ($('li.azul'), $('a.rojo));
	$resultados.uno.hasClass ('azul'); // true
	$resultados.dos.hasClass ('azul'); // false

	// corre de nuevo
	getResults ($('li.rojo'), $('a.azul));
	$resultados.uno.hasClass ('azul'); // false
	$resultados.dos.hasClass ('azul'); // true

La otra, y a mi parecer la mejor, como se recomienda en el punto 4 es usar el método Data en lugar de crear una variable global.

$.data(window, "resultados", { uno: false, dos: true });

//Para accesar los valores:

$.data(window, "resultados").uno; // false
$.data(window, "resultados").dos; // true

// Y para cambiarlos:

$.data(window, "resultados").uno = true;
$.data(window, "resultados").dos = false;

El gran poder de los objetos es que los datos y las funciones que hacen algo pueden estar encapsuladas en un mismo objeto. Así que aprovechandonos de ello y para seguir buenas prácticas, a veces metemos todas las utilidades necesarias al “desnudo” en el namespace global. Algo así:

function getElementsByClassName(cssClassName) {...}

Aunque en esto veo dos problemas:

• Uno pequeño: el nombre de la función es extremadamente largo… que feo
• y uno grande: si estás trabajando con alguna librería, es muy probable que colisione con otra función con un nombre similar y que se comporte diferente

Vamos a arreglarlos

Podemos crear una clase de utilidades que nos sirva para encapsular esta función (y otras) más o menos así:

function DomUtilityBag() {
this.getByClass= function(cssClassName) {...}
}

e instanciarla:

var domUtils = new DomUtilityBag();

Si has usado constructores, parece obvio y familar no?. Pero los constructores fueron hechos para permitir instanciar cualquier número de objetos del mismo prototype. Por qué necesitaríamos hacer eso con un conjunto de utilidades misceláneas? Usualmente no hay razón, porque no hay datos que se diferencien de una instancia a otra.

Acá entra Singleton y es donde JSON se vuelve muy útil. Con él podemos declarar una única instancia y todos sus miembros de una sola llamada, sin meternos con los constructores:

var domUtils = {
getByClass: function(cssClassName) {...}
}

haciendolo aún mejor

Mientras estamos haciendo el domUtils asumamos que esa librería de utilidades podría crecer bastante (siempre lo hacen). Así que vamos a seguir la técnica de YUI para el namespacing, categorizando más las utilidades, y como solo necesitamos una copia, utilizamos JSON para hacerlo. Acá está el esqueleto de mi librería, y le vamos a poner… eeehh, hmm… ZAQ, sí ZAQ:

var ZAQ = {}  //esto crea un objeto namespace vacío

ZAQ.util = {} //un sub-objeto para el paquete de utilidades

//lo granulamos más, con utilidades específicas para el DOM
ZAQ.util.dom = {
getByClass: function(cssClassName) {...},
elemHasClass: function(elem, className) {...}
}

//podemos agregar más tipos de utilidades en sus propias "categorias"
ZAQ.util.array = {
contains: function(theArray, match) {...}
}
ZAQ.util.string = {
startsWith: function(theString, match) {...},
endsWith:   function(theString, match) {...}
}

Y así sucesivamente.

Conclusión?

Necesitamos una?

Ok, ok… El fín es que podés usar el poderoso patrón singleton en JavaScript, funciona perfecto para este tipo de librerías de utilidades y un sin fín de cosas más en las que solo necesités una copia corriendo. Mantiene el código fácil de leer, mantiene el namespace intacto y ordenado y además previene colisiones con otras funciones cuando estás integrando otras librerías.

Que te sirva de algo.

function detectarBlocker() {
    var intento = window.open("about:blank","","directories=no,height=100,width=100,menubar=no,resizable=no,scrollbars=no,status=no,titlebar=no,top=5000,location=no");     if(intento) { // no hay bloqueo
        intento.close();
        return 1;
     } else { // está bloqueado
        return 0;
     }
}

Una de las formas de arreglarlo es cambiando dinámicamente el orden por default de los elementos de la página. Esto asegura que los elementos en el código HTML tengan el índice adecuado, resolviendo la mayoría de los problemas que causa IE7.

El modo de hacerlo usando jQuery sería algo como:

$(function() {
	var zIndexNumber = 1000;
	$('div').each(function() {
		$(this).css('zIndex', zIndexNumber);
		zIndexNumber -= 10;
	});
});

Con esto básicamente lo que hacemos es comenzar con un z-index de 1000 y decrementar el indice de cada div de la página en tractos de 10, es decir, el primer elemento tendrá un z-index de 1000, el segundo 990 el tercero 980 y así sucesivamente. Notá que el selector de jQuery encuentra todos los divs con el codigo “$(’div’)”, usando la misma syntaxis que los selectores de CSS, nada dificil.

Ah… y así se hace lo mismo pero con MooTools, por si estás usando esa biblioteca:

if(Browser.Engine.trident){
	var zIndexNumber = 1000;
	$$('div').each(function(el,i){
		el.setStyle('z-index',zIndexNumber);
		zIndexNumber -= 10;
	});
};

Saluuú.

La idea con este es ayudar con los forms, evitandonos el engorroso trabajo de llenarlos una y otra vez para probarlos.

El generador toma el form en que estás trabajando y crea un bookmarklet específico para los campos que necesitas, con la info que necesitas.

Cómo se usa?

Simple, solo agregas un bookmark y a este lo editas y le cambias la url colocando en su lugar este script.

javascript:var fz=new Array();var z=new Array();function F(p){var m=new Array();for(n=0;n <p.length;n++){var q=new Array();for(ind=0;ind<p[n].length;ind++){q.push('\''+p[n][ind]+'\'')}m[n]=eval('['+q.join(',')+']');}return m;}function C(n,cz){var i=-1;for(ab=0;ab<cz.length;ab++){if(cz[ab][1]==n)i=ab;}return i;}function B(){fz.length=0;if(!document.forms.length){alert('There are no forms in this page.');return;}for(fi=0;fi<document.forms.length;fi++){z.length=0;f=document.forms[fi];for(i=0;i<f.length;i++){ip=f.elements[i].type;iv=f.elements[i].value;ix=f.elements[i].name;if(!iv){continue;}if(ip=='text'||ip=='textarea'||ip=='select-one'||ip=='password')z.push(['d',ix,iv]);if(ip=='radio'||ip=='checkbox'||ip=='select-multiple'){x=C(ix,z);if(x==-1){if(ip=='select-multiple'){iv=%22%22;for(g=0;g<f.elements[i].length;g++){if(f.elements[i][g].selected){iv+=f.elements[i][g].value+%22|%22;}}z.push(['s',ix,iv]);}if(ip=='radio'){if(f.elements[i].checked){z.push(['c',ix,iv]);}}else{if(f[ix].length){if(f.elements[i].checked){z.push(['c',ix,iv]);}}else{if(f.elements[i].checked){z.push(['n',ix,'']);}}}}else{if(f.elements[i].checked){z[x][2]+=%22|%22+iv;}}}}fz.push(F(z));}bms=new Array();for(f=0;f<fz.length;f++){if (!fz[f].length){continue;}bm=%22java%22+%22script:function D(a,b){c=b.split('|');d=false;for(q=0;q<c.length;q++){if(c[q]==a)d=true;}return d;}%22;bm+=%22function E(){f%22+f+%22=document.forms[%22+f+%22];%22;for(k=0; k<fz[f].length; k++){if(fz[f][k][0]==%22d%22){bm+=%22f%22+f+%22['%22+fz[f][k][1]+%22'].value='%22+fz[f][k][2]+%22';%22;}if(fz[f][k][0]==%22n%22){bm+=%22f%22+f+%22['%22+fz[f][k][1]+%22'].checked=true;%22;}if(fz[f][k][0]==%22c%22){bm+=%22for(i=0;i<f%22+f+%22['%22+fz[f][k][1]+%22'].length;i++){if(D(f%22+f+%22['%22+fz[f][k][1]+%22'][i].value,'%22+fz[f][k][2]+%22')){f%22+f+%22['%22+fz[f][k][1]+%22'][i].checked=true;}}%22;}if(fz[f][k][0]==%22s%22){bm+=%22for(i=0;i<f%22+f+%22['%22+fz[f][k][1]+%22'].length;i++){if(D(f%22+f+%22['%22+fz[f][k][1]+%22'][i].value,'%22+fz[f][k][2]+%22')){f%22+f+%22['%22+fz[f][k][1]+%22'][i].selected=true;}}%22;}}bm+=%22}E()%22;bms.push(bm);}w= window.open('','','toolbar,width=150,height=100');for(f=0;f<bms.length;f++){w.document.write(%22<a href=\%22%22+bms[f]+%22\%22>Form #%22+(f+1)+%22</a><br />%22);}w.document.write(%22Arrastra el link a tu toolbar.%22);w.document.close();}B();

Luego, llenas los campos del form en que estás trabajando, das click en el generador y este abre un popup con un link al bookmarklet generado. Arrastrás el link a tu barra de bookmarks y listo, cada que lo actives te llena los campos solo.

$(window).load(function(){
//Acá tu código
});

De verdad sencilla y conveniente si ya estás usando jQuery en el proyecto, pero qué pasa si no? Ahí es donde cobra sentido este post. No nos conviene cargar 30k de código extra para poder resolver este problema solamente, sería matar una mosca con un cañón.

Hace poco más de un año dí con una solución, eficiente, agnóstica y que responde bien en todos los browsers… Para ie a veces basta con agregar defer cómo atributo.

<script defer src="ie_load.js" type="text/javascript"></script>

Y el contenido del ie_load.js sería el script que ie debe cargar cuando esté listo. Suena bien, pero es una solución que no funciona adecuadamente con los otros browsers que simplemente ignorarían el defer, Mozilla y Safari quedarían rezagados.

Afortunadamente Mozilla responde a su propio DOMContentLoaded entonces solo queda escuchar el evento y ejecutar lo que queramos con él:

document.addEventListener("DOMContentLoaded", init, false);

Y John Resig, el creador de jQuery, dió con la solución para safari hace un tiempo:

if (/WebKit/i.test(navigator.userAgent)) { // sniff
		var _timer = setInterval(function() {
			if (/loaded|complete/.test(document.readyState)) {
				init(); // call the onload handler
			}
		}, 10);
	}

Para los demás browsers, solo nos queda hacer uso del window.onload común y corriente que todos conocemos:

window.onload = init;

Ya teniendo todos estos ingredientes dispuestos, solo queda hacerlos funcionar en conjunto, haciendo uso del soporte para compilaciones condicionales que tiene ie (para que no se meta con lo demás) y uno que otro tweak, ponemos todo en un solo script que se encargue del onload adecuado para cada browser.

function init() {
 		if (arguments.callee.done) return;

 		arguments.callee.done = true;

 		if (_timer) {
			clearInterval(_timer);
			_timer = null;
		}

		// Acá va lo que queramos ejecutar

	};

	/* Para Mozilla */
	if (document.addEventListener) {
		document.addEventListener("DOMContentLoaded", init, false);
	}

	/* Para Internet Explorer */
	/*@cc_on @*/
	/*@if (@_win32)
		document.write("<script id=__ie_onload defer src=javascript:void(0)><\/script>");
		var script = document.getElementById("__ie_onload");
		script.onreadystatechange = function() {
			if (this.readyState == "complete") {
				init(); // call the onload handler
			}
		};
	/*@end @*/

	/* Solución de John Resig Para Safari */
	if (/WebKit/i.test(navigator.userAgent)) { // sniff
		var _timer = setInterval(function() {
			if (/loaded|complete/.test(document.readyState)) {
				init(); // call the onload handler
			}
		}, 10);
	}
	window.onload = init;