Cet article et le précédent, plus technique, sur les tiers classiques sont une transcription d’une conférence donnée à Blend Web Mix 2016. Cliquez ici si vous êtes plus audio que texte.

La publicité et les performances

Mettre « pub » et « perf » dans la même phrase fait rire jaune tout travailleur du Web. Le peu de fois où nous désactivons nos adblockers, nous nous demandons comment font « les gens » pour arriver à naviguer. Le peu de fois où nous testons le site sur autre chose que nos mobiles personnels, généralement performants, nous prenons notre mal en patience car c’est pour le travail. Les vrais utilisateurs eux, sont déjà partis.

Performance perçue et Performance business

Il y a des palanquées de chiffres démontrant la relation business/temps de chargement, regardez ne serait-ce que cette collection 2016 chez wpostats (communautaire) ou ces traductions en français chez Dareboost (solution commerciale). Laissez moi vous sortir quelques chiffres de chez mes clients.

une très classique relation engagement / temps de chargement

Cette courbe (réalisée avec le produit commercial webperf.io) est assez classique et range les utilisateurs par temps de chargement (axe horizontal) et indique pour chaque segment le taux d’engagement (plus c’est haut, plus il consomme). Ici c’est un site de presse, donc c’est le nombre de pages consommées par session. Comme souvent, on voit que les utilisateurs sont moins consommateurs lorsque leurs pages se chargent en plus de 5 secondes. Puis au-delà de 20 secondes, la courbe s’aplanit, car ne restent que les fidèles et les motivés. Je précise que j’ai généré cette courbe en filtrant pour n’avoir que les utilisateurs Windows, afin de ne pas être influencé par les mobiles.

Autre constat en fouillant les chiffres :

Les utilisateurs avec adblock ont un engagement 50% supérieur aux autres

Quand on sait que la majorité des temps de chargement sont consacrés à la seule publicité, il devient évident que cette source de revenus a un coût qui dépasse de loin ce qui est écrit sur le contrat avec la régie.

Comment louper 85% des internautes français

Avec quoi vos utilisateurs mobiles naviguent-ils ? Vous trouverez sans doute dans vos analytics les modèles de smartphones et tablettes. Prenez le top 25 et allez récupérer pour chaque modèle son prix de vente actuel, occasions comprises (surtout pour les iPhones). Chez 3 clients (2 journaux, 1 site de e-commerce) j’obtiens à peu près la même valeur moyenne : 380€.
En voyant ces stats, je me suis longtemps dit que les français étaient plutôt privilégiés par rapport à leurs voisins et pouvaient mettre de beaux budgets dans leurs smartphones (merci Free ?). Jusqu’à ce que je trouve les prix d’achat du marché français des smartphones :

prix d’achat des mobiles en 2015

L’étude de marché est faite par GFK pour le 1er semestre 2015 et montre clairement que la population qui possède des portables de plus de 300€ ne représente que 15% des français … La médiane est plutôt comprise entre 100 et 150€.
Utilisent-ils le Web ? Oui puisque d’après l‘ARCEP 70% des cartes SIM utilisent la 3G. Même en supposant que seuls les possesseurs des smartphones les plus chers achètent de la 3G, cela signifie qu’il n’est pas rare d’avoir des mobiles de 75-100€ accéder au Web.
Pourquoi ne les voyez-vous pas sur vos sites ? Tentez de charger une page de journal avec un mobile ou une tablette à moins de 200€ ! Je pense que les gens accèdent bien au Web mais que l’expérience d’un site chargé en pub est tellement pénible qu’ils restent sur les applications de Facebook ou Google (où la pub est parfaitement sous contrôle d’ailleurs).

Pour résumer, laisser ses pubs faire n’importe quoi, c’est se couper de la majorité du parc mobile français.

Pub lourdes ? Essayez avec moins!

Il y a des stratégies intéressantes pour laisser plus d’utilisateurs devant des publicités plus visibles. Elles jouent sur les modes de facturation de la pub (impression ou visibilité garantie), sur la notion de valeur moyenne de l’inventaire et sur la réalité technique qui est que moins on affiche de pubs, plus ça va vite, et plus l’utilisateur consommera de pages, donc d’affichage de pubs.
Prenons par exemple le journal anglais Guardian.

• on affiche d’abord texte et photo principale, c’est ce qui fait que l’utilisateur va rester
• notez qu’un espace blanc en haut de page est déjà prévu pour y afficher une bannière et éviter les désagréables effets de page qui saute
• dans la plus pure tradition de l’amélioration progressive, la plupart des liens sont déjà cliquables et on peut interagir avec le menu même si les fonctionnalités JavaScript n’ont pas encore été récupérées
• affichage progressif des fonctionnalités secondaires, comme les boutons de partage sur la gauche
• enfin, affichage de deux emplacements pub classiques en haut et à droite
• chose importante : aucune publicité en dehors du viewport ne commence à se charger, pour ne pas gêner le chargement des ressources plus visibles
• au scroll, la pub de droite reste bien visible

Du côté de chez Yahoo!, où la performance frontend a été inventée il y a 10 ans (j’y étais !), on peut aussi espérer qu’un soin particulier ait été apporté aux pubs.

En France, nous avons l’exemple de Libération :

En résumé : on réduit l’inventaire, on y met des formats différenciants ou légers, et dans tous les cas on maximise la visibilité d’une position en particulier. Cette dernière étant vendue plus chère, elle compensera les pertes sur les positions disparues qui étaient vendues à l‘impression. L’amélioration de l’expérience utilisateur et l’ouverture à une gamme plus large de mobiles devraient remonter le nombre de pages vues.
Le fait d’avoir moins d’inventaire permet aussi aux équipes de se concentrer sur la qualité de ce qui est diffusé, ce qui est à mon avis un gros plus pour l’image de marque.

La pub et la qualité

L’image de marque

Une mauvaise publicité ne dégrade-t-elle pas l’image de marque des éditeurs ? Ça semble évident et pourtant je n’ai pas réussi à trouver d’étude sur ce sujet. Les éditeurs historiques devraient protéger leur image de marque, dont la crédibilité est encore un critère qui fait cliquer sur un article par exemple, mais on sent bien qu’ils ont partiellement abandonné la partie !
Rassurez-moi, il n’y a pas que moi qui pense que les services de « content discovery » (en France Outbrain, Ligatus ou Taboola) mettent à mal l’image de sérieux des titres de presse ?

À gauche : « Le Monde » et Outbrain,
À droite « Le Parisien » et Taboola

Je n’ai pas eu à me forcer pour trouver sur « Le Monde » sous un article à propos du traité CETA la mise en avant d’articles aux sujets … variés : femme pulpeuse, mal au dos, fabriquer un vélo, Madonna VS Trump … Et pour « Le Parisien », les thèmes sont petites culottes, photos en bikini et poids des stars, juste sous deux articles à propos du sexisme… Oh Ironie.

Avoir une marque c’est aussi avoir une identité visuelle forte.

Extrait des slides de la conférence de Renaud Forestié sur le redesign d’un site de presse

Pas facile de se démarquer des autres quand il faut respecter la charte des régies : avoir une largeur de 1000 pixels (à 20 près), un contenu forcément centré et un pavé de droite visible dans les 800 premiers pixels. Compliqué également pour ces journaux de tenter des formats nouveaux, ce qui est un manque à gagner quand on sait que l’introduction de nouveaux formats augmente toujours le taux d’interaction pub (source).

Qui paye la non-qualité des pubs ?

Quand on arrive de l’extérieur comme moi, c’est compliqué de comprendre comment les régies et les fabricants de pub peuvent se permettre de diffuser les choses suivantes.

Des virus !

Quand la pub diffuse des virus, c’est l’éditeur qu’on accuse.

Régulièrement des pubs vérolées sont diffusées, y compris par des grands éditeurs comme Yahoo! ou MSN. Les virus exploitent les failles des navigateurs non patchés pour s’installer automatiquement sur les machines. Ne croyez pas que ça ne concerne que les vieux IE sur XP, iOS 10.0 a récemment été vulnérable à ce même genre d’attaques : le simple affichage d’un JPEG permettait de l’infecter. Il est donc rentable pour des groupes criminels de pirater des serveurs de pub ou simplement d’acheter des emplacements avec très peu de budget (RTB + ciblage navigateur). Notez que dans ces cas là, c’est l’image de marque du diffuseur qui prend, pas la régie ni ses prestataires.

