Another NoBoy Life part… (le blog de __MaX__)
Retour au blog <<

Archives

:: DEV .:. Parallel downloads et inline script

Jeudi 28 octobre 2010 à 21:46

Terminant une petite optimisation pour la vékat j’avais le blog qui me démangeait afin de partager un peu tout ce que je tente de mettre en place pour faire de cette nouvelle mouture de factor une expérience agréable pour nos utilisateurs.

Bref… ces derniers temps j’ai remarqué que peu de sites utilisent cette technique, et c’est de toute façon compréhensible quand on voit comment ils sont codés à l’arrache.

Quand un navigateur se connecte à un site, il a la possibilité d’effectuer des téléchargements en parallèle (soit simultanément pour ceux qui ne suivent pas), hors il s’avère que les scripts js inclus dans le header d’une page html bloquent tout autre téléchargement. L’expliquer techniquement est toujours difficile pour moi, depuis plus d’un an je cherche un article clair et précis à ce sujet, en vain. Il semblerait que ce soit dut aux spécifications HTTP1.1. Ce qui est sûr c’est que charger vos scripts dans l’entête d’une page donne lieu à une suite de requêtes du genre

Image hosted by uppix.net

[clic clic pour lire les légendes]

A l’appel des scripts, tout autre téléchargement est interrompu jusqu’à obtention de ces fichiers. Dans ce cas de figure tout se produit en 2 secondes, quasi transparent pour l’utilisateur (c’est un test en local). Mais quand on voit aujourd’hui la masse énorme de javascripts chargés par le moindre site, la première requête pour l’utilisateur peut sembler extrêmement longue (surtout à l’heure des connexions haut débit où l’utilisateur n’a plus aucune patience), et à plus forte raison si le serveur est un peu chargé et que les requêtes sur les scripts sont un plus longue que la normale.

La solution ? Charger les scripts juste avant la fin de body. On obtient donc ceci

Image hosted by uppix.net

Tous les téléchargements d’images et autres médias chargés par la page sont appelés dès le début et visiblement chargés en parallèle ; puis sont enfin chargés les scripts.

Cette technique n’accélère pas réellement le temps de chargement de le page. Par contre, l’intégralité de la page est chargée, consultable par l’utilisateur dans le cas où les scripts sont en fin de structure html. Il n’a plus la sensation qu’il attends pour que la page s’affiche, mais que le chargement de la structure et de la partie rédactionnelle est chargée instantanément. Seules les images et animation exécutées en javascript se chargent ensuite.

Ceci est bien sympathique, néanmoins c’est là qu’intervient le problème de l’inline script. L’inline script (ou script en ligne) est en fait tout appel javascript effectué dans le code directement (chose qui est super pas cool quand on écoute les élitistes branlette). Les fameux onclick, onblur avec des jolis javascript:mafonction() dedans. Ce type d’appel nécessite que les scripts contenant ces fonctions soient déjà chargés… par exemple dans le head. C’est un petit peu a l’opposé de l’optimisation que l’on compte faire juste au dessus.

Il faut donc avant de vouloir optimiser les téléchargements parallèles, s’assurer que notre code est compatible à ce genre de changement. Aujourd’hui, jQuery ou Mootools répondent à ces besoins en implémentant des méthodes permettant de binder des événements sur votre structure après le chargement complet de la page ou de la structure (onload / onDomReady). Système réellement agréable quand on a commencé à comprendre le fonctionnement.

Offrant la possibilité d’éradiquer la moindre ligne de script inline et optimisant également le code, ceci permet aussi au développeur de savoir que tous les appels javascript sont effectués uniquement dans les fichiers JS plutôt que d’aller courir à droite à gauche dans ses divers fichiers php, html ou template en s’auto-insultant…  Où ai-je bien pu foutre cette fonction à laquelle je dois rajouter un paramètre. Je ne remercierai jamais assez watt0 de m’avoir fait découvrir cette merveille.

Google a bien compris ce problème, mettant à jour Analytics il y a quelques temps pour une version asynchrone n’impactant aucunement l’utilisateur visitant le site… il reste toujours les régies publicitaires armées de codeurs roumains qui persistent à utiliser du code inline qui ralentit le moindre site profitant de leurs services. (qui est a vrai dire un des gros symptôme de Factornews aujourd’hui).

Conclusion : tout ceci nécessite une rigueur importante lors du développement, mais il est aujourd’hui primordial d’optimiser l’expérience du visiteur… faire du web ergonomique, bourré d’ajax et de petites animations implique des pages plus lourdes, s’il est possible pour vous de limiter les temps d’attente en laissant l’utilisateur profiter de votre contenu sera toujours bénéfique pour vos visites. Il ne faut pas perdre de vue qu’un utilisateur quittera votre site entre 7 à 10 secondes s’il n’a pas perçu une information l’intéressant dans ce laps de temps, si en plus ces 10 secondes sont allouées à charger un javascript…