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…

:: DEV .:. Compatibilité HTML ou IE cette merde… Episode #1

Jeudi 8 octobre 2009 à 19:10

Introduction

Bien que je sois toujours aussi occupé, cela faisait un moment que j’avais envie de continuer mes bafouilles sur le développement web. Et depuis un plus long moment, il me tenait à coeur de partager les astuces que j’utilise depuis plusieurs années pour réaliser des intégrations de sites compatibles tous navigateurs. Enfin… tous, IE6 et supérieur, Firefox et Safari.

On sait tous que Microsoft a un poil dans la main pour ce qui est de faire de Trident un moteur de rendu aussi excellent que Gecko, Presto, ou en fait, n’importe quel autre moteur de rendu autre que celui de l’ex-firme à Bilou. Le poil dans la main s’est étendu à l’arrivée de IE8 au regret de tous les développeurs, un article est même paru sur le MSDN en septembre dernier afin de légitimer le choix de ne pas avoir inclus la gestion de “border-radius”, en expliquant que sur le web il y a de toute façon des tonnes de solutions pour y parvenir sans. Bref, nous voilà encore à attendre IE9 pour la suite des aventures.

Lire le reste de cet article »

:: DEV .:. Validation W3C, découpage et compatibilité : le paradoxe du web.

Lundi 6 juillet 2009 à 17:49

Le développement en web, c’est une histoire d’amour… histoire conclue entre toi, moi, vous, développeurs et intégrateurs du web et un navigateur web. Le problème, c’est que cette histoire n’est pas très “européenne”, et que si l’on veut bien faire les choses et contenter notre partenaire, on devient très vite polygame.

Sur ces douces métaphores représentant le combat acharné que l’on vit tous les jours afin de rendre compatible une application web sur tous types de navigateur, vient se greffer l’intégrisme du web : le W3C, les normes HTML et XHTML. Beaucoup d’entre nous lisent des articles sur les techniques de découpage, font de la veille et observent les techniques des concurrents… tentant de se tenir a jour, de s’adapter tant bien que mal.

Pour en venir aux faits, suite à une nouvelle fonctionnalité que j’ai intégré sur un site de vente en ligne récemment, je repensais au calme à tous ces intégristes qui ne jurent que par les nouvelles techniques de découpage. Le div, les floats, les positionnements absolus qui ont remplacé les tables. Ces gens là bien que je respecte à la lettre ces normes pour obtenir le moins d’erreurs possibles, ne doivent vraiment pas intégrer plus de deux heures par ans.

Depuis le temps que je bosse dans le domaine, c’est un fait, plus de 50% du temps passé sur l’intégration d’une maquette web est lié à la compatibilité inter-navigateurs. Et malgré tous mes efforts, développer intégralement avec les nouvelles techniques et être compatible pour IE 6 ainsi que tous les navigateurs dernières génération (de IE7 à Firefox 3) relève de l’impossible. Surtout qu’il est aujourd’hui hors de question de se séparer d’IE6 qui est encore une norme en entreprise, et représentait encore 22% de part de marché en Juin 2008. Un simple exemple : Le position en absolu de div dans une colonne flottante.

Il y a une forte probabilité que sur IE6, le rendu soit éronné et que le div en question ne se positionne pas correctement. De surcroit, ce problème étant lié au fameux hasLayout, il se peut qu’aucun trigger ne puisse corriger le soucis (inline-block, zoom, rien n’y fait). Je passe sur le fait que si on ajoute à ceci un contenu en overflow pour obtenir un ascenseur vertical ou horizontal toujours sur ce div, les résultats sont encore plus étonnants.

Au final, pour respecter les temps de développement et éviter de déborder de trop sur le planning, on se rabat très souvent sur le bon vieux layout composé de tables.

La question ultime est donc la suivante : doit-on sacrifier 20% de part de marché en ne validant les sites qu’à partir de IE7 ? Est-ce que les intégristes du web rédigent des normes et standards qui peuvent être réellement appliqués dans un workflow d’entreprise où la vitesse et la productivité sont primordiales ?

Ma réponse, après y avoir réfléchit à plusieurs reprises : les standards, je les respecte dans la mesure du possible. Mes découpages sont toujours validés XHTML Transitionnel, mais j’essaie de réduire les erreurs potentielles en utilisant des techniques que l’on pourrait qualifier d’ancéstrales aujourd’hui. Surtout parceque je dois respecter des délais, mais aussi parceque les nerfs sont mis à rude épreuve si on tente d’appliquer des normes modernes aux navigateurs d’antan.

Le jour où les développeurs de navigateurs sauront se donner la main pour créer des moteurs de rendus qui seront tous d’accord sur la manière d’fficher un div flottant ou positionné en absolu ; déjà nous aurons fait un grand pas… et peut être qu’à ce moment là, je pourrais enfin ranger mes tables.