Logo JavaScript

Head.js, le script qui charge vos scripts plus vite… ou pas!

Flattr this!

J'ai pris le temps de tester Head.js. Ce script est censé améliorer les performances de votre site en chargeant les fichiers de script comme des images sans impact sur leur fonctionnement.

Pour mes tests, j'ai fait assez simple. J'ai utilisé en local la version minified complète. Deux types de situation ont été étudiées : sans cache et avec cache. J'ai déroulé ces tests sur les navigateurs suivants : Chrome 10.0, Firefox 3.6 et IE 9 RC, sur un Windows 7 64 bits.

A chaque fois, j'ai chargé la liste des scripts suivants : jQuery 1.4.4 minified, jQuery UI 1.8.10 (tous les composants inclus, thème lightness) et afficher quelques widgets de jQuery UI comme sur une page tout ce qu'il y a de plus banal (je me suis servi de la page de démo de jQuery UI en fait). Vous pouvez retrouver ces pages de tests ici :

Voilà les résultats, en millisecondes :

Sans Head.js - Sans cache Sans Head.js - Avec cache Avec Head.js - Sans cache Avec Head.js - Avec cache
Chrome 10.0 516.2 460.6 674.4 488.6
Firefox 3.6 1284 981.6 1332 734.6
IE 9 RC 826 642 896 480

Pour le cas où, j'ai exécuté systématiquement 5 fois chaque test, je vous donne ici la moyenne des résultats sur chacun de ces 5 tests, espérant amoindrir ainsi la possibilité d'un ralentissement dû à une cause extérieure.

Comme vous pouvez le constater, la différence n'est pas énorme, parfois même son utilisation pénalise les performances. Pour le moment rien ne justifie l'utilisation de ce script.  Je n'ai chargé que 2 scripts sur ce test ceci dit. Alors histoire de corser les choses, j'ai fait d'autres tests avec un poil plus de scripts à charger. Dans l'espoir que Head.js nous montre sa puissance sur des sites plus lourds.

Donc en plus de jQuery 1.4.4 minified, jQuery UI 1.8.10, j'ai rajouté mon plugin de slideshow, mustache.js (un script de templating de données), jQuery.like (plugin proposant un bouton like à la Facebook mais qui respecterait la vie privée), jQuery.doubleSelect, jQuery.WoWwindow (plugin de lightbox) et jQuery.ui.ppmenu (plugin de menu pour jQuery.UI). Là ça va en faire du bazar à charger, je tiens à vous prévenir ceci dit, j'ai pris ces plugins au hasard, je ne les recommande en rien et ne vous garantis ni leur bon fonctionnement ni leur fiabilité.Pour le reste, on ne change rien, mêmes conditions de tests, les fichiers de tests sont ici :

Et les résultats en millisecondes :

Sans Head.js - Sans cache Sans Head.js - Avec cache Avec Head.js - Sans cache Avec Head.js - Avec cache
Chrome 10.0 644.8 520.2 693.4 656.6
Firefox 3.6 1566 1644 1734 1413
IE 9 RC 1010 692 1438 578

Visiblement, le nombre de fichiers de scripts à charger ne change pas grand chose, ça augmente les temps de chargement partout avec le jackpot pour IE 9 RC (à voir si ça a changé avec la version définitive) dans le cas d'utilisation de Head.js et sans cache où le temps de chargement est multiplié par 1.6.

On notera aussi et surtout que lorsqu'il y a utilisation du cache, Head.js aide un peu sur Firefox et IE mais pas du tout sur Chrome.

J'en conclue donc que même si l'idée semble bonne, Head.js n'est pas encore prêt à un usage universel et que vous avez intérêt à vraiment vous assurer que son usage apportera quelque chose. Si votre client impose une application sur IE ou Firefox, allez y de bon coeur mais pensez à mettre en cache au possible. Sinon oubliez cette idée.

Du coup, vu que je suis déçu par ces résultats, je vous promets d'aller faire un tour du côté de la concurrence et les tester aussi. Et vu que je suis sympa, je me dépêche de finir au plus vite la rédaction du tutoriel d'utilisation de Head.js pour Developpez.com. J'espère être capable de le publier prochainement.

Flattr this!

A propos de Mathieu