Des pubs qui ne marchent pas

Au hasard de mes audits de WebPerf qui se font sans adblocker (moment toujours pénible), il est fréquent de tomber sur des pubs qui non seulement font ramer le site mais qui en plus ne marchent pas. Comme cette pub qui tourne en boucle sur une erreur, fait plafonner le processeur mais ne réussira jamais à jouer la vidéo.

Non, cette pub ne s’affichera jamais, mais on va la facturer quand même.

Des pubs loooooongues

D’autres fois il faut tellement de temps à une publicité pour s’afficher qu’on se demande comment quelqu’un espère gagner de l’argent grâce à elle.

La Vache Qui Rame™

Ici il a fallu 17 secondes à la marque pour s’afficher, sur une connexion tout à fait standard. Sur un article passe encore car il y a de bonnes chances que l’utilisateur soit encore là, mais sur une page type Home, résultat de recherche, il n’y a probablement plus personne pour voir la marque.

Qui paye pour ces pubs peu ou pas du tout visibles ?

Il y a deux cas de figure.

L’annonceur paye la régie pour un volume d’impressions. Techniquement tout se joue sur le moment où la comptabilisation de l’impression remonte. Dans le cas « Vache qui rit », il y avait plus de 12 secondes entre la comptabilisation par la régie et l‘apparition de la marque… Dans ces cas, c’est donc les annonceurs qui sont floués, mais ils doivent y être habitués puisque cela fait 20 ans que des pubs sont vendues à l’affichage même si aucun humain ne les voit (56% des pubs ne sont pas vues d’après Google).

L’annonceur achète avec une garantie de visibilité. La visibilité est, d’après le groupement des professionnels de la pub (IAB), lorsqu’au moins 50% des pixels d’une pub sont dans le viewport navigateur pendant plus d’une seconde. Si la comptabilisation se fait honnêtement, c’est à dire après le chargement de la pub mais que celle-ci est trop lente ou en erreur, c’est l’éditeur qui a un manque à gagner en ayant fait une page vue non facturable.

La régie gagne à tous les coups…

Ce ne sont pas de grandes méchantes pour autant : elles sont réactives dès lors qu’on leur signale des publicités en erreur ou qui font planter le site par exemple, et ensuite des rapports de force polis s’installent comme dans toute relation commerciale. Mais disons qu’elles n’ont pas le besoin économique impératif de vérifier toutes les créations de tous leurs prestataires.

Quelles solutions pour les éditeurs ?

Le rapport de force étant en faveur des intermédiaires de la pub, qui ont bien d’autres canaux de diffusion, c’est clairement aux éditeurs de s’organiser pour ne pas périr étouffés.
D’abord en définissant des contraintes de qualité technique (côté éditorial, ça ne peut se faire qu’au cas par cas). Ça tombe bien, l’IAB US a défini un cahier des charges précis où, pour chaque format, ils définissent des limites. Par exemple un Skyscraper ne doit pas dépasser 200Ko au démarrage, puis a le droit de récupérer 300Ko supplémentaires 1 seconde après le chargement de la page. Une vidéo doit se jouer en 24 images/seconde pendant 15 secondes max et un interstitiel animé ne doit pas dépasser 15 secondes.

De la contrainte nait la créativité … et une meilleure rentabilité

C’est dommage que les pros français de la pub n’en aient jamais entendu parler, mais encore une fois ce n’est pas l’univers bouillonnant des intermédiaires de la pub qui va s’auto-imposer des contraintes tant que leurs clients ne leur demande rien.
On peut aussi définir un seuil de temps processeur à ne pas dépasser et exiger le respect des actions techniques de base (compression, concaténation, mise en cache …). Que l’on utilise ces guidelines ou que chaque site les adapte à sa cible (typiquement, nos réseaux mobiles nous permettent d’être moins stricts qu’aux US), le tout est d’en avoir et de s’accorder dessus avec sa régie.

Une fois les règles définies, il faut passer à la phase de vérification, si possible automatisée donc permanente et systématique.
Je n’ai pas eu connaissance de solution, même commerciale, qui permettrait de vérifier automatiquement les pubs délivrées à partir d’un cahier des charges. Même pour surveiller les tiers de manière générale il n’y a pas vraiment d’offre complète, à tel point que je suis en train de construire ce genre de dashboard sur commande.

Visualisation du poids servi par nom de domaine. Tiens une pub de 3 Mo a arrêté d’être distribuée.

On peut surveiller la consommation processeur, réseau, les temps de réponse des tiers… Pour certaines campagnes ciblées on pourrait récupérer les métriques de visibilité : savoir quand le logo de la marque est visible par exemple, vu depuis les postes utilisateur, information que certaines régies font payer. Lorsque le business model dépend des tiers, ce monitoring peut expliquer la variation de certaines métriques métier comme la baisse du nombre de vues le même jour qu’une défaillance partielle des serveurs de la régie.
À la fin, cela redonne matière à négocier un peu plus de qualité ou peut redonner confiance envers votre prestataire.

Conclusion

Nous avons vu dans un précédent article que les tiers en général (pubs, widgets, trackers, services …) pouvaient vous coûter de l’argent pour des raisons de contre-performance perçue, de distraction, d’atteinte à l’image de marque ou présentaient un risque de fuite de données. Nous avions vu que les solutions techniques existaient mais qu’il faut se laisser le temps de les appliquer lors de l’intégration du tiers (principe « si c’est rapide à intégrer, c’est que ça va ramer »).

Nous venons de voir que la publicité posait ses propres difficultés qui demandent bien plus que les solutions techniques classiques. Les éditeurs ont intérêt à rapidement définir des cahiers des charges et à s’équiper pour s’assurer qu’ils seront respectés pour stopper les pertes de revenus dues aux mauvaises qualités de certaines pubs d’une part, et à l’excès de position d’autre part.
Des éditeurs ont choisi des stratégies d’affichage des publicités qui améliorent grandement l’expérience utilisateur (moins d’emplacements, vendus plus cher) et potentiellement les revenus : qu’attendez-vous pour étudier le sujet ?

Cet article et le suivant sur les pubs sont une transcription d’une conférence donnée à Blend Web Mix 2016. Cliquez ici si vous êtes plus audio que texte.

De quels coûts parle-t-on ?
Ma spécialité étant la performance frontend, j’ai dû m’attaquer au sujet pour des raisons techniques qui m’ont amené à constater que les dégradations en qualité et en performance perçue se traduisaient par un certain nombre de coûts cachés:

1. des pertes sèches d’activité
2. un manque à gagner dû au ralentissement du chargement ou au gel de l’interface
3. une ouverture pour le piratage industriel
4. une image de marque entamée.

Qui sont les tiers ici ?

• Analytics, tracking
• Boutons de partage, réseaux sociaux
• Tests A/B
• Widgets divers : cartes, commentaires, chats…

Et étant donnéées leurs spécificités, citons-les à part : les publicités, auxquelles j’ai dédié un article moins technique.

Passons en revue les problèmes et solutions.

1. Les 20 secondes page blanche

Dans le plus spectaculaire des cas, vous pourriez avoir un site qui n’affiche rien pendant plusieurs secondes.

Veuillez patienter, nous allons prendre votre temps.

Pour rajouter un peu de sel sur la plaie, disons que c’est le grand patron qui découvre cela un samedi après-midi de vacances. On va alors se lancer dans une partie de Cluedo pour savoir qui a tué le site et les premiers suspects sont les administrateurs système.
Heureusement pour eux, ce sont également fréquemment les seuls à être suffisamment bien équipés en monitoring pour démontrer que les serveurs de la boîte vont bien. Dans le meilleur des cas ils savent mener une analyse rapide du réseau, vue d’un navigateur.

la requête coupable est une longue barre grise, sur-lignée en rouge (forcément)

Après analyse, c’est un petit script hébergé sur un serveur qui ne répond pas qui bloque la page. On passe donc en revue les suspect suivants :

