Concours Webperf 2010 : les bases

Ce post est le premier d’une série de 3 et est tiré de l’expérience des finalistes du concours de performance Web 2010

Il traite rapidement des actions classiques en Performances Web qui sont les plus faciles à mettre en place tout en offrant un retour sur investissement souvent suffisant. Il devrait être utile aux novices mais ceux qui connaissent déjà les bases devraient aller voir les 2 articles suivants.
Lire la suite »

Concours Webperf 2010 : maîtriser le chargement

Ce post est le second d’une série de 3 et est tiré de l’expérience des finalistes du concours de performance Web 2010

Nous allons analyser les stratégies et techniques gagnantes (ou perdantes parfois) de chargement des dépendances de la page (CSS, JS, images, XHR). C’est là dessus que se sont concentrés les finalistes car il n’existe rien de suffisamment universel pour espérer gagner ce concours, nous avons donc assisté un joli combat de cerveaux.
Ce post sera utile pour les développeurs Web qui pourront être inspirés pour accélérer le rendu de leurs propres pages, et d’un intérêt tout particulier pour ceux qui connaissent déjà cette page.
Lire la suite »

Concours Webperf 2010 : refactoring et enseignements du concours

Ce post est le dernier d’une série de 3 et est tiré de l’expérience des finalistes du concours de performance Web 2010

Tout développeur Web sera content de voir que les bonnes pratiques de codage aident réellement les performances de rendu, en plus de leur intérêt propre. J’ai également résumé les enseignements que j’ai tiré de ce concours

Lire la suite »

Tester avec fiabilité ses navigateurs

Pour une fois, ce blog ne parlera pas d’HTML5, de javascript avancé ou de performances mais de bonnes pratiques. On reste toutefois dans la modernité du développement Web, car nous allons voir pourquoi j’estime que la plupart des développeurs Web et pire, des Web agencies sont sous-équipées lorsqu’il s’agit de tester ses navigateurs.

Je vous livre même la conclusion immédiatement : vous vous devez d’avoir des machines virtuelles pour avoir un environnement de test simplement normal et voici pourquoi.
Lire la suite »

Conférence Paris Web : HTML5 c’est maintenant (IE6 inclus)

J’ai eu l’honneur de présenter à Paris Web 2010 un thème que vous retrouvez souvent sur ce blog : les applications Web. Le titre exact était « HTML5 c’est maintenant (IE6 inclus) », ce qui est un clin d’oeil au grand écart que les développeurs Web font constamment entre les anciens navigateurs et les nouvelles fonctionnalités.

Il y a une vidéo et des slides de cette conférence. Mais si vous n’avez pas une heure de temps devant vous pour voir la vidéo, sachez qu’en préparant cette conférence je suis allé beaucoup plus loin dans les détails concernant HTML5 … avant de réaliser qu’une conférence n’est pas faite pour aller dans les détails mais pour faire passer un message.
Voici donc la version « director’s cut » de la présentation, où est écrit tout ce que j’ai du dire à l’oral mais supprimer des slides vus à Paris Web :

Lire la suite »

Passer son blog WordPress à la sémantique HTML5 et ARIA

HTML5 introduit de nouveaux éléments qui sont parfaits pour ajouter de la sémantique à un blog ou un journal. ARIA fait de même concernant l’accessibilité aussi étant donné la facilité permise par WordPress pour modifier son markup, il serait dommage de se priver, même si vous êtes un débutant WordPress comme moi. Nous allons donc voir :

  • l’utilisation des nouvelles balises <article>, <time>, <nav> ...
  • certains rôles ARIA
  • les améliorations des formulaires
  • les ajouts JS/CSS à apporter
  • les fichiers à modifier dans wordpress

Le tout bien sur compatible sur tous les navigateurs, IE6 inclus.

Même si vous n’êtes pas un utilisateur WordPress, les remarques sur la sémantique HTML5 et les rôles ARIA restent valables quel que soit le site.
Lire la suite »

bienvenue sur braincracking.org

Après 9 mois d’existence de jpv.typepad.com, il était temps de trouver un nom de domaine et une plate-forme correcte pour ce blog. Bienvenue donc sur ce nouveau nom de domaine, voici les améliorations :

  • un moteur de recherche et des tags pour parcourir les 145 revues de presse couvrant l’actualité du développement d’applications Web. Cela commençait à faire du contenu intéressant et au bout de quelques mois, je me suis rendu compte que j’utilisais beaucoup le moteur de recherche (de mon lecteur de RSS : thunderbird) pour retrouver d’anciens articles et tutoriaux, et que mes commentaires de l’époque m’aidaient en plus à retrouver rapidement la conclusion, en plus de mettre pas mal de sémantique. Si ça me sert dans mon travail quotidien, ça vous sera forcément utile aussi, et la version gratuite de typepad que j’utilisais ne permet pas de mettre un moteur de recherche
  • un système de commentaires plus facile : une centaine de commentaires ont également été migrés mais je trouvais que le système typepad de commentaires était très contraignant : j’en apprend beaucoup grâce à vos commentaires et vos points de vue, en plus de l’impression rassurante de ne pas être seul au monde :) Le système de commentaires plus engageant de WordPress devrait donc faciliter la communication.
  • d’autres auteurs ? le nom de domaine jpv.typepad.com n’encourageait pas vraiment à contribuer, car ça donnait l’impression de travailler pour moi. Hors ce blog n’est pas pour me promouvoir moi (je ne suis ni freelance ni en recherche de poste) mais pour remplir un vide : je ne connais pas d’autre revue de presse en français sur les thèmes que vous trouvez généralement ici : les features d’HTML5, un peu de CSS3, les performances Web et l’utilisation avancée de JavaScript. Je recherche donc d’autres commentateurs de l’actualité, ainsi que des articles originaux sur des points précis. Je recherche également quelqu’un qui pourrait traduire les articles en anglais, voir la revue de presse
  • customisons : le passage sur un hébergement normal, avec un wordpress qui est une plateforme impressionante de customisation va me permettre un peu plus de liberté dans le code des démos des articles, jusqu’ici hébergées sur jsfiddle.net. Et accessoirement je vais pouvoir un peu jouer avec CSS3, chose que je ne me permet pas au travail, tout en mettant de la sémantique HTML5 et de la performance sur ce blog

L’url du fil RSS officiel restera http://feeds.feedburner.com/braincracking, si vous aviez souscrit à http://jpv.typepad.com/blog/rss.xml, mettez à jour vos lecteurs RSS :)

inclusion performante de javascript, la mini-conférence

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.caDelicious,
Mail.