Dirty Hacky VII : Le script des bas-fonds

Ce billet fait partie de la série « Dirty Hacky ». Le but de cette série est un objet critique sur les astuces de web-développement, et n'a pas pour vocation d'être une recette définitive, mais d'attirer l'audience par la polémique technique.
BANG! BANG! BANG!

Fallait cadre le javascript, question d'éducation

La balise <script> est l'une des plus étranges et des plus vestigiales. À la différence de <style>, elle ne bénéficie pas d'un équivalent <link /> qui serait nettement plus approprié. Elle n'est pas non plus autofermante, même si elle fait appel à des ressources externes. On ne peut donc écrire <script src="/resource" /> ce qui est bien dommage. Elle a longtemps était affublée d'un attribut alors que le langage par défaut était implicite depuis Netscape Navigator 2. Et tout ça, j'en parle plus dans le précédent épisode. Aujourd'hui, je parlerais de cette manie de mettre cette balise en fin de document HTML.

Quand certaines huiles des interwebs commencèrent à prêcher les bonnes pratiques, quand on se souciat de sortir la présentation du HTML, il fut proposé que les balises <script></> soient installées dans le <head></> du document. Ce qui est logique puisqu'il fait partie de l'interaction et non de la structure pure et dure du document. Qu'on garde la structure du code propre, et le commissariat sera bien gardé.

onready, steady ? go !

Mais l'interprétation d'un javascript, et surtout son interaction avec le DOM posaient plusieurs problèmes. Lors des héroïques heures du millénaire précédent, quand les flics tiraient du code sans aucune logique, pour insérer un bout de code HTML, nous n'avions que document.write() sous la main. Cela signifia que pendant très très très longtemps, cet infâme fonction qui n'aurait jamais dû exister obligeait à placer les balises <script> là où l'on souhaitait insérer son code. Cela est toujours le cas chez certains régies publicitaires (oui, oui, en 2013,…). Et puis, enfin, vers 2000, nous eûmes des manières plus civiles pour changer un élément d'une page. Sauf qu'avant d'opérer sur le DOM et cibler des éléments précis, il fallait attendre qu'il soit fini, même au petit pipi.
Et là, la plupart des programmeurs étaient coincés. Il n'existait pas encore d'événement document.DOMContentLoaded, mais uniquement document.onload. Or, celui-ci n'est lancé qu'une fois que toutes les ressources, l'ensemble des assets d'une page sont chargées. C'est à dire quand l'ultime image est intégralement récupérée et interprétée.
À une époque où le modem n'était pas forcément ADSL, inutile de vous dire que c'était horriblement long.

Je me souviens que j'y palliais avec une combinaison de document.setTimeout() et de === undefined. Oui, j'ai des tâches dans mon casier judiciaire.

À l'époque donc, on recommandait de placer un script en bas de page car c'était le moyen le plus efficace d'être sûr que le reste du DOM du document soit prêt à subir vos manipulations, sans devoir attendre que les 25 jpeg de 200ko aient finis de passer en 56kbauds. Avec DOMContentLoaded(), c'était inutile.

La faute est toujours celle des autres

On aurait pu croire qu'on en avait enfin fini, et que la balise <script> allait rester en <head>. Hélas, la délinqu(esc)ence se cachait parmi l'élite. Quand Google inaugura son service Google Analytics, celui-ci devint très populaire dès la première semaine. À ce moment-là, Google recommandait de mettre l'appel à google_analytics.js en <head>.

Alors qu'on en était au troisième mois de béta publique, le service tomba en rade. 2 jours. 2 putains de journées où plus aucun site ne s'affichait rapidement, puisqu'il fallait attendre que le navigateur ne pouvant charger google_analytics.js se résigne à un timeout. Soit 60 secondes de pages désespérément blanches.

Conscient de l'immense dégât que faisait son script, ou plutôt l'absence de son script, Google recommanda alors d'insérer l'appel en fin de document, juste avant le </body>. Alors qu'on arrivait enfin à avoir de bonnes pratiques d'ingénierie en web dynamique, Google a incité tout le monde à faire exactement ce qu'il ne fallait pas ! Le problème, c'est que cette pratique qui était provisoire et rédigée dans l'urgence, fut reprise par des centaines de sites d'aides aux script-kiddies sans réel recul critique, et que c'est resté !
Or maintenant, quand vous regardez le code GA que vous intégrez à votre site, vous n'avez qu'un bête loader asynchrone, tout à fait propre. Si vous le mettez en haut, cela n'impactera en rien les performances de votre site, même en cas de hoquets du CDN de Google. À vraie dire, j'ai été surpris que Google ne l'avait pas proposé immédiatement, puisque suite à ce white-out, j'avais utilisé la même méthode. 4 instructions.

Ça, c'était avant

Donc ce hack est passé, passéiste et n'est vraiment plus à recommander, essentiellement pour des raisons de maintenabilité.
Néanmoins, avec la simplification HTML5 qui permet de se passer des balises <html>, <head> et <body>, le placement de la balise <script> reste libre. Personnellement, je préfère avoir tout ce qui concerne les métadonnées, les références externes, les assets, le stylage et l'interaction du document groupé à son début, afin qu'il soit plus facile à maintenir. Surtout que maintenant, les navigateurs peuvent prédire quand l'interprétation d'un <script> peut se faire en parallèle des autres opérations de parsing.

Origine	GOOD
Élégance	HARDLY MAINTENABLE
Modernité	NO
Postérité	NO USE

To be continued

Te voilà en bas de mon procès-verbal, t'as la place pour placer tes commentaires ↓