Nous allons non seulement répondre à ces deux questions, mais en plus nous apercevoir qu’il y a une question plus pertinente à se poser.

Pourquoi et comment calibrer ses test ?

Les solutions de monitoring du marché testent les pages généralement sans vous dire avec quel navigateur (probablement des Webkit headless, pour accélérer les tests), et le font depuis des datacenters qui sont beaucoup trop proches des nœuds principaux du Web. Potentiellement, les sondes sont exécutées à partir de machines hébergées physiquement dans le même datacenter que votre hébergeur ou avec un peering privilégié avec le CDN.

Autant dire que les tests standard ne sont pas représentatifs de ce qu’endurent vos utilisateurs et c’est la raison pour laquelle on limite volontairement débit et latence, par exemple sur l’indispensable WebPageTest ou chez certaines solutions payantes. WebPageTest a le mérite d’être transparent car vous avez une liste de connexions pré-paramétrées cependant nous allons voir qu’elles ne représentent pas du tout la France.

Paramètres par défaut de WebPageTest.org

Côté transit réseau, il y a essentiellement 4 données qui influencent l’affichage d’un site :

• la latence ou ping, qui est le temps d’un aller / retour entre un navigateur et le serveur qui lui répond. Pour le site moyen, en HTTP 1.1, basé sur TCP, c’est la mesure la plus importante. C’est aussi la plus difficile à obtenir.
• le download ou bande passante descendante, qui reste importante pour récupérer de gros objets. On nous vend des ADSL à plus de 20Mb/s (1, 2, 3 et des mobiles à 5Mb/s, qu’en est il vraiment ?
• l’upload qui est rarement pertinent dans la webperf.
• la perte de paquets : pratiquement inexistante sur des connexion filaires, mais omniprésent sur mobile. Là par contre impossible de trouver des chiffres, en supposant qu’ils signifient quelque chose

Idéalement, il faudrait récupérer ces métriques de vos propres utilisateurs, grâce à du Real User Monitoring (RUM), mais la mise en œuvre est moins aisée que de récupérer les informations de sources externes, telle que nous allons le faire ici.

Si vous êtes pressé ou si vous me faîtes aveuglément confiance (et je vous comprends), vous pouvez sauter directement à « En résumé »

à la pêche aux chiffres

En cherchant dans mes archives et sur Google, je me suis rendu compte qu’il existait très peu de rapports rendus publics. J’en liste ici 6 en extrayant des données brutes. N’hésitez pas à m’en indiquer d’autres ou à décortiquer plus avant les sources.

Etude Akamai / Pingdom de 2010

Akamai est le leader mondial des CDNs, autant dire qu’ils voient passer du traffic et ont une bonne idée de ce qui se fait à l’échelle mondiale. L’étude de cette année là comprend la répartition des débits en France.

• Débit moyen : 3,3 Mb/s
• Répartition :
  • 25 % moins de 2 Mb/s
  • 60 % entre 2 et 5 Mb/s
  • 15 % plus de 5 Mb/s

Akamai 2012

Chiffres plus récents, mais dont l’échelle de répartition a changé.

• Débit moyen : 4,6Mb/s
• Débit moyen des réseaux mobiles : 2,8Mb/s
• Répartition :
  • 0,1% moins de 256Kb/s
  • 45% plus de 4Mb/s
  • 4% plus de 10Mb/s

DegroupTest, 2012 et 2011

La population des utilisateurs de Degrouptest est probablement biaisée, car on a affaire à des gens qui au minimum s’inquiètent de leur débit. Ce qui exclut ma mère et probablement la votre. Mais ils ont l’avantage de mesurer le ping, et d’isoler les extrêmes comme la fibre, le mobile et l’outre-Mer.

• Débit moyen : 8,27 Mb/s (5,4Mb/s hors fibre )
• Débit moyen des réseaux mobiles : 2.5Mbps (chiffres 2011)
• Ping moyen : 80ms (86ms hors fibre)
• Ping moyen réseaux mobiles : 200ms
• Débit montant moyen : 1,3 Mb/s ( 641Kbp/s hors fibre)
• Répartition :
  • 13% à 27Mb/s de débit moyen
  • 87% à 5,4Mb/s
• à noter :
  • Meilleur latence possible : Fibre Orange avec 19ms. Les opérateurs ADSL se situent entre 70ms (Free) et 100ms (SFR)
  • 1s-1.5s de latence sur satellite
  • 270ms de latence depuis l’outre-mer, 3Mbps de débit moyen

A noter que le débit et la latence moyenne ont baissé entre 2011 et 2012. J’imagine que leur public a du s’élargir à des zones moins bien couvertes.

60 millions de consommateurs, 2012

Leur testeur de débit a tourné pendant 1 an en 2011 et leur public est probablement plus proche du français moyen que DegroupTest. En plus on y quantifie les variations périodiques de débit.

• Débit moyen : 5.6Mb/s
• Répartition :
  • 11.8% moins de 1Mb/s
  • 12.8% de 1 à 2Mb/s
  • 31,8% de 2 à 5Mb/s
  • 30% de 5 à 10Mb/s
  • 12% plus de 10Mb/s
• A noter :
  • -20% de débit à 21h
  • -10% le dimanche

Etude ARCEP

De cette étude sur les chiffres d’affaire des FAI et opérateurs mobile, j’ai extrait les volumes de population pour confirmer ou requalifier les chiffres des autres :

• 22 millions d’abonnements ADSL et fibre
• 0,6 million d’abonnement fibre / cable
• 0,3 million abonnés RTC
• 32 millions d’abonnés mobile « data »
• +80% de volume de data mobile par an

Statistiques Cedexis

Les statistiques de “l’aiguilleur du net” mesurent le temps d’aller-retour moyen entre un utilisateur de FAI et un CDN afin de choisir le meilleur. Les valeurs de latence y sont plus hautes qu’ailleurs car les CDN ne font pas que servir des fichiers statiques, il y a beaucoup d’intelligence lorsqu’une requête arrive chez eux. Je les prends car elles donnent une bonne idée de la vitesse avec laquelle les fichiers arrivent chez l’internaute qui visite des sites utilisant les CDN.

• 118 ms de latence pour des fichiers hébergés sur Akamai (leader)
• 134 ms de latence pour des fichiers sur Amazon EC2 Europe

Après les chiffres bruts, passons à l’analyse.

Quelle analyse ?

Il faut bien se dire que l’on compare des études avec des buts différents : mesurer l’efficacité des CDNs, des FAI ou avoir un vision plus globale oriente les méthodologies. C’est pour cela que j’explicite ma réfléxion, pour que vous utilisiez les commentaires pour critiquer ma tentative de compréhension.

Le débit moyen

Les statistiques d’abonnement de l’ARCEP montrent 2,7% d’abonnés fibres par rapport au nombre total d’abonnement, alors que Degrouptest reçoit 13% de ses mesures depuis la fibre. Nous pouvons donc requalifier le débit moyen de Degrouptest : 5,01Mb/s (97,3 % * 5,4 Mb/s + 2,7 % * 27,3 Mb/s = 5,01 Mb/s).
Cette nouvelle moyenne se situe entre celle d’Akamai pour la France (4,6 Mb/s), et celle de 60 millions de consommateurs (5,6 Mb/s). Akamai ne détaille pas sa méthode mais on suppose qu’elle est plus représentative, car non volontaire. Elle ne mesure cependant que la connexion entre Akamai et un internaute et Cedexis nous indique qu’Akamai n’est pas le plus performant. Il faudrait donc légèrement remonter ce chiffre. D’un autre côté, 60 millions de consommateurs a fait son étude en 2011, et entre-temps DegroupTest semble indiquer une baisse de débit ADSL de 600 Ko/s. Il faudrait donc revoir leur moyenne à la baisse. Les chiffres convergent vers la valeur DegroupTest, que j’estime légèrement surestimée (population trop “aware”).

Pour arrondir, on peut donc situer un débit moyen à 4,8Mb/s sur ligne fixe. Concernant le débit mobile moyen, Akamai et Degrouptest ont à 30Kb/s près la même moyenne, on peut l’arrondir à fixer à 2,5Mb/s.

La latence

On applique la correction des stats ARCEP sur les stats DegroupTest et on obtient cette valeur arrondie : 85ms. Cependant en regardant les données Cedexis, on voit des temps de réponse bien supérieurs, de 110ms par exemple pour récupérer un statique sur un CDN populaire comme Akamai. Cela est assez cohérent avec le fait qu’un CDN rajoute forcément un peu de latence (temps de routage supplémentaire, mise en cache, etc.) et que la population Degrouptest est surement un peu moins représentative que celle mesurée par Cedexis.

Concernant le ping sur mobile, on manque cruellement de données, la seule qu’on ait trouvé pour la France est celle de Degrouptest de 200ms. Dans des études bien moins larges dans d’autres pays, les chiffres varient de 200ms à 300ms.

Pour la latence, nous nous fixons donc une moyenne arrondie de 95ms sur ligne fixe et 200ms sur mobile.

Le cas du mobile

Donc le débit moyen sur réseau mobile (2,5Mb/s) est plus élevé que 25% des ADSL de France. La latence est tout de même deux à trois fois plus élevée. Mais même en calibrant vos tests avec ces données et en supposant que vous les exécutiez depuis un vrai mobile, vous réalisez vite que quelque chose cloche : le ressenti utilisateur n’est pas du tout le même. En fait il manque une dernière composante, assez rare en ADSL : la perte de paquets TCP. Constamment les connexions ouvertes entre votre téléphone et l’antenne relai sont interrompues par des obstacles physiques, électro-magnétiques ou un changement d’antenne. Je n’ai pas trouvé d’étude avec un taux moyen de perte de paquet, aussi c’est un peu au pifomètre que j’utilise la valeur 25%. à débattre.
Il manque également le côté aléatoire de la connexion qui fait tout le charme des réseaux mobiles : parfois vous téléchargez une image en une demie seconde, parfois vous n’arrivez pas à avoir un octet pendant plusieurs minutes.
Exécutez régulièrement les applications speedtest ou Degroupest (iOS, Android) pour halluciner sur la variabilité des caractéristiques réseau.

Test débit mobile

Sur quelques tests ci-dessus, sur 2 tests effectués à moins d’une minute d’intervalle et sans bouger, vous pouvez voir une différence de latence de 1 à 4. Vous pouvez également voir des tests qui vont de 14Kb/s à 9Mb/s, sans compter ceux qui n’aboutissent pas.

Mais non seulement il n’existe pas d’étude sur les trous réseau (en supposant qu’une telle étude puisse être représentative), mais en plus nous ne voulons pas introduire d’aléa dans le cadre du monitoring, ou alors comment savoir si une alerte en est vraiment une ? Nous devons malheureusement choisir des mesures dégradées mais fixes.

En résumé

Il n’y a pas de connexion type

Mon prof de stats me tirerait les oreilles si on s’arrêtait là. En effet une moyenne seule est à peu près inutile sans l’écart-type qui permet de juger de la représentativité de cette moyenne. En fait une moyenne est certes pratique à manipuler, et il est utile de surveiller son évolution, mais elle est particulièrement trompeuse si la répartition des mesures n’est pas concentrée autour de la moyenne.
Et justement les études d’Akamai, de l’ARCEP et de 60 millions de consommateurs montrent qu’il y a de fortes disparités dans l’équipement des utilisateurs.

• L’ARCEP nous dit qu’il reste 1,4% de gens en RTC (56Kb/s), soit à l’échelle de la France 300 000 personnes. Dur de savoir si c’est leur unique moyen d’accéder au Web, mais c’est un débit 500 fois inférieur aux mobiles ! Akamai signale également un faible taux de débit inférieurs à 256Kb/s
• DegroupTest nous avertit sur le fait que depuis la France d’outre-mer, on a du 250ms de ping en moyenne, l’équivalent du mobile, et un débit 40% inférieur à la métropole
• 60 millions de consommateurs et Akamai montrent que 50% des utilisateurs ont moins de 5Mb/s, avec une répartition qui a l’air à peu près égale par tranche de 1Mb/s : 10% ont moins de 1Mb/s, 20% moins de 2Mb/s, etc.
• les tuyaux du Web français sont embouteillés le soir, avec une perte de 20% de débit entre 21h et 22h.

Il n’y a pas d’ADSL type en France

Nous nous sommes donc posés la mauvaise question : calibrer vos tests sur LA moyenne française est à peine moins trompeur que de mesurer depuis votre poste avec votre navigateur récent, sur votre réseau d’entreprise branché à la fibre (oui tout le monde le fait, et c’est MAL).

Enfin : quelle stratégie de test ?

Tous ces chiffres vont nous permettre de définir une vraie stratégie de test de la performance perçue. Cela commence par définir des objectifs de réactivité raisonnables en terme de confort d’utilisation, par exemple :

• afficher quelque chose avant 1 seconde (start render)
• promesse / fonction principale de la page affichée avant 2 secondes
• fonction principale interactive avant 5 secondes

Note : les valeurs que j’indique ici sont un peu génériques, et sont à définir entre les équipes “produit” (marketing, ergonomie) et les équipes techniques (développeurs, sysadmins).
Vous devez maintenant être cruel et déterminer quelle proportion d’utilisateurs n’aura pas droit à cette rapidité. C’est un peu rude dit comme ça, mais une page rapide pour “tout le monde” coûte très cher. Généralement on vise à satisfaire par exemple 80 % de la population.

Voici un petit tableau qui devrait vous aider à prendre vos décisions :

Remarques :

• Les débits et pourcentages semblent joliment arrondis. C’est de la chance.
• Pour le ping, on n’a aucune stat sur la répartition réelle, ce sont donc des suppositions personnelles que je vous invite à critiquer

Pour le réseau mobile, on est bien embêté car on n’a aucune idée de la répartition ! On sait juste qu’elle est très volatile, ne serait-ce que pour le même utilisateur. Donc, soit on joue ça au doigt mouillé avec la certitude de se tromper, soit on utilise la moyenne qui est pratiquement un mensonge. Mmmm. Choix cornélien mais, à choisir, autant partir sur une valeur un tout petit peu objective, c’est-à-dire la moyenne constatée, et y rajouter de la perte de paquets.

Je mettrais donc ces 3 valeurs par ordre de priorité :

1. 3,0Mb/s avec une latence de 110ms pour représenter 70% de vos utilisateurs
2. 2,5Mb/s avec une latence de 200ms et une perte de paquets de 25% pour l’ensemble des utilisateurs de réseau mobile
3. 4,80Mb/s avec une latence de 95ms pour « la moyenne » des connexion filaires

La moyenne reste là surtout parce que c’est un chiffre que tout le monde (croit) comprendre et pour comparer mobile et bureau.

Si vous avez une population particulière (outre-mer, visiteurs à 21 h, habitant une grande ville, professionnelle, très mobile, etc.), il va vous falloir fouiller dans les chiffres ci-dessus pour trouver ce qui se rapproche le plus de vos utilisateurs. Ou, bien sûr, monter votre propre monitoring des capacités de vos utilisateurs.

Résultats

Pour conclure, comparons les valeurs DSL par défaut de WebPageTest.org avec celles que nous avons déterminées pour représenter 70 % des français. J’ai lancé un test sur un site moyennement complexe, qui n’a pas (encore) été optimisé et qui fait partie des sites à forte audience de France : Pluzz.fr.

Comparaison valeurs par défaut et personnalisées

Pour plus de détails, voir le détail du déroulé. Avec les valeurs par défaut, ce site s’affiche en moins d’une seconde, donnant l’impression que l’optimisation n’est pas nécessaire. Avec nos valeurs plus réalistes prenant en compte 70 % de la population, le start render se situe à 1,4 seconde, confirmant le besoin d’entamer des travaux si l’on veut atteindre les objectifs de performance perçue.

On l’a vu dans le premier article, certaines techniques pourtant reconnues peuvent devenir contre-productives si l’on ne fait pas les tests nécessaires. Ne jetons cependant pas tout aux orties, voici les techniques que vous devrez maîtriser plus que jamais et pousser dans leurs extrêmes si vous voulez obtenir un résultat correct sur mobile ; par ordre de priorité :

1. Travailler le chemin critique

La notion de performance est plus un ressenti qu’une collection de chiffres. Lorsque vous devez retravailler une page pour un réseau mobile, demandez-vous ce que l’utilisateur est vraiment venu voir et dégagez le passage pour afficher au plus vite la zone ou la rendre fonctionnelle :

• pas (trop) de redirections, et surtout pas côté client ;
• concaténation ou mise en ligne des CSS ;
• un code HTML / CSS prêt à « marcher » sans JavaScript : pour un article, c’est facile, on affiche le texte (sans police de caractère, jamais) ; pour une vidéo, on peut utiliser HTML5 comme interface de lecture en attendant JavaScript. Si vous dépendez de JavaScript pour afficher la fonctionalité (un webmail par exemple), affichez au moins un indicateur de chargement ;
• scripts asynchrones comme vu dans le premier article ;
• JavaScript chargé et exécuté par ordre de priorité : on peut très bien imaginer de charger d’abord les fichiers JavaScript concaténés qui concernent la zone principale, puis un second pack de fichiers qui concernerait tout le reste de la page.

2. Minimiser le nombre de requêtes HTTP

On l’a vu lors de l’exemple du domain-sharding, la première limite vient du réseau : le même mobile sur la même session de surf pourra passer d’un WiFi de bonne qualité à une absence complète de réseau. Vous ne pouvez jamais prévoir quand la latence va s’allonger jusqu’au timeout ou quand le débit passera en dessous de ce dont vous auriez besoin pour afficher une simple image. En supposant que vous serviez votre site classique sur mobile (1 Mo, 100 requêtes, 15 domaines… source http archive), il va falloir faire baisser de manière drastique le nombre de requêtes pour minimiser les effets de latence ou de timeout et maximiser l’utilisation de la bande passante. Cet objectif est là pour durer et la plupart des techniques classiques utilisées jusqu’ici sont non seulement à investiguer, mais à pousser dans leurs extrêmes.

La concaténation

Il est plus que jamais temps de faire de vos CSS et JS des fichiers uniques ou presque. De base dans Ruby on Rails, avec des plugins divers pour Spip ou Drupal, avec Assetic pour Zend 2, des dizaines de librairies pour d’autres projets PHP, avec SASS côté CSS et des outils comme YUI Compressor.
Il n’y a plus vraiment d’excuses pour ne pas gérer correctement vos JS et CSS, sauf peut être le coût de refactoring initial, mais il reste généralement négligeable par rapport aux bénéfices attendus.

À noter que les stratégies de concaténation vont varier en fonction de la taille de votre site : si il est relativement petit, mettez tous vos CSS dans une seule feuille ; si il est plus grand, mettez le CSS commun dans une première feuille et les CSS de chaque type de page dans une autre. Ne dépassez jamais 2 feuilles par page. En JavaScript, les stratégies sont plus variées du moment que vous utilisez l’asynchrone : un fichier unique pour tout le site si il est petit, un fichier par zone fonctionnelle sinon (avec chargement asynchrone).

Les images

Les images sont généralement petites et nombreuses, c’est donc votre seconde cible après le CSS. Vous avez forcément déjà entendu parler du spriting ; sur mobile, vous pouvez aller encore plus loin avec les caractères unicode : lorsque vous avez beaucoup d’icônes, essayez de voir si vous pouvez en réutiliser (♻) qui viendraient directement des polices du système !
Attention à la compatibilité navigateur ET système d’exploitation. Pour les mobiles, c’est généralement bon ; pour IE sur XP, vous n’aurez qu’un choix limité.

Encodage des images : visez le zéro requête en encodant vos images en texte directement dans le CSS, voire dans le HTML. C’est un peu fastidieux à faire à la main mais un simple script PHP suffit :

print '<img src="data:image/png;base64,'.base64_encode(file_get_contents('/path/to/image.png')).'" />';

Qui vous donnera en sortie quelque chose de ce genre :

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAMAAAAoLQ9TAAABO1BMVEX92RlCQj+7vLzvzSzmhgnXgybyz3uLj5T13mj99cDwrmWMfzXmyTz78bT1zUf++uX437bxzqzmpj/dlDdcVUbuxnjszDLq6uvqmS/43Hv99t+foaOMgl5tYDjsu1vfwT388NijlXr52Vn22Y3999Z2bmD34svhrFlQTD378ajuwWXThzH668PpsFbvw5zrtU2Vh03x0Y3MzMz73kr664qZmZnmnUblqm/7w1HokRbefBb//e324HL2z0TsuENYRC399s/343z46paYijr88s/z1KXvyIvspkzroTj81yL56cnajjLwxm9KSkLmqj1gVj+Xg2H3vkv+/tz35XL+3CD89cj45Lf88MSipab13FnvtGP224T45Yb78rr++uv3zij25Grz1Ub1yi7wxFztu2vYiTH95kfqs2v45csXvxkaAAAAAXRSTlMAQObYZgAAAMlJREFUaN5jYAACY0llQzafZFsGCAiJDvNSkJJSEEjR9wQLROvw86s4OISqxLkJgfhKYfz8/NZA4MBrnW4HFGBzkZKKAwlIxWpmCAMFRKVCQ1VUXFzCY52CpVKBAlpeKo4xUVFR7jGRJmreQAE+N2sbCRsbDhuWxCBzP5Cpcq5BHjYJCTaWnIKsYHs9dV25bIDAXY81CeIyT3WzwLQ0CyvteKhTGcQCFJ25Ve2ZGeBAJiLClN0fwWcwYBI3kpZFEuAR8WXUkGfACgC55CKssDjPhQAAAABJRU5ErkJggg==" />

Des frameworks complets comme SASS permettent de le faire dans le CSS. Vous pouvez utiliser cette technique à partir de IE8, et envisager l’équivalent MHTML pour IE7.

Le nombre de domaines

Le site moyen a entre 10 et 15 domaines à faire résoudre et il n’y a pas eu d’études sur l’utilisation du cache DNS sur mobile. Pratiquement invisible sur ordinateur de bureau, le coût de recherche DNS est peut être dix fois plus important sur mobile à cause de la latence. Chaque recherche de domaine va bloquer une file de téléchargement en attendant la réponse. Donc, soit vous sacrifiez trackers, publicité, widgets et autres sources externes, soit vous les dépriorisez fortement, tout simplement en les appelant après vos propres fichiers.

Connexions permanentes

Si vous avez une version dédiée mobile de votre site (pas de problématique de référencement, code spécifique), autant y aller à fond et utiliser une technologie très prometteuse pour contrer les effets de la latence : WebSocket. Pointez deux navigateurs cette page de démo, et observez le peu de délai dans la transmission d’une info d’un navigateur à l’autre, réseau mobile ou pas. Websocket ou d’autres techniques de connexions permanentes peuvent être détournées : vous chargez en une seule requête une page initiale ne contenant que le strict nécessaire de CSS, de contenu et de JS, puis vous chargez tout le reste (images, CSS, JS, contenu) via cette connexion, que vous pouvez même réutiliser pour renvoyer des informations (AJAX, tracking…), sans payer le prix d’ouverture de nouvelles connexions HTTP.
Je n’ai pas encore vu d’équipe web déclarer avoir implémenter cela, mais ça ne saurait tarder. Au pire, patientez un peu, je vais coder une démo sur de vrais sites.

3. Le cache et l’offline

Comme avant, il va falloir que vous commenciez par maîtriser absolument toutes les URLs vers les statiques de votre site pour pouvoir les servir avec des caches agressifs, sur des domaines sans cookies. Ça c’est surtout pour les navigateurs de bureau car le cache des navigateurs mobile est une vraie calamité en terme d’efficacité ! Il y a beaucoup trop de limites (nombre d’objets, taille maximale par objet, taille maximale par site et taille maximale pour tout le navigateur) pour espérer de vrais gains avec les comportements par défaut. Attention il ne faut pas les ignorer pour autant, si votre visiteur va d’une page à l’autre, il sentira la différence.

Les sites très efficaces en sont donc à utiliser HTML5 localStorage pour stocker des JS, des CSS et même des images (encodées en base64). C’est la technique choisie par LinkedIn mobile, Bing ou GMail, et elle demande un certain niveau de maîtrise de son application. Par exemple, imaginez-vous sur une page d’accueil : vous allez télécharger via XHR tous les objets dont vous avez ou aurez besoin, puis les stocker dans localStorage.

var loader = new XMLHttpRequest();
loader.open("GET", "http://example.com/js/main.js");
loader.onload = function(e) {
    localStorage.setItem('main.js', e.response);
}
loader.send();

Ensuite, au moment ou vous en avez besoin, vous vérifiez la présence des fichiers voulus dans votre cache maison.

if( localStorage.getItem('main.js') !== null ) {
    eval( localStorage.getItem('main.js') );
}

Oui, vous faites à la main le boulot du navigateur (télécharger, gérer le cache, insérer…) mais c’est avec ce genre de code un peu extrême que l’expérience utilisateur sur mobile fera la différence. En prime, les navigateurs de bureau en profiteront aussi.

Une note pour ceux qui ont entendu dire que LocalStorage était contre-performant car synchrone (lorsque vous écrivez, vous bloquez le programme le temps que le disque ait fini de travailler) :

• c’est évitable facilement en passant par un wrapper qui va simplement effectuer l’écriture en asynchrone ;
• les mobiles écrivant tout en RAM / Flash disk, les temps d’accès sont de toute façon négligeables.

Vous pouvez encore passer au niveau supérieur en utilisant une technique qui a autant fait ses preuves que montré ses limites : l’utilisation de la spécification Application Cache. Native, bien supportée par tous les navigateurs modernes mobiles ou de bureau, elle permet de déclarer en un fichier (le manifeste) quels sont les fichiers à télécharger, quelles ressources doivent continuer à être servies en ligne, et quoi afficher lorsque la connexion n’est plus là. Au contraire de la gestion du cache présentée précédemment qui est personnalisée et donc très adaptée à votre application, Application Cache vous force à coder d’une certaine manière (maîtriser absolument toutes ses URLs), présente certains manques (invalider le cache de certains fichiers seulement) et il faut un petit temps d’adaptation pendant la phase de développement pour comprendre son fonctionnement intrinsèque. En revanche, en terme de performance et de mode de distribution, c’est parfait !

4. Réduire la taille

Minification et compression des JS / CSS

La minification est généralement exécutée au déploiement du site juste après la concaténation et vous pouvez généralement gagner 50 % du poids des fichiers avec des outils solides comme YUI Compressor. Activez la compression gzip par-dessus et vous aurez gagné au final 90 % du poids initial de vos fichiers. Sachant qu’il n’est plus rare de trouver des sites avec 200-500 Ko de CSS et de JS, le gain est assez important.

Les photos

Pour les images de l’interface, comme pour les photos, vous avez beaucoup à gagner en compressant au maximum les images servies. Encore plus efficace : ne les afficher que si elles sont nécessaires. Dans le cas d’une application Web Mobile ou l’interface permet de beaucoup scroller, considérez comme une amélioration majeure de faire du lazy-loading sur les images, c’est à dire de ne télécharger l’image que lorsqu’elle est sur le point d’être affichée.
En terme de compresseur d’image sans perte de qualité, voyez avec PNGout (ligne de commande) et PNG Gauntlet (son interface visuelle) pour compresser efficacement les PNG, ou JPGoptim (ligne de commande) et Image Optim (meta interface pour Mac) pour les JPG.

Les cookies

Là aussi, investissez du temps pour maîtriser toutes les URLs de toutes les ressources statiques de votre site , afin de les mettre sur des domaines séparés du domaine principal. Imaginez un cookie d’un peu moins d’un Ko qui serait envoyé à la centaine d’objets généralement appelée par une page Web classique : vous demandez à votre utilisateur d’uploader 100 Ko de données inutiles. Une autre piste pour remplacer les cookies qui sont parfois servis sur des pages statiques qui n’utilisent même pas de données personnalisées est de ne pas les utiliser du tout… pour les remplacer par HTML5 localStorage si vous avez tout de même besoin de persistance côté client (préférence d’affichage, historique…). Pour la compatibilité navigateur, passez par des petites librairies spécialisées.

En résumé

Vous voilà donc paré pour arrêter de perdre vos clients dès qu’ils essayent d’accéder à votre site à partir d’un réseau mobile. Nous avons vu que :

• la performance est empirique : testez même les grands classiques avant de choisir vos solutions ;
• la plupart des techniques déjà connues marchent mais sont à traiter dans un autre ordre ;
• ces techniques sont à pousser dans leurs extrêmes ;
• de nouvelles possibilités sont apparues.

Et ne comptez pas sur l’évolution future de l’équipement réseau : sauf inversion de la tendance actuelle, non seulement vos sites vont continuer à grossir mais en plus les futurs utilisateurs des réseaux 4G voire Wimax auront toujours des doigts, des murs, des gens et de l’atmosphère à traverser avant d’arriver sur vos serveurs.

L’optimisation, c’est maintenant.

Introduction

Vos utilisateurs viennent chez vous sur mobile : 5 % selon StatsCounter ; 10 % selon ATInternet ; 9 % d’après ce que je vois chez mes clients dont le site n’a PAS été pensé pour du mobile. Évidemment cette part est en augmentation constante, a déjà largement dépassé IE7, va dépasser IE8, et il est raisonnable de penser que, ces statistiques étant récoltées via JavaScript, certaines tentatives d’accès ne soient même pas comptabilisées ! Que vous le vouliez ou non, que votre site ait été fait ou pas pour cet usage, vos utilisateurs essaient de venir sur votre site dans des conditions de réseau qui ne vous arrangent pas forcément, mais qui vont vous poser quelques défis intéressants.

De quels mobiles parle-t-on ?

Plus on rentre dans les détails des navigateurs, des systèmes d’exploitation et des capacités matérielles, et plus il semble illusoire de définir ce qu’est vraiment un mobile. Restons pragmatiques et, dans le cadre de cet article sur la performance, précisons ce que nous allons considérer comme notre cible :

• capacité du navigateur à afficher des sites non spécifiquement prévus pour mobiles ;
• navigation « tactile » ;
• matériel sous-dimensionné par rapport à la machine de bureau moyenne ;
• qualité de réseau fluctuante.

Ce dernier critère peut prêter à discussion, tant on observe d’utilisateurs mobiles accéder aux sites depuis le confort du WiFi de la maison : par exemple, la moitié des visiteurs dits « mobile » sont en fait sur iPad, ce qui implique (le plus souvent) le WiFi.

Mais dans le cadre de cet article nous allons surtout nous intéresser aux « problèmes supplémentaires à résoudre pour le chargement des pages » : les temps de chargement depuis une tablette / mobile sur WiFi sont largement comparables aux temps de chargement sur certains navigateurs de bureau.

Comment tester ?

Tout développement commence par la mise dans de bonnes conditions pour tester ; la mesure a lieu ensuite dans un chantier performance web. Le banc de test idéal pour le mobile est simplement impossible à monter et force est de constater que les éditeurs de sites, de l’indépendant aux sites avec des millions de pages vues, se contentent généralement de l’iPhone de l’intégrateur et éventuellement de l’Android-qui-s’appelle-revient du collègue.

Si l’on regarde les parts de marché en France, cela correspond effectivement à une réalité : nous avons Safari pour iOS partagé entre les différents iPhone et iPad, et le navigateur par défaut d’Android distribué avec les version 2.x. En queue de peloton et souvent ignorés, à tort pour les valeurs d’interopérabilité du Web, viennent les Opera (mini ou mobile) pourtant ultradominants dans d’autres pays, Firefox mobile, ainsi que différentes variantes de Webkit sur les OS mobiles survivants (Blackberry, SymbianOS, LG…), ainsi que IE Windows.

Ah, et ne comptez pas sur les émulateurs : ils sont déjà à peine acceptables pour tester les fonctionnalités, alors question performance ils sont tout simplement disqualifiés d’office ! Entre l’utilisation du processeur de la machine hôte, une connexion filaire sans défaut et les approximations inhérentes à tout émulateur, vous n’aurez jamais quoi que ce soit de réaliste dans votre quête de la fluidité.

La solution minimale du pauvre, c’est de conserver ses mobiles et d’attendre qu’ils vieillissent ou d’acheter des occasions datant d’un an ou deux, sans mettre à jour le système d’exploitation. Pour simuler un réseau 3G, on pourra utiliser des proxys via WiFi qui dégradent volontairement la connexion. Il y a une grosse dizaine de solutions, généralement limitées à un seul OS (souvent Mac). La plus compatible et reconnue est le proxy payant Charles mais la gratuité de Trickle (Linux), Network Link Conditioner (OSX 10.6) ou Slowy App (OSX 10.5) peut vous séduire.

Le principe est simple : ces logiciels contiennent de quoi dégrader artificiellement une connexion (débit, latence, perte de paquets). Vous configurez votre téléphone pour utiliser votre machine comme proxy via WiFi, et voilà ! En prime, vous pouvez analyser les trames réseau qui passent. C’est moins cher que de vraies cartes SIM et la constance de la dégradation permet de faire des tests répétés, là où la qualité d’un vrai réseau data peut varier d’une minute à l’autre.

Pour être honnête, les techniques décrites dans cet article ont surtout été testées sur le navigateur Android 2.3 et Safari iOS 6, avec des vérifications fonctionnelles sur Firefox et Opera mobile sur Android, les deux absents notoires étant le Safari de Blackberry et Internet Explorer.

Signalons également que nous ignorons délibérément un bon milliard d’habitants sur cette planète qui se connectent au Net avec des mobiles pré-smartphones : techniquement difficiles à adresser sérieusement, ils sont également une minorité en France à posséder ces anciens mobiles et avoir souscrit un abonnement 3G.

Chargez !

L’importance du réseau

Croyez-le ou non, les débits théoriques en 3G et technologies au-delà peuvent être plus rapides que les débits constatés des ADSL. Mais comme finalement assez peu de gens font du Web depuis les laboratoires de tests des constructeurs, il va falloir composer avec la réalité physique : une couverture nuageuse un peu forte, un déplacement un peu rapide, un doigt mal placé, un mur un peu épais, ou des gens autour de vous également équipés de mobiles (incroyable en 2012), et vous vous retrouvez rapidement avec des débits ridicules, des pertes de paquets énormes et le sentiment global qu’on vous a un peu survendu la « meilleure couverture réseau de France ».

Lorsque le réseau marche, l’utilisateur français moyen a en moyenne 2,50 Mb/s (sources) ce qui est plus rapide que 25% des ADSL de France. Par contre, la latence ou ping est en moyenne à 200 ms soit le double de la moyenne en ADSL.

Depuis toujours, la latence est l’ennemi numéro 1 de nos pages Web. Ceci est du à la nature même de HTTP et signifie que pour un débit moyen seulement deux fois inférieur, le temps de chargement sera en fait 3 à 6 fois plus long sur mobile ! Pire, la perte de paquets est assez conséquente et inhérente à la technologie radio utilisée pour communiquer entre le mobile et l’antenne de l’opérateur. Et cette perte de paquets arrive plus fréquemment pour les petites requêtes… Exactement la manière dont sont composées la majorité de nos pages Web actuelles !

Ajoutez à cela qu’accrocher et maintenir le réseau data est une des opérations les plus coûteuses en terme de batterie : passez en mode avion sur votre smartphone, utilisez-le presque comme d’habitude (lectures, jeux…) et vous verrez qu’il peut tenir une seconde journée sans recharge. Et souvenez-vous des anciens portables sans data qui tenaient une semaine…

Bref, c’en est au point que les constructeurs optimisent comme ils peuvent le matériel, par exemple en mettant en veille la radio après un certain temps d’inutilisation. On se retrouve donc dans des situations où, le temps de lire cet article, l’antenne s’est déconnectée et il vous faudra plusieurs secondes pour que la requête suivante aboutisse !

Malgré cela, les utilisateurs ne sont pas beaucoup plus patients que sur un ordinateur de bureau : après 5 à 10 secondes de page blanche, une majorité d’utilisateurs a déjà rebroussé chemin, et autant vous dire qu’ils n’apparaissent même pas sur les statistiques collectées en JavaScript. Comment faire pour vaincre l’hémorragie de visiteurs et proposer des services de meilleure qualité perçue ?

Eh bien il va nous falloir revisiter tout l’arsenal des classiques de la Performance Web.

Remettre en cause les classiques

Lorsque le pape de la performance, Steve Souders, a émis chez Yahoo! les premières recommandations de performance Web, c’était en faisant du reverse-engineering sur les moteurs IE6-IE7 et Firefox 2. C’était en 2005 et, avec l’abandon progressif du support de ces navigateurs antédiluviens (à l’échelle du Web) d’un côté et la banalisation de l’ADSL de l’autre, certaines règles ou astuces sont devenues moins importantes.

L’apparition de la navigation sur mobile en a même rendu certaines dangereuses !

Le domain-sharding

Citons par exemple le domain-sharding, qui consiste à répartir ses fichiers statiques sur plusieurs sous-domaines différents. Étonnamment populaire, à l’origine cette technique permettait de passer outre la limitation à 2 files de téléchargement par domaine et de bénéficier de toute la largeur des bandes passantes modernes. Mais à partir de IE8, sorti en 2009, cette technique devient inutile car le nombre de téléchargements simultanés passe de 2 à généralement 6 : les navigateurs se sont adaptés à la banalisation des gros débits et tentent d’en tirer parti.

Utilisons le service Cuzillon qui va nous permettre de simuler une page avec 24 images réparties sur 4 domaines et une autre page avec 24 images sans domain-sharding. Le service WebPageTest nous permet de voir qu’il y avait effectivement une amélioration sur le temps de chargement sur IE7 :

WebPagetest – Test de chargement d’une page sous IE7 avec (en bas) et sans sharding (en haut). Voir la source

Le test sur les mêmes URLs sur IE8 nous montre que l’on ne gagne plus grand chose en premier rendu (les petites images chargées) :

WebPagetest – Test de chargement d’une page sous IE8 avec (en bas) et sans sharding (en haut). Voir la source

On ne gagne plus rien car la parallélisation des téléchargements est assurée de base par le navigateur. On a en fait rajouté deux mini-problèmes en rajoutant un temps de résolution DNS supplémentaire par domaine, et en faisant concourrir plusieurs images pour la même bande passante. Je dis « mini-problème » en supposant qu’on ne ciblait que les navigateurs de bureau (c’est mal) où ces problèmes sur des vrais sites (75-150 requêtes, 10-15 domaines) passent finalement inaperçus, mais vous ciblez les mobiles, pas vrai ?

Sur mobile, les navigateurs ouvrent également plusieurs connexions par domaine et font même du multiplexing HTTP (plusieurs requêtes HTTP dans le même tuyau TCP) pour minimiser les problèmes liés à la latence. Vous prenez alors le risque de couper court à ces optimisations. Résultat ?

WebPagetest – Test de chargement d’une page sous iOS avec (en bas) et sans sharding (en haut). Voir la source

L’affichage a été ralenti ! En forçant encore plus de domaines, vous demandez à plus d’objets de se partager la même bande passante, que vous devez considérer a priori comme rare sur mobile. Donc vous ralentissez l’affichage des premières images alors même que les suivantes ne sont pas immédiatement utiles. Ici, le temps de chargement total est en plus augmenté car le multiplexing n’a pas pu être utilisé, ce qui peut être le cas sur des sites avec un ratio ressources / domaine faible.

Les scripts en bas de page

Le temps avant le premier rendu (l’affichage des premiers pixels du site) est un peu le but ultime de la performance Web, car il y a une très forte corrélation entre ce temps et une augmentation des taux de transformation ( + rapide = + d’argent ).

Dans ce cadre, une autre technique populaire consiste à déplacer toutes les balises script en bas de page. Cette technique marche effectivement bien sur les anciens navigateurs et continue à faire ses preuves dans une moindre mesure sur les nouveaux malgré leurs progrès dans la prioritisation des téléchargements.

Regardons l’effet attendu avec IE8 sur une page simple où le téléchargement du JavaScript est retardé côté serveur.

Bureau : tests de comparaison de chargement d’une page avec les scripts en bas et en haut de page. voir la source

En haut, la page améliorée par déplacement des balises script ; on voit que le contenu (une simple phrase) s’affiche rapidement, alors qu’en bas la page blanche de la mort est de rigueur.

Passons sur mobile, si vous le voulez bien, et testons Safari iOS et Android Browser 2.3.

Mobiles Android et iOS : tests de comparaison de chargement d’une page avec les scripts en bas de page. Voir la source

Android se comporte comme nos navigateurs de bureau et affiche le contenu dès qu’il l’a. Safari iOS préfère attendre le script avant d’afficher quoi que ce soit, sans doute par peur du FOUC (Flash Of Unscripted Content).

On peut débattre sur le fait qu’ergonomiquement il vaut mieux attendre une page bien faite (complètement scriptée) plutôt que d’afficher rapidement du contenu pas finalisé, mais les taux de tranformation montrent que l’affichage rapide rapporte plus.
Et de toute façon, en tant qu’auteur de la page, c’est à vous de juger si elle peut être vue momentanément sans scripting ou pas : si vous utilisez des méthodes de développement par couche (HTML, puis CSS, puis JS), ça devrait être bon. Si vous voulez de la performance, il va donc falloir faire évoluer votre technique d’inclusion de script pour passer à une version asynchrone.

Le chargement asynchrone à la base est bête comme chou :

var oNode = document.createElement('script'); 
oNode.type = 'text/javascript'; 
oNode.src = 'http://domaine/monscript.js'; 
document.getElementsByTagName('head')[0].appendChild(oNode); 

Vous utilisez le DOM pour créer dynamiquement de nouveaux noeuds script qui vont charger des fichiers JS. Cette technique est notamment utilisée par les Google Analytics, boutons G+ et autres Like Facebook pour s’insérer dans vos sites sans introduire de dépendance forte vis-à-vis de leurs serveurs.
Autrement dit, lorsque leurs serveurs sont en rade ou bloqués par un proxy, le navigateur va tout de même afficher votre page (trop aimable). Utiliser cela avec ses propres scripts est globalement une bonne idée, et devient vital sur mobile. Vous aurez probablement besoin d’aller plus loin avec le chargement dynamique de scripts (exécuter du code lorsque le fichier est arrivé, gestion des dépendances et de l’ordre de chargement, concaténation de fichiers à la volée…), aussi pensez à utiliser des frameworks solides comme requireJS, YepNope.js (inclus avec Modernizr), HeadJS, LabJS… Chacun a sa philosophie.
Et puisque je vous tiens, voici le mien : LazyLoadLight, qui se veut léger et facile

Voir la suite de cet article qui parle des chemins à explorer pour des pages toujours plus rapides sur mobile.

Cet article se veut une introduction générale à HTML5, notamment pour les développeurs PHP qui sont généralement les mieux placés pour prendre au sérieux ce qu’il se passe au frontend. Si vous avez lu mon livre sur HTML5 ou que vous suivez déjà régulièrement l’actualité, je doute que vous y appreniez grand chose. Il explique :

• l’origine de la spécification
• comment les sites d’aujourd’hui peuvent en bénéficier
• le futur des applications Web
• les rares synergies entre HTML5 et PHP

Historique

Une définition variable

Le terme même « HTML5 » couvre plusieurs définitions, et nous allons voir que le W3C a surpris tout le monde dans son choix final. Avant que le terme HTML5 n’apparaisse, HTML 4.01 était stabilisé et le W3C planchait sur XHTML 2 car pour eux la syntaxe stricte de XML allait permettre à tous les navigateurs d’être enfin d’accord sur les règles de parsingdes pages.

Le logo volontairement énigmatique du WHATWG

Nous sommes en 2004 et des représentants d’Apple, Opéra et Mozilla, pensant que XHTML 2 est une fausse bonne idée, décident de former un groupe dissident, dénommé non sans ironie WHATWG (What Working Group?). Ils travaillent de leur côté à leur vision du Web : celle d’une plateforme de développement universelle qui pourrait battre les applications natives, aux langages généralement propriétaires et fermés, en étant exécutable sur tous les systèmes et toutes les machines. Leur première spécification est « WebForms 2 », une évolution majeur des formulaires HTML que nous allons aborder plus loin. Vont venir s’ajouter beaucoup de petites spécifications regroupées sous le terme « Web Application 1 ».

En 2006 le terme HTML5 apparaît enfin : c’est la version approuvée par le W3C des spécifications travaillées par le WHATWG. Le Web a eu peur un instant que le W3C soit tellement discrédité par cette affaire que ses spécifications, déjà mal comprises des développeurs Web par la faute des implémentations non conformes de certains navigateurs, ne fassent plus autorité. Désormais cette réconciliation donne un nouveau rythme de travail : les navigateurs (hors Microsoft) testent des implémentations de fonctionnalité à toute vitesse, s’accordent sur les APIs finales et les formalisent, pendant que le W3C garde son rôle de gardien des clés et continue son travail de proposition de spécifications.

En 2009, le W3C accuse le coup du rejet par la communauté des développeurs Web de XHTML 2 et l’abandonne : l’inconvénient majeur de la syntaxe XML était qu’elle ne serait jamais rétrocompatible avec les navigateurs déjà en circulation. A cette époque déjà on a du mal à savoir ce que désigne vraiment HTML5 : des spécifications d’API sont réparties entre trois spécifications (« Web Application », « HTML5 » par le WHATWG et « HTML5 » par le W3C), et certaines devenues trop grosses ou pratiquement finalisées sont carrément sorties de HTML5 pour vivre par elle même.

Le logo officiel de HTML5

En 2011 le terme HTML5 est clairement un terme générique : le W3C déclare officiellement qu’il désigne désormais plus une idée de l’évolution du Web qu’une spécification en particulier, et lui donne par la même occasion un logo. Le WHATWG de soncôté bannit ce terme pour renommer ses spécifications « living standard », ce que l’on pourrait traduire par : « ne cherchez pas la stabilité chez nous, allez plutôt voir le W3C pour ça ».

Le HTML5 dont nous allons parler ici désigne trois choses :

• l’évolution de HTML 4, avec une syntaxe assouplie, une nouvelle sémantique et l’introduction des microdata,
• de nouvelles interactions utilisateur, avec les nouveaux formulaires, la géolocalisation et le multimédia
• l’arrivée des applications Web avec des API JavaScript comme Websocket pour la communication temps réel, la gestion du hors ligne, le stockage d’informations côté client et XMLHTTPRequest 2

Nous avons choisi ces sujets car ce sont que vous pourrez utiliser en production le plus immédiatement, en assurant une compatibilité avec tous les navigateurs depuis Internet Explorer 6.

Quand HTML5 sera-t-il prêt ?

Réponse courte : maintenant, et depuis plusieurs années déjà. Lisez la réponse longue pour comprendre de quoi HTML5 est fait.

2022 ?

A l’époque où le WHATWG commença à travailler sur la spécification en 2004, Ian Hickson, l’éditeur de la spécification, avait annoncé une date qui est restée longtemps dans la mémoire des journalistes : 2022. Il faut bien comprendre qu’il faisait référence aux critères du W3C : des spécifications complètes, finalisées, acceptées, et surtout avec au moins deux implémentations complètement interopérables. Cela semble raisonnable à première vue, mais concrètement ce niveau de qualité repousse très loin les dates de finalisation. Par exemple après 10 ans d’existence et d’utilisation en production, CSS 2.1 vient à peine d’atteindre le niveau final des spécifications : « Recomendation ». Et malgré cela il n’existe pas encore deux navigateurs implémentant toutes les fonctionnalités, et sûrement pas de manière identique. HTML 4.01 lui par contre a bien atteint le niveau « Recomendation » il y a 10 ans, et même si il n’y a pas de test unitaire pour le prouver on peut considérer que plusieurs navigateurs interprètent le même code de la même manière. Mais cela ne change pourtant rien au quotidien des développeurs Web qui doivent assurer le support sur les navigateurs qui ont ignoré ou mal interprété les spécifications.

2011 ?

La mauvaise nouvelle, c’est que l’on vient de voir avec CSS2.1 et HTML 4.01 que l’état d’une spécification du W3C ne signifiait pas grand chose pour le développeur web. La bonne nouvelle, c’est que pour HTML5 non plus l’état de la spécification n’a pas beaucoup d’importance ! Ce qui compte vraiment c’est :

• la stabilité des implémentations navigateur,
• la possibilité d’émuler la fonctionnalité sur les anciens navigateurs,
• à défaut, l’acceptation d’une page non améliorée pour les anciens navigateurs

Autre grande nouvelle : HTML5 n’est pas fait d’un bloc. La spécification se découpe en de nombreuses fonctionnalités séparées, n’ayant parfois pas de lien entre elles, et chaque navigateur avance sur ses sujets favoris. Concrètement il y a aujourd’hui une bonne dizaine de nouvelles fonctionnalités qui sont à la fois suffisamment stables, suffisamment répandues et en même temps simulables sur les anciens navigateurs, ce sont celles que nous allons couvrir rapidement aujourd’hui et qui nous font dire que HTML5 est déjà là.

1999 ?

Poussons le raisonnement jusqu’au bout : en découpant HTML5 en spécifications séparées, on arrive à des conclusions étranges ; Internet Explorer 5.5, sorti en 1999 est compatible avec certaines fonctionnalités HTML5 comme le drag and drop. Évidemment cela s’est fait dans l’autre sens, c’est à dire qu’un des premiers travaux du WHATWG a été de coucher sur le papier des fonctionnalités comme le drag and drop qui n’avaient jamais été écrites. Cet exemple est là pour illustrer que la question du « quand » n’a pas vraiment de sens.

Conclusion : des fonctionnalités majeures associées à HTML5 sont disponibles dès maintenant pour des environnements de production, y compris avec la contrainte du support d’anciens navigateurs.

La philosophie

HTML5 est né dans le conflit et avec la volonté d’être pragmatique pour une adoption rapide. Cela lui confère un certain nombre de principes :

• Un assouplissement des règles. En réaction aux travaux sur XHTML 2 qui impliquait la syntaxe stricte de XML dans les pages HTML, HTML5 est clairement permissif et enlève les attributs inutiles, les doctypes compliqués, enlève l’obligation d’utiliser des quotes et autorise les variations de casse.
• L’unification des règles de parsing. Les navigateurs respectant HTML5 implémentent le même algorithme d’interprétation du texte HTML pour construire le DOM, c’est à dire la représentation finale du document accessible en CSS et en JavaScript.
• La rétro-compatibilité. Au contraire de ce sur quoi s’engageait le W3C à l’époque, les nouvelles fonctionnalités sont introduites avec des syntaxes permettant au parc de navigateurs actuels (en partant de Internet Explorer 6) de ne pas « casser » les pages.
• Formalisation de l’existant. Le WHATWG a commencé par écrire les spécifications de fonctionnalités jamais documentées auparavant et pourtant implémentées au prix de longues heures de reverse engineering par tous les navigateurs. Cela va de fonctionnalités complètes comme le drag and drop à des attributs DOM comme .innerHTML.

On le voit, HTML5 a été pensé avec beaucoup de pragmatisme pour une adoption immédiate. Cela est du à la volonté des fabricants de navigateurs de faire avancer le Web. Une fois ces bases saines établies, ils ont maintenant les coudées franches pour rattraper les applications natives en terme de fonctionnalités.

Après HTML4

Avant l’animation 2D, la vidéo ou des piles de JavaScript pour faire du logiciel, HTML5, c’est d’abord du code HTML ! La sémantique est revue, la syntaxe évolue et l’accessibilité est prise en compte.

Nouvelle syntaxe

La modification la plus visible est bien sur l’introduction du nouveau doctype :

<!doctype html>

Cela simplifie les choses et on est même en droit de se demander à quoi servaient les doctypes 4.01 strict ou transitional. Pour la petite histoire, Internet Explorer 6 n’utilisait cette instruction que pour savoir dans quel mode de rendu CSS il fallait se mettre (quirksmode ou mode standard).

Autre simplification : la déclaration de l’encodage de la page.

<meta charset="utf-8">

Certains attributs comme type dont l’absence est universellement bien interprétée peuvent maintenant disparaître :

<script> alert('Iceberg droit devant'); </script>
<style> #titanic { float: none; } </style>

nouvelle sémantique

Plusieurs balises disparaissent carrément car elles ont été accusées de mélanger le fond et la forme. Citons celles qui étaient le plus couramment utilisé : font, center, strike, u, big, frame, frameset ou encore acronym et applet ainsi qu’une petite dizaine d’autres.

Les attributs suivants sont également frappés d’obsolescence :

longdesc et name sur la balise img, scope sur la balise td, classid sur la balise object, target sur la balise link ainsi qu’une dizaine d’autres.

Ont été remplacés pour laisser la place à CSS :

align, bgcolor, background, border, cellpadding et cellspacing sur table, height sur td et th, marginheight et scrolling sur iframe ainsi qu’une vingtaine d’autres.

D’autres changent subtilement de valeur sémantique. Il n’y aurait pas assez de place dans ces colonnes pour ré-expliquer le sens de chacune d’entre elles, aussi prenons la plus célèbre : strong. Avant, elle était censé désigner un mot qui devait se dire avec emphase (sur lequel on mettrait l’accent à l’oral). Cette fonction étant maintenant dévolue à la balise em, strong veut maintenant dire « mot important », ce qui colle avec l’usage effectif qui en était fait aujourd’hui, notamment en référencement.

Enfin et surtout, de nouvelles balises apparaissent, les plus importantes étant les balises dite de section : section, article, aside, header, footer. Elle sont utiles pour préciser un peu les zones de votre site que vous entouriez auparavant d’une div, faute de mieux. Vous pouvez utiliser le chemin de décision suivant pour déterminer la nature de votre balise :

• le contenu est il indépendant du site et peut il être exporté sans ce contexte ? Par exemple un article de blog ou une fiche produit. Dans ce cas là, la balise article est toute indiquée
• le contenu mérite au moins un titre et regroupe des informations sur la même thématique ? La balise section est faite pour ça et vous permet de marquer par exemple des onglets, des modules de news, une zone de commentaires …
• aside, footer et header peuvent être utilisées pour marquer des zones particulières dans les sections que nous venons de voir : un groupe de titres pour header, des métadonnées (copyright, auteur, référence…) pour le footer et des informations complémentaires pour aside (autres articles, produits similaires…)
• La div reste d’actualité pour tous les besoins non couverts

Citons également:

• la balise nav qui marque les liens de navigation de la page (et non d’une section, footer étant plus indiqué pour cela),
• time qui permet de marquer de manière formelle une date (exemple PHP : <time datetime="<?= date( DATE_W3C); ?>">Maintenant !</time>).
• figure et figcaption pour les illustrations et leur description (regardez le code source de cet article)

On le voit, ces nouvelles balises peuvent être mises à profit principalement pour les sites à contenu éditorial (journaux, réseaux sociaux…) voire les sites de e-commerce. Le problème que vous rencontrerez sera que dans les anciennes version d’Internet Explorer vous ne pourrez pas appliquer de style à ces éléments (mettre un display:block sur les balises sectionnantes par exemple). Pour cela il suffit d’un court fix Javascript que vous pourrez trouver sur le net en tapant HTML5 shiv.

microdata

Microdata, présenté plus en détails ailleurs dans ce numéro (NDR : le numéro en question étant payant, je vous propose d’aller directement sur le site édité par Google), se propose de remplacer RDFa et microformat. Si vous ne connaissez pas ces projets, il s’agit simplement de marquer sa page d’une manière beaucoup plus précise et libre que ce que la spécification HTML5 peut prévoir. Si par exemple votre site liste des événements, des recettes de cuisine, des personnes ou des avis vous allez pouvoir indiquer très précisément dans votre page où se trouvent les informations intéressantes. Concrètement vous pouvez définir vos propres vocabulaires ou vous rendre sur http://schema.org (maintenu par Google, Bing et Yahoo!) et choisir le vocabulaire adapté à ce que vous voulez décrire. Puis à l’aide de 3 attributs (itemscope, itemtype et itemprop), vous marquez les éléments importants. Par exemple nous allons marquer précisément une page présentant un profil. On commence par marquer la zone avec itemscope :

<div itemscope>../..
</div>

On déclare ensuite le vocabulaire auquel on va se référer grâce à itemtype et une URL. Ici on va prendre le format hCard, probablement le plus répandu des formats. Notez que l’url pointe sur le site microformats : microformat et microdata sont compatibles car définir un vocabulaire ne consiste jamais qu’à lister des clés et leurs valeurs possibles.

<div itemscope itemtype="http://microformats.org/profile/hcard">
../..
</div>

Enfin avec itemprop vous marquez chaque information de votre markup pour indiquer où se trouve la valeur de chaque partie du vocabulaire.

<div itemscope itemtype="http://microformats.org/profile/hcard">
Vous pouvez contacter <span itemprop="given-name">JP Vincent</span> 
pour toute question HTML5 sur 
<a itemprop="email" href="mailto:jp@braincracking.org">ce mail</a>
../..
</div>

Un programme tel que ceux de Google ou certains plugins navigateur vont lire le markup et associer le nom avec le mail. 

ARIA

ARIA est une spécification axée sur l’accessibilité et permet de proposer des interfaces riches qui restent accessibles aux utilisateurs de technologie d’assistance. A son niveau le plus basique vous pouvez au moins indiquer les zones principales grâce à l’attribut role: les liens de navigations avec role="navigation", le contenu principal avec role="main", les mentions légales avec role="contentinfo", le titre ou le logo avec role="banner"…

A un niveau un peu plus évolué, vous pouvez marquer des interactions plus complexes et néanmoins répandues comme des barres de progression (role="progressbar"), des curseurs (role="scrollbar", role="slider"), des menus, des boîtes de dialogue (role="dialog"). C’est très utile aux technologies d’assistance pour comprendre des zones de l’écran qui sont plus dynamiques que jamais : imaginez que vous ayez un chat en ligne en Web, comme dans l’exemple suivant.

<ol>
	<li>KevinDu75: Kikoo ^__^
</ol>

Sans indication particulière, un lecteur d’écran va lire une seule fois ce code, alors qu’il y a sûrement une routine JavaScript qui met à jour régulièrement cette zone. Avec ARIA, il suffit de rajouter le rôle correspondant (d’après la spécification, c’est log) à cette fonctionnalité classique, et les lecteurs se mettront à lire automatiquement tout dernier élément ajouté au DOM

<ol role="log">
	<li>KevinDu75: Kikoo ^__^
	<li>DarkBlackWarrior666 : LOL !!!!!
</ol>

La bonne nouvelle c’est que certaines librairies JavaScript y compris certains plugins jQuery rajoutent automatiquement des attributs ARIA lorsqu’ils vous proposent des widgets un peu compliqués. C’est à vous de faire attention à ce que l’option soit bien proposée pour garantir une meilleure accessibilité de vos interfaces.

Interaction utilisateur

Les nouveaux formulaires

Les formulaires HTML ont été largement dépoussiérés.
Auparavant on avait surtout des champs de type texte ou mot de passe. HTML5 définit une série de nouveaux types qui se rencontrent couramment sur les formulaires : url, mail, search, date, number&helip; Quel est l’intérêt ? Il offre aux navigateurs et aux technologies d’assistance des points d’attache pour améliorer l’expérience utilisateur : changement de clavier virtuel sur les mobiles pour faciliter la saisie, apparition d’interfaces spécialisées pour sélectionner facilement des dates ou des chiffres …

les adaptations des navigateurs aux champs date et tel

Pour le développeur Web coincé entre PHP et JavaScript il y a ici une vraie opportunité : la validation des données doit bien sur rester côté serveur, et il y a maintenant une manière très simple de réutiliser le même code entre le client et le serveur. Prenons une classe de validation en PHP simpliste que l’on voudrait utiliser, comme ci-après.

<?php
class validation {
	// d'abord on met public l'expression rationnelle pour l'utiliser plus tard
	public static $regMail="^[w-]+(?:.[w-]+)*@(?:[w-]+.)+[a-zA-Z]{2,7}$";
	public static $regNickname="#^[a-zA-Z0-9àáâãäåèéêëìíîïòóôõöùúûüýýÿçñ _-.']{2,50}$#i";
	// fonctions appellées par le serveur
	static function isValidMail( $email ) {
		return preg_match("/".self::$regMail."/",$email));
	}
	static function isValidNickname( $nickname ) {
		return preg_match("/".self::$regNickname ."/",$nickname));
	}
}