Ingénieur développeur web dans la vente par correspondance B2B, adepte de nouvelles technologies et d'innovation. Vous pouvez aussi me retrouver sur Twitter @mathrobin
Cette entrée a été publiée dans JavaScript, avec comme mot(s)-clef(s) , , , , , , , , , , . Vous pouvez la mettre en favoris avec ce permalien.
  • Romz

    Merci Mathieu pour cet excellent article et tests (que je n’avais pas pris la peine de faire).
    j’en profite aussi pour t’encourager à continuer la rédaction de tes billets : clairs nets et précis, j’adore !

  • http://www.mathieurobin.com Mathieu

    Merci! 😀

  • https://twitter.com/pomeh Pomeh

    Head.js est pas mal mais un peu trop « fourre tout » selon moi. Il fait trop de choses différentes, et à force d’en faire trop il risque de les faire mal (ou en tout cas moins bien que s’il en faisait moins).
    Et puis par exemple, la partie CSS modernizer / HTML5 enabler a été récupéré du projet Modernizr. C’est une bonne chose, sauf que:
    – Modernizr évolue très régulièrement donc il faut maintenir head.js en conséquence,
    – Modernizr peut être utilisé en standalone, et depuis la version 2 on peut « construire » sa version Modernizr sur mesure (=inclure que les tests dont on a besoin), donc ce sont 2 arguments pour utiliser Modernizr tel quel. Si on inclus en plus head.js, du code sera redondant voir carrément inutile, ce qui augmentera le temps d’éxécution du Javascript ce qui augmentera le temps de chargement de la page… Dommage pour un script qui est justement censé améliorer ce point ^^

    Son point fort, ou en tout cas son but principal, est l’amélioration de la vitesse d’affichage des sites via le téléchargement parallèle et l’exécution des scripts Javascript. C’est donc dommage qu’il ait tous ces « a côtés » qui sont souvent superflus ou redondants avec d’autres outils.

    Pour information, il existe de nombreux autres outils/script pour améliorer la vitesse de téléchargement et d’exécution de ses scripts. Une liste est en train d’être créée et sera maintenue au fil du temps par de nombreuses personnes et est déjà disponible en ligne: https://docs.google.com/spreadsheet/ccc?key=0Aqln2akPWiMIdERkY3J2OXdOUVJDTkNSQ2ZsV3hoWVE#gid=2

    A+

  • http://www.mathieurobin.com Mathieu

    Il est vrai que je n’en ai pas parlé parce que je trouve que ça sortait du cadre de cet article sur les performances mais Head.js en fait bien plus que seulement le download « amélioré ». Je suis en train de faire un tuto pour Developpez.com où j’aborde comment utiliser Head.js, aussi bien pour le download que toutes les autres fonctionnalités.
    Et je songe comme je le disais dans ce billet à aller voir la concurrence, je te remercie donc au passage pour ton lien qui va me faciliter énormément le travail de recherche.

  • http://danielhagnoul.developpez.com/ danielhagnoul

    Bonsoir Mathieu

    Sauf erreur de ma part, il manque une variante dans ta série de tests. Il est conseillé depuis quelque temps, et recommandé si on adopte la stratégie d’amélioration progressive, de placer tous les scripts juste avant le tag /BODY, de plus cela améliore aussi beaucoup le téléchargement des scripts. J’ai adopté cette technique depuis plusieurs mois avec succès.

  • http://www.mathieurobin.com Mathieu

    Ah, je vais regarder ça de plus près alors. Et voir aussi avec la version loader seul. peut être que ça aidera pour les perfos. A l’occasion, je prendrai le temps de refaire un passage dessus. Merci du partage de l’info en tout cas 😀

  • Yannick

    Ton article est super, j’attends avec patience la suite. J’ai moi même un portfolio (en construction) bourré de script jquery et ça m’aiderai drôlement de trouver un bon script de chargement.
    Je suis tombé sur cette article en recherchant le script tester et je suis bien tombé, je te souhaite bon courage pour ton article sur developpez.com, l’étude de la concurrence et les tests avec le loader seul.

    Cordialement,
    Yannick

  • http://www.mathieurobin.com/ Mathieu

    Merci ça fait toujours plaisir. Effectivement, même avec une bonne connexion et un navigateur performant, ton site souffre de quelques soucis de performances, c’est dommage parce qu’il est plutôt sympa. Je pense avoir le temps ce weekend de faire les tests de la version loader seul et donc publication dans la semaine (je ne publie jamais le jour de l’écriture, le temps de me relire à tête reposée).

  • http://www.go-festival.com Didier

    Est-ce que je me trompe si je dis que le but du loader head.js n’est pas de rendre plus rapide le chargement complet d’une page mais de seulement et simplement déporter le chargement/exécution des scripts javascripts en fin de page afin d’afficher plus rapidement son vrai contenu ? Ainsi, l’internaute lis le contenu pendant que les js se charge et s’exécute 😀

    ps : sympa ton tutorial sur developpez.com :)

  • http://www.mathieurobin.com/ Mathieu

    On peut aussi voir cet aspect comme une réelle optimisation. Dans ce cas, ok, Head.js fait son boulot correctement. A condition qu’on ne soit pas complètement dépendant de l’exécution du code javascript pour l’affichage du contenu.
    De plus le site officiel suggère une optimisation du temps de chargement, chose que je remets en cause ici.
    D’où la publication sous peu de tests similaires avec la version loader seul dans l’espoir de voir une réelle amélioration des temps de chargement.
    Merci pour le compliment à propos du tuto!

  • http://gillesdumas.com Gilles

    Comme un autre commentaire plus haut, je trouve ce script un peu trop « fourre tout ».
    Et au vu de tes tests, il ne vaut pas le coup d’être encore utilisé. Merci pour ces tests parce qu’après avoir lu ce que tu avais mis sur developpez.com j’étais conquis, mais maintenant je le suis moins, et ne vais pas l’utiliser pour l’instant.

  • Kris

    Salut,

    j’ai rencontré de gros problème de chargement des scripts sous IE6. Du coup, si comme moi, vous devez développer des applications avec un large de spectre de navigateurs, évitez-le ou bien faite du chargement conditionnel (avec des balise <[if ie]).

    Kris

  • http://www.mathieurobin.com/ Mathieu

    Était-ce dû à Head.js ou tout simplement aux scripts chargés? Pour savoir

  • http://www.eboyer.com Eroan

    Je découvre seulement cet article sur un sujet qui m’intéresse pourtant beaucoup !

    J’ai personnellement déployé Head.js avec Jquery sur mon site http://www.scooter-system.fr/ il y a 1 an, et les retours sont très positifs. Comme indiqué plus haut, le but n’est pas tant de réduire le temps de chargement que de permettre un chargement plus rapide de la page en elle-même. Et cela fonctionne.

    J’utilise même Head.js pour charger les librairies Facebook, Twitter et Google +1, qui ralentissent habituellement le chargement des pages. Mes travaux sont expliqués ici : http://www.eboyer.com/dev/807-boutons-asynchrone/

    Je suis intéressé par d’autres articles sur le sujet, n’hésitez pas à partager 😉

    • http://www.mathieurobin.com/ Mathieu

      Salut et merci du commentaire !
      J’ai mis de côté ton article, dans mon dossier « à lire ». (oui je tutoie et j’en demande autant)
      Côté Head.JS, en effet, je suis assez dur avec, mais c’est pour éviter que justement des gens pensent que ça charge plus vite. C’est uniquement fait pour charger d’abord l’apparence et le contenu avant le comportement, ce qui rend le site lisible et regardable avant de commencer à charger les actions possibles. Ce qu’on appelle le « visible » devient prioritaire. Et c’est ce que fait très bien Head.JS.

  • Julien Cousineau

    Salut, j’aborde dans le même sens que Eoran.

    Et j’ajoute, qu’il ne faut pas de négliger le fait que vous avez tester avec un load de 1 utilisateur.
    La beauté, c’est qu’on fait moins de « vrai » requête GET pour chargé plusieurs js. Plutôt que les chargés par la bande comme head.js le fait.

    Si on prend le même scénario mais avec un load de 200 req/sec. Je suis certain qu’on verrais un gain.
    Je travail sur des plateformes avec ce genre de trafic. Et head.js sera intégré. Je vais faire mes propres test afin de valider ce que je dis et je les publierais avec vous!
    @CousineauJulien

    • http://www.mathieurobin.com/ Mathieu

      Je t’avoue que je suis assez curieux de ton approche. Perso, j’ai basculé vers RequireJS. Avec plaisir pour tes résultats. D’ailleurs si tu veux, tu pourras même les publier en rédacteur invité en ton nom et visible de tous plutôt que dans un commentaire ou plus grand monde ne les verra 😉

      • Julien Cousineau

        Salut,

        J’ai terminer les résultat de mes tests. Si tu veux je peux te les envoyés par courriel avec les paramètres de mes tests. En conclusion, ça ne change rien (ou peu) même avec plusieurs utilisateurs en même temps. J’ai un beau graphique 2D qui démontre tous cela.

  • johnny

    Malheureusement head.js ne sert à rien. pour accélérer l’affichage d’un site, il faut différer le chargement des fichiers javascript ( quand c’est possible ), c’est à dire que lorsque le site est chargé on charge les javascripts ( bien sûr pour que ça aille bien il faut qu’à la conception du site, il ne soit pas dépendant du javascript pour son affichage ).
    Pour pousser le vice, on peut différer le chargement des javascript ( comme le conseil google sur pagespeed ), et à l’aide de template php savoir si tel ou tel js est requit pour une page, le tout combiné à un cache php ( type mmcache ou eaccelerator ) , les gains de vitesse de chargement de page sont minimum multiplié par 5.

    • http://www.mathieurobin.com/ Mathieu

      Oui ce billet fait partie des articles que j’ai écrit dont j’ai un peu honte aujourd’hui. Je n’avais pas encore réalisé la différence à l’époque. J’ai juste réfléchi un peu bêtement… Ça ne sert en fait qu’à supprimer le chargement immédiat des scripts pour permettre un affichage plus rapide de la partie visible du site vu qu’elle passe du coup en priorité.

Articles liés