• les développeurs frontend qui n’ont fait que leur devoir en implémentant la solution demandée par le métier,
• les services marketing et commercial qui ont légitimement besoin de cette solution de [adserving | test A/B | widget | tracker]
• le service tiers, qui avait donné comme garantie au moment de l’intégration : « On est sur un CDN ».

L’enfer c’est les autres

Il est très tentant d’incriminer le tiers à la moindre occasion, et parfois c’est justifié, comme cet incident il y a quelques années où certains tunnels de paiement se mettaient à afficher des erreurs de sécurité.

une alerte de sécurité du plus bel effet au moment de payer

Les pages touchées étaient celles en HTTPS qui incluaient jQuery depuis le CDN code.jquery.com … dont l’administrateur avait oublié cette après midi là de renouveler le certificat de sécurité.
Mais il y a plein d’autres raisons pour lesquelles un serveur tiers peut ne pas répondre comme :

• des attaques mettant à mal votre prestataire ou ses propres prestataires. Dans le cas de l’attaque DDoS contre le DNS Dyn, Twitter n’était plus visible de certains endroits de la planète … tant pis pour les pages incluant les widgets.
• des erreurs réseau de l‘hyper-espace comme la redirection temporaire du domaine Google vers un site de prévention du terrorisme du gouvernement … Uniquement pour les clients Orange un 17 octobre o_O
• les wifis gratuits publics (hôtels, aéroports…) qui redirigent certaines requêtes pour insérer dans les pages leurs propres régies publicitaires
• les firewalls d’états (Chine en tête) ou les proxys d’entreprise qui ont une opinion tranchée sur l’utilisateur Facebook ou Youtube et qui bloquent les domaines : dommage pour les widgets et analytics

Bref : il y a 1001 raisons pour qu’un serveur tiers plante ou ralentisse, il faut donc prévoir son intégration avec cet état de fait.

Savoir intégrer les tiers

Généralement l’intégrateur reçoit simplement comme instruction un mail disant :

Insérez ce script dans le <head>

J’exagère un peu, parfois on a droit à un document Word formaté proprement (mais qui dit la même chose).
Il arrive aussi que les développeurs décident d’eux même de faire une bêtise :

• inclusion de librairies JS / CSS directement depuis leurs CDNs respectifs, comme le préconisent les documentations,
• récupération des fichiers de polices depuis les serveurs Google Fonts ou autre.

Dans ce dernier cas, il peut y avoir l’excuse de la licence qui n’autorise pas forcément le rapatriement du fichier. Du coup vous faites subir à vos utilisateurs le comportement par défaut de tous les navigateurs (sauf IE) qui n’affichent pas le texte tant que le fichier de police n’est pas présent.

Je vois pas le problème

Pour visualiser les problèmes d’intégration, et surtout leurs conséquences pour l’utilisateur, je ne saurais trop vous recommander les outils suivants :

• L’indispensable service en ligne WebPagetest : déplier « Advanced Settings », onglet « SPOF » et y mettre les noms d’hôtes à faire planter.
• L’extension Chrome SPOF-o-Matic qui permet d’alerter, de tester et même de programmer un test comparatif sur WebPagetest.
• En ligne de commande (pour l’intégration continue par exemple), je vous ai fait un petit script par dessus SPOF-check

l’extension SPOF-o-Matic débusquant les potentiels fauteurs de troubles

Solutions

Pour ne jamais dépendre d’un tiers, il n’y a qu’environ 2 stratégies :

1. Les ressources critiques sont à rapatrier sur vos propres serveurs. Le CSS bien sûr, les dépendances JS, les polices si vous en avez le droit.
2. Tout ce qui reste hébergé ailleurs doit passer en asynchrone : trackers, analytics, widgets, les polices…

Il y a certains cas spéciaux comme l’inclusion des tests A/B qui sont à la fois dynamiques et critiques pour le rendu de la page, étant donné qu’ils essayent de le modifier. Mais si vous demandez poliment une mécanique de « timeout » ou un rapatriement périodique du fichier, vous n’aurez plus de soucis.

2. Les retards à l’allumage

Une fois traité le problème impressionnant mais rare de la page blanche dûe à un tiers, reste le problème sournois du ralentissement quotidien, moins visible mais bien plus coûteux. Même avec des inclusions asynchrones on peut se retrouver dans ces situations

Moteur de recherche (95% du business) attendant une régie pub (5% du business)

Beaucoup (trop) de fonctionnalités dépendent complètement de JavaScript et de moins en moins de développeurs tentent l’amélioration progressive. Dans certains cas comme ici un moteur de recherche complexe, il est même irréaliste de vouloir afficher un moteur sans JS, d’où l’idée de mettre une interface de chargement pour patienter. En sachant que ce code métier critique est inclus en haut de page, quand l’exécuter ? Du pire au mieux :

1. en haut de page ! Bien sur que NON, le DOM n’est pas forcément disponible à ce moment-là (ce qui ne se voit pas forcément quand on développe sur son poste en local d’ailleurs )
2. on fait confiance à StackOverflow et on attend que document.readyState === 'complete' … Cela correspond à l’événement window.load, c’est-à-dire qu’on va attendre patiemment que toutes les images, iframes et même certains scripts asynchrones soient chargés ! L’utilisateur n’attendra pas, lui.
3. on attend l’événement document.DOMContentLoaded (en jQuery : $(document).ready(init) ou juste $(init)). Cet événement est retardé par les insertions de scripts même en bas de page, les scripts asynchrones avec l’attribut defer et toute exécution de script, dont le tueur de performances document.write(). La pub utilise toujours cette instruction.
4. juste après le code HTML du formulaire : vous avez à la fois la garantie que le DOM est présent, et d’être exécuté avant tous les événements navigateur. C’est ce que je recommande pour du code critique comme ce formulaire.

Il y a donc un conflit ouvert entre le tiers inclus et votre code métier, que vous pouvez résoudre en exécutant plus tôt votre code. Si vous persistez à vouloir dépendre de l’événement DOMContentLoaded pour exécuter votre code, il va falloir travailler au corps l’inclusion des scripts des tiers :

• s’ils ne sont pas lourds à l’exécution et importants, le plus bas possible dans la source avec l’attribut standard async (IE10 +)
• s’ils sont secondaires, en inclusion asynchrone classique après le chargement de la page (natif façon Analytics ou $.getScript)
• refuser les scripts dépendant ou utilisant document.write() (d’ailleurs partiellement dépréciée par Chrome).

La pub est spéciale : les régies ne peuvent pas se passer de l’instruction document.write() car leurs propres fournisseurs l’utilisent peut-être. La solution technique est simplement d’inclure la publicité en iframe, ce qui interdit certains formats invasifs. Désolé de vous le dire mais si votre business dépend de la pub et que vous vous êtes engagé à afficher des pubs qui peuvent déborder de leur cadre, il n’y a pas de solution purement technique ! On va voir dans un autre article qu’il y a matière à bien faire, mais que les décisions sont loins d’être techniques.

Après le chargement

Vous avez forcément déjà constaté les effets d’interface gelée voire de crash sur mobile, ou vous avez eu l’impression que votre ordinateur portable allait décoller de votre bureau par la seule force de ses ventilateurs. Pour faire le test, je vous conseille de visiter cette page parodique sans adblock, voire sur mobile : http://worldsmostshareablewebsite.greig.cc/, qui se contente d’inclure plusieurs fournisseurs de boutons de partage. Sur une tablette Nexus 7, l’interface est gelée pendant 20 secondes.
La nouvelle bataille de la performance frontend, est clairement les temps d’exécution abusifs côté client. J’ai déjà eu le cas avec de « simples » inclusions de bouton de partage (Facebook et G+ en tête) mais c’est le cas avec n’importe quel script qui va modifier l’interface. Il y a un principe général à comprendre avec les tiers :

Si c’est rapide à intégrer, c’est que ça va ramer

Les tiers, en particulier s’ils ont une version gratuite, ont 2 besoins antinomiques : simple et passe-partout. Le tutoriel doit paraître simple et consiste généralement en une inclusion de script et à la création d’un peu de HTML. À l’image du bouton Facebook.

Trop simple pour être performant

