Brain Cracking

RPW 27/07/10: youtube et HTML5, faire son player video html5, chiffres Web Mobile français, historique de GMail

Revue de Presse Web de hier :

• Vidéo : Youtube propose son player "embedable" en version HTML5. Il s'agit d'une iFrame incluant une page comme celle-ci contenant le player et ses dépendances, le fallback Flash étant inclus au besoin. Même si le journaliste s'en étonne, car Youtube avait fait un rapport critique (résumé dans cette news) sur son expérience HTML5, il faut tout de même rappeler que cette critique est valable aujourd'hui, et ne le sera plus dans le futur (1 an ?), et que bien peu de sites ont la grille de critères de Youtube. D'autant que ce nouveau player est en phase d'expérimentations et est fait de manière à recevoir des feedbacks de la part des développeurs, une bonne manière donc de prévoir le futur. Ravi de voir cette confirmation que Google n'abandonne pas la partie.
• Vidéo : tutoriel pour construire soi même un player video HTML5, avec fallback Flash. Il manque la partie la plus compliquée qui est une API unifiée à l'un ou l'autre player et avec des skins similaires, mais le but avoué du tuto est de faire découvrir <video> et son API JS, à vous donc d'implémenter le reste. Ou de choisir parmi la pléthore de librairies "video HTML5" (si quelqu'un a un tableau comparatif des fonctionalités de ces librairies, je prends, j'en aurais besoin pour mon intervention Paris Web)
• Mobile : des chiffres français sur le Web Mobile. 30% des français ont un forfait Web Mobile. Il y a même 2 millions de comptes ouverts data uniquement (les "clés 3G" pour Netbook ou les Sim pour iPad, probablement une majorité de pros ?), et d'après les projections (qui valent ce qu'elles valent) cela donnerait une majorité de français utilisant le Web mobile d'ici à 2 ans. La bonne nouvelle pour les développeurs, c'est qu'ils peuvent compter sur la présence très forte de navigateurs modernes (utilisation de HTML5 et CSS3), la mauvaise est qu'il n'est pas aisé d'avoir un site à la fois desktop et mobile et que les conntraintes (taille d'écran, touchscreen ou pas, réseau rapide ou pas, utilisation nomade ou pas ...) se multiplient.
• Applications : l'histoire impressionnante du code de GMail. De 10 000 lignes de JS à son lancement en 2004, ils en sont aujourd'hui à 443 000 lignes (hors commentaires), mais cela inclue Buzz, les chats video et audio et la partie SMS et des fonctionalités disponibles dans le labs. Dès le début ils ont innové en créant des outils côté serveur pour vérifier et valider le code JS, ce qu'ils ont fait évolué ensuite en un compilateur qui ré-écrit le code, dont les outils Closure sont issus. Issu de cette conférence, il se dit un peu partout que JS a même remplacé Java côté serveur, mais ce n'est pas écrit dans les slides et je ne peux pas accéder à la vidéo pour confirmer ces rapports. Depuis le début ils maîtrisent la génération de JS en fonction des besoins client : spécialisation par langue, par vue, par type d'utilisation, ne délivrant ainsi que le code qui sera le plus probablement utilisé pour chaque type d'utilisateur, ce qui correspond à énormément de combinaisons possibles, en plus d'avoir un mécanisme de lazy-loading. Ils se sont mis un peu tardivement à l'orienté objet, ont inventé un langage de templating commun et performant entre java et JS et passent à HTML5 très rapidement avec l'offline et le drop de fichiers, ainsi qu'à CSS3. Bref, vu les contraintes, la manière de coder et la capacité de développement de l'équipe Gmail, je crois qu'il faut arretter de se comparer et de dire "comme gmail" :)

Articles et liens partagés via RSS, Twitter, Facebook (twitter + blog ou blog seul), identi.ca, Delicious, Mail .

RPW 26/07/10: tests unitaire AJAX, librairie WebSocket, imprimer des éléments HTML5 sous IE

Revue de Presse Web du WE :