On voit dans le listing 4 que l'on a isolé les expressions régulières utilisées pour valider le formulaire dans des variables statiques, et nous allons en fait les réutiliser dans le HTML. En HTML5 nous avons l'attribut pattern pour donner des expressions régulières au navigateur qu'il va exécuter pour vérifier l'entrée utilisateur, comme ci-après.

<form>
	<label >Votre mail : <input type="email" pattern="<?= validation:: $regMail ?>" required />
	</label>
	<label >Votre surnom : <input type="text" pattern="<?= validation:: $regNickname ?"> required />
	</label>
</form>

interface de validation de formulaire, sous Chrome

Sans avoir tapé de CSS ou de javascript, certains navigateurs afficheront l'équivalent de la figure 5 à l'utilisateur. Vous trouverez quelques librairies Javascript qui permettent d'émuler la même chose sur tous les navigateurs.

vidéo native

Les balises audio et video ont été calquées sur le modèle de la balise img : permettre très simplement d'insérer du multimédia dans une page Web. La promesse est bien sur de se passer de Flash pour lire de la vidéo, et d'offrir à vos utilisateurs plus de fluidité (pas de démarrage de Flash ou d'un autre plugin), une meilleure utilisation du CPU sur les environnements que Flash n'adressait pas (Mac OS, Linux, les mobiles) et une interface par défaut qu'ils connaissent déjà. Pour le développeur, pouvoir utiliser JavaScript et CSS pour contrôler une vidéo est très naturel et promet donc de belles intégrations.

Tempérons cela par plusieurs points :

• les implémentations actuelles des navigateurs sont encore un cran en dessous de ce que permet Flash. Notoirement mettre une interface en CSS en vrai plein écran n'est encore possible sur aucun navigateur, il faut pour cela attendre une autre spécification : la Fullscreen API, en cours de test chez Firefox et Chrome
• la guerre des codecs continue de faire rage : le standard de l'industrie vidéo est h.264 et ils n'ont aucune envie d'adapter tous les outils de leur chaîne de production pour le Web. De l'autre côté WebM, pourtant offert à la communauté par Google, ne peut être décodé que sur Firefox, Chrome et Opéra et on attend depuis un an qu'Adobe fasse de même pour que les sites Web n'aient pas à stocker en deux encodages leurs vidéos.
• le W3C n'a pas l'intention d'adresser le marché particulier du streaming payant ou des vidéos protégées, car c'est contraire à la philosophie d'ouverture du Web. Cela signifie que pour ces marchés Flash restera très longtemps la seule technologie utilisable.

En bref, les éléments multimédia sont déjà indispensables sur des environnements où Flash n'est pas présent, et vous pouvez déjà essayer de l'intégrer en complément de Flash sur vos sites Web, mais il est peu probable que ce soit votre seul lecteur.

Géolocalisation

La géolocalisation permet à une page Web de savoir (après autorisation de l'utilisateur) où celui-ci se trouve. Au contraire de la géolocalisation par IP qui peut au mieux vous donner le nom de la ville de votre point d'entrée sur le Net (en ADSL, cela peut être une erreur de 5 kms), les implémentations navigateur se basent sur des données matérielles plus précises :

• sur bureau, l'adresse MAC de la carte Wifi est envoyée sur les systèmes de Google (pour Firefox, Opéra et Chrome) ou de Microsoft, qui ont scanné à grande échelle les zones les plus densément peuplées, et qui y ont associé des coordonnées GPS. En gros, si la « streetview » de Google Maps ou de Bing est disponible pour votre quartier, vous serez repéré précisément (de l'ordre de la centaine de mètres)
• sur mobile, c'est le GPS embarqué qui est directement interrogé. A défaut de GPS, c'est la triangulation par antenne relai.

Dans tous les cas si aucune donnée n'est disponible, c'est au final l'adresse IP qui est utilisée, avec l'imprécision que l'on sait.

Voici un exemple d'implémentation qui essaye d'utiliser l'API du navigateur, mais qui à défaut va utiliser les solutions traditionnelles de détection par IP :

// test du support navigateur
if( navigator.geolocation ) {
	// appel asynchrone à l'API
	navigator.geolocation.getCurrentPosition( function( position ) {
	// l'objet position un sous-objet contient toutes les informations
		console.log( position.coords.latitude,  position.coords.longitude );
	});
} else {
	// retour à une solution moins précise
	var oXHR = new XMLHTTPRequest();
	// appel d'un script PHP qui va récupérer l'IP et trouver la ville
	oXHR.open('GET', '/getlocation.php');
	// on peut supposer que le script répond avec des coordonnées
	oXHR.onload = function( e ) {
		console.log( e.currentTarget.responseText );
	};
	oXHR.send();
}

Les solutions de correspondance IP / ville sont généralement payantes, même si il en existe des gratuites. Elle se présentent sous la forme de script et de base de données à installer chez soi et à exploiter en PHP. Dans l'un ou l'autre cas vous n'êtes bien sur absolument pas certain de la véracité des données. La géolocalisation des navigateurs permet à tout le moins d'avoir une solution IP gratuite, et dans la plupart des cas d'obtenir des informations beaucoup plus précises.

L'API prévoit aussi de demander des coordonnées plus précises, de pouvoir surveiller les déplacements et de fournir des données de vitesse, d'altitude, d'orientation par rapport au nord. Certaines implémentations peuvent également y rajouter la ville ou l'adresse !

Le fait que géolocalisation existe, et marche depuis déjà deux ans est majeur pour les technologies du Web, car c'est la première fois qu'une page Web peut interagir avec le matériel de l'utilisateur, privilège réservé jusqu'ici aux applications natives.

L'ère des applications Web

Websocket et Server Sent Events

WebSocket implémente ce que les développeurs Web devaient jusque là simuler : de la communication temps réel bi-directionnelle entre le client et le serveur. Le protocole HTTP montre en effet ses limites lorsqu'il s'agit d'attendre des informations venant du serveur ou d'écrire un jeu vidéo avec un flux d'informations continu client / serveur. Chaque envoi d'information est encapsulé par parfois plusieurs ko de headers tandis qu'avec websocket il ne s'agit plus que de quelques octect superflus. De plus la connection reste ouverte en permanence ce qui réduit très fortement la latence, chose indispensable pour des applications aussi réactives que des jeux. Il y a un article dans ce numéro qui trait plus en profondeur de WebSocket

Le problème de WebSocket pour le développeur PHP, c'est que cela remet en cause beaucoup de choses côté serveur : les serveurs WebSocket d'aujourd'hui sont écrits dans des langages tels que JavaScript (sur serveur Node.js) qui sont taillés pour exécuter du code de manière asynchrone et qui supportent en théorie des milliers de connexions ouvertes simultanément. Il existe bien une implémentation WebSocket en PHP, mais on ne sait pas vraiment quelle charge elle peut tenir en production, l'empreinte mémoire et la consommation CPU d'un processus PHP étant généralement assez gourmande : après tout pour tenir un socket ouvert, il n'y a pas d'autre moyen qu'une boucle infinie entrecoupée de sleep() et PHP n'a pas été pensé dans ce sens !

A côté de WebSocket, il y a la spécification « Server Sent Events », qui elle ne permet d'avoir que la communication du serveur au client, ce qui peut suffire à la plupart des applications : surveiller un flux twitter, un cours boursier, avoir un dashboard etc … Pour envoyer des informations au serveur, il reste bien sur XMLHTTPRequest, qui est un peu plus lent que WebSocket et qui crée un nouveau thread sur le serveur. En fait SSE remplace efficacement et formalise la technique dite « forever iframe » où PHP et JavaScript gardaient la connexion ouverte via une iframe où du HTML était régulièrement injecté, même lorsqu'aucun événement ne devait être envoyé.

L'avantage de Server Sent Events, c'est qu'elle permet de réutiliser pratiquement le même code côté PHP, avec quelques ajouts que nous allons commenter, tout en optimisant le trafic réseau et en formalisant les échanges de données. Regardons d'abord comment on faisait en PHP pour maintenir la connexion ouverte par une iframe :

<?php
// désactivation des caches navigateurs et proxys
header('Cache-Control: no-cache');
// boucle infinie
while(true) {
	// méthode métier de récupération des données
	$data = my_get_data();
	// encodage en JSON pour interprétation directe en JavaScript
	$data = json_encode( $data );
	// on fait exécuter une fonction JavaScript qui contient nos données
	print '<script> fonction_rappel('. $data .'); </script>';
	// même si les données sont vides, la connexion est maintenue car du HTML est envoyé
	flush();
	// on laisse respirer le CPU avant la prochaine itération
	sleep(1);
}

Voici maintenant les lignes que nous devrions ajouter pour renvoyer des informations à un navigateur supportant SSE :

<?php
// détection du support par le navigateur
$hasSSE = ($_SERVER['HTTP_ACCEPT'] === 'text/event-stream');
// désactivation des caches navigateurs et proxys
header('Cache-Control: no-cache');
// on informe le navigateur qu'on va lui répondre au format SSE
if( $hasSSE === true)
	header('Content-Type: text/event-stream');
// boucle infinie
while(true) {
	// méthode métier de récupération des données
	$data = my_get_data();
	// encodage en JSON pour interprétation directe en JavaScript
	$data = json_encode( $data );
	if( $hasSSE === true)
		// le standard prévoit que les données arrivent après la chaîne data:
		print 'data: '. $data;
	else
		// on fait exécuter une fonction JavaScript qui contient nos données
		print '<script> fonction_rappel('. $data .'); </script>';

	// le standard sépare les données sur plusieurs lignes par un double retour chariot
	print PHP_EOL.PHP_EOL;
	flush();
	sleep(1);
}

On le voit, on envoie simplement un entête supplémentaire, puis chaque ligne de donnée est préfixée par data: (avec ou sans espace), et les blocs de données sont séparées par un double retour chariot.

Côté client il suffit d'instancier l'objet EventSource avec l'URL du serveur et d'écouter les événements, comme ici :

// on se branche sur le PHP
var connexion = new EventSource('/get_data.php');
// programmation événementielle
connexion.onmessage = function( e ) {
	// la propriété data de l'événement contient directement la chaîne JSON qu'on a créé en PHP
	console.log( e.data );
};

L'API va beaucoup plus loin et en plus de la reconnexion automatique gère également :

• les tickets, généralement un marqueur de temps ou un numéro de ligne qui peut servir de repère à PHP lorsque le navigateur se reconnecte,
• des événements nommés, qui permettent de créer des catégories de dialogue,
• des événements comme les erreurs, l'ouverture et la fermeture de la connexion

Il existe d'hors et déjà des librairies JavaScript permettant de simuler l'API Server Sent Events sur tous les navigateurs, et donc de réutiliser votre code PHP.

Offline

De plus en plus d'utilisateurs sont en situation de mobilité lorsqu'ils consultent des sites Web, qu'ils soient sur smartphone ou qu'ils utilisent un laptop dans un café avec une connexion Wifi défectueuse ou inexistante. Le grand avantage qu'ont les applications dites natives, c'est que l'interface se lance immédiatement, qu'il y ait du réseau ou pas. Hors certaines applications Web comme les jeux casual n'ont parfois pas du tout besoin de connexion, tandis que d'autres comme les webmails n'ont besoin d'une connexion que pour aller chercher de nouvelles données.

La gestion de l'offline vise à mettre les applications Web au même niveau que les applications natives en :

• ne faisant télécharger qu'une fois pour toute l'interface et le cœur applicatif,
• donnant de quoi gérer les versions de l'application,
• permettant de réagir et détecter les situations de déconnexion.

Concrètement vous allez référencer un fichier .manifest dans votre HTML :

<!doctype html>
<html manifest="mapage.manifest">
…

Puis vous allez servir ce fichier (avec un entête type mime "text/manifest") qui référence plusieurs choses :

• les dépendance (CSS, JS, images..) à garder pour une utilisation offline (section CACHE) ,
• les URLs qui doivent absolument accéder au réseau (section NETWORK),
• les pages par défaut lorsque le réseau ne répond pas (section FALLBACK)

L'exemple suivant serait une application Web qui n'aurait que deux dépendances, qui irait chercher le reste sur le réseau, et qui affiche la page offline.html pour toute autre requête sans réseau :

CACHE MANIFEST
# v1.0

CACHE
css/styles.css
js/main.js

FALLBACK:
/ offline.html

NETWORK:
*

La déclaration est simple, c'est dans la programmation métier de votre application que les choses se compliquent. Par défaut les navigateurs vont donc afficher la version qu'ils ont en local, puis aller vérifier si le manifeste de cache a changé ne serait ce que d'un octet (c'est pour cela qu'on met généralement en commentaire le numéro de version de l'application). Si c'est le cas, il va télécharger de manière transparente toutes les ressources, qu'elles aient changé ou non, et envoyer un événement Javascript pour dire qu'il a mis à jour le cœur applicatif. Il appartient au développeur de gérer ces états de transition entre deux versions de la même application. Il peut être aidé en cela par une série d'événement JavaScript et de fonctions situées dans l'objet global applicationCache, et qui lui donneront l'état de la mise à jour et un contrôle sur celle ci.