Remarquez que l’insertion du script est généralement asynchrone comme ici, car les tiers ont fait des efforts pour ne pas bloquer les chargements ces dernières années.

Détecter le problème

Maintenant mettez vous à la place du développeur de ce code : comment faire pour savoir où afficher son widget ? La réponse est aussi simple que contre-performante : en s’auto-exécutant dès que possible, et en scannant le DOM régulièrement. Selon la lourdeur initiale de votre site, on peut vite arriver à de jolis blocages dont vous ne comprendrez l’origine qu’avec un profilage en règle. Notez qu’il faut utiliser de vraies machines pour tester correctement tout cela.

3 longues secondes d’exécution pour ce seul tiers

Le fichier mis en cause ici (post-widget.js surligné en gris) provient effectivement d’un tiers qui inclut des boutons sociaux. Il bloquait l’interface et faisait même régulièrement planter un iPad mini 2. À sa décharge, la page visée était lourde et contenait 150 éléments que le script recherchait et modifiait.
Il n’existait pas d’outil dédié — même payant — permettant de déceler facilement qui était responsable des pics de charge processeur sur une page. J’ai du écrire un petit script du nom de 3rd-party-cpu-abuser qui exploite la timeline de Chrome Dev Tools pour mettre des noms sur les responsables :

80% du CPU consommé l’est par les tiers

WebPagetest a également récemment introduit une visualisation du CPU répartie par fichier JS : onglet « chrome », case « capture devtools timeline »).

Pour débloquer la situation, je me suis contenté comme souvent d’aller lire la documentation pour y chercher 2 optimisations classiques :

• comment ne pas initialiser le script automatiquement, afin d’éviter l’effet Big Bang du début de construction de page et ne l’exécuter qu’au moment opportun.
• comment indiquer le DOM à modifier, pour éviter les recherches DOM coûteuses

Pratiquement tous les fournisseurs de widget proposent maintenant ces options dans leurs APIs. Si ce n’est pas le cas, c’est mauvais signe donc partez chez le concurrent !

3. L’espionnage industriel

Les réseaux sociaux

La performance

Rajouter quelques boutons de partage n’est pas aussi gratuit que ça en a l’air. Il y a bien sûr la performance utilisateur, qui en pâtit.

4 boutons = ralentissement de l’affichage et du temps de chargement

Sur cette page wordpress simple et optimisée, rajouter 4 boutons natifs multiplie le temps de 1er affichage et de chargement par deux !

Les taux de transformation

Mais il faut aussi se demander si ces boutons apportent vraiment quelque chose au site. Par exemple Smashing Mag en 2012 avait constaté qu’en ENLEVANT le bouton Facebook, leurs utilisateurs partageaient plus les articles sur Facebook !

Smashing Mag : « le trafic depuis Facebook a augmenté depuis que nous avons enlevé les boutons FaceBook de nos articles » (2012)

NB: Entretemps Facebook a sorti un bouton « Partage » plutôt que simplement « Like », et Smashing Mag l’a ré-intégré de manière statique.

Autre exemple : un test A/B fait par un site de e-commerce qui a consisté à SUPPRIMER ces boutons de la page produit et leur a permis de constater que cette suppression AUGMENTAIT les taux de conversion de 12%. Ils supposent que finalement ces boutons n’étaient qu’une distraction à ce moment-là, et que les chiffres de partage affichés, proches de 0 comme souvent dans le e-commerce, renvoyaient un sentiment négatif. J’y ajouterais que la légère dégradation de performance induite par ces boutons a dû contribuer

Bref : comme pour n’importe quelle fonctionnalité, demandez vous si elle ne dessert pas plutôt votre produit, ou s’il n’y a pas une meilleure manière de l’intégrer.

Nourrir vos concurrents

La raison d’être secondaire de ces boutons pour Google et Facebook est qu’il leur permet de mieux qualifier leurs propres utilisateurs, en dehors de leurs propres murs. Même lorsque l’utilisateur n’interagit pas avec, leur simple présence signale à G. et FB qu’un de leurs utilisateurs visite une page, leur permettant ainsi d’affiner les profils. Dans le cas de Google, l’utilisateur n’a même pas besoin d’avoir un compte. Ne me lancez pas sur le respect de la vie privée, d’autres le font mieux que moi, parlons plutôt argent.
À toute fin utile, il faut tout de même rappeler que Google mange 42% du marché de la publicité en France (95% des 47% du CA de la search).

Marché de la pub en 2014

Pour le marché qui vous intéresse probablement, c’est-à-dire le « display » (affichage de bannières classiques) on estime que Facebook en capte 30%. Ce que les annonceurs apprécient, outre l’audience, c’est que leur base est hyper qualifiée, et c’est en partie grâce aux sites qui incluent les boutons.
Déjà que ces boîtes s’évitent un maximum d’impôts en France, ce n’est pas la peine de leur faire de cadeau supplémentaire en utilisant leurs scripts tels quels.

Les solutions

En admettant que vous ayez déterminé que les boutons de partage étaient vraiment bons pour votre site (typiquement, un site d’articles), il existe des manières d’inclure qui ne nourrissent pas vos concurrents, sont performantes et respectent votre charte graphique :

1. les boutons statiques, qui sont des liens simples formatés permettant le partage et que vous pouvez mettre par dessus de simples icônes
2. si vous avez besoin de fonctionnalités supplémentaires comme des icônes toutes faites, afficher les compteurs ou avoir des analytics, vous pouvez rajouter un peu de JavaScript. Voici une solution open-source parmi d’autres
3. enfin il existe quantité de services tiers (addThis, shareThis, shareAholic …) mais on retombe sur les travers habituels des tiers : il faut benchmarker les temps de chargement car ils vont du simple au triple et le business model de certains comme shareAholic est de revendre les données utilisateur

Les tiers des tiers de vos tiers

Le problème

Quand il n’y en a qu’un ça va

S’il est normal de faire confiance à un prestataire direct, la confiance ne peut que s’étioler au fur et à mesure de la chaîne d’appel de leurs partenaires. Or quand vous accordez techniquement les pleins pouvoirs à votre prestataire (une simple insertion de script), vous les accordez également à toute une chaîne de sociétés dont vous n’aviez peut-être jamais entendu parler. Je vais utiliser l’outil RequestMap pour visualiser un affichage sur la Une du journal Le Monde.

Appels vers les tiers de 1er niveau

Chaque cercle est un nom de domaine, les flèches sont les appels. Au centre en bleu clair, le domaine principal www.lemonde.fr qui appelle 2 sous-domaines de statiques (s1 et s2.lemde.fr). Tous les autres domaines (cercles) appartiennent aux tiers de 1er niveau et correspondent à une quinzaine de sociétés. On y trouve 3 solutions d’analytics, une solution de test A/B (Kameleoon), un tracking de réseau social (Po.st), FaceBook, un moteur de recommandation d’articles (Outbrain ici), Cedexis … Ce sont les tiers de 1er niveau : ceux que l’on inclut de manière tout à fait consciente. Les relations avec ces tiers sont régies par un contrat direct ou par l’acceptation des CGU, et tant que les principes d’intégration cités plus haut dans cet article sont respectés, je n’ai plus rien à rajouter.

Puis arrive le moment où l’on contacte la régie pub (SmartAd en l’occurrence, à droite sur le graphe précédent, à gauche sur le graphe suivant).

Appel des tiers de niveau 2, 3 et 4 … Oh la belle rose

Les solutions

Se parler !

Les premières actions ne sont pas techniques du tout.
D’abord, lister quelles sociétés atterrissent sur vos pages, avec des solutions :

• open-source, comme LightBeam et privacy-badger
• commerciales, comme le populaire Ghostery

Ensuite, du côté des contrats signés avec vos partenaires, vérifiez que leurs partenaires à eux vous conviennent et demandez-vous quels engagements de moyens ils ont et pourquoi pas imaginer un système de pénalités. Les régies savent se montrer réactives lorsqu’un de leurs clients leur signale un problème avec un prestataire, mais détecter le problème en question est très compliqué.
Enfin, il faut établir un dialogue entre les équipes IT et les utilisateurs des services tiers (marketing, produit, commerciaux …), en faisant un point régulier « Tiers », avec l’ordre du jour suivant :