• Perfs : 2 résumés de la soirée performances : l'un par Zeroload, l'autre par Johan Bleuzen qui a noté quelques points particuliers sur la technique du flush() telle qu'utilisée par Google, ainsi que d'autres détails de la présentation très dense de Stoyan (je suis à peu près sur qu'elle était inédite et qu'il a profité du niveau de la soirée pour se lacher un peu).
• Tests : outil jQuery permettant de compléter vos tests unitaires et d'intégration en simulant des retours de XHR (dites requête Ajax). Les tests unitaires coûtent très cher pendant la phase de développement (il faut ajouter 50% du temps de dev), mais ce temps est compensé par une baisse du coût de debug et une hausse de la qualité du service (et de la satisfaction des développeurs, ce qui n'a littéralement pas de prix). Si vous avez franchi le cap, vous avez probablement déjà un framework de tests unitaires, mais il ne comporte pas forcément de quoi simuler (mocker) les XHR. Si ce n'est pas le cas, il est intéressant de commencer par tester les couches les plus basses comme l'accès aux données, car c'est généralement la plus stable. Le retour sur investissement est donc bien meilleur et cet outil peut vous aider à démarrer.
• HTML5 : un fix pour IE, qui ne sait pas styler les éléments inconnus comme ceux de la nouvelle sémantique HTML5. Le fix est on ne peut plus bourrin puisqu'il consiste à remplacer les <article> et autre <nav> par des <div> au moment de l'impression ... Pas sur que cela marche donc avec toutes les feuilles de style, si il y a des règles qui ciblent ces éléments (ce qui d'après certains était une mauvaise idée du point de vue des performances ou de l'organisation du code).
• Websockets : Socket.IO est le genre de petite librairie que l'on aime car elle permet de s'affranchir des questions d'implémentation dans les browsers pour se concentrer le code de votre appli. Elle émule donc WebSocket sur les navigateurs ne le supportant pas (IE6-8, anciens FF) avec un fallback Flash et d'autres méthodes que je ne connaissais pas (ActiveX HTMLFile qui est l'équivalent d'une iframe scriptée mais qui évite l'indicateur de chargement d'IE). Le projet a l'air jeune mais très actif, par contre je ne l'ai pas testé et le manque de documentation est inquiétant (hormis les fonctions de base) : il est évident qu'utiliser le(s) fallback(s) long polling ou websocket ne se gère pas du tout de la même manière côté serveur, et rien n'est dit là dessus.
• Nawak : insultes de développeurs, style "Ta mère a oublié de faire un checksum à ta naissance" ou "Ta mère en Open source". Drole. Ou pas

Articles et liens partagés via RSS, Twitter, Facebook (twitter + blog ou blog seul), identi.ca, Delicious, Mail .

RPW 23/07/10: HTML5 et DIV, Node.js sur un multi-thread, introduction performances Web

Revue de Presse Web de vendredi dernier :