Notons par ailleurs que l'on a accès à la propriété window.navigator.onLine (valeur booléenne), censée donner l'état de la connexion, et aux événements ononline et onoffline, qui avertissent du changement d'état. Malheureusement seul Internet Explorer, et encore à partir de la version 8, implémente de manière utile cette propriété et ces événements.

XHR 2

XMLHTTPRequest a été la base technique à ce que l'on a appelé le « Web 2.0 » et permet de faire des requêtes asynchrones au serveur pour récupérer ou envoyer des informations. Dans HTML5, la version 2 déjà implémentée dans la plupart des navigateurs donne plus de contrôle et d'informations sur les requêtes :

• indications de progression : si la taille totale de votre envoi de fichier ou de votre téléchargement est connue, vous avez accès à l’évènement progress, et aux propriétés total et loaded. Vous pouvez maintenant afficher à votre utilisateur de vraies barres de progression.
• création de formulaires à la volée : l'API FormData permet de créer ou de modifier des formulaires à la volée et le navigateur les formate en mode POST. Ceci permet de gérer facilement l'envoi de fichiers envoyés en drag and drop depuis le bureau ou en sélection multiple, le tout sans rechargement de page

En bref, là aussi cette API modernise les applications Web en faisant évoluer un des outils principaux des développeurs.

Local Storage

Que l'on gère un site Web classique avec des formulaires sur plusieurs pages ou une application Web lourde type google Docs, on a besoin de stocker les informations que l'utilisateur génère, sans forcément passer par le réseau pour stocker ces informations sur le serveur. On pouvait jusqu'ici utiliser les cookies, mais on était limité en taille (4ko tout compris) et on pouvait dégrader sérieusement les performances : sur la plupart des sites les cookies sont envoyés avec chaque requête HTTP et une page Web moyenne est composée de 80 requêtes HTTP, soit un trafic réseau énorme et surtout inutile. La solution préconisée par PHP est d'ailleurs de ne stocker dans le cookie qu'un court identifiant de session, pour retrouver côté serveur les données.

« Web Storage » permet soit de faire tampon, soit d'éviter carrément le trafic réseau ou la gestion de session en offrant aux développeurs un espace pour stocker au moins 5 Mo de données. Utilisez l'API sessionStorage pour un stockage temporaire (vidé à la fermeture de la page) ou localStorage pour un stockage permanent. Dans les deux cas vous pouvez stocker des paires clé/valeur très simplement :

localStorage.setItem('locale', 'fr_FR');
console.log( localStorage.getItem('locale') );
localStorage.removeItem( 'locale');

Seules les chaînes de caractère sont acceptées, donc si vous avez besoin de stocker des données plus structurées, utilisez simplement JSON. Si vous avez besoin d'utiliser cette fonctionnalité sur tous les navigateurs, sachez que vous pouvez utiliser Flash ou des techniques propriétaires de chez Microsoft pour y stocker jusqu'à 100ko de données. Il existe déjà plusieurs petites librairies qui font cette abstraction pour vous.

Le futur

Les navigateurs veulent clairement concurrencer les applications dites natives, voici ce sur quoi ils planchent.

La 3D : avec WebGL, qui permet donc de faire des jeux ou des environnements immersifs le tout en 3D. L'interaction avec le DOM permet même de réutiliser d'autres composants : on peut par exemple utiliser en texture un élément <video> ou le contenu d'une <div> sur des éléments de décor. Certaines sociétés éditrices de jeux vidéos console ou PC travaillent déjà sur cette techno pour trouver de nouveaux canaux de distribution et toucher plus de monde, en pariant sur une plus large diffusion des navigateurs et sur l'accélération matérielle généralisée d'ici 2 à 3 ans.

