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 .:. mailto et base64

Mardi 3 mars 2009 à 13:48

Le mailto, quelle magnifique invention du net. Malheureusement, c’est un “exploit” utilisé par les bots de spam pour recolter des adresse email. Du coup, j’ai cherché plusieurs solutions pour parer à ce problème. J’ai trouvé quelques JS sur le net, mais le fait est qu’il fallait découper le mail en plusieurs parties pour éviter que ces fameux bots retrouvent l’adresse dans le corps.

Hors en php, mon but est d’afficher l’email directement… du coup j’ai pensé à une conversion en base64, ça pourra servir probablement a quelques un d’entre vous.

Tout d’abord j’ai récupéré un joli js sur le net qui encode et decode le Base64.

&lt;!--

// This code was written by Tyler Akins and has been placed in the
// public domain.  It would be nice if you left this header intact.
// Base64 code from Tyler Akins -- http://rumkin.com

var keyStr = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=";

function encode64(input) {
var output = "";
var chr1, chr2, chr3;
var enc1, enc2, enc3, enc4;
var i = 0;

do {
chr1 = input.charCodeAt(i++);
chr2 = input.charCodeAt(i++);
chr3 = input.charCodeAt(i++);

enc1 = chr1 &gt;&gt; 2;
enc2 = ((chr1 &amp; 3) &lt;&lt; 4) | (chr2 &gt;&gt; 4);
enc3 = ((chr2 &amp; 15) &lt;&lt; 2) | (chr3 &gt;&gt; 6);
enc4 = chr3 &amp; 63;

if (isNaN(chr2)) {
enc3 = enc4 = 64;
} else if (isNaN(chr3)) {
enc4 = 64;
}

output = output + keyStr.charAt(enc1) + keyStr.charAt(enc2) +
keyStr.charAt(enc3) + keyStr.charAt(enc4);
} while (i &lt; input.length);

return output;
}

function decode64(input) {
var output = "";
var chr1, chr2, chr3;
var enc1, enc2, enc3, enc4;
var i = 0;

// remove all characters that are not A-Z, a-z, 0-9, +, /, or =
input = input.replace(/[^A-Za-z0-9\+\/\=]/g, "");

do {
enc1 = keyStr.indexOf(input.charAt(i++));
enc2 = keyStr.indexOf(input.charAt(i++));
enc3 = keyStr.indexOf(input.charAt(i++));
enc4 = keyStr.indexOf(input.charAt(i++));

chr1 = (enc1 &lt;&lt; 2) | (enc2 &gt;&gt; 4);
chr2 = ((enc2 &amp; 15) &lt;&lt; 4) | (enc3 &gt;&gt; 2);
chr3 = ((enc3 &amp; 3) &lt;&lt; 6) | enc4;

output = output + String.fromCharCode(chr1);

if (enc3 != 64) {
output = output + String.fromCharCode(chr2);
}
if (enc4 != 64) {
output = output + String.fromCharCode(chr3);
}
} while (i &lt; input.length);

return output;
}

Puis tout simplement, j’ai créé la fonction suivante :


function showEmail(string) {
var codedmail = decode64(string);
document.write('&lt;a href="mailto:'+codedmail+'"&gt;'+codedmail+'&lt;/a&gt;');
}

Une fois ce pavé écrit, il vous suffit d’appeler la fonction comme ceci :


&lt;script type="text/javascript"&gt;showEmail('bWFjaGluQHRydWMuY29t');&lt;/script&gt;

Seul point noir au tableau, il faut le javascript activé. Mais l’intérêt est que par exemple, pour une liste de mail, il n’y a aucunement besoin d’encoder les informations en base. Il suffit juste de ressortir le champ en clair, de passer la fonction base64_encode(); dans la zone du script… et ce, en ne laissant aucune trace d’un quelconque mail, @ ou machin [at at at] truc [dot] com.

A priori, c’est la meilleur technique que j’ai trouvé à l’heure actuelle sans avoir a passer par un formulaire.