Il y a des fois où ce n’est pas idéal et c’est Steve Souders qui étudie les solutions dans sa présentation aux conférences Velocity 2008. Quelques cas en vrac :

• Le Javascript est prioritaire, il doit être téléchargé et exécuté le plus tôt possible, mais pas au prix d’un blocage de tout le reste ;
• Il n’est pas possible déplacer l’insertion de la balise à la fin du document, le système ne le permettant pas ;
• Vous ne voulez pas montrer à l’utilisateur que la page est toujours en train de se charger (logo et barre de statut) ;
• Vous ne voulez pas que l’événement onload de la page attende le téléchargement et l’exécution du javascript.

Ne pas bloquer le rendu

Pour résumer les solutions intéressantes abordées par Steve Souders :

Passer par l’API DOM

La première solution est d’insérer le javascript via la création d’un noeud DOM. Le script ne bloque alors plus les nouveaux téléchargements. Le problème principal est que certains navigateur délaient l’événement onload tandis que d’autres l’exécuteront avant la fin du script. Cette différence peut rendre la gestion de la page un peu difficile

var se = document.createElement('script');
se.src = 'http://example.org/test.js';
se.type = 'text/javascript' ;
document.getElementsByTagName('head')[0].appendChild(se);

Passer par une iframe

La seconde solution est d’insérer le javascript via une iframe. Le rendu et les nouveaux téléchargements ne sont pas bloqués, l’événement onload réagit de la même façon sur tous les navigateur. Le défaut est que l’iframe fait elle-même perdre un peu de temps au rendu et que pour réutiliser le contenu on est limité à avoir la page et le script sur le même domaine. Impossible donc d’utiliser un CDN sur un domaine tiers.

Cela demande de plus de réorganiser le script lui même. La page principale devra passer par window.frames[x] pour accéder aux fonctions du script, et le script devra lui passer par parent.document pour accéder au DOM de la page principale.

Passer par XMLHttpRequest

La solution qui peut paraitre magique c’est d’insérer le javascript via une requête XMLHttpRequest. Le script ne bloque ni les nouveaux téléchargements ni l’événement onload. Mieux le navigateur ne montre pas à l’utilisateur que la page continue à se charger. Cela peut amener l’utilisateur à avoir une meilleure impression de vitesse. Par contre on est ici aussi limité à un seul domaine pour la page HTML et le javascript, donc pas de CDN sur domaine tiers.

Je ne vous met pas de code, chacun a sa bibliothèque pour ça. Vous pouvez utiliser DOM ou eval, comme vous voulez.

Passer par un script DEFER

Enfin, vous avez l’attribut DEFER que vous pouvez ajouter à une balise de script des plus classiqes. Là non plus le script ne bloque pas les nouveaux téléchargements … mais uniquement sous Internet Explorer.

Préserver l’ordre d’exécution

Tout ça donne déjà un bon aperçu mais tout n’est pas résolu. Dès que vous avez plusieurs javascript vous avez certainement des dépendances et l’ordre de chargement est important. Là ça se gâte. Vous oubliez la technique de l’iframe qui ne vous garantit rien.  

Si vous pouvez vous permettre d’avoir le javascript sur le même domaine que la page HTML, alors il va vous falloir gérer vous même un code dans XMLHttpRequest pour assurer l’ordre d’exécution.

L’écran 26 de la présentation donne une excellente grille de lecture de tout ça. Et les autres navigateurs ? motus et bouche cousue. Dans l’ensemble les comportements ont des chances d’être similaires à ceux de Firefox, mais c’est à tester. Il y a quelques liens vers le Cuzillon donc si certains veulent tester et donner les résultats Safari et Opera…

Utiliser YUI

L’équipe Yahoo! est toujours sur la brèche côté performance. Vous avez doc un outil YUI pour charger dynamiquement scripts et des feuilles de style en tenant compte des dépendances, sans bloquer le navigateur. Visiblement tout n’est pas clair sur la situation de Safari, il faudrait que je fouille un peu pour tirer ça au clair. D’ordinaire la politique est d’avoir un comportement stable sur tous les navigateurs grade A, dont Safari fait partie, donc j’ai bon espoir que si ce n’est pas déjà le cas, une solution finisse par être trouvée.

Pour le même prix l’outil YUI permet aussi de charger aussi les feuilles de style et éviter leur aspect bloquant sur Firefox.

Stoyan Stefanov en parle lui aussi, en détail.

Et l’avenir ?

Le bon côté c’est que les équipes Webkit et IE8 ont dans leurs cartons la possibilité de charger les scripts sans bloquer le navigateur et en les exécutant dans l’ordre d’apparition dans la page.

Tout ceci est pour demain, et les navigateurs d’aujourd’hui ne sont pas amenés à disparaitre rapidement, mais au moins, à moyen terme, on pourra n’avoir de ralentissement que sur les anciens navigateurs. Reste juste à espérer que Firefox et Opera bougent aussi sur ce point, mais malheureusement je n’ai pas vu d’information dans ce sens.