Le multithread : la spécification Web Workers permet d'exécuter du javascript dans un processus différent du navigateur, et même d'exploiter un second processeur. Cela permet d'avoir des applications avec des calculs lourds telles de la manipulation de photo ou de vidéo, des jeux vidéo ou des applications scientifiques.

L'accès au matériel : la géolocalisation permet déjà d'accéder au GPS des mobiles, getUserMedia permet d'accéder à la caméra, et DeviceOrientation pointe sur les informations du gyroscope. Il y a déjà des implémentations sur Firefox, Chrome et certains mobiles.

Le peer to peer : des expérimentations ont été menées et permettent de faire dialoguer directement deux navigateurs de deux machines différentes sans passer par un serveur pour maintenir la connexion. Oui le prochain Skype pourrait être écrit en JavaScript.

L'accès au bureau : plein écran, notifications, contacts … il y a plusieurs expérimentations autour de ces fonctionnalités qui vont permettre aux pages, pardon aux applications Web de s'intégrer complètement à votre OS, que vous soyez sur mobile ou sur PC classique.

Et je n'ai listé ici que les API qui ont au moins une implémentation, fusse-t-elle expérimentale. L'idée vous l'aurez compris est de donner les pleins pouvoirs aux « sites » Web qui sont aujourd'hui les interfaces privilégiées par le grand public. Cela ne se fait pas sans soulever des questions sur la sécurité, mais le W3C veille et chaque API est prévue pour passer par une demande de permission à l'utilisateur.

Conclusion

HTML5 et les navigateurs apportent toutes ces nouvelles capacités qui rivalisent avec les applications natives. Avec la puissance de diffusion du Web qui est de fait multi-plateforme, HTML5 termine le travail commencé par PHP et Linux car les logiciels de demain pourront être écrits avec des langages non propriétaires. C'est une grande victoire pour le monde du libre.

Références :

Sur Internet

• http://braincracking.org/ – [FR] le site de l'auteur : veille technologique sur HTML5, Javascript et les performances Web,
• http://livre-html5.com/ – [FR] le site du livre HTML5, avec les démos,
• http://html5-css3.fr/ – [FR] formation et tutoriaux à HTML5 et CSS3,
• http://alsacreations.com/ – [FR] tutoriaux, forums et actualité des technos frontend,
• http://html5doctor.com/ – [EN] site d'information sur la sémantique de HTML5,
• http://www.html5rocks.com/ – [EN] maintenu par Google : tutoriaux et présentation générale avec démos de HTML5 au sens large.

javascript == la pornstar des langages de dev: souple, puissant, tu lui fait faire ce que tu veux, et ça peut finir bien crade.

Admettons donc que vous ayez digéré sans problème les portées et les fonctions, passons à deux choses vraiment particulières à JavaScript :

1. le renvoi de fonction qui permet de belles optimisations et qui ouvre la voie à des patterns que les amoureux de la théorie du langage apprécieront,
2. une implémentation de classe statique, pour reprendre le terme utilisé en PHP ou en Java.

Et enfin nous verrons une proposition d’implémentation de deux design pattern célèbres et particulièrement utiles en JavaScript : Singleton et Factory.

Classe statique

Pour rappel, en PHP et dans d’autres langages, une propriété ou une méthode statique peut être appelée sans que la classe n’ait été instanciée pour créer un objet. C’est généralement là que l’on range les constantes ou les fonctions utilitaires par exemple. En JavaScript, tout étant objet y compris les fonctions, cela se fait assez naturellement :

// constructeur
var myClass = function () { 
};
myClass.staticMethod = function() {
	console.log('OK');
};
// que voit on au niveau global ?
myClass.staticMethod(); // OK

Regardez la manière dont est définie staticMethod : on la range directement dans la fonction myClass ! Elle est donc directement disponible sans passer par la création d’un objet. Comparons d’ailleurs avec une définition de méthode d’objet comme on l’a vu dans les paragraphes précédents pour bien comprendre où sont disponibles ces nouvelles méthodes de classe.

// constructeur
var myClass = function () { 
	return { 
		publicMethod:function() {
			console.log('OK');
		}
	}
};
myClass.staticMethod = function() {
	console.log('OK');
};

// que voit on au niveau global ?
myClass.publicMethod(); // Error
myClass.staticMethod(); // OK

// que voit l'instance ?
myObject = myClass(); 
myObject.publicMethod(); // OK
myObject.staticMethod(); // Error 

Si vous exécutez ce code dans votre console, vous allez voir où se produisent les erreurs :

• vous ne pouvez pas accéder à publicMethod sans avoir d’abord instancié myClass,
• l’instance de myClass ne contient pas staticMethod car celle ci est directement disponible à partir du nom de la classe.

Renvoi de fonction

Une fonction peut se redéfinir elle même quand elle s’exécute. Ca a l’air sale dit comme ça, mais nous allons voir un cas concret où cela est bien utile. Imaginez que vous construisez une mini-librairie dont une des fonctions permet de se rattacher à un événement du DOM. Pour supporter tous les navigateurs, il y a deux méthodes aux noms distincts et aux arguments légèrement différents que vous pouvez encapsuler dans une fonction en faisant un simple if.

var onDOMEvent =
	function( el, ev, callback) {
		// le monde de Microsoft
		if(document.body.attachEvent){
			el.attachEvent('on'+ev, callback);
		// le monde du W3C
		} else {
			el.addEventListener( ev, callback, false);
		}
	};

Cette fonction marche très bien, mais à chaque fois qu’elle est exécutée, le test sur la condition aussi est exécutée. Si vous faîtes une librairie vous vous devez de ne pas ralentir les développeurs qui l’utiliseraient. Hors cette fonction pourrait très bien être appelée des centaines de fois, exécutant ainsi inutilement du code. Pour optimiser cela, nous allons redéfinir la fonction à la volée lors de sa première exécution.

var onDOMEvent =
function( ) {
	if(document.body.attachEvent) {
		return function(element, event, callback) {
			element.attachEvent('on'+ event, callback);
		};
	} else {
		return function(element, event, callback) {
			element.addEventListener( event, callback);
		};
	}
}();

Comme vous le voyez :

• cette fonction est auto-exécutée grâce aux deux parenthèses finales, et n’a plus besoin des arguments puisqu’elle ne sera plus jamais exécutée après.
• le if reste, mais il ne sera exécuté qu’une seule fois.
• la fonction renvoie des fonctions anonymes contenant les codes spécifiques au navigateur. Notez que ces fonctions attendent toujours les mêmes paramètres.
• lorsque onDOMEvent() sera appelé, seul l’un ou l’autre corps de fonction sera exécuté, nous avons atteint notre objectif

C’est une technique d’optimisation pas forcément évidente à intégrer mais qui donne de très bons résultats. Cela irait un peu trop loin pour cet article mais si vous avez l’âme mathématique, cherchez donc sur le Web comment calculer la suite de Fibonacci en JavaScript, avec et sans « memoization » (Wikipedia). Vous pouvez également créer des fonctions spécialisées qui capturent certains paramètres pour vous éviter d’avoir à les préciser à chaque fois, technique connue sous le nom de currying (voir ce post de John Resig à ce sujet).
Autre cas concret d’école d’utilisation de cette technique. Partons du code suivant qui boucle sur un petit tableau d’objet et qui rattache l’événement onload à une fonction anonyme.

var queries = [ new XHR('url1'), new XHR('url2'), new XHR('url3')];
for(var i = 0; i < queries.length; i++) { 
	queries[i].onload = function() { 
		console.log( i ); // référence 
	}
} 

Observez bien la valeur de i : notre fonction anonyme crée une portée, le parseur javascript ne voit pas i dans cette fonction, il remonte donc d’un niveau pour la trouver. Jusqu’ici tout va bien notre variable est bien référencée. Pourtant lorsque l’événement onload est appelé par le navigateur, nous avons une petite surprise:

queries[ 0 ].onload(); // 3! 
queries[ 1 ].onload(); // 3! 
queries[ 2 ].onload(); // 3!

L’interpréteur JavaScript a correctement fait son boulot : la fonction onload voit bien i (sinon nous aurions eu undefined), mais c’est une référence vers la variable, pas une copie de sa valeur ! Hors onload n’est appelé qu’après que la boucle se soit terminée, et i a été incrémentée entretemps. Pour fixer cela, nous allons utiliser deux choses :

1. l’auto-exécution, qui va nous permettre de copier la valeur de i
2. le renvoi de fonction pour que onload soit toujours une fonction

Attention, ça peut piquer les yeux :

for(var i = 0; i < queries.length; i++) { 
	queries[i].onload =  function(i) { 
		return function() { 
			console.log( i ); // valeur 
		}; 
	}(i); // exécution immédiate 
} 
// plus tard ... 
queries[ 0 ].onload(); // 0 
queries[ 1 ].onload(); // 1 
queries[ 2 ].onload(); // 2

Essayez de suivre le chemin de l’interpréteur :

• i est donné à la fonction anonyme auto-exécutante
• le paramètre de cette première fonction anonyme s’appelle aussi i : dans cette portée locale, i a pour valeur 0 (pour la première passe)
• la fonction renvoyée embarque toute la portée avec elle et n’a donc que la valeur de ce nouveau i, qui ne bougera plus

Pour info, ce cas d’école est souvent posée lors des entretiens d’embauche si on veut vérifier que vous avez bien compris les portées.

Implémenter des design pattern

En combinant namespace (voir l’article JavaScript pour les développeurs PHP), portée maîtrisée, espace privé et émulation d’objets, nous allons implémenter le design pattern Factory. Factory ou Singleton sont très intéressants en JavaScript, notamment pour les widgets (type jQuery UI) : vous pouvez vous retrouver sur des pages où vous ne savez pas si le JavaScript d’un Widget s’est déjà exécuté sur tel élément du DOM. Pour optimiser, vous ne voulez pas recréer systématiquement le Widget mais plutôt créer une nouvelle instance ou récupérer l’instance en cours. Vous avez donc besoin :

1. d’interdire la création directe d’un objet
2. de passer par une fonction qui va faire la vérification pour vous et vous renvoyer une instance

Commençons par créer notre espace de travail, ainsi que notre namespace:

(function(){
// création ou récupération du namespace et du sous-namespace
MY = window.MY || {};
MY.utils = MY.utils || {};
// constructeur 
MY.utils.XHR=function( url ){
	console.log( url );
};
})();

A ce stade nous avonc une classe accessible de l’extérieur avec new MY.utils.XHR( url );. C’est bien mais pas top, nous voudrions passer par une fonction qui va vérifier s’il n’existe pas déjà une instance avec ce même paramètre URL. Nous allons déclencher une erreur en cas d’appel direct (comme en PHP) et prévoir une fonction getInstance( url ) qui va se rattacher au namespace de la fonction constructeur.

(function(){
// création ou récupération du namespace et du sous-namespace
MY = window.MY || {};
MY.utils = MY.utils || {};
// constructeur 
MY.utils.XHR=function( url ){
	throw new Error('please use MY.utils.XHR.getInstance()');
};
// factory
MY.utils.XHR.getInstance = function( url ) {
};
})();

Enfin nous allons introduire une variable privée qui va contenir la liste de nos instances (un objet currentInstances avec en index l’url et en valeur l’instance). Nous allons également rendre privé notre vrai constructeur.

(function(){
// constructeur 
MY.utils.XHR=function( url ){
	throw new Error('please use MY.utils.XHR.getInstance()');
};

//constructeur privé
var XHR = function( url ){
	console.log( url );
};
// liste privée d'instances
var currentInstances = {};

// factory
MY.utils.XHR.getInstance = function( url ) {
	// déjà créé ? on renvoie l'instance
	if(currentInstances[url]) {
		return currentInstances[url];
	// on crée, on enregistre, on renvoie
	} else {
		return currentInstances[url] = new XHR(url);
	}
};
})();

Telle quelle, cette implémentation permet déjà de créer une factory pour des objets qui ont besoin d’être unique mais qui n’ont qu’un seul paramètre (id d’un objet DOM, URL …). La vraie raison d’être d’une Factory, c’est de gérer des objets complexes à instancier, à vous donc d’étendre ses fonctionnalités. Les puristes auront remarqué que l’objet renvoyé n’était pas du type MY.utils.XHR, et qu’on ne pouvait donc pas faire de vérification avec instanceof du type de l’objet. Honnêtement je ne connais pas de bon moyen de le faire, à vous de voir si c’est un manque dans votre code.
Vous voilà paré à écrire du code un peu plus maintenable et mieux rangé, et vous pourrez crâner dans les dîners en ville en racontant vos exploits de codeur JS orienté objet.

Conclusion

• JavaScript a des concepts différents des langages majeurs et devient extrêmement important sur votre CV. Prenez le temps de l’apprendre
• Les librairies telles que jQuery ne sont pas faites pour couvrir les cas que nous venons de voir. jQuery permet d’utiliser le DOM sereinement, pas d’organiser votre code proprement.
• J’ai essayé d’être pratique, mais lire un post de blog ne suffira jamais pour comprendre des concepts de programmation : codez !

Maintenant que je suis consultant indépendant je retourne dans des équipes qui avaient autre chose à faire que de se demander si on a le droit de parler de classe en JavaScript, quelle est la bonne définition d’une closure, ou quelles sont les fonctionnalités de EcmaScript 5 qui auraient du rester dans Ecmascript.Next.

J’avais déjà parlé sur ce blog de JavaScript et la programmation orienté objet pour les développeurs PHP, nous allons explorer ici les 3 notions fondamentales de JavaScript qui sont probablement les plus grosses sources de bugs, d’incompréhension et de frustration pour le développeur Web moyen. Et qui accessoirement sont la base d’une programmation plus évoluée par la suite.

JavaScript est différent : apprenez le

Le monde du développement Web semble dominé par les langages dérivés de la syntaxe du C, PHP en tête, avec des paradigmes qui se ressemblent. Forcément en abordant JavaScript dont la syntaxe n’est pas vraiment révolutionnaire, on est tenté d’appliquer la même logique. Mais c’est oublier un peu vite que ce langage a été créé il y a déjà 15 ans, quand Java était seulement à mode et pas encore ultra dominant comme aujourd’hui, et qu’il est principalement l’héritier de langages comme Erlang et Lisp, aujourd’hui très peu connus. En fait le mot Java dans JavaScript a été rajouté pour des raisons commerciales, et seuls quelques concepts comme la syntaxe et je crois la gestion des dates ont contribué à former JavaScript. JavaScript n’est donc qu’un cousin éloigné des langages mainstream.

Le maître mot de ses concepteurs semble avoir été la versatilité. Nous allons voir qu’en explorant seulement 3 bases à priori simples, il est possible d’obtenir à peu près n’importe quoi, ce que les grands maître de JavaScript s’amusent tous les jours à faire. En attendant de passer dans la catégorie des maîtres, il faut déjà maîtriser ces bases pour faciliter son travail au quotidien.

Nous allons donc nous baser sur EcmaScript 3 (le javascript de IE6-7-8) dont les trois fondamentaux sont :

• La portée des variables ( var + function)
• Les fonctions
• Le contexte (this)

Commençons par la portée.

La portée des variables

La théorie

La portée, c’est ce que voit l’interpréteur à un moment donné de l’exécution du code. Ouvrez un fichier JS, tapez le mot clé debugger; où bon vous semble, démarrez firebug ou votre outil préféré et cherchez l’onglet « Espions » ou « Watch ».

L'onglet Watch ou Espions de Firebug

La règle pour comprendre comment est créée une portée est très simple :

1 function = 1 portée

Concrètement vous avez la portée globale où tout se trouve (dans un navigateur, c’est window), puis à chaque fonction que vous créez, vous créez une nouvelle portée, et celles ci peuvent s’imbriquer à l’infini. Chaque fois que vous précédez une assignation par le mot clé var, la variable n’est visible qu’à partir de cette portée.

test1 = function() {
	var x = 1;
	test2 = function() {
		var x = 2;
		test3 = function() {
			var x = 3;
			console.log(x); // 3
		}();
	}();
	console.log(x); // 1
}();
console.log(x); // undefined

Si vous exécutez le code précédent dans votre console JavaScript, vous constaterez 3 choses :

• le console.log le plus profond affiche bien sur la dernière valeur de x, à savoir 3. Dans ce troisième niveau, on a écrasé les valeurs précédentes de x.
• malgré cet écrasement à un niveau inférieur, le second console.log (qui affiche 1) montre bien que les nouvelles valeurs de x ne sont pas visibles depuis la première fonction.
• enfin le dernier console.log est fait au niveau global, en dehors des définitions de fonction. Ici x n’existe même pas.

La pratique

Nous avons vu comment le couple var + function permet de définir une portée et empêche le code en dehors de la portée de voir certaines variables. Pourquoi ne pas tout mettre au niveau global ? Pour des raison d’organisation du code et de maintenabilité ! Imaginez le code suivant :

function genericFunctionName() {
	for(i = 0; i < myArray.length; i++) {
		console.log(i);
	}
}
for(i = 0; i < 10; i++) {
	genericFunctionName();
}

Nous avons simplement une fonction qui parcourt un tableau fictif, puis nous appelons cette fonction 10 fois. N’exécutez surtout pas cela dans votre navigateur, car c’est une boucle infinie !

En fait les deux boucles for utilisent le même nom de variable (i) pour compter les tours. C’est un nom extrêmement commun et ça ne poserait pas de problème si les deux boucles ne pointaient pas sur la même variable ! Fixons cela.

function genericFunctionName() {
	for( var i = 0; i < myArray.length; i++) {
		console.log(i);
	}
}
for(i = 0; i < 10; i++) {
	genericFunctionName();
}

Dans la fonction, nous avons rajouté le mot clé var pour spécifier que la variable n’appartenait qu’à cette fonction. Les deux bouclent ne pointent plus sur la même variable même si leurs noms sont les mêmes. C’est très important pour le développeur de savoir qu’il est le seul maître sur les variables qu’il crée pour créer un code particulier. Ceci nous donne la première application concrète des portées.

Créer son espace de travail sécurisé

En tant que développeur, vous allez créer ou modifier du code sur des pages dont vous ne maîtrisez pas l’environnement. Entre l’historique du code, vos collègues et les publicités ou les widgets, beaucoup de variables sont créées ou écrasées au niveau global sans que vous ne puissiez le prévoir. Au milieu de cette tourmente, je vous propose de vous créer un petit havre de paix :

(function() { 
}()) 

Je vous conseille de démarrer tout fichier javascript ou tout code entre balise <script> par la première ligne et de toujours terminer par la dernière. Ce bout de code vous permet de poser les bases de votre portée et de créer des variables qui n’appartiennent qu’à vous, sans pour autant s’isoler du reste du monde.

(function() {
	var privateVariable = true;
	window.init = function() {
		console.log( privateVariable );
	}
}())
init(); // true
console.log(privateVariable); // undefined 

Exécutez ce code, et vous verrez que privateVariable n’est pas accessible de l’extérieur, mais que le code défini à l’intérieur permet d’y accéder. Très pratique en environnement hostile. Vous remarquerez aussi que l’on rattache la fonction init directement à la portée globale, afin qu’elle soit elle aussi visible de l’extérieur.

Les fonctions

C’était si simple …

Il est facile de créer une fonction et de l’exécuter. Les syntaxes que vous utilisez au quotidien sont celles ci :

// création v1
function action() {}
// création v2
action = function() {};
// exécution
action();

Simple non ?

La fausse bonne idée

Au fait quelle est la différence entre les deux manières de déclarer une fonction ? Pour la première ( function nom() ) le compilateur JavaScript extrait toutes les définitions et les met à disposition au niveau global AVANT de commencer l’exécution. Concrètement vous pouvez même exécuter la fonction avant qu’elle ne soit créée dans la source.

// exécution avant la définition !
action();
// création
function action() {}

Cool ? Pas vraiment : c’est systématiquement la dernière déclaration dans la source qui est prise en compte par les interpréteurs JS. Vous ne pouvez pas conditionner la définition des fonctions. Par exemple le code suivant ne va pas s’exécuter comme vous pourriez le penser :

if( 1 == 1 ) {
	// l'exécution du code passe ici ...
	function action() {
		console.log('a == 1');
	}
} else {
	// ... pourtant le compilateur se souvient de cette fonction
	function action() {
		console.log('a != 1');
	}
}
action(); // a != 1 

Lors de l’exécution, l’interpréteur passe bien dans le premier if et pourtant c’est la seconde définition qui est retenue, uniquement parce qu’elle arrive en dernier dans la source.
Et malgré cela, contrairement à d’autres langages, la déclaration d’une fonction n’est valable que pour la portée en cours et ses descendantes. Dans le code suivant, la fonction action n’est pas visible au niveau global :

(function() {
	function action() {
		console.log('action');
	}
}())
action(); // undefined

La manière traditionnelle de déclarer les fonctions est donc assez trompeuse et de ce fait tombe doucement en désuétude. Pour des débutants on utilisera plutôt la seconde méthode qui a le mérite de pouvoir explicitement choisir la portée de ses fonctions, au même titre qu'une variable

var action = function() {};

En ce qui concerne le compilateur cette syntaxe est une variable avec pointeur sur une fonction anonyme. Le désavantage est que lorsque vous utilisez un débogueur pas à pas, la pile d'appels (call stack) ne vous affiche pas le nom des fonctions (l'anonymat sur Internet existe donc). Vous pouvez retrouver le nom de la variable assignée simplement en cliquant sur la fonction et en regardant dans la source.

Particularités Javascript

JavaScript a rajouté plusieurs particularités aux fonctions qui les rendent terriblement puissantes et flexibles. En fait toutes les constructions de code un peu élaborées telles que l'orientation objet ou l'application de design pattern se basent sur ces spécificités. Nous entrons donc dans le coeur de JavaScript.

Auto-exécution

En rajoutant simplement une paire de parenthèses après une déclaration, la fonction va immédiatement être exécutée.

var autoInit = function() {
	console.log('hello world');
}();
// hello world

Comme nous l'avons vu tout à l'heure, cela vous permettra principalement de créer des portées, pour protéger l'ensemble de votre script, et nous allons voir dans une minute que vous pouvez aussi l'utiliser dans certains cas particuliers.

Classe ou fonction ?

En JavaScript, tout est objet. Un objet n'est jamais qu'une collection de clés et de valeurs, et les valeurs peuvent être tout et n'importe quoi y compris d'autres objets. Lorsqu'une fonction est créée, automatiquement JavaScript y rajoute la propriété prototype. Tapez le code suivant dans votre console JavaScript :

var myFunction = function() {};
console.log( myFunction.prototype ); // Object

Nous avons donc un objet myFunction.prototype et nous pouvons directement y accéder pour y rajouter des valeurs, comme d'autres fonctions par exemple. Ensuite pour accéder à ces fonctions, nous allons utiliser le mot clé new.

// cette innocente fonction devient un constructeur
var myClass = function () {
	this.publicVariable = 0;
};
// accès au prototype
myClass.prototype = {
	decrement:function() {
		console.log( --this.publicVariable );
	},
	increment:function() {
		console.log( ++this.publicVariable );
	}
};

myObject = new myClass();
myObject.decrement(); // -1
myObject.decrement(); // -2

myObject2 = new myClass();
myObject2.increment(); // 1
myObject2.increment(); // 2

Entre nous, nous venons de créer quelque chose qui ressemble furieusement à une classe, avec une instanciation (new myClass), des variables propres à chaque instance ( this.publicVariable ) et un constructeur (le corps de la fonction).

Orienté objet ?

Si vous trouvez bizarre qu'une fonction se transforme soudainement en classe puis en objet, attendez de voir la suite. Toujours grâce à la notion du tout objet de JavaScript, nous pouvons également faire de l'héritage ! Là encore, en utilisant .prototype, nous allons créer une nouvelle fonction (ou classe) qui va hériter des méthodes de la première. Outre la déclaration de la nouvelle fonction, cela ne va prendre que deux lignes.

mySubClass = function() {
	// maintenant on part de 10 au lieu de 0
	this.publicVariable = 10;
};
mySubClass.prototype = myClass.prototype;
mySubClass.prototype.constructor = mySubClass;

myObject2 = new mySubClass();
myObject2.increment(); // 11
myObject2.increment(); // 12

La première ligne après la déclaration de fonction fait pointer l'objet .prototype de notre nouvelle fonction vers l'objet .prototype de la classe mère, empruntant ainsi toutes ses propriétés. La seconde ligne est là pour rectifier un défaut de l'écrasement de .prototype : on refait pointer .prototype.constructor (encore une propriété automatiquement créée pour toutes les fonctions) vers le bon constructeur.

Slip ou caleçon ?

Pardon je voulais dire : pour les classes, vous êtes plutôt prototype ou closure ? On vient de voir que grâce à .prototype on pouvait émuler une classe en JavaScript. Les fonctions peuvent également renvoyer des objets simples contenant des propriétés et des méthodes, et la manière de les utiliser se rapprochera toujours terriblement d'une classe.

myClass = function () { 
	// variable privée !
	var privateVariable = 0; 
	// méthodes publiques
	return { 
		decrement:function() { 
			console.log( --privateVariable ); 
		}, 
		increment:function() { 
			console.log( ++privateVariable ); 
		} 
	} 
};
myObject = myClass(); 
myObject.decrement(); // -1 
myObject.decrement(); // -2 
myObject2 = myClass(); 
myObject2.increment(); // 1 
myObject2.increment(); // 2

Plusieurs différences par rapport à la version prototype :

