Chaque fois que je parle de reléguer les codes javascript en fin de page, je vois une moue sur le visage de mon interlocuteur. Mettre le javascript dans le du document, et encore plus à la fin de celui-ci, et souvent préjugé comme une pratique "sale". Laissez moi vous convaincre du contraire.
Hier j'ai tenté de convaincre de mettre les codes javascript à la fin du document. Et là, d'ordinaire, chacun trouve une raison pour ne pas suivre le conseil. Des fois de très bonnes raison, souvent des contestables.
Rappelez-vous : cool URIs don't change (les URIs sympa ne changent pas), et mieux, autant que possible elle ne disparaissent pas non plus. Reste que beaucoup d'éditeurs ne tiennent pas compte de cette recommandation, et que les développeurs ne peuvent s'abstenir de faire des erreurs quand ils font des liens.
Ces pages d'erreurs donnent une piètre expérience à l'utilisateur, je ne l'apprend à personne. Je me concentre ici sur l'aspect performance mais sur cet aspect aussi il y a des conséquences.
J'abuse, il parait. Je parle de demi seconde ou même de centaines de milli-secondes. Je parle de quelques dizaines de kilo-octets là où la plupart ont des pages qui en font cinq ou dix fois plus.
Alors voilà, j'assume. Mais peut être que ça vaut le coup de rappeler trois chiffres qui permettront à chacun d'avoir des arguments quand on ne les prend pas au sérieux :
On en parlait il y a peu mais ça vaut le coup de faire un petit billet dédié : L'équipe de WebKit vient d'annoncer l'intégration de SquirrelFish. SquirrelFish c'est une réécriture de Javascript Core, leur moteur Javascript.
Un petit peu de Javascript ? C'est Peter-Paul Koch aussi dit PPK qui lance la question sur Quicksmode il y a trois mois. Il tente de comparer diverses méthodes pour ajouter du contenu à une page, et plus spécifiquement innerHTML et les fonctions DOM (par DOM j'entend appendChild, createElement et associés).
On créé un tableau de 50×50 avec une astérisque dans chaque cellule et on compare. Le résultat est joli, en couleurs : DOM est lent, innerHTML est rapide. On parle d'un facteur 2 à 3, sauf pour Internet Explorer (oui, toujours) où on parle d'un facteur 20 à 30. Oui, vous avez bien lu.