• HTML5 : article sur l'utilisation du tag <div> dans la sémantique HTML5. Dans mon implémentation de l'époque je n'avais pas très bien compris la différence entre <div> et <section>, la raison principale étant que je croyais que <section> ne voulait rien dire. Cet article rappelle donc que ce n'est pas le cas, que non seulement <div> fait toujours partie de la spec HTML5 mais qu'en plus il est recommandé de l'utiliser, notamment pour s'aider à styler la page ou à séparer des parties du markup de manière arbitraire. <section> s'utilise quant à lui autour d'un contenu de texte isolable suffisamment important ou signifiant pour contenir un titre (<hx>), et qui n'est pas un <article>, <nav> ou tout autre nouvel élément plus signifiant. Voir ce très pratique (et imprimable affichable dans le bureau) schéma de décision.
• Node.js : Yahoo! fait ses essais et les partage : la problématique de Yahoo! et des sites en général qui développent avec des langages server-side traditionnels comme PHP, c'est que pour tenir la charge, ils ont eu tendance à s'acheter des serveur multi-core. Dans ma boîte par exemple, on a très peu de puissance brute par process, mais on peut tenir énormément de threads en simultané. Hors un serveur Node.js ne tient que dans un seul thread, gérant en interne les concurrences, et du coup ne bénéficiant pas des serveurs multi-thread. Les solutions explorées par Yahoo! ici passent soit par un load-balancer, par un patch du kernel ou (probablement plus facile à déployer) d'un seul serveur Node.js pour router sur les autres instances Node, avec l'utilisation inattendue de Web Workers côté serveur.
• Perfs : bonne présentation générale autour des performances Web, ou la problématique (temps = argent, 90% de l'optimisation est côté client) et les premières solutions (gzip, réduire les requêtes HTTP ...) sont présentées à des non-experts performances Web, en 20 minutes seulement. Bien pour débuter ou faire ce genre de présentation en interne.
• HTML5 history : cette spécification permet de gérer l'url affichée et l'utilisation des boutons précédent/suivant des navigateurs, sans recharger la page, et est déjà supportée par les Webkit et FF4. Elle viendra en remplacement des hacks actuels, certes encapsulés, qui consistent à utiliser une iframe ou à gérer les états de l'application derrière le # de l'url (et donc à faire tourner un timer infini pour surveiller cette url). Il ne reste plus qu'à espérer que les librairies vont se mettre à jour pour l'utiliser, afin de continuer à l'utiliser uniformément sur tous les navigateurs.

Articles et liens partagés via RSS, Twitter, Facebook (twitter + blog ou blog seul), identi.ca, Delicious, Mail .

inclusion performante de javascript, la mini-conférence

ce site a migré : retrouvez cet article à jour sur braincracking.org

Pas de revue de presse ces 2 derniers jours car j'ai du préparer une mini conférence de 20 minutes et les sujets performances demandent énormément de recherches et de validation :)

Voici donc mes slides en ligne (PDF ici) de la soirée performance de hier, organisé par Eric Daspet et hébergé (et alcoolisé) par Octo. L'idée était d'explorer un point particulier des performances Web, le sujet traité ici étant l'inclusion non-obstrusive de JS. Il y a beaucoup de techniques plus ou moins exotiques, au final je vous ai épargné un listing savant que j'ai troqué contre un début de guide pratique d'implémentation. Je n'ai pas pu estimer de coûts de développement car les sites sont beaucoup trop différents.

Après un rappel des contre-performances des <script> dans le <head> (Voyages-sncf a des serveurs ultra performants qui délivrent du HTML en 200ms, mais la page reste blanche 2s), rappel des 3 techniques non bloquantes officielles :

• Inline : on n'y pense plus, et pourtant c'est celle qui demande le moins de modification de code. A utiliser pour les pages avec beaucoup de nouveaux visiteurs, sans trop de JS (jeux concours, les HP Google, facebook, Yahoo!, Netvibes ...)
• Bottom : déplacer le <script> du <head> à la fin de <body>. A partir de là les difficultés d'implémentation commencent car vous avez probablement du JS inline qui avait des dépendances dans le fichier que vous venez de déplacer. 2 hacks possibles alors, l'un mute+eval() que j'applique déjà, l'autre que je n'ai pas exploré qui consisterait à hijacker les fonctions qui seront appellées pour les exécuter plus tard. Si cela n'est pas possible, vous êtes bons pour modifier votre code inline, ce qui est en général le moment où le "projet performances" tombe à l'eau ...
• DOM : la meilleure mais la plus lourde à implémenter, qui consiste à créer dynamiquement des <script> et à y attacher un callback JS contenant le code dont il dépend. C'est la plus pérenne à mon sens car une fois passé le gros boulot consistant à fixer son JS inline (en général encapsuler le code dans une fonction de callback suffit), alors le code est extrêmement souple et résistera aux changements à venir : code JS qui grossit et se complexifie, découverte de nouvelles techniques ...

Les liens en raccourci dans les slides sont des références que je vous ai déjà partagé, mais vous trouverez aussi quelques références sur le comportement IE6-7 intéressantes si vous êtes plutôt côté R&D

On le voit, sur un site existant gagner plusieurs secondes (donc de l'argent) sur l'inclusion des JS est réalisable mais a un certain prix. Ceux qui sont avantagés sont ceux qui développaient déjà de manière non-obstrusive (HTML d'abord, puis CSS, puis JS) et qui organisent déjà bien leur code JS (une classe ou un ensemble de méthodes par fichiers par exemple).

Si vous n'arrivez pas à faire passer un projet d'un bloc malgré vos arguments financiers, passez au moins doucement votre code à la méthode DOM au fur et à mesure de la maintenance de votre site, tout évolution future sera moins pénible :)

Et avant cela, il vous faut implémenter des techniques tout aussi efficaces et moins chères, comme la compression gzip, la concaténation des CSS/JS et surtout la gestion du cache navigateur.

Articles et liens partagés via RSS, Twitter, Facebook (twitter + blog ou blog seul), identi.ca, Delicious, Mail.

RPW 19/07/10: savoir lire un graphique réseau, les fichiers complémentaires des sites, référence Canvas, astuce police

Revue de Presse Web de hier :

• Perfs : bonne vidéo sur comment lire un graphique réseau généré par webpagetest.org et httpwatch.
• Gestion : petit listing des fichiers invisibles mais utiles qui accompagnent les sites, et qu'on oublie souvent de maintenir, voir de faire au début d'un site. Il y a bien sur les favicon.ico et robots.txt qu'on ne présente plus, et qui vous éviteront d'avoir des logs plein de 404, mais aussi sitemap.xml qui pointe les moteurs de recherche sur certaines urls (généralement généré dynamiquement), Dublin.rdf qui permet de stocker des metadatas de votre site (ce qui évite de les mettre systématiquement dans le <head> de votre site) et enfin Opensearch.xml qui permet à un utilisateur d'ajouter votre moteur de recherche dans son browser (tutoriel ici par Alsacreations)
• Canvas : feuille de références qui liste sur une image les méthodes et propriétés Canvas. Toujours pratique pour imprimer et afficher dans son bureau, si vous en venez à commencer à utiliser Canvas en complément voire en remplacement de Flash.
• Fonts : astuce pour ceux qui hébergent leurs polices : Firefox inclut des restrictions de nom de domaine pour respecter les droits inhérents à certains formats de police. L'hébergement des fichiers statiques sur un autre nom de domaine (sans cookie) étant une amélioration de performance Web qui devrait se populariser, cela peut poser problème. La solution décrite ici est de modifier la configuration du serveur Apache pour que FF accepte de télécharger la police.
• Outils : excellent tutorial complet sur l'utilisation de Git, en remplacement de CVS ou SVN.
• Canvas : n'est pas toujours le meilleur choix même pour des applications très graphiques comme un jeu vidéo en 3D isométrique. J'avais déjà partagé avec vous cette conférence sur l'impressionante implémentation d'un moteur de jeu en JS. Le point le plus surprenant était que ces développeurs ont préfèré utiliser un DOM classique plutôt que Canvas. Ils s'en expliquent donc dans ce post : problèmes de performances avec les images, beaucoup de code pour recalculer certaines choses que le navigateur gère déjà très bien et impossibilité de copier des parties de HTML pour les injecter dans un Canvas. 

Articles et liens partagés via RSS, Twitter, Facebook (twitter + blog ou blog seul), identi.ca, Delicious, Mail .

RPW 17/07/10: tester le type en javascript, HTML5 version courte, tester le comportement navigateurs face au cache

Revue de Presse Web de ce WE :

• HTML5 : présentation vidéo ultra courte des nouveautés d'HTML5 (la vraie spec), pas inutile pour montrer rapidement les promesses d'HTML5. On y voit notamment de la sémantique avec des <section> dans des <article> (j'ai mis du temps à quoi servait <section>...) et comment s'utilise <figure> et <legend> pour ajouter une légende à une image. Après sont rapidement passés en revue localStorage, Canvas, audio / video et la communication entre frames.
• JavaScript : comment tester le type en JS. On se dit typeof est là pour ça, mais comme souvent en JS, ça n'est finalement pas très intuitif. Par exemple "(typeof 'chaine')' renvoie bien 'string', mais "(typeof new String('chaine')" renvoie 'object'. Vous me direz : pourquoi utiliser l'objet String ? D'abord vous ne maîtrisez pas forcément tout le code JS (des librairies peuvent l'utiliser), et ensuite il y a un micro gain de performance JS : les opérations sur un objet String() sont un poil plus rapides que les mêmes opérations sur une 'string', ce qui devient important dans certains cas extrêmes (un moteur de template pour moi). Pour être certain d'avoir un code bullet proof, il vaut donc mieux utiliser une méthode qui sait tester les types. L'auteur présente ici sa version, perso j'utilise YUI et je n'ai pas trouvé d'équivalent jQuery à part un isArray, mais vous connaissez surement jQuery mieux que moi ?
• Perfs : Petit script pour tester le comportement du cache des navigateurs en fonction des headers. Il vous permet de construire une page de test incluant JS, CSS ou images avec des temps d'attente et surtout des directives de cache. C'est moins pratique que Cuzillion, mais dans ce dernier les headers ne sont pas configurables, vous ne pouvez donc tester que les visites sans cache.

Articles et liens partagés via RSS, Twitter, Facebook (twitter + blog ou blog seul), identi.ca, Delicious, Mail .

RPW 16/07/10: poids des pages, moteur de jeux en JS, convention de codage JavaScript, intersection de tableau javascript

Revue de Presse Web de hier :

• Perfs : les pages web sont de plus en plus lourdes, c'est un constat que l'on se fait depuis l'avènement de l'ADSL pour tous en France mais à quel point cela est il grave ? Le markup d'un site populaire comme CDiscount fait 172Ko (normal, tout est à base de <table> ...), mais il ne fait plus que 31Ko une fois gzippé : il est généré et reçu en moins d'une demie seconde, ils ne voient sans doute pas l'intérêt de changer. Et pourtant si l'on ajoute les 15% d'utilisateur à qui l'on ne sert pas Gzip (voir ce PDF) aux utilisateurs sans ADSL (5%) ou sur réseau mobile, on peut se dire que le poids de la page est toujours important, même en France pays du haut débit.
• JavaScript : un code très optimisé pour obtenir l'intersection de 2 tableaux. Des solutions JS génériques comme Taffy DB ou JSLINQ permettent de manipuler sans difficulté des tableaux, mais lorsqu'arrivent des problèmes de performances, ces librairies ont rarement été optimisées. L'auteur présente donc ici un algorithme qui est beaucoup plus efficace sur les grands ensembles. Etant donné les licences et la vitesse à laquelle ces librairies évoluent, cela vaut peut être mieux d'utiliser un wrapper pour pouvoir changer facilement de code et avoir le mieux optimisé pour vos besoins.
• JavaScript : convention de codage en JavaScript, par Google. Sans le savoir et à force d'erreurs je respecte déjà les ³/₄ de ces conventions, qui deviennent logiques dès que ce que l'on code dépasse le stade du scripting ou que la taille de l'équipe dépasse 1. Les règles sont très diverses et vont de la documentation au format JavaDoc (la même que pour PHP, facile) à l'utilisation d'eval() en passant par les conventions de nommage (majuscules pour les constante, camelCase pour les fonctions ...). Et cela évite également les débats sans fin sur l'utilisation de ' ou " pour les chaînes de caractères ou la position des {} : il n'y a parfois pas de gagnant, il faut juste trancher. Même si certaines de ces règles sont orientées pour faire passer son JS au Google Closure Compiler, la formalisation de ces règles dans votre équipe vous assurera quoi qu'il en soit une maintenance plus aisée.
• JS : conférence sur un moteur de jeu en JS. Il s'agit du moteur Aves, dont voici une bonne démo. Ca prend 45mn en anglais, voici donc quelques notes :
  • Canvas n'est pas assez efficace => utilisation directe de .innerHTML
  • jquery est utilisable pour sa gestion de la souris et son modèle évènementiel
  • 2D et 3D isométrique seulement, WebGL est très loin
  • Flash éliminé pour manque d'interopérabilité
  • utilisation de la génération de classes plutôt que de générer des styles inlines sur chaque élément
  • l'industrie du jeux peut se permettre d'attendre HTML5, CSS3 et l'accélération matérielle, car ils savent qu'ils vont passer 1-2 ans sur un jeu
  • 3 listeners pour tout le document ! pour gérer les zones non carrées, ils voulaient gérer une carte de pixels en JS, et finalement ils ont utilisé Canvas pour analyser les images et savoir si la zone cliquée était transparente ou pas !
  • l'avantage de réutiliser JS au frontend comme au backend est que des portions de code sont réutilisables, pour calculer les positionnements par exemple
  • JS au backend est presque aussi rapide que C, utilisation de EcmaScript 5
  • mais Node est tout neuf
  • le code backend event-driven, jamais bloqué est idéal pour des MMO
  L'intérêt d'étudier cette utilisation extrême de JS est que c'est une vraie implémentation professionelle de toutes les techniques HTML5, CSS3 et Node.js. Même si leur vision se situe à 2 ans d'ici, cela préfigure ce qu'il sera possible d'ici là.

Articles et liens partagés via RSS, Twitter, Facebook (twitter + blog ou blog seul), identi.ca, Delicious, Mail .

RPW 15/07/10: paris Web 2010 j'y serais, CSS3 pour IE, Youtube application mobile, remplacer ses icônes par du texte, détecter la langue de l'utilisateur

Rattrapage de la revue de presse Web de cette semaine :

• Evènement : le programme de Paris Web 2010 est sorti. Très riche avec 38 orateurs, organisée par des passionés, les éditions précédentes ont toujours été d'une très grande qualité, malgré un tout petit prix (250 ou 340, avec les repas). Pour vous donner une idée du succès : un tiers des places a déjà été vendu alors que le programme n'était pas connu (estimation perso en prenant ce chiffre et celui ci), dépêchez vous donc pour passer commande. Cette année étant visiblement l'année de mon coming-out (je blog, je tweete, je commente partout, je fais une mini conf sur les performances bientôt), je me jette dans l'arène : j'y ferais une conférence (passer à HTML5 sans oublier IE6) et j'animerais un atelier sur les performances Web. Qui y sera ?
• CSS3 : un script permettant d'appliquer certaines propriétés CSS3 sur les IE6-8. Cela ne concerne que celles qui ont un filter correspondant : coins arrondis, fond en dégradé et ombre portée (il manque l'opacité bizarrement). Attention toutefois car la solution est à base de .htc (une techno MS permettant de modifier le comportement du navigateur), ce qui peut être catastrophique pour les performances : il faut imaginer qu'un petit process est lancé à chaque fois que le style est exécuté. Solution à réserver à l'écriture rapide de petite pages, sinon je vous redonne cet excellent article qui liste les équivalences filter / CSS3 avec en particulier leurs limites (via @goetter)
• Intl : détecter la locale (langue + variante de pays) de votre utilisateur côté serveur. Il faut juste savoir quelle variable regarder ($_SERVER['HTTP_ACCEPT_LANGUAGE']) et ce développeur vous donne en plus son code pour l'analyser. A ma connaissance tous les navigateurs modernes envoient ce header, mais au cas où prévoyez un fallback (en-EN par exemple)
• Perfs : remplacer certaines icônes par du texte ! Sur cette page de démo, vous pouvez voir des symboles qui sont déjà inclus sur la plupart des OS. Remplacer ces icônes faites avec des images par du texte présente des avantages de performances (moins de poids dans vos sprites ou moins de requêtes HTTP) et de maintenance (moins d'images à gérer, taille et couleur variables en CSS). Par contre l'auteur a oublié de préciser (il n'a visiblement qu'un Mac et un Vista) c'est que sous XP, beaucoup de ces symboles n'existent pas : même si il reste au moins des flèches (→, ») les très utiles ✓, ✗ ou ✎ qui sont des icônes courament utilisés n'existent pas.
• HTML5 : youtube se lance en version Application Web Mobile. Le site est clairement destiné à reprendre la main sur l'application youtube de l'iPhone, car tout le communiqué de presse parle de ce qu'elle apporte en plus de cette version, mais elle est bien sur compatible tout smartphone (récent). Je suis impatient de voir combien d'utilisateurs vont "installer" cette appli ou du moins l'utiliser en lieu et place de la native. Est ce wx l'interopératibilité et les features additionnelles possibles grâce à la nature "toujours à jour" du Web suffiront pour que cette appli soit un succès ?

Articles et liens partagés via RSS, Twitter, Facebook (twitter + blog ou blog seul), identi.ca, Delicious, Mail .

RPW 14/07/10: que supporte les mobiles, bénéfices de la performance Web, implémentation de la balise , inclure son JS de manière non obstrusive

Désolé pour le manque de revue de presse de ces derniers jours, mais une petite surcharge de taf s'est imposée à moi. La revue a pu continuer sur Twitter mais je n'ai pas eu le temps de la commenter. Rattrapage :

• Mobile : tableau comparatif du comportement des navigateurs mobiles (modernes), sur des éléments aussi variés que le support CSS3, l'API Selector, l'interprétation de la spec ECmascript, la sécurité et surtout l'utilisation du réseau : nombre de JS en parallèle, nombre de téléchargement en parallèle par nom de domaine... Bref, cela vous sera utile en particulier concernant les performances réseau qui sont encore plus essentielles sur mobiles que sur desktop.
• Perfs : résumé graphique et données chiffrées issues de la conférence Velocity sur la performance Web. Des chiffres toujours utiles à glaner pour estimer ce que vous rapporterait une amélioration de la performance. On y apprend par exemple qu'un temps de chargement de 3s augmente de 50% le temps de rebond, et baisse de 25% le nombre de pages vues, par rapport à la même page se chargeant en 1s.
• Audio : implémentation et tutoriel de la balise <audio> , avec fallback Flash. Comme sa cousine <video>, le support de la balise elle même n'est bien sur pas assuré chez les IE, et il n'y a pas non plus d'entente sur le format à utiliser (FF refuse de lire les fichiers MP3). Bref l'intérêt du tuto est d'utiliser la librairie jPlayer qui utilise un fallback Flash, par contre ils suggèrent d'encoder en MP3 et en OGG les fichiers audios, sans préciser si la librairie est suffisamment intelligente pour servir à FF la version Flash dans le cas où l'on n'utilise que la version MP3 par exemple. A tester donc.
• Perfs : inclure son JS de manière non-obstrusive, tout en préservant l'ordre d'inclusion des scripts et en faisant marcher les scripts inline. C'est un peu le Graal du moment dans le monde des performances Web. Ici l'implémentation utilise la librairie labJS (inclusion synchrone ou non de fichiers JS) et un trick JS façon Analytics pour les scripts inline, qui consiste à stocker dans un tableau le code JS à exécuter une fois que toutes les dépendances sont là. C'est plus propre que ma solution mute + eval, mais ça demande à modifier le JS inline. Et encore une fois document.write() n'est pas géré.

Articles et liens partagés via RSS, Twitter, Facebook (twitter + blog ou blog seul), identi.ca, Delicious, Mail .

RPW 07/07/10: étude de cas performances Mappy, Firefox 4b1, déclaration de fonctions en JS, tester simplement et automatiquement son interface

Revue de Presse Web de hier :

• Browser War : Firefox 4 beta 1 est de sortie, avec un énorme paquet d'améliorations que les webdevs attendaient. Je ne les liste pas ici, Mozilla l'a déjà très bien fait. Comme pour IE9, je recommande d'au moins vous l'installer sur une machine virtuelle pour tester votre site car le parser HTML a changé et les formulaires HTML5 sont (partiellement) supportés. Ne remplacez pas votre FF de travail, la plupart des addons dont firebug ne marchent pas. Update : la version alpha de Firebug marcherait avec cette beta
• JS : il y 2 manières de déclarer une fonction en JS et je n'avais jamais compris la différence, mais elle est piégeuse car elle touche au scope. Par expression ( var theExpressionWay = function() ) ou de manière déclarative ( function theDeclarativeWay() ). Je n'utilise pratiquement plus cette dernière car elle ne permet pas de gérer la portée de la fonction : elle se met directement dans le namespace global (window.), ce qui peut provoquer des conflits. Mais ce que je ne savais pas, c'est la fonction est déclarée quoi qu'il arrive, même si séquentiellement le parser n'est pas censé arriver jusqu'à la déclaration.
• Qualité : un outil OSX (fakeapp) pour automatiser des actions sur un site. De manière très visuelle il permet de programmer une navigation, à priori même sur des interfaces compliquées dépendant lourdement de JS, et de tester certaines valeurs. Utile pendant le développement ou avant de passer en production pour vérifier que l'on n'a rien cassé (login, signup, actions principales ou secondaires rarement testées ...). Sur le principe il se met en concurrence avec Selenium, en pratique Selenium est bien plus complet (plusieurs browsers, ne bloque pas le développeur, stockage des rapports sur serveur ...), et donc beaucoup plus lourd à mettre en place. A vous de voir si vous voulez doucement mettre le pied dans les tests automatisés avec une interface sympa ou passer directement au standard de facto. Par contre FakeApp est actuellement gratuit car en beta et finira payant.
• Perfs : Etude de cas d'optimisation sur Mappy.com. La principale méthode, hormis le nettoyage de code qui n'a pas apporté grand chose et la concaténation, a consisté à maîtriser l'ordre d'affichage des zones importantes (le formulaire et la carte) pour les faire afficher en premier, et donc jouer sur la perception plutôt que sur les temps de chargement total. Le logiciel WebPageTest est un outil à utiliser pour avoir un développé dans le temps du rendering d'une page, et il émule en plus différentes vitesses de connexion. Les commentaires valent aussi le coup d'être lus, ils sont un bon complément à l'article.

Articles et liens partagés via RSS, Twitter, Facebook (twitter + blog ou blog seul), identi.ca, Delicious, Mail .