1. l’IT fait l’inventaire des tiers de 1er niveau et remontent éventuellement les problèmes rencontrés
2. côté business, on classe par ordre d’importance les tiers … oui il va y avoir du débat !
3. décisions de suppression
4. décisions quant à l’ordre de chargement

On se retrouve à prendre des décisions complexes car comment décider de ce qui est plus important entre un test A/B, les analytics, le player vidéo, les pubs, la carte ou les boutons de partage ? Il faut pourtant que ce soit une décision réfléchie car jusqu’ici, cette décision était de fait laissée à l’intégrateur et au navigateur …

Côté technique

Si votre business model vous permet de vous passer des publicités invasives, ce qui est le cas des sites de e-commerce par exemple, alors je ne saurais trop vous recommander la bonne vieille technique de l’inclusion en iframe. Cela gomme les inconvénients de document.write(). L’attribut sandbox vous permet (depuis IE9) d’accorder aux tiers d’accéder à votre page, vos cookies ou le droit d’ouvrir une popup.
<iframe sandbox="allow-scripts" src="carre_pub.html" /> suffit pour les publicités classiques : il autorise JavaScript, mais la sous-page ne peut rien faire sur la page principale. Si vous avez besoin de communiquer, l’API postMessage est là pour ça !

Pour aller plus loin, mais je ne l’ai encore jamais vu en production, il y a le standard Content Security Policy (à partir de Edge) qui permet entre autres de limiter les pouvoirs donnés aux tiers inclus directement en JavaScript. Pour une transition en douceur, vous pouvez passer par une phase d’observation des erreurs côté client (report-uri). Maintenant on ne va pas se mentir : la vraie difficulté, c’est de faire admettre que l’on veut limiter le pouvoir des tiers, pas de les en empêcher !

Conclusion

Les tiers posent leurs lots de problèmes mais ils ont pratiquement tous une solution technique, au contraire des publicités. Du moment que l’on fait attention au moment de l’intégration et que l’on surveille les régressions de performance, on évite la plupart des écueils. Si vous avez plus de quelques services externes et qu’ils peuvent mettre en péril votre business, mettre en place une solution de monitoring dédiée est à envisager rapidement.

Tout site sortant aujourd’hui doit avoir été pensé avec des contraintes mobiles, et utiliser des techniques d’amélioration progressive pour délivrer rapidement les fonctionnalités sur toutes plateformes.

En attendant cette conclusion, nous commencerons par essayer de connaître notre utilisateur, puis nous verrons les tactiques et stratégies propres au mobile.

Où est le problème ?

La 4G a débarqué, des mobiles à 8 processeurs se vendent, et la plupart des gens utilisent leur mobile depuis chez eux : en Wifi ! À priori le métier de spécialiste performance web serait donc mort et vous me trouverez en train de parler HTML5 à mes chèvres dans le Larzac, merci au revoir. À moins que…

L’utilisation

La « situation de mobilité » est-elle un mythe ? L’expérience et une étude Googlemontrent clairement que les ¾ des gens utilisent majoritairement leur mobile depuis le confort de leur canapé / lit / lunette, derrière le wifi familial. 15% de ces mêmes Français ont même la fibre.

Le temps passé dans une situation confortable est majoritaire mais cela est justement dû à la réalité de la situation de mobilité : cela doit être très rapide. Dans un magasin, les gens vérifient les prix des concurrents sur le Web : si votre page ne s’affiche pas en plus de quelques secondes, vous avez perdu la guerre des prix dès la première bataille (afficher le prix) ! Dans la rue, l’utilisateur va vouloir connaître les horaires de cinéma ou les restaurants du coin : si c’est votre coeur de métier vous n’aurez toutes vos chances qu’en affichant rapidement l’information demandée. Dans les situations d’attente, les gens dégainent les téléphones pour consulter réseaux sociaux et mails : si votre page a la chance d’être dans leur fil d’information, il va falloir afficher la promesse très rapidement (un article sur les félins à travers les âges, une vidéo de chats, le lolcat du jour…). Enfin la préparation d’achat se fait fréquemment sur mobile (plus discret dans l’open space, à portée de main lors des pauses clope voire au feu rouge), même si la finalisation de la commande se fait encore majoritairement sur l’ordinateur du foyer voire sur tablette.

Tout cela ne compte que pour quelques secondes dans les statistiques mais les utilisateurs se souviendront de votre marque de manière très positive si vous avez résolu leur problème rapidement.

La connexion

Les données de cette année montrent clairement une amélioration des débits 3G (6 Mb/s en moyenne selon Akamai) et la 4G à la française envoie du poney au galop (21-32 Mb/s constatés selon Degrouptest, pointes de 34 Mb/s selon Akamai).

Mais si vous êtes utilisateur régulier du mobile, vous devinez la vérité derrière ces excellentes moyennes : même avec une puce et un abonnement 4G vous ne chargez parfois pas du tout les pages et vous esquissez un sourire triomphant lorsqu’un site web se charge aussi bien qu’au bureau. C’est parce que l’ennemi numéro 1 du chargement de page web reste la latence réseau, et même sur une 4G de bonne qualité les latences constatés par Degrouptest sont entre 50 et 100 ms.

Concrètement :

• ligne du haut : une 4G de cadre parisien avec 20 Mb/s de débit mais 200 ms de latence (les murs de Paris sont épais),
• ligne du bas : l’ADSL de la mamie du Cantal avec 2 Mb/s et 20 ms de latence (oui son DSLAM est proche).

La mamie du Cantal gagne
(et avec un ping pareil, elle frag aussi de l’ado à tout va).

L’affichage via la connexion à 2 Mb/s commence 1 seconde plus tôt, le formulaire est utilisable 2 secondes plus tôt et le site au complet se charge 5 secondes plus vite.

Ajoutez à cela que les réseaux 3G des grandes villes sont saturées, et qu’en fonction de l’endroit, de l’heure de la journée, du jour de la semaine et de la position de votre doigt sur le mobile, les performances ne sont pas du tout les mêmes. Dans certains cas pas un octet ne passe.

Tout ça pour dire que les grands principes de la limitation du nombre de requêtes d’abord, puis du poids du contenu restent valables.

L’utilisateur

Tout le monde n’investit pas dans un bidule avec 8 processeurs et 3 Go de RAM, par contre les utilisateurs mobiles sont clairement habitués à ce que les interfaces soient fluides et réactives, et même à ce qu’on leur affiche des données en l’absence de réseau. Ajoutez à cela le fait que l’on sert fréquemment des sites mobiles minimalistes et vous comprendrez que l’utilisateur a bien du mal à accepter que les sites qu’il consulte mettent du temps à apparaître, ou laggent lorsqu’il scrolle.

Du coup un tombereau d’études utilisateur ou d’analyse statistiques démontrent ce que l’on pressent déjà : le temps coûte cher.

Absolument tous les indicateurs marketing sont touchés :

• le taux de rebond (Etsy : ajouter 160Ko d’images = +12% de taux de rebond),
• le taux de clic (DoubleClick : supprimer 1 redirection = +12% de taux de clic),
• l’abandon pur et simple de la page (Radware : 60% d’abandon après 4 secondes de page blanche),
• l’abandon du processus d’achat (Wallmart : -50% de conversion par seconde),
• l’abandon du visionnage (Akamai : -6% de vidéo vue par seconde d’attente),
• la perception négative de la marque.

Le côté amusant de l’histoire : si vous surveillez vos taux de rebond sur mobile en vous disant « ça va encore, » dites-vous que les statistiques sont en dessous de la réalité puisque dans les cas des pages blanches, il est probable que la requête remontant sur le serveur qui comptabilise les hits ne soit jamais partie.

Nos sites !

Étant donné que les grands chefs regardent les sites sur des mobiles qui valent le prix de ma première voiture, via le wifi de la boite et qu’ils s’arrêtent à la homepage, forcément il y a un peu de laisser-aller sur les sites, y compris dédiés mobile. Le poids des sites dits dédiés mobile (mDot) augmente régulièrement. La bonne idée d’avoir un site mobile dépouillé et ergonomiquement efficace s’efface pour laisser la place aux mauvaises habitudes des sites desktop : on met tout sur la HomePage, et on rajoute un maximum d’information sur les pages intérieures.