• Notez le return {...} dans la définition de la fonction : vous pouvez y mettre exactement ce que vous auriez mis dans le prototype.
• Vous pouvez utiliser la portée de la fonction constructeur pour avoir des variables privées (ici var privateVariable), alors qu'il n'est pas possible d'avoir des variables privées avec prototype
• Lorsque vous instanciez votre classe, vous n'avez plus besoin d'utiliser new myClass(), un simple appel sans new suffit.
• Le mot clé this désigne l'objet renvoyé, alors qu'avec prototype il désignait le corps de la fonction constructeur. Généralement avec closure on n'utilise plus du tout this
• la création des fonction est évalué à chaque fois que vous invoquez la fonction constructeur, tandis que ce n'est fait qu'une seule fois avec prototype. N'utilisez jamais closure avec des objets qui peuvent être instanciés des centaines de fois.

Voilà pour l'essentiel sur les fonctions : avec cela vous maîtrisez déjà leur portée et vous pouvez commencer à développer orienté objet, ce qui va vous permettre d'éviter beaucoup de bug et d'avoir un code plus maintenable.

Le contexte ou this

this est le petit mot clé qui perd beaucoup de développeurs, notamment lorsque l'on est habitué aux dérivés du C comme PHP. En JavaScript comme ailleurs, il fait référence au contexte d'exécution, donc le code suivant s'exécutera probablement comme vous vous y attendez :

myClass = function() { 
	this.id = 'myClass'; 
} 
myClass.prototype = { 
	action:function() { 
		console.log( this.id ); 
	} 
}; 
myObject = new myClass(); 
myObject.action(); // 'myclass'

Ici on a défini dans le constructeur this.id avec une certaine valeur, puis on instancie la classe (new myClass()) et la méthode action() accède tout naturellement à this pour retrouver la valeur de id.
Pourtant lorsque vous voulez exécuter myObject.action au clic sur un élément du DOM, plus rien ne marche comme prévu.

document.body.onclick = myObject.action; 
// document.body.id
 

Vous pouvez exécuter les deux bouts de code précédent dans votre console JavaScript et cliquer sur la page, vous verrez que this.id n'est plus 'myClass' mais fait référence à l'id du body, qui n'existe peut être même pas. Ceci n'est pas particulier au DOM d'ailleurs, imaginez que vous créiez un autre objet qui aurait un événement onfire que vous auriez besoin d'écouter :

myEvent = { 
	id:'myEvent' 
};
myEvent.onfire = myObject.action; 
myEvent.onfire(); // 'myEvent' au lieu de 'myClass'

Lorsque onfire() s'exécute, il exécute bien le corps de la fonction action, mais comme pour les objets du DOM, this fait référence à l'objet d'où est exécutée la fonction, pas forcément à l'objet d'origine de la fonction.
Ceci est du à la versatilité de JavaScript qui permet de très simplement copier le corps d'une fonction d'un objet à l'autre, alors que dans les langages traditionnels orienté objet il vous faut explicitement faire de l'héritage. Comment fixer cela ? Il y a au moins deux méthodes.

Changement de contexte (natif)

La première méthode est native à JavaScript et utilise la fonction .call(). Ici seule la dernière ligne a changé :

myClass = function() { 
	this.id = 'myClass';
} 
myClass.prototype = { 
	action:function() { 
		console.log(this.id); 
	} 
}; 
myObject = new myClass(); 
myEvent = { 
	id:'myEvent' 
};
myEvent.onfire = myObject.action; 
myEvent.onfire.call( myObject ); // myClass

Le premier argument de la fonction .call() est l'objet qui sera utilisé pour this. Ici on redonne à onfire l'objet d'origine de la fonction action.
Le problème avec cette solution, c'est qu'il faudrait que vous soyez certain que TOUS les endroits où votre fonction peut être appelée vont rectifier le contexte d'exécution. Hors ne serait ce que pour les événement natifs du DOM cela n'est pas possible, sauf si vous utilisez une bibliothèque de manière systématique. Donc faire confiance à this n'est raisonnable que si vous maîtrisez parfaitement tout le code qui sera écrit.

Conservation du contexte (à la main)

Pour éviter ces problèmes de maintenance, la solution en vogue est de tout simplement ne jamais utiliser this directement et de préférer utiliser la syntaxe closure et une variable privée pour définir ses classes.

myClass = function() { 
	this.id = 'myClass';
	// capture du contexte
	var me = this;
	return {
		action:function() {
			console.log( me.id );
		}
	}
};
myObject = myClass(); 
document.body.onclick = myObject.action; 
// 'myClass'

On voit donc ici :

• dans le constructeur, on capture le contexte avec une variable privée : var me = this
• dans la fonction action on n'utilise plus this mais me

Peu importe l'endroit d'où est lancé la fonction (ici au clic sur la page), et peu importe la valeur réelle de this, on est maintenant certain que l'on aura toujours un accès à l'objet originel grâce à une variable privée. Bien sur this reste utilisable normalement, notamment si vous avez besoin de retrouver l'objet DOM cliqué par exemple.

Pour encore plus de souplesse avec les fonctions de JavaScript, allez voir la deuxième partie de cet article.

L'essentiel

Si vous ne deviez retenir que quelques points, les voici :

• JavaScript a des concepts différents des langages majeurs et devient extrêmement important sur votre CV. Prenez le temps de l'apprendre
• Les bibliothèques telles que jQuery ne sont pas faites pour couvrir les cas que nous venons de voir. jQuery permet d'utiliser le DOM sereinement, pas d'organiser votre code proprement.
• Lorsque vous créez une classe, choisissez la syntaxe prototype pour la performance ou closure pour les variables privées et la maîtrise du contexte d'exécution
• N'utilisez plus la syntaxe function maFonction() {}
• Utilisez systématiquement la fonction anonyme auto-exécutée ( (function() { var .. }())) en début et fin de fichier ou de <script>
• Utilisez systématiquement var pour vos variables, y compris celles qui font référence à des fonctions

Dernière chose : j'ai essayé d'être pratique, mais lire un post de blog ne suffit jamais pour comprendre des concepts de programmation : codez !

Mes capacités d‘orateur valent ce qu‘elles valent, mais le contenu et le discours restent d‘actualité et devraient permettre je l‘espère à certains développeurs de se décoincer face à HTML5 : les fonctionnalités sont utilisables maintenant en production, pour peu qu‘on sache coder, utiliser des librairies faites pour ça et qu‘on soit suffisamment curieux pour tester tout cela. Les bénéfices sont soit immédiats soit à venir, et il y a certains écueils à connaître.
Le maître mot est : testez ! Dans la plupart des cas vous vous rendrez compte que vous pouvez mettre en production et donc améliorer votre site pour vos utilisateurs.

Le chapitrage

La conférence :

• 0:05 : bonjour
• 1:10 : relativisier l’état des specs
• l‘exemple de Web Storage
  • 3:00 : 7 implémentations, mais utilisable
  • 4:30 : librairies d‘accès à Web Storage
  • 5:40 : Exemples d’utilisation de Web Storage
