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 .:. Sites accessibles, un trou sans fond.

Jeudi 28 janvier 2010 à 14:37

En écho à un article plus ancien, je pensais récemment à l’incroyable fumisterie qu’est la validation WCAG ou l’accessibilité sur le web. Quelque soit le niveau choisit pour un site (a, aa ou aaa) le premier point qui me choque est que le client faisant cette demande est rarement prêt à payer le prix pour ce genre de fonctionnalité lorsqu’elle est devisée.

Bien sûr la parade simple est de l’intégrer au découpage… si bien que le coût de la validation devient transparent, mais bien sûr n’est pas couvert complétement. On ne pourrait pas se permettre de doubler le prix d’une intégration sans que cela paraisse étrange ou supérieur à ce que la concurrence propose.

L’autre constat est qu’en fin de compte, 80% des sites accessibles ne le sont pas vraiment : la première règle de l’accessibilité est d’être valide W3C sur le découpage… hors, de nombreux sites dits valides ne le sont déjà pas sur le code html comme celui ci, celui là ou encore ce dernier. Pourtant les clients ne cessent de se palucher sur les validateurs en nous remontant des erreurs html engendrées par le contenu qu’ils ont saisit eux même dans l’éditeur dont je parlais précédemment.

Côté technique, valider un site de mairie pour une accessibilité parfaite est juste un casse tête chinois. A l’heure où 99% des sites web sont inutilisables sans javascript. L’accessibilité nous impose de pouvoir naviguer sur un site de la même manière qu’un non-handicapé… tous scripts et autres joyeusetés technologiques désactivées ET en conservant un rendu quasi identique. Il va sans dire que c’est quasiment impossible. Dans le même temps, le client a demandé un maquettage du site avec des jolis sliders qui bougent dans tous les sens, des diaporamas… un grand panel de librairies uniquement fonctionnelles avec du javascript en somme. Si en plus on choisit la validation triple A, il faut faire passer la charte graphique par un validateur colorimétrique afin de couvrir les divers types de daltonismes.

Tout ceci semble toujours lointain malheureusement tant que l’on a pas vraiment été en relation avec des handicapés, c’est le problème des organismes publics généralement : on ne jure que par des normes établies par des organismes divers ou l’on court après son 5ème arobase… mais connaître la réelle implication d’une demande sur le produit final ou sa réelle utilité c’est autre chose.

J’ai rencontré il y a quelque temps deux personnes handicapées, et j’ai donc pu me rendre compte des réels besoins de ces gens. Et c’est là que l’on tombe de haut. Sur ces deux personnes, une a un handicap moteur qui ne lui permet pas de se servir de ses mains normalement et l’autre a un handicap moteur tout autre : elle est paralysée des jambes. Dans les deux cas, la validation WCAG telle qu’elle existe est quasiment inutile.

Pour la première, le point important de la validation provient des touches de raccourcis, sauf qu’avec des mains difficilement utilisables les raccourcis ALT+NUM sont une véritable torture… mais les scripts restent pourtant actifs. D’après ce que j’ai entendu dire, il existe des périphériques d’entrée dédiés a ce genre de handicap, mais très peu peuvent se les payer.

Quant à la seconde, ses jambes ne lui imposent pas de devoir désactiver le javascript : validation WCAG = useless.

Résumé des choses : la validation WCAG est une plaie pour les développeurs et le gain d’argent sur ce genre de fonctionnalité est ridicule sauf si l’on en fait son activité principale. Le second point touche les rédacteurs du site qui doivent être à même de pouvoir préserver une validation correcte du site, ce genre de personne est tellement rare du côté client qu’un site livré valide ne le sera bientôt plus. Pour finir, les normes officielles et les navigateurs actuels sont inadaptés à un handicap ne permettant pas de naviguer correctement.

La seule solution que j’ai envisagé mais qui implique un temps de développement supérieur serait de faire un miroir d’un site spécialement conçu pour les handicapés. Occultant tous les scripts js inutiles et offrant des couleurs neutres.

Mais combien de clients veulent payer le prix pour ce genre de chose ? Aucun… offrir un réel soutient pour les handicaps dans notre société, ça n’existe pas… malheureusement.

:: 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.