Le RWD devient la norme pour les refontes graphiques, mais rarement le « mobile first » : on se retrouve donc avec des spécifications planifiant 5 breakpoints, devant afficher des images « retina » tout en gérant IE 6 (oui cette spécification existe vraiment). Le poids des sites en général a doublé en 3 ans et grâce au RWD on demande maintenant d’afficher des sites de 2 Mo et 100 requêtes sur mobile. Ça finirait par arriver si l’utilisateur était encore là pour le voir.

Sur ces même sites cross-device, votre département marketing a bien sûr opté pour la totale :

• de l’analytics (augmentation du nombre de requêtes),
• des publicités (poids, temps d’exécution, requêtes),
• de l’A/B Testing (retardement volontaire de l’affichage, temps d’exécution),
• des boutons sociaux (le moindre bouton G+ rajoute 100 Ko et des dizaines de requêtes)

Et les tendances webdesign du moment ne sont plus aux coins arrondis qu’on aurait pu régler en CSS3 en pouffant, mais aux polices de caractère (blocage temporaire du rendu, texte invisible, poids), aux « hero images » (l’image principale en 1200×800, retina-ready, cordialement) ou pire aux slideshows (pourtant une mauvaise idée) qui peuvent charger de grosses images invisibles.

Veuillez patienter, un opérateur va prendre votre appel

L’arsenal technique

Le problème est donc bien réel et s’inscrit dans la durée : les utilisateurs seront de plus en plus exigeants, les sites de plus en plus gourmands, et la latence des réseaux mobiles ne fera pas de grands progrès. Ce qui tombe bien c’est qu’on peut y faire quelque chose.

Le chemin critique

D’accord le chemin critique est connu depuis 2006, désolé de redire les choses mais sur mobile il ne faut surtout pas se rater sur les bases. Prenons un cas un peu extrême (iOS < 8, grosse latence, débit correct).

La fameuse angoisse de la page blanche (1 case = 1 seconde)

Pourquoi 9 secondes avant le premier pixel, et 10 avant de voir quelque chose d’utile ? Regardons l’action au ralenti, avec la trace réseau suivante.

Le trait vert est le premier Graal.

Vous pouvez considérer que tout ce qui est à gauche de la ligne verticale verte (l’affichage du premier pixel) est sur le chemin critique. Un effort d’optimisation est déjà en place car les CSS sont déjà groupés et les JavaScript sont chargés de manière asynchrone. Sauf que c’est à cause de cette dernière optimisation que le site est ralenti : ce qui marche sur navigateur de bureau n’est pas forcément vrai sur mobile.

Déplacer les JavaScript en bas de page aurait aussi été une mauvaise idée, grâce à notre ami Safari iOS qui refuse d’afficher quoi que ce soit tant que ces fichiers ne sont pas là. Ici comme sur la plupart des sites, on gagnerait plusieurs secondes en chargeant de manière classique les fichiers JS agglomérés, en haut de page.

Pour résumer :

• testez sur les vraies plate-formes avant d’appliquer des recettes qui marchent ailleurs.
• choisissez la bonne stratégie de chargement des JS : de manière classique en haut de page, ça marche souvent très bien
• les recettes classiques doivent être appliquées : groupement en 6 requêtes maximum des HTML / CSS / JS
• minification et gzip des ressources de type texte

La police

Les fonts sont la grosse tendance 2013 et sont maintenant présentes sur la moitié des sites. C’est joli tout plein mais ça retarde encore le moment où l’utilisateur peut accéder au contenu. En fait il y a 3 états possibles pour l’affichage de votre texte.

Les phases possibles pour un chargement de police

Phase 1 : pas de bras, pas de chocolat, le texte est là mais masqué. Un peu dommage pour un site essentiellement basé sur le contenu textuel.

Phase 2 : le navigateur en a marre et vous sauve la mise en affichant le texte. Mal stylé mais fonctionnel.

Phase 3 : tout va bien, le site est quasiment comme sur la maquette. On espère que l’utilisateur regarde encore.

Savoir coder

L’art ancestral de l’amélioration progressive doit aussi s’appliquer aux polices : la phase 2 n’existe que si vous avez bien pensé à préciser une police système de fallback. Dans le cas contraire l’utilisateur regardera plus longtemps le site sans rien pouvoir y lire.

Pour raccourcir voire éliminer la phase sans tete lisible, il s’agit de faire un travail approfondi de coopération intégrateur / designer : 1 ou 2 polices maximum, de moins de 40Ko, testées sur toutes les plate-formes (mention spéciale à Chrome sur XP)

Ensuite vient le travail d’optimisation :

• la font critique doit avoir sa place dans vos 6 premières requêtes.
• chargement asynchrone des polices secondaires (variantes, titres invisibles, police d’icônes…).

Il y a des techniques plus avancées permettant de toujours afficher du texte même si ça n’est pas la font finale, ce qui ne plaît pas toujours. Vous pouvez également utiliser les data:uri et un encodage base64 de votre police directement dans le CSS, mais vous l’alourdissez du poids de la police.

Testez.

Se méfier des autres

Je vois encore des développeurs inclure des scripts depuis des serveurs qui ne leur appartiennent pas. Il s’agit le plus souvent d’une version plus ou moins à jour de jQuery ou de HTML5 shim. Les bénéfices sont nuls, et le risque énorme. Vous pensiez sérieusement que les serveurs des grands de ce monde sont disponibles 100% du temps ? Ou qu’ils répondent toujours plus vite que vos propres serveurs ?

Non.

SPOF ? pouf.

Sur ces graphes, on voit les temps d’affichage de sites majeurs (ligne du haut) augmenter de 20 secondes pendant le temps où les serveurs Facebook sont moins disponibles. Pour faire le point des dangers page par page, je vous conseille d’utiliser SPOF-O-Matic.

Sur mobile la résolution du nouveau nom de domaine est particulièrement pénible à cause de la latence. Les stratégies sont relativement simples, en fonction de la nature de la ressource :

• widget / bouton : utiliser la version asynchrone pour ne pas dépendre des autres,
• widget / bouton : mieux, une version statique vous évite 100-200Ko et des temps d’exécution énormes,
• JavaScript ou CSS tiers : rapatriez le script bien au chaud chez vous, groupez-le avec les autres si il est critique
• polices : rapatriement sur vos serveurs, quitte à payer une licence

Publicités, trackers et autres A/B testing

Ils requièrent tous d’être en haut de page pour être exécutés en premier et sont massivement déployés sur les sites même dédiés mobiles. Le département marketing moderne se doit de posséder au moins un exemplaire de chaque catégorie.

« J’ai dépassé mon objectif de 42 régies pub sur la home, et toi ?
— Je viens de découvrir 4 fournisseurs d’A/B testing, ça part en prod demain »

Les solutions techniques non bloquantes sont à négocier d’abord en interne pour faire prendre conscience du problème, puis auprès des fournisseurs, de moins en moins réfractaires. On arrive fréquemment à mettre les publicités dans des iframes et les scripts de tracking en asynchrone. Pour l’A/B testing ou certaines zones de publicité vitales, une bonne option, techniquement complexe, consiste à rapatrier en local, de préférence de manière automatisée, le code JS du prestataire, puis à l’inclure comme le reste des JS critiques en haut de page.

Les 3 caches

C’est comme les 3 coquillages : on peut faire sans, mais les gens du futur se moqueront. Partant du principe qu’il n’y a pas plus rapide qu’une requête qu’on ne fait pas, il convient de maîtriser rapidement les 3 techniques suivantes sur mobile.

Le cache HTTP

Depuis toujours la recette est simple :

• mettre des temps de cache très longs sur toutes les ressources statiques (plus d’1 mois),
• en cas de mise en production d’une nouvelle version, la mise à jour des caches clients se fait par le changement des URLs pointant sur les statiques.

Point.

Sur navigateurs de bureau, on pourrait s’arrêter là mais sur mobile le cache HTTPpeut se révéler très volatile, voire capricieux. Si l’OS estime qu’il a besoin de mémoire, il peut vider le cache du navigateur. C’est la raison pour laquelle certains sites ont développé leur propre système de mise en cache, en se basant sur localStorage.