• 6:25 : HTML5, c’est gros, et alors ?
• La nouvelle sémantique
  • 8:30 : le doctype
  • 9:20 : nouvelles balises (nav, article, header, légendes …
  • 13:30 : microdata
  • 16:15 : nouveaux types de champs de formulaire
• 18:55 : les APIs JS
  • 19:25 : est on vraiment dans la nouveauté ? Listing des fonctionnalités qui ont déjà un équivalent
  • 21:57 : comportement des formulaires, démo de librairies sous IE6
  • 24:00 : intérêt d’utiliser quand même le standard HTML5 pour les formulaires
• 27:05 : Géolocalisation navigateur : démo et intérêt par rapport à la géolocalisation par IP, alternative
• 32:00 : SVG : Démo sur IE6 grâce à la librairie raphaelJS
• 34:20 : La vidéo HTML5 : limites et librairies
• 36:30 : Drag and Drop et sélection multiple : démo IE6 (applet, flash), retour d’implémentation en prod, transcodage en HTML5
• 41:10 : conclusion : partez sur les standards, utilisez les librairies, jouez et testez

Vu mon débit de parole lorsque je suis sous le feu de la rampe j‘ai terminé 10 minutes avant l‘heure prévue. La scéance de question / réponses a donc pu être longue et très intéressante :

• 44:10 : la remarque qui tue à propos de l‘accessibilité actuelle de HTML5 par Aurélien Levy (j’ai développé ses argument dans ce post sur l’accessibilité de HTML5). Pour résumer : je maintiens que à part 2 bugs, l‘accessibilité n‘est pas dégradée même pour IE6.
• 47:30 : remarque sur la surenchère de librairie JS sur les formulaires chez certaines sociétés
• 49:20 : on revient sur ma mauvaise opinion de l‘implémentation de la vidéo HTML5
• 51:20 : ARIA sera t il toujours utile ? (oui)
• 52:00 : on re-discute de l‘accessibilité de HTML5 entre pros
• 53:45 : HTML5 boilerplate
• 54:05 : question sur l‘interprétation du doctype HTML5 par IE6 (réponse mal dite : IE n‘a que 2 modes, standard ou quirskmode)
• 55:25 : inquiétude sur les failles de sécurité des librairies

La vidéo

Les slides

Les slides vus à la conférence sont ceux ci :
HML5 c‘est maintenant (IE6 inclus)

Vous trouvez 3 fois plus de détails concernant HTML5 dans une autre série de slides, avec notamment le détail de Audio/Video, un exemple de microdata, le détail du problème des nouveaux éléments et du localStorage et une implémentation de géolocalisation. Bref, à regarder au calme chez soi pour se former.

Une suite ?

Ma prochaine conf sur HTML5 sera plus petite, mais complémentaire de celle ci : à la Kiwi Party organisée par Alsacréations, j‘essaierais de montrer qu‘intégrer HTML5 dans son processus de fabrication de site ne devrait rien changer tant qu'on respecte déjà les bonnes pratiques.
En parallèle mon projet actuel tourne uniquement autour du passage à HTML5, j‘aurais l‘occasion de vous en reparler dès qu‘il pourra être rendu public.

Autant vous le dire tout de suite, mes conclusions sont mitigées, et il se peut même que je revienne sur ce que j‘affirmais à l‘époque.

Quel HTML5 ?

Le terme commençant à être flou, il vaut mieux le préciser à chaque fois qu’on l’évoque : pour une fois sur ce blog le HTML5 dont nous parlerons dans cet article représente uniquement la spécification adoubée par le W3C, celle qui représente l‘évolution de HTML4 avec les nouvelles balises, le nouvel algorithme de parsing, canvas et le multimédia.

Les nouvelles balises

Leur apport

Les balises comme article, time, header, nav ou figure apportent de la sémantique à votre page. Cela signifie concrètement plusieurs choses :

• une meilleure lisibilité du code, ce qui est important pour ceux qui l’écrivent et facilite la maintenance
• une (future) exploitation facilitée pour les tiers : Readability (Application de lecture, service de rétribution des auteurs de blogs) se base sur ces nouvelles balises (ou sur microformat) pour tirer les informations des articles des pages. Il est difficile de trouver d‘autres exemples pour le moment.
• un (futur) meilleur référencement : la position officielle de Google sur le sujet est qu‘ils adaptent leurs algos à toutes les pratiques émergentes. Si beaucoup de sites utilisent article, google finira par l‘interpréter.
• une (future) meilleure accessibilité : les navigateurs vont rajouter automatiquement des rôles ARIA sur certaines balises. Ce tableau vous montre le support actuel, il est aujourd‘hui très limité : Firefox 4 pour certaines balises, Opéra pour les formulaires sont leaders

Bref, les apports immédiats pour tous les sites ne sont pas évidents. Il y aura tout de même un bonus pour ceux qui jouent l‘innovation et y passent avant les concurrents lorsque ces lecteurs de code source (services, moteurs de recherche, navigateurs) exploiteront cette mine d’informations.

Les problèmes

Le reproche principal fait aux nouvelles balises, c‘est que IE6-8 font disparaître du DOM les éléments qu‘il ne connaît pas, et donc ne les présentent pas aux technologies d‘assistance. Le moyen de contourner cela est connu, facile à mettre en place et bullet-proof mais il induit une dépendance envers JavaScript. Les derniers chiffres français pris sur la homepage de Yahoo! font état de 1.5% d‘utilisateurs dans cet état. La part de marché de IE est d‘environ 50%, cela vous laisse avec 0.7% d‘utilisateurs que cela peut gêner parmi vos visiteurs handicapés.

A ma connaissance, il y a 2 autres choses qui ont donné une mauvaise réputation à ces nouveaux éléments :

• une combinaison de certaines versions de JAWS et de Firefox avait un bug qui faisait disparaître le contenu situé dans une balise <header>. En plus de la perte brute de contenu, selon où elle est placée, <header> peut contenir des titres ou des liens, 2 éléments fondamentaux pour la navigation avec les technologies d‘assistance.
• Une autre combinaison, celle de versions de Windows-Eyes et d‘Internet Explorer, n‘arrivait pas à lister les liens à l‘intérieur d‘éléments HTML5 avec une balise role. C‘est très spécifique mais là aussi il y a perte d‘éléments de navigation fondamentaux.

Doit on changer sa manière de coder parce 2 logiciels buguent ? Historiquement les développeurs Web ont toujours répondu oui à cette question, en changeant leur code pour s‘adapter aux bugs de IE par exemple. Sauf que IE est officiellement supporté par tous les sites Web alors que ce n‘est pas le cas pour ces 2 logiciels. Même si ces bugs ont été corrigés, ils restent majeurs (perte de contenu). Je n‘ai pas de chiffre sur le taux de pénétration de ces versions buguées, mais les seuls chiffres publics que j’ai pu trouver montrent que 25% de ces utilisateurs n‘ont pas mis à jour leur version après un an, ce qui signifie qu‘il faut prendre en compte ces bugs plusieurs années.

En conclusion : l‘introduction des nouvelles balises est surtout compromise par des bugs majeurs de certains logiciels importants et votre sentiment sur la dépendance à JavaScript (que vous devriez d‘ailleurs mesurer sur votre site). Elle est à mettre en balance avec les avantages de ces balises, qui eux ne sont pas immédiats.

Les zones de navigation

L‘introduction des balises nav, header, footer et aside est très intéressante car elle permet au navigateur de fournir aux technologies d‘assistance une carte de la page. Jusqu‘ici les utilisateurs de ces technologies naviguaient principalement avec la liste des titres et la liste des liens d‘une page, ils pourraient également avoir accès automatiquement aux zones classiques présentes sur les sites Web.

Première ombre au tableau, HTML5 définit un mapping strict entre certaines balises et des rôles de zone ARIA, mais sur ces zones là il n‘y a pas de rôle par défaut. Il y a donc contradiction entre la spécification et les rôles que les navigateurs devraient automatiquement implémenter ( <nav role="navigation">, <header role="banner">, <footer role="contentinfo">, <aside role="complementary">). Qui dit contradiction dit mésentente possible entre navigateurs.

Ensuite vient le support : la traduction automatique des balises en rôle de zone ARIA par les navigateurs arrive à peine, Firefox 4 étant pour le moment seul. Par contre ARIA est bien supporté par les versions récentes des lecteurs d‘écran. Sauf que comme pour les navigateurs, les clients de ces logiciels mettent un certain temps avant de passer aux nouvelles versions.

Enfin, ces rôles et ces balises sont censées permettre la disparition des liens d‘échappement, bonne pratique d‘accessibilité reconnue. Mais ça serait oublier ceux qui n‘utilisent pas ces logiciels, mais qui naviguent tout de même au clavier (choix, accident de souris, mauvais matériel, certains mobiles …). A ma connaissance les navigateurs n‘ont pas prévu de fonctionnalité pour ces utilisateurs en leur mettant à disposition des raccourcis vers ces zones.

En conclusion : la technique du lien d‘évitement restera très longtemps un moyen de navigation plus universel. Si vous ne la pratiquiez pas, utiliser les nouvelles balises maintenant apportera naturellement de l‘accessibilité au fur et à mesure du déploiement des nouvelles versions de navigateurs et de technologie d‘assistance

Le multimédia

Les éléments audio et video natifs ont fait rêver un peu tout le monde, et sur le papier règlent d‘épineux problèmes. En pratique c‘est beaucoup plus compliqué (sur mon projet, nous avons jugé que les implémentations navigateur ne valaient pas encore Flash) et l‘accessibilité n‘est pas en reste. Les implémentations des navigateurs concernant la navigation clavier sont variées, parfois buguées et parfois inexistantes.

Les sous-titres ne sont implémentés nativement nul part et les spécifications ont vraiment beaucoup bougé à ce sujet. Difficile de savoir si le consensus actuel autour de l‘élément track et le format WebSrt va rester.

Comme vous devez de toute manière fournir une lecture de la vidéo en Flash, qui lui est naturellement encore moins accessible (il pourrait, mais les flasheurs ne le font pas), votre seule option est de coder vous même un lecteur vidéo accessible, en sortant les contrôles du lecteur (natif ou Flash) pour en faire des éléments HTML marqués avec ARIA, et d‘implémenter votre propre solution de sous-titrage en Javascript. Mais vous sacrifiez l‘option fullscreen, ce qui est rarement toléré.

Conclusion : les balises video et audio sont vraiment trop jeunes concernant l‘accessibilité, et il n‘y a pas de gros bénéfice à en tirer sur les navigateurs de bureau. Flash étant pire, vous devez améliorer vous même les choses en codant un player accessible ou en espérant en trouver un dans cette longue liste.

Les titres

HTML5 définit un algorithme pour déterminer le vrai niveau des Hx d‘une page. Concrètement si vous mettez un h1 dans une balise section ou article qui n‘est elle même pas enfant d‘une autre balise sectionnante, alors votre h1 est en fait un h2. C‘est très pratique pour ceux qui développent des sites Web de façon modulaire : on ne s‘occupe que de la hiérarchie interne d‘un bout de page, sans avoir à se demander quel est le nombre de niveaux de titre déjà introduit. Pour voir cet algorithme en action, vous pouvez utiliser l‘outil HTML5 outliner.

En quoi est ce important ? les titres sont la première manière de naviguer sur une page lorsque l‘on utilise un lecteur d‘écran et selon le moteur HTML utilisé, la hiérarchie interprétée ne sera pas la même, et vous ne pouvez rien y faire. Honnêtement si vous n’aviez pas prêté attention à la hiérarchie globale des titres jusqu‘à présent, HTML5 vous aidera au contraire à mieux vous organiser module par module et obtenir au final quelque chose de cohérent au moins sur les nouveaux navigateurs. Si vous aviez une belle hiérarchie, alors pour la conserver sur tous les navigateurs, il vous faudra éviter les balises sectionnantes comme article, section ou aside.

Cela dit, une hiérarchie bien maîtrisée de titres n‘est réellement importante que si la page comporte beaucoup de titres, par exemple sur des sites à fort contenu textuel (longs articles de journaux, encyclopédie …). La plupart des sites se contentent d‘une vingtaine de titres de niveau 1 et 2.

Conclusion : Si vous ne gériez pas votre hiérarchie parfaitement au niveau de la page (site très modulaire, maintenu par plusieurs personnes ou par méconnaissance), autant passer directement à la logique HTML5, vous devrez vivre avec une hiérarchie de titres différente selon le navigateur. Si vous aviez une belle hiérarchie et beaucoup de titres, alors pour la conserver sur tous les navigateurs, il vous faudra éviter les balises sectionnantes comme article, section ou aside.

Canvas

Canvas est effectivement un trou noir d‘où rien ne sort, et ironiquement même Flash peut être plus accessible que cette balise (encore une fois, si le développeur Flash a fourni un effort supplémentaire). Seul IE9 permet d‘accéder au shadow DOM, mais en supposant que tous les navigateurs fassent de même, la question de l‘intérêt se pose : pourquoi accéder à des paquets de pixels ? Si vous l‘utilisez pour obtenir des effets graphiques décoratifs, un contenu alternatif textuel peut suffire. Si vous l‘utilisez pour la navigation, vous vous êtes probablement trompé de technologie. Si votre application repose de manière justifiée sur cette technologie, comme pour un jeu, alors il me semble de toute façon impossible de rendre accessible ce type d‘application très graphique.

Conclusion : ressortez donc les bonnes pratiques, fournissez un contenu alternatif si c‘est possible et évaluez bien vos besoins : SVG / VML ou une navigation scriptée peuvent suffire.

Passer à ARIA

Ma conclusion personnelle est qu‘il faut rajouter ARIA et ses multiples rôles à votre page HTML5. Voici ce que j‘utilise occasionnellement pour tester l‘ajout d‘ARIA ou pour vérifier l‘accessibilité d‘une page. Pour tester ARIA, il vous faut un Windows, un Firefox et un Internet Explorer 8 qui sont les 2 navigateurs les plus utilisés par les clients des lecteurs d‘écran. Ce sont également les 2 navigateurs qui supportent le mieux ARIA. En lecteur d‘écran JAWS par Freedom Scientific est clairement le leader du marché, suivi par Window-Eyes de GW Micro. Ils offrent tous deux des version d‘essai gratuit dont la limite est que vous devez redémarrer Windows toutes les 40 minutes. Astuce : utilisez des machines virtuelles, et la fonctionnalité snapshot pour vous éviter ces redémarrages fastidieux. Vous pouvez également utiliser un lecteur d‘écran open-source : NVDA ainsi que la toolbar Juicy Studio Accessibility Toolbar pour Firefox qui permet de vérifier ses zones pendant le développement.

Conclusion

Vaste sujet que l‘accessibilité de HTML5, et j‘imagine (j‘espère!) que des experts accessibilité passeront sur ce blog pour me corriger ou rajouter d‘autres difficultés. En conclusion :

• il me faut l‘admettre, l‘introduction des nouvelles balises peut causer des bugs majeurs ou gêner des logiciels de lecture d‘écran. Ces bugs et cette gêne de la hiérarchie sont là pour plusieurs années tandis que les avantages des nouvelles balises ne sont pas encore massivement arrivés. A vous de voir
• l‘utilisation des balises video et audio est prématurée à tous les points de vue
• il va falloir encore du temps avant que HTML5 vous apporte plus d‘accessibilité que ARIA. Soit vous passez à ARIA immédiatement, soit vous pariez sur le futur

Si le ton négatif de ce billet vous fait conclure qu‘il ne faut pas utiliser HTML5, alors je vous invite à me relire : j’ai principalement listés les problèmes afin que vous sachiez à quoi vous vous engagez en restant sur les techniques actuelles ou en partant sur certaines nouveautés de HTML5. HTML5 au sens des applications Web avec toutes ses nouvelles APIs JS ne sont ici pas concernées.

• 0 à 10:30 : relation chiffre d’affaire et temps d’affichage
• 10:30 : référencement et webperf
• 12:30 : quelles sont les mesures à prendre en compte ?
• comparaison affichage 01net / evene.fr
• utilisation webpagetest.org
• 21:20 : contre-performance du protocole HTTP, parallélisation et latence
• 24:20 les JS/CSS (outil cuzillion), quels navigateurs tester ?
• 33:58 : outils pour JS/CSS
• 41:40 : organisation du code JS (bottom, loader)
• 48:10 : minifier le HTML ?
• 49:59 : checklists des recomandation webperf
• 50:30 : sprites ou encodage des images ?
• 55:30 : les images en PNG
• 57:00 : gzip
• 59:00 : interlude
• Outils
• 1:00:30 : firebug, ySlow, pageSpeed et cuzillion.org
• 1:03:50 : démo (plantée) de AOL pageTest et fallback sur webpagetest.org
• 1:07:30 : aparté sur les cookies
• 1:11:30 : Speed tracer
• 1:14:20 : dynatrace AJAX
• 1:15:00 : mot clé debugger
• 1:16:30 : IE8 debug tools (démo plantée)
• Questions
• 1:19:30 : question sur les commentaires conditionnels
• 1:22:30 : remarque sur l’importance du server-side ?
• 1:24:30 : remarque sur le PNG et l’encodage de JS

Je remercie en tout cas l'organisation sans faille de Paris Web, le caméramen qui a bien filmé les zones intéressantes de l'écran projeté et le monteur de la vidéo !

Un peu de machiavélisme

Mettons de côté les principes philosophiques d’un web ouvert : soit vous y adhérez déjà par principe, soit ça vous en touche une sans faire bouger l’autre auquel cas il est bon de se rappeler ce que le Web ouvert peut vous apporter personnellement.

Ca n’appartient à personne

On peut remercier Apple pour nous avoir démontré avec Objective-C et les applications iOS tous les désavantages liés aux langages et processus de distributions fermés. C’est un succès commercial et les utilisateurs sont heureux, alors pourquoi est ce que les développeurs joueraient les rabats-joie ?

• Outils et langage imposés, parfois payants
• Une autorité arbitraire peut décider unilatéralement que votre application ne sera pas visible ou doit fermer
• La même autorité peut décider que votre business model ne lui convient pas (voir le cas de la presse belge)
• Si la communauté est petite, la formation sera chère. Les infos pour développer sur iOS sont monnaie courante, mais il est difficile de trouver des infos pour les autres plate-formes

Le multi-plateforme arrive

Ca m’ennuie de le reconnaître, mais le Web à partir du bureau devient l’exception plutôt que la règle, en particulier lorsque l’on regarde les statistiques mondiales. Depuis plusieurs années déjà il y a plus d’internautes sur mobile que sur bureau, et dans les pays en voie de développement c’est même l’unique usage du Web. Certes pour ces pays ça n’est pas du smartphone mais ça viendra. Dans l’occident, l’usage du Web depuis différents terminaux est maintenant courant et se fait selon la fonctionalité et les conditions pratiques : le mobile pendant les pauses, les éventuels trajets ou le soir au lit pour vérifier son facebook et ses mails, le PC au bureau et à la maison pour du e-commerce par exemple.

Hors dans l’ère pré-iPhone il fallait savoir coder en java ou pire dans des langages propriétaires pour faire des applications. Apple a imposé l’Objective-C, Android et d’autres sont restés sur java. Je n’ai rien contre java, mais pourquoi j’apprendrais un nouveau langage si j’ai la possibilité de capitaliser sur ce que je connais déjà ? Et quelles sociétés hormis les pages jaunes peuvent se payer de construire et maintenir la même applications sur une dizaine de plate-formes mobiles différentes ?

Il est déjà possible de construire des applications Web qui tournent très bien sur la majorité des webkits mobiles, et aujourd’hui ces sites-applications peuvent se passer d’une connexion au net (Offline, Web Storage), peuvent parfois avoir accès aux capacités matérielles du mobile (la géolocalisation) et peuvent être “installés”.

Le W3C est en train de spécifier de quoi accéder à beaucoup plus de matériel (SMS, contacts, caméra, fichiers locaux …), avec le concours de Nokia, Ericson ou Vodafone. Il y a donc un espoir pour qu’une application Web ait les mêmes possibilités qu’une application native. Pousser dans le sens des standards du Web, c’est donc aussi se donner la possibilité de pouvoir changer de branche ou d’utiliser la même équipe de développeurs pour faire du Web desktop, mobile et de l’applicatif mobile.

La concurrence, c’est bon, mangez en

Pourquoi les technos du Web devraient elles s‘attaquer au mobile voire au software ? Il existe déjà de très bons langages avec de très bons frameworks et de très bons développeurs dans ces domaines. Sauf que le manque de concurrence dans la technologie est très dangereuse, même si elle entraîne des difficultés pour les développeurs. Souvenez vous comme c‘était pratique pour les développeurs Web de voir IE6 gagner la première Browser War. En ces temps heureux pendant 1 ou 2 ans, beaucoup ont eu le sentiment qu’ils pouvaient ne tester qu’un seul navigateur et ignorer les autres (Safari Mac, Lynx …). Et puis Firefox est arrivé, a grandi et a forcé Microsoft à s’engager, négocier puis bientôt respecter les standards du Web. Le projet Webkit a survécu et a facilité l’arrivée de Chrome et des Webkits sur mobiles. Opéra a testé un business model et a fourni de bonnes idées à tout le monde.

Bref la concurrence entre navigateurs a fait que l’expérience utilisateur en général s’est améliorée. La situation pour les développeurs Web s‘est compliquée d‘une certaine manière, puisqu‘il y a une bonne dizaine de navigateurs à tester. Cette complexité est compensée par la maturité grandissante des développeurs et des librairies. Que se serait il passé si Microsoft était resté à 90% de part de marché ces 10 dernières années ? L‘accès aux technos du Web serait sans doute plus complexe (essayez de lire la MSDN), voire payante comme l‘est le développement iOS.

Même en regardant le processus d‘écriture des specs, le fait d‘avoir 2 organisations a déjà eu des effets positifs, et on espère que l’émulation va continuer. Après le schisme de 2004, le WHATWG (originellement Apple, Mozilla et Opéra) avait travaillé sur ces spécifications :

• WebForms 2, qui améliore l’interface des formulaires natifs
• Web Storage, pensé comme un super cookie
• Web Socket et Server Sent Event qui permettent une communication plus efficace entre le client et le serveur

En résumé : ils se sont concentrés sur ce qui pouvait être utile aux développeurs d’application Web dans l’immédiat et se sont lancés dans le même temps dans l’implémentation dans les navigateurs. On n’est peut être pas dans la révolution technologique (les formulaires sont émulables en Javascript, le reste avec Flash), mais cette marche forcée du HTML vers les “applications Web” est très positive, car elle nous donne plus de pouvoir, et certaine API comme “Web Workers” sont très innovantes.

Un peu de pragmatisme

En attendant le mobile, voyons déjà ce qu’on peut faire des nouveautés sur navigateur desktop, avec notamment les apports de HTML5. Ce qui compte pour un développeur au moment de faire ses choix techniques, c‘est l‘état d‘implémentation de chaque API JavaScript par les navigateurs ou, pour la partie sémantique, de savoir quels sont les user-agent qui savent exploiter le nouveau balisage.

Sémantique

Côté sémantique, la politique des lecteurs d‘écran est probablement la même que celle du moteur Google : s‘adapter à ce que font la majorité des sites (source : un community manager de Google). Si les webmasters se mettent à utiliser nav ou article, ils suivront. Les navigateurs seront sans doute un peu plus pro-actifs pour proposer des fonctionalités tirant parti de l‘analyse des balises (un lecteur d‘article comme Safari par exemple). Dans les 2 cas, suivre les balises standards (et éviter d‘en inventer) c‘est se donner une longueur d‘avance sur les concurrents pour un coût de développement négligeable.

les APIs

Côté APIs (Web apps selon le WHATWG) il ne faut pas prendre HTML5 comme un bloc mais partir de la fonctionnalité souhaitée et regarder quelles sont les APIs qui peuvent vous être utiles. La plupart du temps, la fonctionnalité est simulable en JavaScript ou en Flash, et un certain nombre de petites librairies (ou polyfills, si l‘usage du terme prend) permettent d‘y accéder sans trop de problèmes. L‘intérêt fonctionnel est de proposer une meilleure expérience à la moitié de vos utilisateurs qui ont des navigateurs au niveau, et une fonctionnalité qui marche pour les autres.
Au niveau du code, les spécifications n‘étant pas réservées aux implémentation navigateur, l‘API est généralement également suivie par ces polyfills. Lors d‘un changement de projet, de librairie, ou lorsque vous passerez à l‘utilisation exclusive de la fonctionnalité en natif, vous retrouverez les mêmes signature de fonction et la même structure de code.

J‘ai fait une conférence entière à Paris Web 2010 sur ce sujet, je vous invite à regarder les slides pour vous forger une opinion sur le déploiement possible en production.

Mais que faire John ?

Au niveau individuel, pour aider à tout cela, c‘est autant une affaire d‘expertise technique que de savoir vendre en interne ces technologies. Formez vous, faîtes votre veille techno, participez aux réunions produit ou faîtes des démos en interne utilisant vos nouvelles connaissances : ça égaie le travail et vous donnera l‘impression salutaire d‘être un peu plus qu‘un cracheur de code.
Un engagement un peu plus fort pourrait aussi consister à signaler des bugs aux navigateurs, à ceux qui font des librairies open-source ou des outils vous permettant de transposer vos compétences Web sur mobile ou desktop.
Enfin vous pouvez également contribuer au code open source ou participer aux discussions W3C ou WHATWG, ils sont réellement dans l‘attente des avis des développeurs Web pour progresser!

Au niveau de la communauté, je pense qu‘une initiative du W3 comme ce logo reste positive, tant que la discussion avec la communauté est ouverte (le logo ne sera officiel que début 2011) et que le message n‘est pas brouillé (une phrase heureusement retirée incluait CSS3, WOFF et SVG dans HTML5). Beaucoup de développeurs seront heureux d‘avoir une bannière à laquelle se rallier et tant pis pour ceux qui accusent le W3C de vouloir faire du marketing. Demandez à la fondation Mozilla si le marketing sert ou dessert la cause du libre.
A propos de brouiller le message, je ne pense pas que la décision du WHATWG d‘abandonner HTML5 et de parler de “living standard“ et de “web application” soit la bonne. Concernant le terme HTML5, on pourra se limiter à la spec du W3C, préciser quelles APIs on y inclue ou bien en parler à tort et à travers : comme “AJAX”, tout est fonction de votre interlocuteur.

Conclusion

Pourquoi pousser dans le sens du Web ouvert notamment avec HTML5 et les APIs associées ?

• pour jouer le jeu de la concurrence et placer le tryptique Javascript/HTML/CSS  au backend, dans des applications de bureau ou sur mobile
• pour les sociétés du Web, la possibilité de ré-utiliser les compétences et les outils en interne pour attaquer d’autres domaines
• pour les développeurs, plus de possibilités de carrière, plus de nouveautés, bref que du bonheur
• l‘accès à de nouvelles fonctionnalité est plus facile, ce qui permet d‘avoir une longueur d‘avance sur les concurrents
• les standards même en construction facilitent la réutilisabilité et la maintenance du code

Nous avons reproduit cette page via des fichiers statiques et les concurrents ont pu modifier les sources sur un serveur commun. Résultats ? la page de base mettait 4-5 secondes avant de commencer à afficher quelque chose d’utile et plus de 15s pour récupérer complètement la page. Et on parle bien de la version statique : pas de script côté serveur, pas de requête SQL, bref aucun ralentissement de côté là.

Mais comment font ils ?

Afin de contribuer à répandre la bonne parole sur les performances Web, et pour nous aider à les juger, chaque candidat avait la responsabilité de noter les modifications qu’il avait entrepris. Il y en a de toute beauté, mais il faut fouiller pour les trouver : il y en a 250 que vous retrouverez ici dans la colonne Gist. Vous pouvez classer les concurrents par temps de rendu, nombre de requête, poids total et score YOTTAA pour voir ceux des finalistes

Il y a aussi un petit nombre de posts de blogs des participants que je vous conseille de lire :

• l’énorme post du suractif Cédric Morin, à relire plusieurs fois tant certaines techniques sont géniales. On y apprend aussi que le projet SPIP va bénéficier de cette expérience, qu’il en a profité pour lancer JQI, un lazy-loader de jQuery et qu’il contribue à CSSTidy
• un retour tout aussi détaillé de Timothée Carry-Caignon sur son travail, avec notamment un bug de <noscript> et pas mal de travail sur JS
• un court article d’un développeur espagnol spécialisé dans la performance Web, qui dit tout le bien qu’il y a à précharger ses sprites en JS dans le head avant d’y faire référence dans le CSS . Pas sur que l’idée soit géniale.

Ex-concurrent ? : contribuez vous aussi : si vous avez le sentiment d’avoir essayé une technique qui vaut qu’on parle d’elle car elle est peu connue mais efficace ou au contraire connue mais décevante, bloguez dessus ou écrivez moi ! Ca fera peut être l’objet d’un post complémentaire

Je n’ai pas la journée …

Moi non plus, donc j’ai pris plusieurs soirées : faisant partie du jury, j’ai du passer du temps à analyser le travail de la quinzaine de finalistes (ceux qui avaient le meilleur score calculé automatiquement). En passant j’avais préparé ces articles, que je n’ai mis en forme que récemment, et divisé en une série de 3 posts qui résument globalement les techniques utilisées :

Ce n’est qu’une vue partielle et ça ne sera jamais que mon opinion mais devant la somme de travail et le nombre d’avis divergents potentiels, je ne peux que vous demander de réagir en commentaire, par mail ou par blog, afin que la communauté en bénéficie

Bilan sur le concours lui même

0 retour presse, preuve que la performance Web est loin de l’oeil de la presse informatique généraliste. Mais nous avons tout de même eu 250 inscrits dont 55 ont réellement participé. Aux deux tiers français de par l’influence d’Eric Daspet et Alsacreations, ce chiffre est tout de même largement supérieur à nos attentes (honnêtement j’aurai déjà été heureux avec une vingtaine de français…). J’interprète ce bon résultat comme le signe que les développeurs Web commencent à envisager avec autant de sérieux les techniques de performance Web que l’accessibilité ou le bon usage des CSS.

• la charge de travail était énorme : ceux qui ont été finalistes ont consacré plus de 30h sur cette page ! Certains ont abandonné après avoir vu le nombre de fichiers et la taille du HTML, et d’autres en en cours de route. Pour être honnête nous ne nous attendions pas à ce volume de travail. Rassurez vous, nous avons passé autant de temps à l’organiser puis à le juger.
• malgré cela, je maintiens que cette page était parfaite car complètement représentative des pages du Web d’aujourd’hui : un long historique, des fonctionnalités qui s’accumulent, des compétences variées qui travaillent le même code avec différents niveaux de qualité … Les poids, le nombre de requêtes et les temps de chargement sont dans les moyennes mondiales
• beaucoup de concurrents, c’est beaucoup d’essais différents, et donc beaucoup de validation / invalidation de techniques. Je pense sérieusement que c’est bon pour les connaissances globales sur les performances Web
• même les concurrents qui ont abandonné très tôt ont dit avoir appris des choses, ce qui était le but premier. Ne serait ce que de mettre les mains dans le cambouis et se poser des questions qu’on n’a pas le temps ou l’envie de se poser au travail, c’est ça qui fait de vous autre chose qu’une dactylo-codeuse
• du code open-source a été amélioré ou créé, grâce à l’infatiguable Cédric Morin : Spip, CSSTidy, jQueryLoader
• nous avons testé les limites de YOTTAA (un bug trouvé et corrigé) et de WebpageTest.org

Vous retrouverez un bilan plus technique dans le dernier post.

Bravo à l’organisateur principal Zeroload qui a eu l’idée et qui a consacré le plus de temps à ce projet. Bravo également à tous les concurrents que je n’ai pas cité dans les différents posts, ça n’était pas facile mais vous comme les autres en retireront une meilleure connaissance. Merci à mes collègues juges Eric Daspet et Stoyan Stefanov et enfin Merci à nos sponsors YOTTA, Catchpoint System et Always Data d’avoir fourni hébergement et lots

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.

La configuration d’Apache

Les premières actions pour améliorer à peu de frais et de manière impactante les performances Web passent par la configuration de son serveur Web. Si vous voulez un exemple complet, regardez ce .htaccess, fait par Omar Haddouchi, qui a fait par ailleurs un boulot impressionant. Il y a principalement 3 actions :

Gérer le cache navigateur

Il s’agit de demander au navigateur de garder chez lui autant que possible les fichiers statiques. Non les techniques à base de ETag et de réponse 304 sont quasiment inutiles car une requête HTTP est tout de même faite pour vérifier la fraîcheur du fichier. Et sur des fichiers de page Web, généralement entre 1 et 200Ko, l’aller-retour au serveur seul est plus long que le téléchargement. Voici un exemple de configuration :

<IfModule mod_expires.c>
	ExpiresActive On
	ExpiresDefault "access plus 1 month"
	ExpiresByType image/jpeg "access plus 1 month"
# ../..
	ExpiresByType text/javascript "access plus 1 month"
</IfModule>

Un mois ça n’est pas encore assez agressif, la valeur généralement recommandée est de 10 ans Par contre cela demande une très bonne gestion (dynamique donc) des URLs qui mènent aux fichiers statiques, afin de faire recharger les JS/CSS/images que vous mettez à jour.

La compression Gzip

Compresser à la volée les fichiers non binaires (HTML, CSS, JS) vous épargne d’envoyer 80% de leurs poids sur votre réseau, et aide vos utilisateurs à petit débit (à l’étranger, sur mobile, un petit pourcentage de français). Compresser du binaire est généralement inutile et consommateur de ressources serveur, d’où cette configuration :

<IfModule mod_gzip.c>
	mod_gzip_on       yes
	mod_gzip_dechunk  yes
	mod_gzip_item_include file      .(html|txt|css|js|json)$
	mod_gzip_item_exclude file      .(jpg|png|gif|ico)$
</IfModule>

Vous pouvez aller encore plus loin avec gzip et ne pas faire faire la compression par Apache à chaque requête mais plutôt en générant des fichiers gzipés (au build, ou de manière dynamique) de vos HTML (si la page est statique) et CSS/JS et en servant cette version si le navigateur le supporte. Voici un exemple de configuration :

# déclaration des types des fichiers gzipés
AddType "application/javascript" .jsgz
AddType "text/css" .cssgz
AddType "text/html" .htmlgz
# ajout de l'entête gzip pour ces fichiers
AddEncoding gzip .jsgz
AddEncoding gzip .cssgz
AddEncoding gzip .htmlgz

Cet exemple est pris du .htaccess de Etienne Guilluy. Dans le cadre du concours, l’intérêt était limité, mais en production l’avantage est évident car il permet d’épargner du CPU et donc de mieux résister aux charges.

Supprimer les cookies inutiles

Un cookie fait entre 0.5 et 4ko. Une page moyenne déclenche une cinquantaine de requêtes (115 sur cette page de la FNAC …). Si vous n’y prenez pas garde vous allez donc demander à votre utilisateur d’uploader chez vous entre 25Ko et 200Ko (le double donc pour la FNAC) alors que le cookie n’est généralement utile que pour la partie dynamique qui génère le HTML, et que l’upload des ADSL beaucoup plus précieux que le download.

La technique consiste à mettre ses fichiers statiques sur un autre nom de domaine ou sous-domaine et à ne pas activer les cookies. Pour ce concours, nous fournissions des sous-domaines, mais il fallait penser à remplacer la définition du cookie sur le domaine faite en JS dans le marqueur pour en bénéficier complètement.

Le poids des images

et le choc des mots… Mais je m’égare L’avantage de ce concours, c’est que certains ont pu revisiter les images de la FNAC qui comme sur beaucoup de sites sont fabriquées à la chaîne, sans optimisation particulière. Plusieurs concurrents ont donc réduit le poids des images avec les techniques suivantes :

• réduction de la palette de couleurs pour les PNG 8 bits
• indexed colors pour les images de moins de 256 couleurs

Optimisation du CSS

Automagique

La technique générale a été de générer une version « de production » par un outil, en voici plusieurs :

• CSS Tidy pour le compresser
• l’addon Firefox css-usage pour ne récupérer que les CSS utilisés

Il n’y a pas vraiment d’outil meilleur que l’autre en terme de performance pure (poids final et rendu). Prenez donc celui qui s’adapte le mieux à votre environnement de mise en production (vous en avez un n’est ce pas ?) et vérifiez bien que tous vos hacks restent compris.

Si dans le cadre du concours il était intelligent de réduire le CSS en supprimant les lignes inutilisées dans cette page, en environnement de production, c’est forcément plus délicat

A la main

Dans les recommandations Google se trouve depuis le début un conseil sur les sélecteurs CSS qui permettent d’accélérer le rendu. Théoriquement c’est évident. Mais on va se parler franchement : je n’ai jamais constaté ou lu que cela permettait de gagner quoi que ce soit de significatif ( > 100ms).

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.

Charger ses CSS/JS

Toute la difficulté du CSS, c’est que pendant qu’il est téléchargé, le rendu est bloqué. On pourrait alors tout mettre inline (comme la home de Yahoo!), mais c’est alors sacrifier les bénéfices du caching sur les fichiers statiques externes. Et le cache sur un cybermarchand est extrêmement utile puisqu’on peut s’attendre à ce qu’un utilisateur visite plusieurs pages d’affilé.

Tout est donc question de balance entre l’inline et l’external, voici plusieurs stratégies :

CSS différé

L’idée est de mettre le minimum de styles inline : un reset CSS, un peu du header et un préchargement d’images, et charger en JavaScript le CSS externe. Malgré un start render au plus bas (200ms!), ceci déclenche malheureusement un FOUC désagréable le temps que le CSS final arrive.

Contenu non stylé pendant 1s

Après 1s le contenu s'affiche

Ces 2 screenshots sont extraits de cette série. Vous pouvez tester cette technique sur vos navigateurs avec Cuzillion. Mais par principe un site ne devrait pas dépendre de JavaScript au point de ne pas être stylé si le JS n’est pas exécuté

Cette technique un peu extrême trouverait cependant un intérêt si le CSS était parfaitement maîtrisé, auquel cas on pourrait mettre le CSS utile et visible inline lors de la première visite (bénéfice du start render rapide), charger le CSS via JS, puis marquer l’utilisateur d’un cookie signalant qu’il a bien chargé la feuille de style pour ne lui servir que l’URL du fichier (bénéfice du cache).

CSS inline

Une autre stratégie pour ne pas avoir à télécharger un CSS qui bloque le rendu est de mettre son contenu inline. Pour cette page en particulier, certains ont réussi à réduire le poids du CSS à 4Ko gzipé, alors que le HTML fait 8Ko gzipé. La taille totale est donc largement acceptable et cela épargne un blocage de 100ms, mais c’est le genre de technique qu’on n’utilise que sur des pages très surveillées et généralement uniques (les homes de Yahoo! et de google par exemple).

Mix Inline / Inclusion

Une technique que je voulais voir en action et qui va au contraire des règles établies : mettre le minium inline et charger plus loin dans la source le reste des CSS. Ceci permet en théorie de différer le téléchargement et le parsing du CSS et de lancer au plus vite le téléchargement des images qui se trouveraient avant l’inclusion. Le tout sans dépendre de JavaScript.

Mais si IE commence effectivement le téléchargement des images, il attend tout de même le CSS avant de commencer le rendu (voir l’effet simplifié sur Cuzillion ou l’effet sur la page finale, créée par Timothée Carry-Caignon). C’est à confirmer mais le seul cas où cela pourrait marcher serait sur une page longue à calculer server-side, qui enverrait des bouts de HTML qui ne contiennent pas encore d’appel CSS. Mais même là je pense que le progressive rendering ne serait pas satisfaisant car il y aurait un effet de freeze au moment où le navigateur découvrirait qu’il y a un CSS à télécharger, laissant l’utilisateur bloqué sur une page pas encore stylée.

Un autre essai a été tenté ici par Thomas ROULET : inclusion inline d’un CSS s’occupant du layout pour que le premier rendu soit satisfaisant. Sans JavaScript, il utilise la balise noscript pour télécharger le CSS. Voici le rendu :

Rendu avec le CSS inline

Rendu avec le CSS final

Cette technique cumule les avantages, mais pour d’autres raison le temps pendant lequel la page restait avec le CSS minimal était énorme

Conclusion : ne changez rien, il faut faire télécharger le CSS au plus tôt. Si votre CSS est vraiment énorme, outre un refactoring, envisagez le découpage en 1 feuille légère et spécifique à une page que vous placerez inline et à pré-charger les CSS des pages suivantes.

Javascript différé

Certains ont utilisé des lazy-loaders, d’autres ont utilisé l’attribut defer (inventé par IE, standardisé dans HTML5, supporté par tous) voir async. Voici un petit graphe qui résume les effets de ces attributs, tiré de cet article :

Comportement du navigateur avec async et defer

Dans les 2 cas cela demandait des modifications de code qui n’ont pas été très lourdes et qui apportent un réel plus à la fluidité du chargement de la page.

Lazy-loading de JS

Outre le chargement différé, il était aussi possible de ne charger le JS qui régit l’autocomplete du champs de recherche qu’au focus sur ce champs. C’est la technique dite du lazy-loading qui permet de ne charger les dépendances d’une fonctionnalité que lorsqu’on va en avoir besoin. Voir par exemple la home de Yahoo! qui est utilise à fond ce principe.

Paralléliser

En performances on commence toujours par là où ça va le moins vite, et là on arrive forcément à IE6/7. Ce navigateur n’autorise que 2 téléchargement de JS/CSS en parallèle. La technique généralement pratiquée est de toute façon de n’avoir qu’un seul fichier de chaque type à télécharger, mais Cédric Morin a testé le regroupement puis le split des JS/CSS en 2 fichiers pour maximiser l’utilisation de la bande passante. Résultat sur le JS :

Téléchargement parallèle des 2 seuls JS de la page

Ce sont les barres bleues (le téléchargement) qui nous montrent le gain. On doit être ici à 70ms, ce qui n’est pas énorme mais sur un site avec un JS plus lourd cela peut commencer à être intéressant. Et dans le cadre d’un concours de peformance, l’intérêt est évident Par contre, il faut bien faire attention à l’ordre d’exécution des scripts, mais cela peut se ranger dans des fonctions simples ou vous pouvez utiliser des librairies.

Concernant le CSS par contre, la parallélisation n’amène rien en terme d’accélération du rendu car les temps de téléchargement s’additionnent (à tester sur IE7 avec Cuzillion), mieux vaut donc rester sur un fichier unique.

Techniques de lazy-loading

Une des grandes techniques de la performance Web est de maîtriser parfaitement le chargement des dépendances, en les chargeant si possible au tout dernier moment, juste avant que l’utilisateur n’en ait besoin. C’est en pratique difficilement applicable les yeux fermés en production car il n’y a rien de générique, hormis quelques librairies qui chargent les images non visibles au moment où l’utilisateur scroll. Comme souvent dans les perfs, on est ici dans du spécifique pour chaque page et c’est au développeur de bien la connaître et de savoir ce qui est important à télécharger durant la première seconde et ce qui peut être remis à plus tard.

Cette technique semble idéale si l’on ne regarde que les outils de mesure automatisés puisqu’il y a beaucoup moins d’objets à télécharger (les outils ne scrollent pas) : le poids initial est réduit et le temps onload raccourci. Ca a donc remonté des concurrents en haut du tableau. Mais dans le cas de la FNAC, il était par exemple non toléré de :

• différer le chargement des images produit : dans un magasin, le visuel et le prix sont 2 informations de première importance. Pas de photo ou de prix, pas d’achat. Même si la population sans javascript est de quelques %, il faut au moins que ces gens puissent voir le produit. Sur Internet, les cybermarchands espèrent en plus que des moteurs comme Google Image indexeront leurs images. Notez que pour un autre business qui accepterait de sacrifier ses utilisateurs sans JS et l’indexation (un réseau social par exemple), cette technique très efficace aurait été acceptée
• déclencher des téléchargements au onmousemove : l’accessibilité au clavier en prend un coup

Les concurrents de la catégorie meilleur poids ont choisi diverses techniques de chargement différé :

• placer dans une balise <noscript> le contenu de la boutique référençant les images. C’est bien vu car les gens sans JS et le référencement ne sont pas gênés. Le contenu est ensuite récupéré en JS et les images téléchargées en fonction de la zone visible. Cela a été fait avec plus ou moins de bonheur par les finalistes, mais regardez cette page du mythique Cédric Morin avec JavaScript désactivé pour avoir la meilleure version
• la fnac ayant déjà fait le choix original de mettre son footer en iframe, les concurrents ont simplement retardé ou conditionné son affichage en JS, certains utilisant <noscript> pour la version sans JS.

Encodage des images

La réduction du nombre de requêtes HTTP étant le nerf de la guerre, cela peut aller jusqu’aux images. La technique répandue aujourd’hui est l’utilisation de sprites. Il est fortement probable qu’elle soit remplacée demain par la technique d’encodage des images dans le CSS.

MHTML et data:uri

Internet Explorer 6 et 7 supportent l’encodage des images en MHTML tandis que les autres navigateurs supportent l’encodage en base64. Voici un exemple de CSS fait par Christophe Laffont ne contenant que des images encodées et son équivalent pour les autres navigateurs. Cette technique est largement industrialisable du moment que l’on maîtrise la fabrication de son CSS final avant mise en production. Plusieurs outils ont été utilisés : il existe même une librairie PHP qui s’occupe de concaténer les feuilles de style et de séparer les règles sans images des feuilles contenant les images encodées. Au niveau des outils :

• l’encodage en base64 peut se faire simplement en PHP
• CSSEmbed en java
• CSS-JS-Booster en PHP
• il existe même un service en ligne (russe)

Nous attendions beaucoup du MTHML, et ce déploiement en situation réelle a révélé une énorme lacune. Ce graphique d’une vue de la page en cache est révélateur :

Le coût CPU du MHTML

Le HTML et toutes les dépendances viennent du cache, aucun téléchargement sauf le tracking n’est nécessaire … mais la barre des téléchargements montre un énorme vide, expliqué par le graphe CPU : il faut une pleine seconde avant de rendre utilement la page !

Les extrêmes

Certains concurrents ont tenté des techniques extrêmes qui ont été révélatrices. Parfois disqualifiantes mais très instructives

1 seule requête HTTP

Une seule requête HTTP au lieu des dizaines à l’origine, c’était théoriquement possible, et Arnaud Lemercier l’a osé. La page s’affiche bien et est fonctionnelle sous Firefox, mais ne marche pas sous IE7, ce qui était disqualifiant, mais ça nous apprend plusieurs choses :

1 query to rule them all

• Le poids total de la page ainsi arrangée était de 500Ko. Et pourtant regardez l’utilisation de la bande passante (graphique vert) : le navigateur fait des pauses pendant le téléchargement, mettant finalement 7s au lieu de moins d’une seconde théorique
• le processeur est occupé à 100% pendant 6 secondes : sans doute un mix de décompression Gzip sur un fichier qui peine à arriver, de la lecture d’un DOM extrêmement lourd et d’interprétation des images en base 64
• les premiers pixels ne sont affichés qu’au bout de 4,4 secondes, et on observe le même phénomène, moins gravement, sur Firefox

Je cite les autres désavantages de la méthode inline :

• pas de mise en cache : les visiteurs allant sur une seconde page devront re-télécharger la plupart des éléments, ce qui est dommage pour un site comme la FNAC, mais qui n’est pas grave pour certains sites « de destination » comme la homepage de Yahoo!
• la technique des data:uri est incompatible avec IE6-7, il faut donc rajouter une technique équivalente appellée MHTML. Et donc doubler le poids des images encodées ou faire de la détection de navigateur

En résumé : mettre inline CSS, JS et surtout images encodées en base64 est extrêmement consommateur de ressources, quel que soit le navigateur au point d’empirer la situation du start render. Il serait intéressant de savoir si c’est la construction d’un DOM fait de 500k de texte ou si c’est le décodage des images qui plombe à ce point les performances de rendu. Si quelqu’un a du temps pour nous tester cela, le code source de cette page extrême est ici : http://entries.webperf-contest.com/4cd9d06f380f8/

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

HTML, markup et DOM

Quand on me dit qu’on peut accélérer le rendu d’une page en modifiant le HTML, je commençais généralement à rigoler doucement : comme pour le CSS, je n’ai vu aucune démonstration du phénomène
Mais à bien y repenser je me souviens des grandes années du Web où j’étais passé de layouts à base de tables imbriquées à un mix de divs et de règles CSS externalisées : non seulement le poids des pages était réduit (et à cette époque pré-ADSL, c’était encore important) mais sur les machines de l’époque on pouvait sentir la différence de rapidité d’affichage.
Et aujourd’hui on retombe parfois sur des sites dont la maintenance n’est pas évidente, l’équipe sous pression et où chaque ajout au design s’accompagne d’une pléthore de div et de règles CSS ultra spécifiques. Même sur nos machines modernes, avec IE7 le rendu peut être ralenti sans que l’on s’en rende vraiment compte.

Force est de constater que les concurrents qui ont simplifié à la main le HTML (réduction de 30% à 50% des 1900 éléments du DOM) ont constaté un réel gain de vitesse de rendu. Je n’ai aucun graphe pour le prouver (imaginez la difficulté pour mesurer cela), juste les ressentis concordants de plusieurs concurrents et un constat sur leurs pages finales.

L’ordre d’affichage a aussi son importance : sur une page statique comme ici, ça n’était pas visible, mais un site dynamique comme la FNAC pourrait très bien envoyer son contenu par blocs en flushant dès que possible des blocs de HTML. Certains comme Cédric Morin ont donc travaillé le CSS pour pouvoir mettre en premier dans la source les éléments importants comme la colonne centrale.

Produire du bon code !

Certains concurrents comme la jusqu’au-boutiste Alexandrine Boissière sont partis sur un refactoring complet du code, du HTML au CSS en passant par JavaScript ! Même si ça ne ressort pas forcément bien sur les graphes (par rapport aux autres finalistes), le rendu au premier affichage est parfait (on voit en moins d’une seconde le contenu principal), et la sensation de fluidité au scroll ou à l’utilisation est saisissante : attendez le chargement et scrollez sur la page originale et sur cette page. Ce n’est pas le genre de donnée qui se calcule, sauf peut être en regardant les courbes CPU, mais un robot ne peut pas le calculer.

IE7 avait visiblement du mal à afficher un arbre DOM aussi gros (213Ko bruts pour 2000 éléments) et avec autant d’erreurs : plus de 2300 erreurs repérées par le validateur pour du HTML4.01 Transitional, c’est rare. On peut donc imaginer que le parser de IE souffrait pour afficher la page. Certains finalistes ont :

• diminué de moitié le nombre de noeuds du DOM, ce qui influence clairement sur la fluidité finale
• nettoyé le HTML des erreurs qui ont peut être une influence sur le parser ( IDs non conformes,
• supprimé les tableaux : IE a toujours eu du mal avec l’affichage de tableaux imbriqués
• nettoyé les appels JS inline
• corrigé des erreurs de HTML comme des URLs malformées (!)
• enlevé les paramètres de session des URLs, pour les rajouter en JS dynamiquement

Au niveau CSS :

• mise en place d’un reset.css, ce qui permet de supprimer beaucoup de déclarations
• suppression des filter() IE, consommateurs de ressources. Je note au passage que cela augure du mauvais pour CSS3 : il ne faudra pas abuser des opacités, ombrages et autres tranformations ou transitions
• séparation des CSS texte des CSS avec images encodées
• nettoyage des règles CSS inutiles sur cette page, soit 75% de la feuille. Ce nettoyage est largement discutable, car on a affaire à une feuille pour tout un site. Cependant 3/4 de règles non utilisées, ça vaut le coup à mon avis de soulager le parser en créant un CSS par type de page, généré automatiquement en concaténant une feuille de style par module par exemple.
• utilisation de CSS3 et de dégradation gracieuse pour les bords arrondis ou les effets de reflets. C’est un choix que nous cautionnions, même s’il faut bien avouer que peu d’équipes Web arrivent à échapper au diktat du pixel-perfect
• utilisation de :before pour certains éléments répétitifs (IE6 n’était pas à prendre en compte)
• dégradés gérés avec un seul PNG transparent, la couleur étant définie en CSS

Au niveau JavaScript il y avait pas mal de ré-écriture de code à faire, même si j’estimais personnellement cela hors-sujet du concours. Certains candidats ont pourtant gagné en fluidité grâce à cela. Je les cite en vrac :

• remplacement du widget d’autocomplete
• moins de manipulations de DOM
• plus de cache sur les variables
• optimisation des sélecteurs jQuery
• accès par ID et moins par sélecteurs (opinion personnelle : jQuery habitue mal les développeurs)
• suppression du document.write()
• remplacer les modifications de style sur des éléments par des changements de classe
• mutualiser les XHR qui récupéraient les infos de stock

Les enseignements du concours sur la performance Web

• MHTML est très consommateur de CPU et met à mal IE7. A utiliser avec précaution et lui préférer les sprites si nécessaire
• la taille du DOM et sa complexité jouent réellement sur la vitesse et la fluidité d’affichage
• diviser par 10 le temps de rendu et améliorer la fluidité d’une page comme La Fnac a maintenant un prix : une semaine à temps complet pour un développeur dans les conditions d’une page statique. A vue de nez, pour industrialiser cela, il faut peut être décupler ce temps ?
• les optimisations de base sont déjà très efficaces et faciles à faire, mais dans ce cas ne suffisent pas : il faut peut être envisager un refactoring
• les bonnes pratiques du développement Web et l’organisation de son code HTML/CSS aident réellement à garder de bonnes performances
• les meilleurs concurrents étaient également les mieux organisés : versioning, tests automatisés des fonctionalités, processus de mise en ligne… Ils étaient également les plus clairs dans leurs notes ce qui je pense n’est pas un hasard
• il y a des consultants en performance qui ont participé mais les finalistes et les vainqueurs ne disent pas être des pros de la performance Web. Juste beaucoup de travail, des bonnes pratiques et de l’auto-formation avant et pendant le concours
• dans les techniques utilisées, il n’y a eu que du connu, malgré la cinquantaine de cerveaux qui se sont réellement penchés sur la question. Cela signifie peut être que l’on a fait le tour des techniques Webperf, et que le combat sera maintenant de les industrialiser et d’en répandre l’usage.
• en France on n’a pas de pétrole, mais on a de bons Webdevs. Les 2 tiers des participants étant français, on peut se dire qu’il est statistiquement normal d’avoir 3 gagnants français. Mais si on regarde la quinzaine de finalistes en haut du tableau, il y a sur-représentation.

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.

Je ne m’énerve pas, j’explique

Je travaille dans des conditions outrageusement luxueuses.
Comprenez par là que je bosse sur un MacBook Pro depuis 4 ans, et que j’ai une machine virtuelle pour chaque version d’Internet Explorer. J’ignorais ma condition de nanti jusqu’au jour où j’ai travaillé avec une web agency puis discuté avec d’autres développeurs.
Ce qui comme la plupart des développeurs ne me gênait pas au début (après tout c’est cher à mettre en place) est devenu rapidement un problème : mes prestataires ne pouvaient pas reproduire certains bugs car ils n’avaient pas les outils nécessaires. Après une petite année à ce régime, j’ai cumulé suffisamment de preuves pour me permettre de demander légitimement aux prochains prestas de s’équiper avant de travailler avec nous.

Arrettez les « compatibility mode »

Choix du mode de compatibilité dans IE8 Debug Tool

C’est probablement le pire moyen de tester : le mode de compatibilité d’IE8 ou IE9 supposés exécuter le moteur de rendu d’IE7 ou IE8. MS a voulu bien faire pour faciliter la vie de ses utilisateurs et leur permettre une transition en douceur de IE7 vers IE8, mais les développeurs se sont vite rendu compte que le mode de compatibilité générait des rendus différent de IE7. A tel point que Yahoo! et sa matrice de navigateurs à tester recommandent constamment de tester spécifiquement le mode de compatibilité (voir les updates, dans les notes).

Certaines techniques sont faussées : j’ai par exemple constaté que le support des images en data:uri et base64 marchait dans IE8 en mode IE7 standard alors que IE7 ne le supporte pas. Comment faire pour valider certaines techniques émergentes (ici pour les performances) si vous n’avez pas les bons navigateurs pour tester ?

La différence de comportement la plus grave que j’ai constaté (et je ne suis pas le seul) vient du moteur javascript : sous IE6 et IE7, le fait d’oublier d’enlever la dernière virgule (,) après une chaîne JSON a toujours planté le script :

var oData : {
	value1:"blah",
	value2:"blah", // === boom
};

Sous IE8 comme sur tous les autres navigateurs, cette syntaxe est valide. Or si vous vérifiez avec le mode de compatibilité IE7 sous IE8, vous ne verrez pas cette erreur qui casse votre javascript et qui enlève donc des fonctionnalités majeures de votre site, simplement parce que vous n’êtes pas dans les bonnes conditions pour tester.

Les installation multiples d’Internet Explorer

Screenshot IE tester

Internet Explorer est à ce point implanté dans son OS qu’il est en théorie impossible d’installer plusieurs versions d’Internet Explorer (ce qui leur avait même valu des problèmes avec la justice). Mais plusieurs softs ont pallié à cette situation et permettent d’exécuter plusieurs versions d’IE comme IETester, IECollection ou Multiple IE. Le problème, c’est que ces différentes instances d’IE continuent de partager certaines DLLs et autres appels système. Ca n’a l’air de rien, mais concrètement pour le développeur Web ça l’empêche de voir certaines choses :

Plugins

Les interaction avec des plugins populaires comme Flash ou Java sont problématiques :

• J’ai déjà vu Flash planter sans que IE dans un IETester ne s’en aperçoive, le fallback que nous implémentions en Flash (la sélection multiple de fichiers pour un uploader) était essentiel, mais le développement était pénible : on s’est rendu compte au bout d’un moment que Flash ne répondait plus ou mal, et qu’il fallait tuer le processus Flash pour que cela remarche. Avec un IE natif, pas de problèmes : lorsque Flash plante, il se relance correctement, ce qui accélérait le développement
• l’interaction avec une applet java (toujours pour un uploader, en drop de fichiers cette fois) était tout simplement impossible à tester avec plusieurs IE dans le même IETester. Une machine virtuelle, c’est déjà lourd à lancer, alors imaginez 3 applets en parallèle qui essayent de s’afficher sur la même zone de l’écran. Les fichiers n’étaient pas réceptionnés dans la bonne instance d’IE …

Fonts et couleurs

Pour le rendu des fonts il vous faudra typiquement vérifier votre site sous un Safari sur Mac et sur un IE6 sous XP : le Safari Mac rend les polices exactement comme votre graphiste l’a prévu sur sa belle maquette Photoshop. C’est la vision qu’il a du site, et c’est surement celle que les décideurs ont du site …
Le couple terrible IE6-XP qui est encore là pour longtemps est lui à l’extrémité opposée du spectre des rendus, et correspond au pire de ce que verront vos visiteurs. Les versions supérieures de IE et des navigateurs ne font qu’améliorer le rendu sans jamais totalement atteindre la perfection du couple Safari / OSX.

Au moins 4 rendus par police

J’ajoute que selon la taille de police, l’activation ou pas de l’option lissage, le type de police et les caractères utilisés, certains mots peuvent devenir illisibles ou du moins pénibles à lire sur les Windows. Lorsque vous décidez de l’utilisation d’une police, il vous faudra d’abord vérifier son rendu final sur au moins XP, Vista ou Seven, et enfin MacOS. Soit vous maintenez 3 machines physiques avec 1 OS sur chacun, soit vous utilisez les machines virtuelles (ou plus pénible : des machines en dual boot).

Le rendu des couleurs : j’avoue ne pas très bien savoir comment faire ici. Mac et les différents Windows rendent les couleurs différemment, discutez en 2 minutes avec un graphiste, ça lui laissera le loisir de vous montrer qu’il en sait plus que vous. Hors avec les machines virtuelles, on affiche un Windows sur un Mac, je n’ai aucune idée de ce que cela donne réellement. Pour en rajouter un peu, je n’obtiens pas les mêmes couleurs selon que je suis sur l’écran du macbook ou sur le 2nd écran … Devant mon incapacité à vous expliquer comment tout cela marche, je ne peux que citer une des bonnes pratiques généralement accolée à l’accessibilité : inutile de jouer avec des nuances de couleurs, préférez de forts contrastes.

Etre à jour

Microsoft patche régulièrement ses OS ainsi que ses IE. Rarement mais sûrement certaines choses peuvent s’arrêter de fonctionner suite à ces patchs. Exemple concret : dans les IEs on pouvait récupérer le chemin local d’un fichier sélectionné par un input type=file. Ceci permettait d’afficher une miniature d’une image avant upload, fonctionnalité d’ailleurs à nouveau permise par HTML5. En 2009 un patch est passé qui a fait disparaître cette possibilité, après 10 ans de bons et loyaux services (voir les screenshots que j’avais fait).

Les packs d’IE ne permettent pas de rester à jour, ou alors vous dépendez de leur bon vouloir. Avoir une machine virtuelle permet d’utiliser le mécanisme d’auto-update de MS.

Autres fonctionnalités cassées

Il y a d’autres bugs connus sur Multiple IE ou IETester :

• les champs texte sur « Multiple IE » ne fonctionnent plus
• les popups et leur interaction avec la page d’appel est cassée
• les filtres CSS ne marche pas
• la fonctionnalité d’impression ne marche pas

Dégradation gracieuse et Fallbacks

Les anciens et les futurs navigateurs

Outre Internet Explorer, certains versions de Firefox valent encore la peine d’être testés avec plusieurs versions. Ca a été le cas pendant longtemps pour FF3, c’est encore peut être le cas sur vos sites pour FF3.5 et à l’heure d’écrire ce post, c’est certainement vrai pour FF3.6, alors que l’on est passé à la 4.0.

Les bugfixs passés dans ces releases impactent rarement le travail des webdevs (mais ça arrive) mais il y a surtout eu des ajouts de fonctionnalité majeures (rangées sous l’ombrelle HTML5) ou l’ajout de supports CSS3 : il faut que vous testiez au moins une fois pendant le développement comment se comporte votre fallback ou votre graceful degradation sur ces anciennes versions.

Il n’est peut être pas utile de conserver des versions de Chrome et Opéra, l’un car il force l’auto-update, l’autre parce qu’il est rare, mais c’est à vous de juger.

Par contre il est vital d’avoir les versions de développement de IE (la 10 preview) et Firefox (Minefield) pour tester régulièrement votre site avec : faites corriger les bugs par Microsoft ou par Mozilla avant que vos utilisateurs ne tombent dessus et vous fasse changer votre code !

Il n’est peut être pas nécessaire d’avoir une machine virtuelle dédiée à une version passées et futures des navigateurs hors IE, car il me semble que différentes versions de FF savent cohabiter ensembles et que les beta/preview d’IE savent également s’installer sans conséquences. Mais il vaut peut être mieux jouer la prudence là dessus : ce sont des versions beta et avec les nouvelles fonctionnalités type accélération matérielle, les navigateurs s’intègrent de plus en plus au système, il me semble donc évident que toute nouvelle installation met en péril l’intégrité des autres versions du même navigateur.
Et une fois que le mal est fait, difficile de revenir en arrière, tandis que sur une machine virtuelle vous pouvez isoler le problème, et vous pouvez même revenir en arrière grâce aux fonctionalités de snapshot à exécuter avant toute installation hasardeuse.

Plugins et addons

Votre site dépend parfois de Flash ou Java ? Il affiche des publicités ? Il vous faut au moins une machine où Flash et Java ne sont pas installés, afin de tester de manière réaliste votre contenu alternatif ou le fallback de votre fonctionnalité. On ne développe pas ce qu’on ne voit pas.

Concernant Flash, et c’est valable avec Java : il existe des différences entre Flash 9 (encore répandu) et Flash 10.x. Les flasheurs développent et testent toujours avec la dernière version : ayez donc une machine avec une ancienne installation de Flash pour vérifier rapidement que le Flash qu’on vous livre marche pour tout le monde.

Votre Firefox est peut être comme le mien : c’est devenu un navigateur de développement sur lequel est installé une dizaine de plugins dont le gourmand firebug. Après quelques heures de développement mon Firefox est à la limite du praticable sur certaines pages chargées. Un tour régulier sur un Firefox sans aucun plugin dans une machine virtuelle me permet de vérifier (et non pas de supposer) si c’est un plugin ou mon code qui fait ramer le navigateur.

Quelles contraintes ?

Vous êtes probablement d’accord avec le principe d’être dans de bonnes conditions pour tester, mais vous avez peur que cela demande du budget et de la ressource machine ? C’est le cas, mais rien d’insurmontable. Concernant votre machine de développement d’abord :

• Mac OS : il faudra le tester de toute façon, ne serait ce que pour tester ce que voient les graphistes et les journalistes… Pendant longtemps il n’y a pas eu de machine virtuelle capable de le faire tourner mais il semblerait que cela soit aujourd’hui possible, donc si vous voulez rester sous Windows ou Linux, c’est peut être jouable, à vos risques et périls. Pour ma part et depuis 4 ans, j’ai convaincu mes employeurs de payer 50% plus cher mon matériel pour être dans des conditions de test réalistes. Pour les managers qui doivent justifier ce budget : outre la qualité, un développeur sous mac est un développeur qui restera plus longtemps chez vous
• 4GO de RAM : pendant le développement, il faut tourner avec au moins un IE6 (ou 7) sous XP en permanence ouvert en plus l’environnement de développement normal (Firefox, éditeurs, divers logiciels …). Avec 2Go, c’est parfois pénible, du coup certains développeurs ferment à jamais la machine. 4Go, c’est mieux, et ça permet de supporter ces jours pénibles, généralement en début et en fin de projet, où vous allez lancer successivement toutes vos machines virtuelles pour valider des choix techniques ou le développement lui même.
• un disque rapide : 2 OS qui cohabitent, ça fait énormément d’appels au disque dur, surtout que vous allouerez peu de RAM à Windows (512Mo max en général), et ce dernier utilisera la mémoire virtuelle (le disque donc). Si vous n’avez que 2Go de RAM et un disque de portable à 5400 tr/mn, la situation sera intenable. Essayez d’upgrader à 7200 (la différence est flagrante), voir de le remplacer par un SSD, technologie qui commence à être abordable.

Concernant le software :

• XP et Seven : il vous faut au moins ces 2 OS pour installer de IE6 à IE9. Concernant les licenses, chez Yahoo! nous utilisions des licences dites corporate (valables pour des milliers de postes), donc pas de problème. En PME, la pratique généralement admise est d’acheter la licence, d’installer … puis de cloner l’image de la machine autant de fois qu’il y a d’environnement et de développeur. Honnêtement je ne sais pas si c’est prévu par la licence. Si vous émulez à partir de Seven avec Virtual PC, Microsoft vous offre des images d’installation (limitées dans le temps) parfaites pour les webdevs.
• Une machine virtuelle Mac :
  • payant : j’utilise Parallels Desktop qui me satisfait pleinement mais qui a la réputation d’être gourmand en ressources. J’ai entendu du bien de VMWare. Dans tous les cas comptez moins de 100 euros.
  • gratuit : VirtualBox est le leader de l’open source, mais n’était pas sorti lorsque j’ai commencé à utiliser Parallels il y a 4 ans, je ne peux donc pas en parler. Si vous êtes sur Windows Seven, vous pouvez utiliser Virtual PC.

Les machines virtuelles vous fournissent généralement des images pré-installées. Mais elles ne sont jamais en français, et bien sur ne dispensent pas de fournir une clé Windows valide. Veillez aussi à ce que les images d’XP fournies contiennent bien IE6 :  on ne peut pas désinstaller IE7 pour installer IE6.

La matrice de tests

Je vous conseille de suivre la matrice de Yahoo!, mise à jour 2 à 3 fois par an. Voici en tout cas le contenu de mes machines après plusieurs années de pratique :

Liste des configurations dans Parallels

Vista et FF2-3 ne sont peut être plus utiles à posséder, mais sinon toutes ces combinaisons tiendraient en 5 machines. Cela donne accès à :

• pas de flash/java, flash 9 et un Flash à jour partout ailleurs
• IE 6, 7 et 8 sur XP, IE9 sur Seven
• FF3.6 et FF4 (qui n’apparaît pas)
• IE10 preview à jour, un FF Minefield pour vérifier des bugfix à l’occasion
• Ces machines comportent presque toutes un Chrome et un Opéra à jour, en plus du Chrome / Opéra / Safari de mon Mac. Oui il y a parfois des différences pas uniquement visuelles entre une version Mac et Windows d’un même navigateur.

Cela fait beaucoup de combinaisons et il en manque encore : par exemple si je dois un jour tester le site sur IE6 sans Flash, je n’ai pas de machine toute prête. Qu’à cela ne tienne, il me suffit de cloner ou de faire un snapshot de ma machine IE6 puis de desinstaller Flash pour vérifier mon bug.

Les alternatives

Service en ligne

Des services comme browsershots.org ou browserlab permettent d’obtenir rapidement un screenshot d’une page vue par beaucoup de couples OS/navigateurs différents. Le désavantage évident, et dans mon cas bloqueur, est que votre page doit être sur une URL publique et que vous ne pouvez pas interagir avec la page. Peu d’équipe développent directement en ligne, préférant des URLs internes, et il est difficile de se passer de tester des interaction (:hover, formulaires, application Web …)

Machines physiques

Les machines physiques sont encore plus réalistes que les machines virtuelles, en théorie vous y gagnerez donc en qualité de test. Le point négatif que j’ai expérimenté ne vient pas de l’outil mais de la nature humaine : accessibles physiquement ou depuis un VNC, c’est une solution peu pratique que les développeurs finissent par ne plus utiliser, préférant coder à l’aveugle plutôt que de se déplacer physiquement ou subir des lags réseau… Oui les développeurs sont comme ça, d’où l’intérêt d’investir dans du matériel

J’ajoute que les machines virtuelles permettent de faire des snapshots, ce qui permet de gagner en souplesse en installant sans remords des programmes pour tester certaines conditions extrêmes (IE toolbars, mises à jour de Flash, Silverlight et Java, reproduire un bogue avec un antivirus agressif …). Maintenir un parc de machines physiques qui permet d’avoir autant de souplesse prendrait beaucoup de temps

Linux, windows comme OS principal

Par conviction ou par économie, vous pouvez préférer développer sur autre chose que Mac OS. Sur ces 2 familles d’OS vous pouvez tout à fait créer des machines virtuelles, mais il vous reste cependant le problème de l’émulation du Mac (je maintiens qu’il faut le tester quoi qu’il en coûte) : à priori la seule solution viable est d’avoir une machine physique Mac constamment à jour que l’équipe pourra utiliser. Mais d’expérience cette machine finira par être sous utilisée, et donc les tests de compatibilité seront moins assurés.

Conclusion

• Si vous vous considérez comme un professionnel du Web, vous vous devez d’investir dans un environnement de test fiable
• Il y a de vraies différences de comportement et de rendu entre un IE natif et des packs d’IE, et entre OS
• Il y a un gros nombre de combinaisons possibles (4 OS, 5 navigateurs, plusieurs sous-versions, Flash …) et les différences iront en s’accentuant (nouveaux navigateurs, adaptation à chaque OS …)
• La seule solution fiable et souple est d’avoir plusieurs machines virtuelles
• Il vous faut une machine Mac OS physique pour tester cet OS (une machine partagée ou une par développeur)

Comment ça marche ?

Le principe est simple : tous les développeurs doivent optimiser la même page, page prêtée par La Fnac, et mise à disposition sous forme de fichiers statiques que vous pourrez modifier à volonté. On parle donc bien d’un concours de performances frontales, puisque le code backend ne peut pas influer sur le temps d’affichage de la page. Ce qui tombe bien car c’est là où passe 90% du temps d’affichage : sur cette page très représentative des sites Web d’aujourd’hui, 1 seconde suffit à générer le HTML, les fichiers statiques sont servis en 50ms chacun, ce qui correspond à des performances honorables côté backend. Mais le site n’est pas utilisable avant plusieurs secondes (voir ce graphique). Inscrivez vous donc et visez une des 3 catégories (ou toutes, ce qui est théoriquement possible) :

• meilleur score YOTTA (sponsor principal fournissant des outils de monitoring de performances). Le score YOTTA est, je cite : « an overall performance assessment that takes into account page load time, global reachability, yslow and complexity ». Récompense : un iPad
• meilleur temps d’affichage, calculé par l’indispensable webpagetest.org depuis un IE7 à Paris. Le start render actuel est à 2.5s et n’est pas très utile (voir ce screenshot), d’autant qu’il est suivi par un freeze du navigateur perceptible à la souris nue, et visible facilement sur ce graphique où l’on voit le CPU plafonner à 100% pendant plusieurs secondes. Le temps onload total est de plus de 7 secondes, je pense que le diviser en 2 avec des fichiers statiques et un peu de malice est largement jouable. Récompense : un iPod touch
• plus petit nombre de requêtes HTTP et poids total, calculés en additionnant première et seconde impression de la page. La difficulté dans cette catégorie est que les techniques permettant l’un et l’autre sont parfois antinomiques. Récompense : des livres dédicacés par Stoyan Stefanov

Une fois inscrit, vous recevez un espace FTP et un ZIP contenant les fichiers statiques.

J’ai une chance ?

L’idée du concours est bien sur d’apprendre en s’amusant, avec la concurrence comme aiguillon. En passant du temps sur cette page de la FNAC, vous allez pouvoir mettre les mains dans le cambouis, et on sait bien qu’en terme de développement en général, et d’optimisation en particulier, c’est la meilleure école. A mon sens la connaissance basique des performances Web fait maintenant partie intégrante de l’arsenal d’un développeur Web moderne, au même titre que le respect des balises HTML ou du passage des layouts en tableau au tout-CSS il y a plusieurs années. Accessoirement, c’est l’un des premiers concours avec ce thème et la discipline commence à peine à être maîtrisée. Pour preuve, il doit y avoir moins de 10 professionnels vivant uniquement du consulting sur les performances Web dans le monde, et un seul en France (Zerolad, par Vincent Voyer, organisateur principal). Nous sommes donc tous plus ou moins amateurs, peu nombreux et vous avez dès lors de vraies chances de gagner.

Quelques conseils

Etant donné que je suis juge, je vais tenter de rester impartial pour ne pas favoriser les français ou mes lecteurs. Cependant je vais vous faciliter la tâche en rappelant ces quelques ressources qui vous donneront une idée de par où commencer. Ces ressources sont publiques et vous serviront même en dehors de ce concours.

• la liste de référence toujours valable faite par Yahoo! : Dans le cadre de ce concours, il est clair qu’il vous faut au moins assurer sur la majorité de ces conseils. C’est de toute façon une connaissance et des techniques qui vous serviront sur tous les sites.
• l’autre liste de référence, faite par Google. Les points se recoupent aussi en général je me contente de citer la liste de Yahoo!. Mais pour ce concours, vous voudrez certainement optimiser plus avant et certains points innovateurs de Google devraient vous aider à gratter des dixièmes de secondes ou quelques kilos
• les archives d’Eric Daspet (co-organisateur et juge), qui bloguait en français à l’époque où toutes les règles de performances commençaient à sortir
• mes propres archives des RPW taguées « Perfs » qui couvrent elles l’année écoulée et qui contiennent des conseils généraux et aussi quelques techniques extrêmes difficile à sortir en production mais qu’il serait intelligent de déployer dans un concours de performances Web

Côté outils, pour vous éviter beaucoup de choses fastidieuses, surtout les premières heures :

• les classiques ySlow et pageSpeed, pour repérer facilement les problèmes basiques, sur Firefox. Le score ySlow fait d’ailleurs partie du score YOTTA
• le complexe mais très utile dynatrace AJAX, pour Internet Explorer. Il permet notamment de comprendre comment IE affiche une page, et peut vous aider à repérer d’autres problèmes invisibles de firebug
• le méconnu AOL page Test pour IE, qui est en fait le logiciel utilisé par WebPageTest.org . 3 avantages :
  • Vous verrez votre page comme la verront les juges
  • Vous ne dépendez pas de Webpagetest.org qui sera forcément saturé de demandes des autres concurrents
  • Vous ne révélerez pas votre URL secrète par erreur aux autres concurrents en passant par WebPageTest.org . Il suffit d’oublier de cocher la case « private » une fois …
• IE7 ! c’est notre étalon, il ne faut donc pas se baser sur des navigateurs plus récents comme IE8 et Firefox. Vous devriez y installer AOL page Test pour voir la page telle que Webpagetest.org la testera. Faîtes attention aux packs d’IE : ils dépannent dans la majorité des cas, mais j’ai déjà noté des différences de comportement (filtres CSS, interaction avec plugins et addons …) et je ne sais pas si cela influe sur la manière d’afficher une page (nombre de requêtes parallèles par exemple). Utilisez une machine virtuelle pour chaque IE reste un bon conseil.

Et enfin des discussions :

• le groupe de discussion performances Web français lancé cet été à la suite de la première soirée Webperfs où vous devriez trouver tous ceux qui ressemblent à un expert des performances Web
• un forum ouvert récemment pour l’occasion sur developpez.com, et qui restera sûrement après le concours. Nous surveillons ce forum pour répondre à vos questions si vous sentez que vous tentez des optimisations un peu trop extrêmes et que vous n’êtes pas surs que nous les accepterons au final
• et bien sur le twitter officiel du concours : @webperf_contest qui vous permet de dialoguer directement avec nous

Un dernier conseil pour ce concours : remplissez bien votre Gist de toutes les modifications que vous faîtes. Nous nous doutons que les finalistes arriveront dans la même plage de 50-100ms et il serait injuste que les aléas du réseau choisissent un gagnant. Pour les départager, nous allons tout simplement lire les techniques que vous aurez appliquées et voter au plus méritant (originalité, facilité de mise en oeuvre …) Voilà, inscrivez vous, téléchargez et jouez avec la page. C’est le moment d’apprendre et peut être même de gagner des bouquins ou un peu d’électronique

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 :

1. HTML5 maintenant partie 1 : la sémantique
   
2. HTML5 maintenant partie 2 : APIs
   
3. HTML5 maintenant partie 3 : multimedia
   

Je serais ravi d’exploiter ces slides pour faire des conférences ou des cours plus approfondis sur certaines parties de HTML5, contactez moi si vous êtes intéressés, que vous organisiez une conférence gratuite ou que vous soyez une école.

Encore merci à Paris Web d’exister tout simplement : en discutant avec des experts dans leur domaine et des gens venus se faire un tour d’horizon des technos et bonnes pratiques du Web, je me suis rendu compte à quel point cette conférence est de bonne qualité malgré son prix, et comment il peut aider tout le monde se mettre à niveau, le tout dans une humeur bon enfant.

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

Travail préparatoire

Tout passage à HTML5 doit passer par 2 ajouts à votre site, afin d’avoir un comportement normal des nouveaux éléments, que les anciens navigateurs ne pouvaient bien sur pas connaître. Je les reprend de mon précédent article sur le passage à HTML5, la situation n’ayant pas évolué depuis.

JavaScript

IE ne sait pas styler les éléments inconnus. Heureusement il existe une solution JS reconnue appelée HTML5 shim pour contourner ce problème, qui consiste à créer dynamiquement au moins une fois ce nouvel élément. Ceci marche avec IE6 et supérieur. Notez que ce code doit être exécuté obligatoirement dans <HEAD>. Plusieurs choix alors :

• pour des gains de performances, vous avez enlevé les inclusions de fichiers JS du <HEAD>. Il vous faut alors éditer header.php pour rajouter ce script inline, avant <HEAD>
• vous ou votre thème inclue déjà modernizr, ce script est déjà inclus dedans. Si modernizr est dans le <HEAD> vous n’avez rien à ajouter
• vous avez un fichier javascript global inclus dans le <HEAD>, c’est dans ce fichier qu’il faut rajouter ces lignes.

// inspiré de http://code.google.com/p/html5shim/source/browse/trunk/html5.js
// crée tous les tags HTML5 au moins une fois pour que IE sache les styler
// Commentaires et discussions, voir http://remysharp.com/2009/01/07/html5-enabling-script/
(function(){
	if(!/*@cc_on!@*/0)
		return;
	var e = 'abbr,article,aside,audio,bb,canvas,datagrid,datalist,details,dialog,eventsource,figure,footer,header,hgroup,mark,menu,meter,nav,output,progress,section,time,video'
		.split(',');
	for(var i=0, iTotal = e.length; i<iTotal;i++) {
		document.createElement(e[i]);
	}
})();

CSS

Tous les éléments inconnus pour les navigateurs sont de type display:inline par défaut, ce qui peut rapidement casser un design : si vous passez d’une <DIV> à un <ARTICLE>, vous allez être obligé de rétablir display:block pour chaque élément. Il est préférable de s’inspirer de la stratégie des CSS reset et de définir un comportement par défaut à toutes les balises HTML5 possibles. Notez que l’on définit également les balises qui devraient être inline, ceci afin de prévenir le cas où un navigateur déciderait de mettre une des ces balises en display:block. Dans le fichier style.css, après le CSS reset :

/* tags HTML5 qui se comportent comme des blocs */
article, aside, audio, canvas, datagrid, datalist, details, dialog, figure, footer, header, menu, nav, section, video { display: block; }
/* tags de type en ligne */
abbr, eventsource, mark, meter, time, progress, output, bb { display:inline; }

doctype

Nous allons maintenant remplacer votre doctype par le désormais célèbre nouveau doctype HTML5. dans header.php, première ligne : <!DOCTYPE html>. Vérifiez que votre blog s’affiche toujours comme avant sur tous vos navigateurs cible, je n’ai jamais entendu que ce nouveau doctype posait problème. Vous êtes officiellement passé en HTML5

Les articles

La sémantique en théorie

Il y a 4 nouvelles balises toutes trouvées (en plus du <Hx>) qui vont enrichir sémantiquement nos articles. Ce qui change avec HTML5, c’est que non seulement la balise a un sens, mais ce sens peut varier en fonction des éléments parents :

• <ARTICLE> : surpris ? Allons un peu plus loin : la définition du W3C dit qu’elle représente une section isolable du site, qui peut s’autosuffire en dehors du contexte de la page (dans un lecteur RSS par exemple). Cette balise peut aussi être enfant d’un autre <ARTICLE>, comme dans l’interprétation qu’en a fait HTML5 Doctor, auquel cas elle pourrait représenter les commentaires relatifs à un article. Nous n’allons pas le faire ici car ce point est parfois discuté et cela demande beaucoup plus de modifications dans wordpress car les styles de l’articles et des commentaires n’ont pas été prévus pour s’imbriquer.
• <HEADER> : cette balise n’est pas exclusivement réservée à l’en-tête du site ! A l’intérieur d’un <ARTICLE>, elle sert à repérer les titres et méta-données de l’article comme la date de publication et le nom de l’auteur. Dans WordPress, cela correspond exactement aux éléments avec les classes .entry-title, .entry-header, .author, .published et .comment-count
• <FOOTER> : elle non plus n’est pas réservée au pied de page du site. Placée dans un <ARTICLE>, elle marque les informations relatives à l’article mais non indispensables, telles que tags et catégories. Dans WordPress, cela correspond aux classes .entry-footer, .entry-categories et .entry-tags
• <TIME> : elle sert à indiquer une date. Rajoutez y l’attribut pubdate pour signifier au parseur qu’il s’agit de la date de publication de l’<ARTICLE> parent. L’attribut datetime doit contenir la date à un format standardisé qui peut varier de « 2010-08-20″ à « 2010-08-20T20:00+09:00″. PHP à la rescousse : il y a une constante pour ce format qui s’appelle DATE_W3C et que vous pouvez passer à la fonction wordpress d’affichage de la date.

Le code final :

Voici le code original simplifié d’une installation WordPress 3 avec le thème par défaut :

<div class="hentry" id="post-777">
	<h2 class="entry-title">Titre + lien</h2>
	<div class="entry-meta">
		<span class="meta-prep meta-prep-author">Publié le</span>
		<span class="entry-date">Vendredi 20 août 2010</span>
		<span class="author vcard">Auteur</span>
	</div><!-- .entry-meta -->
	<div class="entry-content">
		corps de l article
	</div><!-- .entry-content -->
	<div class="entry-utility entry-footer">
		catégories, tags, commentaires ...
	</div><!-- .entry-utility -->
</div><!-- .hentry -->

notez les très pratiques commentaires qui marquent les balises de fermeture. Nous allons donc :

• remplacer la DIV.hentry par une balise ARTICLE, en conservant les classes
• remplacer la DIV.entry-utility (ou .entry-footer dans mon thème) par une balise FOOTER, en conservant les classes
• entourer le <H2> et la DIV.entry-meta par une balise HEADER
• remplacer le <H2> par un <H1> : en HTML5, les Hx sont relatifs à l’élément parent pour lequel cela a un sens : <ARTICLE>, <SECTION> ou BODY. Contrairement à certaines recommandations SEO, il est donc possible d’avoir plusieurs H1 par page
• entourer ou remplacer le SPAN.entry-date par ce code : <time pubdate datetime="<?php the_time( DATE_W3C ); ?>"> ... </time>

pour obtenir ce markup :

<article class="hentry" id="post-777">
	<header>
		<h1 class="entry-title">Titre + lien</h1>
		<div class="entry-meta">
			<span class="meta-prep meta-prep-author">Publié le</span>
			<time pubdate datetime="2010-08-20T11:34:47+00:00"
					class="entry-date">
				Vendredi 20 août 2010
			</time>
			<span class="author vcard">Auteur</span>
		</div><!-- .entry-meta -->
	</header>
	<div class="entry-content">
		corps de l article
	</div><!-- .entry-content -->
	<footer class="entry-utility entry-footer">
		catégories, tags, commentaires ...
	</footer><!-- .entry-utility -->
</article><!-- .hentry -->

Que modifier ?

Il va falloir apporter ces modifications à beaucoup d’endroits, voici une liste non exhaustive (selon votre thème) :

• archive.php
• single.php
• page.php
• index.php
• category.php
• author.php
• tag.php
• search.php (à la différence que <ARTICLE> ne doit pas remplacer le <LI> mais être son premier et unique fils)
• date.php

Je déteste dupliquer le code, donc si vous êtes bons en WordPress vous devriez peut être inclure un template unique d’article dans tous ces fichiers, car c’est quasiment le même markup à chaque fois. La partie difficile étant bien sur de coder le « quasiment » Voilà, vous êtes passé à la sémantique HTML5 sur la partie importante du blog que sont les articles. Logiquement Google ou d’autres programmes devraient utiliser un jour ce standard, au même titre que les microformats, microdata ou RDFa pour comprendre plus facilement votre site et donc proposer des fonctionalités spécifiques à vos lecteurs (un affichage spécifique dans les résultats Google, une meilleure indexation, les navigateurs pourraient mettre en avant l’article …).

HTML5 Forms et rôles ARIA dans votre layout

Pour le reste du site, nous allons ajouter plus de sémantique. Notez que les rôles ARIA sont déjà correctement définis dans le thème par défaut, mais ce n’est probablement pas celui que vous utilisez, donc je vais les répéter.

Formulaires

Forms 2 a été renommé en HTML5 Forms et continue de définir de nouveaux types de champs ainsi que d’ajouter du comportemental sans JavaScript. Par défaut il n’y a pas de JavaScript qui régisse les formulaires de WordPress (commentaires et recherche), on ne perd donc pas de fonctionnalité pour les anciens navigateurs : on en rajoute pour ceux qui supportent HTML5 Forms Si vous voulez ajouter facilement ces fonctionnalités pour pour d’autres navigateur sans taper de code JS, vous pouvez partir sur la librairie WebForms2

Dans comments.php :

• la <DIV> avec l’id #respond devient une <SECTION> : comme une <DIV>, la <SECTION> n’a pas de valeur sémantique particulière, sinon qu’elle contient un titre, ce qui est ici le cas avec un <H3> comme enfant direct. Ce <H3> est d’ailleurs promu au rang de <H1> car c’est le titre le plus important de cette <SECTION>
• dans le formulaire de commentaire, on modifie le type de 2 champs : celui de l’email et du site Web pour les passer très logiquement en type="email" et type="url". Cela ne change rien pour la plupart des navigateurs mais outre la lisibilité du code, le seul bénéfice connu actuel est le changement de clavier sur iOS … Mais dans les mois qui viennent, d’autres clients pourraient l’utiliser pour une meilleure autocomplétion des champs ou pour signaler un type de données invalides. En attendant cela ne coûte rien
• rajouter l’attribut required ainsi que aria-required="true" aux champs obligatoires (au minimum l’email et le champs de commentaires). En code WordPress cela donne :

 <input name="email" id="email" type="email" value="<?php echo $comment_author_email; ?>" tabindex="2" <?php if ( $req ) echo "aria-required='true' required"; ?> />

Les navigateurs supportant required (FF4, Opéra 9+, Webkits) ne laisseront pas l’utilisateur valider le formulaire tant qu’il n’a pas rempli correctement les champs. Voir cette démo faite par Opéra.

Vous pouvez ensuite styler en CSS grâce aux pseudo-sélecteurs les champs non ou mal remplis :

input:invalid,
input:invalid + label {
	background-color : red;
}

Votre code final généré pour la zone de saisie de commentaires devrait ressembler à ceci :

<section id="respond">
	<h3 id="leave-a-reply">Laisser un commentaire</h3>
	<!--BEGIN #comment-form-->
	<form action="...">
		<!--BEGIN #form-section-url-->
		<div class="form-section" id="form-section-url">
			<input type="url" required="required" aria-required="true" value="http://braincracking.org/" id="url" name="url">
			<label class="required" for="url">Site Web</label>
		<!--END #form-section-url-->
		</div>
	../..
	<!--END #comment-form-->
	</form>
<!--END #respond-->
</section> 

Notez que l’on pourrait passer de même tous les widgets avec <SECTION> et leur titre en <H1>.

Dans searchform.php :

Si votre thème n’a peut-être pas ce fichier ou équivalent, sachez que le formulaire de recherche par défaut se trouve dans general-template.php, dans la fonction get_search_form. Nous allons rajouter ici 3 choses :

• le rôle ARIA sur le formulaire lui même : <form role="search" ...>
• le type « search » sur le champs de formulaire : <input type="search" />. Notez que sous les webkits sur Mac OS, votre champs apparaît stylé comme Spotlight : arrondi avec une croix d’annulation
• un « placeholder », grand classique du Web : un texte par défaut disparaît lorsque l’on clique sur le champs et ré-apparaît si rien n’a été écrit : <input placeholder="Rechercher" />

ce qui se devrait se traduire par ce code final :

<form role="search" action="http://braincracking.org/blog" method="get" class="searchform">
	<input type="search" placeholder="Rechercher" name="s" class="search" />
	<button type="submit" class="search-btn">Rechercher</button>
<!--END #searchform-->
</form> 

Layout

sidebar.php

Ceci affiche la ou les colonnes latérales, qui est donc un contenu sans forcément un rapport direct avec le contenu principal du site. ARIA et HTML5 ont tout prévu pour cela : role="complementary" et balise <ASIDE>. Vous devez donc modifier une (ou plusieurs selon le thème) <DIV> parentes pour obtenir ceci :

<aside role="complementary" id="..." class="...">
	widget et contenus relatifs
</aside>

header.php

Nous avons déjà modifié ce fichier pour y rajouter le doctype, notre JS et le CSS afin de préparer le blog à HTML5. Passons maintenant aux ajouts sémantiques :

• la balise <HEADER>, pour marquer cette zone
• la balise <NAV> pour indiquer une zone de liens. Selon votre thème, cela peut être la liste des catégories ou des pages à part. Nous lui ajouterons le rôle ARIA navigation qui lui correspond exactement
• le rôle ARIA banner qui signale titre et logo
• si votre formulaire de recherche n’est pas déjà modifié, c’est le moment de rajouter role="search" sur le formulaire et type="search" placeholder="Rechercher" dans le champs de recherche

Les résultats varient grandement selon le thème, mais voici un exemple simplifié à partir du code du thème par défaut WordPress 3 :

<header class="header">
	<nav id="access" role="navigation">
		<ul class="nav">
			<li class="current_page_item"><a href="http://braincracking.org/blog/" title="Accueil">Accueil</a></li>
			<li class="page_item page-item-2"><a href="http://braincracking.org/blog/a-propos/" title="A propos">A propos</a></li>
		</ul>
	</nav>
	<!-- END #access -->
	<div id="branding" role="banner">
		<h1 id="blog_header"><a href="http://braincracking.org/blog">BrainCracking</a></h1>
	</div> <!-- #branding -->
</header><!-- #header -->

footer.php

Là aussi, sans grande surprise nous allons utiliser la balise <FOOTER> ainsi que le role=contentinfo qui sont tous deux faits pour baliser une zone contenant copyrights, liens vers mentions légales et autres textes relatifs au site, mais pas forcément au contenu de cette page. Attention, chez WordPress cela ne correspond pas exactement à la DIV id="footer" du template par défaut, celle ci contenant également d’autres widgets.
Concrètement :

<!--BEGIN #footer-->
<div id="footer">
	<div id="footer-widget-area">
		code généré par les widgets
	</div><!-- End #footer-widget-area -->
	<footer id="copyright" role="contentinfo">© 2009-2010
		<nav role="navigation">
			Liens vers mentions légales, vie privée, qui somme nous ...
		</nav>
	</footer>
<!--END #footer-->
</div>

Notez que pour ceux qui font des liens, on peut tout à fait rajouter la balise <NAV>.

Conclusion

Avec ce tutoriel et 2 à 3 heures de travail, vous pouvez passez assez facilement à la sémantique HTML5 sur votre blog dès aujourd’hui. En fait en le codant, il devient même évident que les spécifications HTML5 et ARIA on été influencées par la sémantique WordPress tant la correspondance est facile.

Du côté de HTML5, il est probable que sur ce thème par défaut, WordPress ait préféré faire l’impasse pour ne pas dépendre de Javascript ou de spécifications qui ne sont pas totalement fixées. Je pense personnellement que ces 2 limites ne sont pas un problème :

• les éléments que j’ai cité ici ont tous ont été largement discutés, et il est peu probable que le W3C revienne dessus. Si c’est cependant le cas les modifications à faire ne sont pas complexes
• j’estime la population avec IE et javascript désactivé comme négligeable, au pire ils auront un design cassé mais sur un blog le contenu principal (l’article) restera exploitable.

Les rôles ARIA sont déjà inclus dans le thème par défaut de WordPress 3, mais nombre de thèmes ont oublié de les répliquer. En créant ce blog, je cherchais des thèmes exploitant déjà la sémantique HTML5, mais ils sont peu nombreux donc le choix en graphismes est limité, et à l’heure d’écrire cet article aucun n’exploitait autant ARIA et HTML5.

Références, outils, remerciements :

• 2 thèmes WordPress tout faits (mais incomplets) : Toolbox et JustCSS
• les specifications HTML5 et ARIA
• la démo d’Opéra sur les formulaires HTML5
• HTML5 Doctor pour l’ensemble de leur oeuvre d’explication des specifications
• Merci à Johan Bleuzen d’avoir relu et validé la partie WordPress
• les validateurs W3C et WHATWG que passe maintenant braincracking.org
• le plugin Wave pour vérifier ARIA sur son site
• le bookmarklet h5o pour analyser une page HTML5 selon l’algorithme W3C

• 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

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.