DOM Storage

localStorage est un système simplissime de stockage de clé / valeur, de 5Mominimum. Pour limiter les accès au serveur, stockez-y des informations aussi simples qu’un historique de navigation ou lourdes et complexes, comme une liste de toutes les marques automobile et des modèles. L’utilisation en est tellement facile que c’en est ennuyeux.

Du coup certains en abusent.

Tiens, du CSS dans mon localStorage

Certains sites stockent carrément du HTML, du CSS, du JavaScript, des images ou des fonts puis via un système classique de gestion de session évitent de renvoyer les ressources au client.

Application Cache (dit offline)

L’énorme avantage ergonomique d’une application native installée chez l’utilisateur, c’est qu’elle va s’ouvrir quand vous appuyez dessus, même si à ce moment-là vous transitez par le tunnel sous la manche. Imaginez que l’on puisse faire de même avec nos sites : il suffirait d’aller une seule fois sur une des pages pour rapatrier l’ensemble de l’interface, et toute la navigation se ferait en local. Les mises à jour du contenu ne se feraient que lorsque la connexion est rétablie et on ne dépendrait pas de la validation d’un store pour mettre à jour son application.

Figurez-vous que la technologie existe, et date même d’une époque lointaine où Apple ne pensait pas encore à l’app store et à Objective C pour écrire des applications mais bien au Web et ses langages . Faites-moi plaisir et enfourchez votre mobile pour aller sur l’URL suivante :

http://appcache.offline.technology/demo/

Une fois la page chargée complètement (scrollez en bas pour voir les logs), passez offline (mode avion), puis allez sur la 2de page nommée cache. Non seulement la page s’affiche comme si de rien n’était mais l’image du machin vert est également présente alors qu’elle ne peut pas être dans le cache HTTP classique.

Belle bête

Si vous utilisez Chrome, vous pouvez regarder sur chrome://appcache-internals/votre liste des sites utilisant cette technologie.

À ce stade de la compétition vous avez peut être déjà entendu dire beaucoup de malsur appCache. C’est effectivement le genre d’API qui demande du temps et de l’amour pour être bien comprise, mais elle apporte un énorme confort utilisateur et est très bien supportée sur mobile et même sur bureau. Elle est très adapté aux sites qui se comportent comme des applications (une seule page) mais il existe des techniques à base d’iframe pour partager ce super cache entre plusieurs pages d’un site plus classique.

Les images

Elles représentent fréquemment les deux tiers du poids des sites et ralentissent le chargement des ressources critiques.

Éviter de les charger

Captain Obvious a dit : c’est plus rapide sans image. C’est pas faux et il commence à y avoir pas mal de techniques permettant d’éviter des requêtes :

• CSS3 pour les dégradés, arrondis, rotations et opacités. Dommage que ça ne soit plus à la mode.
• Les caractères unicodes des polices fournies avec les OS : ►★✓ ⇨ (attention si vous visez également IE8 sur Windows XP)

Lorsque certaines images sont critiques pour votre interface, vous pouvez les embarquer directement dans le HTML ou le CSS. C’est la technique du data:uricouplé à l’encodage en base64. Oui ça a l’air sale mais uniquement si c’est mal fait.

L’image la plus importante à charger est celle indiquant justement qu’il y a chargement ! Pourquoi ne pas mettre également le logo ou une image de contenu réellement importante.

L’image d’attente arrive bien avant toutes les autres

Il ne faut pas abuser de la technique car elle alourdit le HTML et le CSS qui sont des ressource critiques, mais sur quelques petites images stratégiques cela fait patienter l’utilisateur.

Chargement à la demande

C’est à se demander pourquoi les navigateurs ne le font pas déjà d’eux-mêmes : l’idée est bêtement de ne pas charger les images qui ne sont pas visibles ! C’est radical pour les sites avec beaucoup d’images car cela libère la bande passante pour les ressources critiques et les images qui sont visibles. Voici un bon exemple de librairie, utilisé notamment sur lequipe.fr, bureau ou mobile. Naviguez dessus (c’est pour le travail) et scrollez très vite : vous verrez les images apparaître au fur et à mesure de votre progression dans la page.

Cette technique seule sauve des dauphins tous les jours.

Les images responsive

Comment servir le meilleur rapport poids / qualité à l’utilisateur mobile ?

Le standard

Votre plus grand problème concernant les images à délivrer sur mobile est de comprendre ce que vous voulez réellement en faire. Le problème est de définir le problème si vous voulez, en répondant à ces 4 questions :

• adaptation à la taille du viewport : veut on servir des petites images aux petits écrans ?
• écran haute densité de pixels (ok, retina©) : veut-on leur servir des images de très haute qualité ?
• art direction : pourquoi ne pas afficher des images au cadrage différent en fonction de la taille de l’écran ?
• format de l’image : veut-on servir du WebP à Chrome, du JPG XR à windows et du JPG 2000 à iOS ?

Pour compliquer l’affaire, sachez que :

• un écran retina peut avoir un petit viewport,
• deviner la bande passante de l’utilisateur est hautement hasardeux,
• vous ne connaissez pas la seule valeur qui compte : la taille physique de l’écran et la distance écran-œil.

Si vous êtes capable d’écrire un cahier des charges répondant à ces questions, alors vous pouvez vous pencher sur la réponse officielle et standard au problème : <picture>. Le temps que ça marche partout, la librairie JS officielle est picturefill 2.0.

La question est complexe, la réponse aussi.

La peinture étant un peu fraîche, il n’y a pour l’instant pas de retour sur la mise en production de cette technique. L’amélioration de performances devra donc se tester chez vous, en particulier sur les plateformes sans support.

Fait à la main, roulé sous les aisselles

Difficile pour une solution générique de faire mieux que du code écrit spécifiquement. À force j’utilise généralement chez mes clients un petit ensemble de techniques :

• JPG grande résolution, qualité 0 : pour une image unique à faire passer sur tous type d’écran, éditée à la main. Ça passe pour 90% des JPG. (à essayer sur un écran haute densité),
• images basse définition pour remplir l’espace, suivies du chargement de la haute définition. Le JPG progressif marchant mal sur iOS, c’est une manière d’avoir le même effet,
• lazy-loading pour la majorité des images, images embarquées pour les critiques,
• quand on peut, des formats vectoriels : SVG et polices d’icônes.

Combinez, testez et saupoudrez de JS pour obtenir de beaux effets. La maintenance n’est pas facile mais les résultats sont bons.

Interfaces fluides

Vous avez remarqué que les smartphones sont capables de jouer de manière fluide des jeux 3D mais ont des difficultés dès qu’il s’agit de retailler des divs ou de jouer avec du texte ? Au contraire de la 3D, il n’existe pas de puce dédiée à recalculer un DOM qui bouge ou l’écoulement des caractères. Il va donc falloir aider un peu nos pages.

Animations

Elles peuvent être fluides si on les travaille au corps. D’abord il y a un certain nombre de propriétés CSS qu’il vaut mieux ne pas animer comme top, left, width et height. On leur préférera les variations de transforms comme translateX() ou scale() qui ont la bonne idée d’être pris en charge directement au niveau du processeur graphique.

Vous pouvez essayer dans l’ordre :

• les transitions CSS, qui suffisent à la plupart des sites,
• les animations CSS, quipermettent des effets plus avancés
• enfin si JS doit tout piloter (un jeu par exemple), utilisez requestAnimationFrame, arrêtez jQuery animate et préférez des librairies spécialisées comme D3.js, GSAP ou TweenJS qui génèrent du CSS3.

CSS 3 avec modération

Remplacer les images de décoration par CSS c’était une bonne idée jusqu’à ce que vous réalisiez que le scroll lag sérieusement depuis que vous avez rajouté une ombre portée sur toute la hauteur de votre liste. De fait, tous les effets d’ombre, de transparence et de coins arrondis sont calculés en continu et cela peut coûter cher.

Une seule règle : tester, et sur de vrais mobiles bien sûr.

Calculs

On ne calcule pas tous les jours une suite de Fibonacci mais si ça vous arrive, utilisez les Web Workers. Sur les mobiles modernes ça vous donne accès à un second processeur pour exécuter du JavaScript. Sur les autres, la bonne veille technique du setTimeout(0) reste valable pour exécuter des boucles lourdes sans bloquer l’interface. Devinez qui vous a écrit un script pour ça ?

Testez !

Les derniers navigateurs mobiles acceptent enfin le déboguage à distance ! Cela signifie que vous allez pouvoir utiliser le profiler que vous connaissez sur de vrais téléphones et débusquer les endroits qui font ramer votre interface.

Oh la belle verte : c’est mon CSS qui est gourmand

Pour les anciens OS comme Android 2.3, cela reste la devinette, rassurez vous.

Impliquer, mesurer, surveiller

On ne peut pas résoudre le problème qu’on ne voit pas. Avant de commencer tout projet de performance, il faut définir ce que doit être la performance, prendre un point de départ, choisir ses métriques, et surveiller automatiquement les performances dans le temps.

Sinon le projet performance s’arrêtera après la mise en prod des premières améliorations de performance.

Il fut un temps où il était possible d’avoir une équipe Web composée d’une seule personne : référencement, accessibilité, code, design, administration système, c’était fun. Mais aujourd’hui, à toutes vos compétences techniques il faut maintenant rajouter une grosse capacité à comprendre pourquoi l’on code et comment dialoguer avec le reste de la boite.

Donc par pitié, ne partez pas en croisade solitaire contre les lenteurs de votre site, au risque que personne dans la boîte ne s’en aperçoive. Il faut d’abord sensibiliser et évangéliser sur le coût du manque de performance pour la société et l’image du produit. Toute l’introduction de cet article est là pour cela.

Une fois que vous avez l’oreille des décideurs, faites écrire dans ce qui se rapproche le plus d’une spécification les objectifs de performance : en dessous de quels temps considère-t-on qu’il faut agir ? Vous pouvez par exemple prendre ces chiffres, relativement universels sans être trop ambitieux :

1. Pour 80% des utilisateurs
2. Premier rendu en moins de 2 secondes
3. Fonctionnalité principale en moins de 5 secondes
4. Navigation de page en page en moins de 2 secondes

Les utilisateurs et le premier rendu

Les deux premiers points demandent à déterminer l’équipement des utilisateurs :

• Quels navigateurs ?
• Quelle est la puissance des mobiles ?
• Quelle est la qualité de leur connexion ? (l’origine géographique peut suffire à la deviner)

Les seuls moments où on vous a dit que le site était lent, c’est lorsque vos collaborateurs ont essayé de l’utiliser sans le Wifi du bureau. Comme des vrais gens donc. Il faut reproduire ces conditions de manière systématique et certaine pour constater les dégâts et juger des progrès avec le temps.

Le temps de premier rendu est relativement facile à vérifier avec des outils comme WebPagetest.org. Ce qui est plus compliqué c’est de paramétrer WebPagetest avec une simulation de connexion qui soit réaliste par rapport à vos utilisateurs. Comme ce n’est pas le cas de Webpagetest.org par défaut, je vous donne mes paramètres beaucoup plus représentatifs de la France.

Des paramètres de connexion plus réalistes.

WebPagetest s’installe également en interne, et peut piloter des mobiles.

La fonctionnalité principale

Là ça se complique : comment déterminer le temps d’accès à la fonctionnalité principale ? Aucun outil ne peut faire cela automatiquement pour vous car seul vous connaissez bien votre interface (prends ça Skynet). Par contre vous pouvez collecter automatiquement des temps en JavaScript et vous les envoyer dans l’outil de tracking qui vous sied (G. Analytics peut suffire au début).

Si vous êtes un site de news ou à contenu visuel, trackez la fin de téléchargement de la première image visible utile par exemple (tiens, voici du code qui peut vous y aider). Si votre fonctionnalité principale dépend de JavaScript (vidéo, moteurs de recherche complexes, application…), il est encore plus facile de minuter le moment où le contenu devient interactif.

La navigation interne

Le dernier point consiste à ne pas décevoir l’utilisateur après la première page, que ce soit la vitesse de chargement des pages suivantes ou la fluidité de l’interface.

Là vous pouvez surveiller les taux de mise en cache client (utilisation avancée de WebPagetest Monitor) et simuler des navigations dans vos tests de performance.

Attention chérie ça va ramer

Il n’y a pas de moyen facile et automatique de surveiller que l’interface elle-même est fluide sur mobile : contentez-vous d’une vérification systématique et digitale.

Stratégies de chargement

Il faut jouer avec la perception utilisateur et afficher quelque chose d’utile le plus rapidement possible. Cela demande à s’asseoir autour d’un café avec les autres équipes et à écrire la liste des priorités d’une page. Charge à vous de traduire cela en code pour régler l’ordre dans lequel les ressources vont être chargées par le navigateur.

Prenons 2 exemples de sites qui ont fait ce travail de priorité des requêtes.

Home Google

La fonctionnalité principale est évidemment l’affichage du champ texte. Mais les fonctionnalités secondaires sont légion : autocomplete sur ce champ, l’obligatoire intégration Google+, le menu, la suggestion de géolocalisation et même une bannière d’auto-promotion.

Ils ont de l’avenir

Google n’attend pas : il embarque un CSS minimaliste et suffisant dans le HTML, le HTML ne contient que le champ et des éléments pour définir la structure de la page. En 1 requête et 22Ko, soit l’équivalent de 2 allers-retours réseau, la fonctionnalité principale est déjà utilisable. Ensuite arrivent plus de 200Ko de ressources diverses pour afficher et rendre fonctionnel le reste de la page.

Home avec carrousel massif

Cette homepage était principalement vue depuis la Chine, il a donc fallu la calibrer pour des petits débits / grosses latences : elle était déjà optimisée pour le mobile. Par contre il fallait également afficher dans un carrousel plusieurs images de haute qualité de 1200 pixels de large.

Le carrousel classique

Du point de vue du réseau, charger plusieurs ressources en parallèle est généralement vu comme une bonne idée. Sauf lorsque le débit est ténu et les ressource trop grosses comme c’est le cas ici. Le chargement de plusieurs images en simultané ralentissait le chargement des ressources du chemin critique.

Il a donc fallu prioriser : logo, texte, et image principale d’abord.

Les fonctionnalités secondaires sont les icônes, un moteur de recherche (non visible ici) les autres images du carrousel et des images bien plus bas.

Adieu donc la police, utilisation de data:uri pour embarquer le logo en base64, inclusion en <img src> traditionnel de la première image du carrousel (et seulement elle) et on développe un petit script pour aller chercher de manière asynchrone les photos suivantes avant de vraiment démarrer le carrousel.

Conclusion : Mobile first

Ça n’est pas du lâcher de buzzword gratuit mais bien une adaptation à la manière dont nos utilisateurs utilisent nos sites, qu’ils soient en situation de mobilité, dans un pays lointain ou qu’ils fassent partie des 20% de français avec moins de 2Mb/s.

Le mobile first est l’héritier de la pensée « amélioration progressive » : délivrons très rapidement la promesse initiale, chargeons les fonctionnalité supplémentaires après et en fonction des capacités du client. Cela oblige à se poser la vraie question : quelles sont les priorités de chaque page ?

Cela s’intègre parfaitement avec un processus de conception moderne où designer et intégrateur web passent pas mal de temps l’un à côté de l’autre pour fignoler les maquettes sur les mobiles.

Nous avons évoqué une palanquée de techniques : certaines sont connues depuis bientôt 10 ans, beaucoup émergent et certaines sont devenues dangereuses. Toutes répondent à une situation particulière donc c’est à vous de tester ce qui marche ou pas, page à page.

Le processus de travail est presque aussi important que les techniques individuelles : la communication et l’effort de groupe sont vitaux pour maintenir la qualité à travers le temps. Sans monitoring ou automatisation des déploiements cela va rester amateur et pénible. Sans soutien hiérarchique du client (interne, externe, hiérarchique, bref celui qui vous paye) vous n’irez pas bien loin seul. Ou pire vous serez frustré par ce métier pourtant formidable qui est le nôtre.

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 = new 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.